lunes, noviembre 07, 2005

FON. Un análisis


Desde hace semanas sigo el proceso de creación de esta compañía. La verdad es que admiro a Martín Varsavsky. Me fascina la forma en que una idea la puede convertir en algo real, esto no está al alcance de muchos. Apoyo el proyecto, me gusta, y me tienen a su disposición como ya le comenté a Martín.
La idea de compartir ancho de banda no es nueva ni mucho menos, lo que si es nueva es la orientación de este proyecto, FON lo hace desde un punto de vista empresarial. Esto es una empresa y como tal, el objetivo es ganar dinero, esto puede hacer del proyecto un éxito en mi opinión.
Quizá, no lo sé, el modelo de negocio no esté todavía muy claro, lo importante ahora es tener una red medio-gestionada con una cobertura decente, a partir de ese punto las cosas son fáciles, la clave es la cobertura y por tanto la movilización de la gente es ahora lo más vital. Las aplicaciones (las hay y muchas), vendrán después como bien han notificado recientemente, no hay que precipitarse. Dentro de esas aplicaciones está la voz, que es lógicamente un gran objetivo… ni más ni menos que rascar mercado a lo operadores móviles.
Sin embargo conseguir los objetivos expuestos va a ser una ardua tarea, lo intentaré exponer más adelante.
Este análisis tendrá los siguientes capítulos:

- FON. Su estructura.
- FON. Aspectos tecnológicos.
- FON. Servicios.

Lo de los servicos lo dejo para otro día, el tema tiene "injundia"

FON. Su estructura (para gente con algunos conocimientos técnicos).

FON basa su red en los accesos ADSL/Cable que la gente contrata Para tener una red hay que controlar los accesos a la misma de alguna manera, es por eso que FON parte con un único modelo de CPE el WRT54G de Linksys. ¿Y por qué este modelo y no otro?. La razón fundamental es que hay un proyecto GPL que ha desarrollado un puerto de Linux para la CPU de este cacharro. A todos lo efectos lo convertimos en una pequeña máquina Linux con todas sus capacidades que no son pocas:

- Linux es un router (kernel)
- Linux es un Access point wifi.
- Linux es un firewall (IPTables)
- Linux tiene capacidades avanzadas de routing: VLANs, QoS (quality of service), WFQ, WRED basadas en IPROUTE2 (tremendo desarrollo)
- Linux admite clientes radius (freeradius).
- Linux puede ser una PBX (Asterisk) o incluso una central telefónica (SIP Express Router)
- Una máquina Linux a día de hoy puede ser lo que alguien con creatividad quiera que sea…y además gratis.

Se puede observar que todo lo que necesita FON está desarrollado y solo hay que integrarlo y probarlo.
Los Linksys harán de AP con al menos 2 SSID uno para el uso del propietario de la línea y el otro dispuesto a ser compartido. Para que no se canibalicen uno a otro se gestiona el ancho de banda disponible haciendo uso de los controles de congestión que nos brinda Linux (IPROUTE2). Esto es algo parecido a las VLANs en los entornos wired, cada trama ethernet va marcada con una etiqueta con el objetivo de aislar segmentos de red en este caso wireless. La red wifi del propietario seguirá como siempre (autenticada o no, encriptada o no), sin embargo el SSID FON requerirá de autenticación vía radius.
En algún punto, conectado a Internet, FON tendrá un servidor radius (y quizá un LDAP) donde autenticará las peticiones de acceso a la red de FON y realizará el accounting oportuno. Depende como se facture a los “aliens” los sistemas serán más o menos complicados: si se factura por tiempo, por ejemplo, bonos de un día o una semana, es más sencillo que si se hace por cantidad de tráfico intercambiado.
Cada dispositivo móvil se asociará al AP Linksys que ofrezca mejor cobertura obteniendo del mismo la dirección IP (vía DHCP) que probablemente será privada (cuidado con esto para VoIP!). De cara a Internet el usuario aparecerá con la IP pública que tenga asignada la conexión ADSL/Cable.
Como podéis ver FON no es propietario más que de los sistemas de acceso y facturación, el resto de elementos son ajenos…gran cosa esto visto desde un punto de vista financiero, no tan bueno desde una perspectiva de ofrecer servicios de calidad.

