Este artículo lo escribí con Guillermo e Ignacio, compañeros en Telefónica I+D, sobre el trabajo que realizamos en el diseño e implementación del servidor de notificaciones PUSH para Firefox OS.
El artículo original en La Cofa
Autores: Fernando Rodríguez Sela, Guillermo Lopez Leal, Ignacio Eliseo Barandalla Torregrosa.
Introducción
Hoy en día las aplicaciones móviles recuperan información de múltiples sitios y de manera asíncrona. Los desarrolladores tienen dos caminos para recuperar esta información:
- Polling: Periódicamente solicitar la información al servidor.
- Push: El servidor envía la información al cliente cuando la información requerida está disponible.
El primer método esta totalmente desaconsejado debido a la gran cantidad de conexiones que se realizan al servidor sin necesidad, ya que la información no está disponible y se pierde tiempo y recursos.
Es por ello que los métodos de recuperación de información de tipo PUSH son ampliamente utilizados, sin embargo el cómo funcionan actualmente las plataformas PUSH hacen un uso indebido de la radio móvil consumiendo gran cantidad de batería y recursos del usuario.
En este artículo se pretende explicar cómo se gestiona este tipo de mensajería en la actualidad, los problemas que tienen las actuales soluciones y finalmente cómo Telefónica Digital, dentro del marco del desarrollo del sistema operativo Firefox OS, ha diseñado una nueva solución más amigable con la red y con un bajo consumo de batería en los terminales móviles.
Estado del arte
Históricamente las operadoras móviles ofrecían (y ofrecen) mecanismos REALES de notificaciones PUSH, también conocidos como WAP PUSH. La tecnología WAP PUSH permite “despertar” las aplicaciones cuando se requiere alguna acción de las mismas por parte del lado servidor (sin interacción por parte del usuario). El envío de mensajes WAP PUSH se realiza en el dominio de circuitos, el mismo utilizado para la voz y los mensajes cortos SMS, y es por ello que el usuario no necesita establecer una conexión de datos para que este tipo de mensajes funcione correctamente.
La solución de WAP PUSH funciona muy bien cuando el usuario se encuentra registrado en la red móvil, pero si se encuentra sin cobertura y conectado a Internet por WiFi no puede recibir este tipo de mensajes y si a esto le sumamos que los mensajes PUSH conllevan un coste económico (básicamente se trata de un mensaje corto SMS) ha provocado que los grandes sistemas operativos para teléfonos inteligentes (iOS de Apple y Android de Google) hayan implementado una solución paralela que funcionase independientemente de la red móvil a la que pertenece el usuario y que pueda funcionar sin problemas cuando se encuentran utilizando redes WiFi.
Problemas de las soluciones actuales
Estas soluciones alternativas se basan en un servidor público accesible desde Internet mediante el cual se canalizan toda la mensajería PUSH para los terminales móviles y actúan de intermediario entre las plataformas de las aplicaciones y los terminales móviles.
Estas nuevas plataformas de mensajería PUSH tienen una importante barrera que superar ya que los terminales móviles suelen encontrarse en redes privadas (no accesibles desde Internet) y cuya comunicación es gestionada a través de servidores NAT y firewalls que impiden el acceso directo al teléfono desde el servidor, debido a esto, los sistemas operativos abren una conexión permanente (no la cierran) con estos servidores propietarios y utilizando este canal de comunicación reciben las notificaciones PUSH cuando los servidores de terceros se la envían a la plataforma de mensajería.
Tanto Apple como Google han utilizado esta solución alternativa que obliga al teléfono a mantener una conexión abierta de forma permanente con el servidor y para evitar que esta conexión sea cerrada, ya sea por los propios temporizadores de TCP como los temporizadores de los servidores NAT que tienen que atravesar para llegar al servidor, se envían pequeños paquetes de datos, conocidos como keep-alive, que no contienen nada de valor y sólo sirven para indicar que algún dato está atravesando la conexión.
Esta solución tiene varios problemas:
- El tener que mantener conexiones abiertas en los routers intermedios reducen notablemente el rendimiento de estos provocando grandes problemas de escalabilidad en las redes móviles, piense que España podemos estar hablando de unos 15+ millones de teléfonos inteligentes (smartphones) conectados a Internet.
- Tormentas de señalización: Las redes celulares utilizan gran cantidad de mensajes de señalización para poder gestionar la ubicación del terminal, su estado, establecer nuevas comunicaciones,… Cada vez que se envía un paquete de datos, se generan una serie de mensajes de señalización. La gran cantidad de terminales móviles avanzados que se encuentran hoy en día en nuestras redes producen un efecto de sobrecarga en la señalización que deteriora la calidad de servicio ofrecida por las operadoras móviles.
- Por otro lado, estas soluciones, que a primera vista son válidas en redes “tradicionales”, ya sean cableadas como redes WiFi domésticas, no son válidas en un entorno de red móvil celular, ya que el funcionamiento de los MODEM radio que llevan los teléfonos están diseñados para bajar su consumo energético cuando no tienen nada que transmitir, sin embargo, estas soluciones PUSH usadas por los sistemas operativos más expandidos, tienen la obligación de enviar mensajes de keep-alive y por tanto evitan que el teléfono pueda alcanzar este estado de reposo, o bajo consumo energético.
El efecto co-lateral de estas soluciones es que las baterías de los terminales son consumidas a una gran velocidad para realizar tareas realmente redundantes (enviar pequeños mensajes para evitar que sus conexiones sean cerradas).
Estos problemas se ven aún más empeorados cuando vemos que muchas aplicaciones (populares todas ellas) hacen sus propias conexiones sin utilizar las ofrecidas por los sistemas operativos con lo que están multiplicando los problemas por cada aplicación.
¿Qué sucede en la red móvil?
Como comentamos anteriormente, las redes móviles funcionan de forma distinta a cómo se desenvuelve, por ejemplo, una red WiFi y el diseñar este tipo de soluciones para ser utilizadas en una red celular sin considerar primero cómo funciona dicha red, nos lleva a los problemas con los que nos enfrentamos hoy.
Para entender bien el problema, debemos tener en cuenta los distintos estados en los que puede estar el modem radio del terminal:
En la especificación de la 3GPP TS 23.060, podemos ver todo lo relacionado con los estados de la capa GMM (GPRS Mobility Management) correspondiente al dominio de conmutación de paquetes en terminales móviles. En la especificación 3GPP TS 25.331 se puede consultar la información relativa a la capa RRC (Radio Resource Control) donde se definen los estados a nivel radio.
Juntando los estados radio y GPRS podemos saber en que estado está el terminal.
NOTA: Por simplificar, en la siguiente tabla consideramos que no hay actividad en el dominio de circuitos, esto es, no hay llamadas de voz:
|
GMM |
RRC |
|||
| Estado 2G | Estado 3G |
3G |
Descripción del estado | |
| READY | PMM-CONNECTED | Cell_DCH | El teléfono está transmitiendo o recibiendo datos usando un canal dedicado o un canal compartido HSPA.Los temporizadores de Cell_DCH son muy cortos, de manera que si no hay nada que transmitir o no estamos recibiendo datos durante los últimos segundos, el temporizador nos llevará a Cell_FACH.Este temporizador se conoce como T1 y puede variar entre 5 y 20 segundos. | |
| Cell_FACH | El teléfono ha estado transmitiendo o recibiendo datos hace unos segundos y debido a la inactividad (> T1) se ha movido a del estado Cell_DCH al estado Cell_FACH.Si la inactividad continua durante T2 segundos, RRM ordenará al teléfono a moverse al estado Cell_PCH, URA_PCH o Radio Idle.También es posible que el teléfono se encuentre transmitiendo o recibiendo pequeñas cantidades de datos, como pings, keep-alives, actualizaciones de celda…
Normalmente el temporizador T2 es de alrededor de 30 segundos. |
|||
| Cell_PCH o URA_PCH | El teléfono ha estado en Cell_FACH hace unos segundos y debido a su inactividad (superior a T2) el RRM lo ha movido de Cell_FACH a Cell_PCH o URA_PCH.Sin embargo, la conexión de señalización permanece aún disponible a pesar de que no se van a enviar datos ahora.Se mantiene establecida de forma que si en cualquier momento necesita ser utilizada no se tenga que restablecer nuevamente. | |||
| STANDBY | PMM-IDLE | Cell_PCH o URA_PCH | El teléfono no está transmitiendo datos y la conexión de señalización se ha borrado, de todas formas, el contexto PDP continúa activo, por tanto dispone de una dirección IP válida.Por esta razón es uno de los estados más interesantes dónde mantener un teléfono móvil el mayor tiempo posible ya que el consumo de batería es reducido pero su dirección IP se mantiene disponible para poder recibir información de la red.En este estado no se gastan recursos: ni de red, ni batería, tráfico… Aún así puede transmitir o recibir información en cualquier momento.
Tan pronto como el enlace de datos necesite ser establecido, bien por el teléfono o bien por un servidor de la red, éste puede ser reestablecido cambiando el estado de la radio de Cell_PCH o URA_PCH a Cell_FACH o Cell_DCH. Este cambio lleva menos de medio segundo y consume muy poca señalización. |
|
| RRC IDLE | Este caso es el mismo que el anterior con la salvedad que la radio está en modo Idle.Cuando el teléfono está en Cell_PCH o URA_PCH sin ninguna actividad durante más del tiempo establecido por T3, El RRM moverá a la radio de *_PCH a Idle.Reestablecer el enlace radio desde este estado puede llevar más de 2 segundos y muchísima señalización. | |||
| IDLE | PMM-DETACHED | RRC IDLE | El teléfono no está transmitiendo datos y no hay establecida ninguna conexión de señalización y tampoco tiene abierto ningún contexto PDP.En este estado, el terminal no dispone de dirección IP.Si un teléfono tiene un contexto PDP, probablemente sea automáticamente cerrado después de unas 24 horas de no recibir ni transmitir información. | |
El consumo de batería en cada uno de estos estados es el que sigue:
- RRC Idle – 1 unidad relativa de consumo de batería.
- Cell_PCH – menos de 2 unidades relativas
- URA_PCH – menor que Cell_PCH en escenarios de movilidad e igual en escenarios dónde no hay movilidad
- Cell_FACH – 40 veces el consumo de IDLE.
- Cell_DCH – 100 veces el consumo de IDLE.
Como fácilmente se puede apreciar, las soluciones anteriormente comentadas y sus correspondientes mensajes de keep-alive evitan que el terminal pueda estar mucho tiempo en el estado IDLE de bajo consumo de batería.
La solución propuesta por Telefónica
Con todos estos problemas sobre la mesa y con la intención de hacer un sistema operativo con nuevas e innovadoras soluciones, Telefónica Digital en colaboración con Mozilla ha diseñado un nuevo sistema de notificaciones que evita el tener que mantener conexiones abiertas dentro de la red móvil.
Esta nueva solución, implementada y distribuida íntegramente con código abierto, define no sólo el cómo el servidor de notificaciones se debe comunicar con los terminales, sino también, los distintos APIs que se tienen que utilizar para comunicarse con el mismo.
Para solventar los problemas previamente mencionados, esta solución es capaz de mantener dos canales de comunicación con los terminales móviles, de manera que cuando estos se encuentran en una red no gestionada por la operadora, por ejemplo, en la WiFi doméstica del usuario, se mantiene la conexión abierta, al igual que se hace en las otras soluciones mencionadas, con el uso de WebSockets, sin embargo cuando el terminal se encuentra dentro de una red gestionada por la operadora, la conexión basada en WebSocket es cerrada por parte del servidor el cuál “despertará” al teléfono cuando éste tenga mensajes para él.
Para despertar el teléfono, la plataforma de notificaciones se basa en una solución simple a la par de elegante:
- Sabemos que en el momento que el terminal móvil establece una conexión de datos estableciendo un contexto PDP, su dirección IP (ya sea pública o privada) es mantenida por los servidores de la operadora (GGSN) y no por el terminal móvil, por lo que aunque este último entre en un modo de bajo consumo, su dirección IP no se pierde.
- Cuando el terminal se encuentra en IDLE pero con una conexión de datos establecida y la red tiene datos que enviarle (el GGSN ha recibido un paquete TCP o UDP para la IP del terminal) envía un mensaje de señalización conocido como PAGING utilizado para “despertar” al teléfono y sacarlo del modo IDLE. Este mensaje de PAGING es similar al utilizado por la red móvil para notificar al terminal que tiene que atender una llamada de circuitos (voz, SMS, …)
- Aprovechándonos de este modo de funcionamiento, la única pieza que nos faltaba para terminar el puzzle era poder enviar un mensaje directo al teléfono, pero al estar dentro de la red móvil (con direccionamiento privado) era necesario tener un servidor dentro de cada una de las redes móviles.
Pues bien, esta solución utiliza precisamente esto, un servidor de WakeUp dentro de la red móvil que enviará un mensaje UDP a la IP del teléfono. El teléfono al recibir este mensaje será “despertado” por la red y el teléfono procederá a conectarse al servidor de notificaciones utilizando la conexión basada en WebSocket para recuperar los mensajes pendientes.
Algunos ejemplos de aplicaciones actuales
Por razones obvias no podemos citar los nombres de las aplicaciones que os vamos a enseñar así como los modelos de terminales sobre los que se ha probado. Lo que si podemos decir es que se trata de aplicaciones muy populares, probablemente en su teléfono las tenga instaladas, y los terminales usados son también los más populares del mercado, con los sistemas operativos más usados en la actualidad.
Las siguientes gráficas podremos ver el consumo de datos que hacen estas aplicaciones cuando se encuentran en reposo, es decir, sin hacer nada en particular. Los colores indican distintos terminales.
Se puede observar que mientras que algunas aplicaciones hacen pequeños envíos puntuales, otras están transmitiendo de manera contínua.
Este estudio ha sido realizado por: Telefónica – NSN Smartphones lab
Como podemos observar, las aplicaciones intentan mantener su conexión mediante “pings” realizados durante intervalos relativamente estables de tiempo. Mientras que la primera gráfica muestra una aplicación que manda mensajes cada 10 minutos, la segunda y la última hace que se envíen mensajes prácticamente de forma continuada, haciendo que el teléfono esté siempre en el estado máximo de la red, gastando recursos para simplemente decir “sigo vivo”.
Así, con nuestra solución, estos “pings” regulares se eliminarían completamente, haciéndose sólo cuando una notificación es recibida por el teléfono, mejorando el uso de la red, bajando la señalización, y además haciendo que la batería de los dispositivos de los usuarios dure más debido a estar en estados más relajados de la red.