FON. Aspectos tecnológicos.

Hasta ahora casi todo lo que he leído son parabienes del proyecto, sin embargo se enfrenta a numerosos problemas, alguno de ellos de difícil solución a día de hoy. No quiero que se tomen los siguientes puntos como un intento de menospreciar el proyecto, antes al contrario son retos que hay que afrontar. En muchos hay que hacerlo con transparencia (creo que en este sentido FON va bien orientado) y en otros delimitando bien el servicio, por ejemplo no haciendo una comparación directa con las redes de telefonía móvil ya que a día de hoy no se pueden comparar (y en esto si debería FON mejorar en mi opinión).

La tecnología Wifi no se diseñó para coberturas metropolitanas. Su utilización ha estado restringida a áreas pequeñas y controladas (campus, edificios…). Y es que la potencia de emisión es muy pequeña. Esto se transforma en que para dar una cobertura decente debemos de tener multitud de microceldas. La técnica habitual en planificación radio para lidiar con este tipo de problemas es emplear antenas direccionales allá donde tengamos una zona alargada que cubrir, sectoriales con determinado ángulo si así se requiere, de esta forma lo que hacemos es proyectar la potencia donde se necesite. Pero poca planificación radio va a tener la red de FON y menos con lo Linksys diseñados para dar una cobertura casera.
FON debe usar la fuerza bruta para sobrepasar esta problemática, es decir, tener tantos foneros que de alguna manera me llegue la señal de algún sitio.
Aún siendo muchos foneros los que se den de alta siendo realistas un porcentaje muy pequeño van a aportar valor a la red:

- Muchos estarán en zonas en absoluto interesantes
- Otros tantos estarán en pisos altos (interesante para sus vecinos, poco más)
- Algunos más, estando en pisos bajos y en zonas interesantes el PA lo tienen metido en una habitación interior y la señal apenas alcanza la calle.

En fin, del porcentaje total, ¿cuál va a ser interesante? 1%,5%, 10%....no sé.

La calidad de servicio para aplicaciones sensitivas al retardo (voz).
La tecnología wifi a día de hoy no está preparada para proporcionar QoS, si es cierto que hay fabricantes que lo han implementado como Cisco pero a día de hoy no hay un estandar que cubra esta materia (parece ser que 802.11e). Esto se complica con el hecho que las conexiones ADSL son no garantizadas en su mayor parte o en su totalidad.
Dar voz de calidad es aplicar QoS extremo a extremo, es decir, priorizar los paquetes rtp de voz desde el “wififon” hasta el destinatario de la llamada, este es el azaroso viaje de cada paquete:

1. Red wifi. Aquí deberá competir con el resto de los paquetes de datos, cuanto más grandes y numerosos sean estos (por ejemplo ftp), peor. Un problema añadido es la cobertura deficiente (esto nos puede ocurrir si nos movemos de donde teníamos buena cobertura), en estas condiciones los paquetes se pierden y es imposible una conversación.
2. Red ATM (ADSL). Un paquete que ha conseguido llegar al Linksys debe transitar ahora encapsulado en ATM. Las redes ATM están preparadas para dar calidades de servicio (cbr, vbr, vbr-rt, ubr son descriptores típicos en ATM). Los ADSL residenciales tienen configurado UBR que es una especie de “best effort”. Además lo hace en subida donde hay menos ancho de banda.
3. Redes IP. Lo normal e que el paquete que consiguió pasar la red ATM se enfrente ahora con el reto de pasar redes IP, primero la del operador que ofrece el ADSL y luego las necesarias para llegar al destino (Internet es una red de redes). En Internet no hay calidades de servicio.
4. Los puntos 1, 2 pero en sentido inverso.

Esto nos da un entorno para la voz bastante hostil y por tanto debe ser un servicio muy muy barato dado que no hay garantía en ningún aspecto.
La red GSM usa conmutación de circuitos para la voz, es por esto que el canal está garantizado mientras hablamos.

La seguridad.
Importante aspecto ya que el hecho de compartir abre una puerta de acceso a la LAN de los foneros. Como es de dominio público las tecnologías de encriptación estandarizadas por el 802.11 han sido dinamitadas ya hace tiempo es por tanto muy importante añadir componentes de seguridad adicionales. Se necesita una gestión de claves mejorada.

La movilidad para voz.
Importantísimo aspecto este. A día de hoy veo difícil que se pueda tener movilidad, con esto me refiero a poder cambiar de AP manteniendo una conversación.
El hecho de cambiar de AP implica cambiar de IP pública, esto hace que perdamos las sesiones que podamos tener establecidas. Para navegar no es tan importante pero para la voz es vital. A día de hoy hay técnicas para mantener una IP única, esto es lo que se conoce como “mobile IP”. Básicamente consiste en tirar un tunel desde un elemento centralizado hasta el terminal. El terminal dispone de 2 IPs una la que asigna el AP y que puede cambiar y otra la que se usa para el servicio, siendo esta fija (al menos durante la conversación). Si pasamos de un AP a otro se conmuta el túnel. Implementar esto es complicado y más sobre un entrono hostil como es Internet. Además, todo el tráfico de voz iría a para a un elemento centralizado lo cual no es en absoluto deseable.
A día de hoy existen redes wifi metro (full mesh) que además ofrecen roaming entre AP, la clave es no tener que cambiar de IP. Esto lo puedes hacer si controlas el backhaul (la red de nivel 2), en este entorno se puede hacer una asignación global de IP, sin necesidad de cambiar cuando cambiamos de AP. FON no puede hacerlo ya que son los proveedores ADSL quienes imponen la IP.
GSM y UMTS fueron diseñados para ofrecer movilidad.

Los CPE. Una barrera.
Homogeneizar los CPEs si se quiere hacer una red es la mayoría de las veces una obligación. Esto es lo que pasa con FON. Tradicionalmente esto se lo “come” el operador (es la estación base si lo comparamos con la telefonía móvil), este caso es distinto porque se pide al fonero que lo compre. Yo en el fondo pienso que es justo porque con esto va a disfrutar de Internet en muchos sitios si todo va bien. Sin embargo creo que es una barrera de entrada.
Además, el abanico de equipos está entre los que es posible actualizar a linux.

La gestión de claves.
Cuando se popularice FON tengo la impresión de que cientos de claves van a empezar a “rular” por Internet para conectarse “por la patilla”.
El modelo de negocio basado en “aliens” puede verse muy afectado. De hecho yo no lo veo no preguntéis por qué, no sabría dar una respuesta contundente.
Quizá lo vea más orientado a ceder la red a organismos e instituciones tipo ayuntamientos.

Service level Agreement (SLAs)
Bueno pues esta es una razón por la que no veo el negocio de los “aliens”. Quien paga tiene derecho a exigir. Poca respuesta se podrá dar a alguien en una red donde apenas se gestiona nada.

6 Comments:

Anonymous Alberto said...

Extraordinario análisis. Espero los comentarios acerca de los servicios.

2:54 p. m.  
Anonymous Luis said...

Perfecto.

4:33 p. m.  
Anonymous Herme Garcia said...

Muy buen análisis, se nota que llevas tiempo en esto.

En cuanto a la parte de los terminales móviles sobre Wifi, está todavía en los inicios, y cierto que Wifi no se diseñó pensando en telefonía móvil, pero los primeros early-adopters ya estan en el barco .. acuerdate de cuando los móviles pesaban 2 kilos y solo habia cobertura solamente en la Gran Vía y en la Castellana de Madrid

Tienen inconvenientes, pero cada vez menos

Un saludo

11:20 a. m.  
Anonymous Jorge said...

Coincido con el resto en cuanto a que tu análisis es muy bueno. Sólo un comentario en cuanto a las redes MESH:

Como dices correctamente, el Wi-Fi habitual no sé pensó para despliegues metropolitanos. Los APs tienen que cablearse a un switch lo que hece inviable (en coste, mantenimiento, despliegue,..) plantear una cobertura municipal...o si no que se lo digan a la gente de AFITEL con sus proyectos de Zamora Wireless...

En cuanto a las redes MESH, la gran diferencia es que la "mayoría de los nodos" se comunican entre ellos vía radio (actualmente estos protocolos son propietarios, por ejemplo el PWRP de TROPOS. El estándar 802.11s de las redes mesh está actualmente bastante parado debido a las luchas comerciales entre los fabricantes).

Entre un 10-20% de los nodos MESH (los llamados nodos GATEWAY)necesitan conectividad con el BACKHAUL.¿Cómo se consigue? Pues lo más cómodo es mediante radioenlaces pto a pto en 5Ghz; pero está conectividad también se puede lograr con fibra, cablemodem, ....

Con estas características, un despliegue de una red MESH en, por ejemplo 10 km2, es cuestión de una semana. Lo único que se necesita es colocar los nodos en las farolas y darles corriente.

Los servicios sobre infraestructura MESH son espectaculares; el roaming es limpio y transparente. Datos, video en streaming (cámaras) a 25fps. También podemos conectar a la infraestructura cualquier tipo de sensor, por ejemplo de ruido, calidad del agua,..., o más interesante aún, podemos conectar una red AMR(Automated Meter Reading) que pueden desplegar las utilities para hacer lecturas automatizadas de contadores de luz, gas, agua,...

Por último, en cuanto a los servicios de voz, las redes MESH son Multi-Hop, es decir que la conexión desde el cliente hasta que llega al nodo GATEWAY dará una serie de saltos a través de la malla. Estos saltos no son estáticos; la malla se configura dinámicamente lo que produce que la "latencia" y el retardo sea difícilmente predecible. Esto unido a que no tenemos aprobado aún el 802.11e (parece que a primeros de año tendremos buenas noticias) hace que podamos decir que la telefonía móvil Wi-Fi sobre redes MESH, hoy, funciona en un 70%.

Perdonad por el rollo que he soltado. La empresa NEOMEDIA (www.neomedia.es) está haciendo los primeros despliegues MESH en Europa (con TROPOS).

Si queréis más información el blog de Miguel Caballero es muy buena referencia: http://migcaballero.blogspot.com/

De todas formas HERME, no te preocupes porque esto es sólo cuestión de tiempo. Las preubas q hemos hecho con TROPOS son muy prometedoras. El año que viene tendremos muy buenas noticias para PC.

9:20 a. m.  
Blogger Antonio Higuera said...

Jorge, tienes toda la razón en que las redes mesh son las topologías mas adecuadas para despliegues metropolitanos. En un despliegue controlado se pueden hacer las cosas que comentas por dos razones:

- Puedes solapar coberturas para poder hacer handover (roaming).
- Puedes hacer asignaciones de direcciones IP permanentes.

Yo me refería al caso concreto de FON donde los GW (en principio todos los AP)nos van a imponer direcciones IP distintas ya que estamos en Internet y no controlamos el direccionamiento. Pasar de un AP a otro significa cambiar de IP y cambiar de IP significa caída de sesión (a no ser que se use mobile IP).

10:01 a. m.  
Blogger pablo said...

que profundo el estudio que has realizado!!! feliciatciones!!

4:55 a. m.  

Publicar un comentario

Links to this post:

Crear un enlace

<< Home