Los problemas de señalización en los smartphones
Autor: Ignacio Berberana y Francisco Javier Lorca
En el blog de noticias de Nokia Siemens Networks hay una entrada que nos ha resultado interesante. Se relata el caso de un operador europeo (no identificado) que decidió ofrecer terminales Blackberry sin un plan de datos asociado (básicamente dirigidos a usuarios que envían muchos mensajes cortos, para los que disponer de un teclado QWERTY puede resultar atractivo). El resultado inesperado del éxito de esta oferta fue un incremento desmesurado del tráfico de señalización que amenazaba incluso con colapsar la red. La raíz del problema está, al parecer, en el hecho de que los Blackberrys están programados para intentar establecer frecuentemente conexiones a la red de datos y actualizar así el correo. Estos intentos de establecimiento de conexión eran rechazados por la red, lo que generaba nuevos reintentos por parte del terminal, que volvían a ser rechazados, y así sucesivamente. Los problemas pudieron ser controlados con una serie de medidas tanto comerciales (ofrecer planes de datos de bajo coste a los usuarios de los terminales problemáticos) y técnicas (configurar los SGSNs para que ignoren la señalización de esos móviles). La solución definitiva, según NSN, es simple: nunca vender un Blackberry sin un plan de datos asociado.
En la misma página de NSN donde se referenciaba la noticia hay un documento muy interesante (disponible aquí) que explica los problemas de señalización que están ocasionando muchos smartphones.
La clave en muchos casos está en una funcionalidad estandarizada en 3GPP Release 8, llamada Fast Dormancy. Para explicar en qué consiste es necesario hacer un poco de historia desde los comienzos de las redes 3G. Al principio las redes se desplegaron pensando fundamentalmente en dispositivos de datos sobre portátiles (dongles), donde las limitaciones de batería no existen, y por ello en la práctica se implementaron únicamente tres estados RRC de los cinco previstos en el estándar: “Idle” (estado inactivo, en el que el terminal envía muy poca información a la red), “Cell_FACH” (para pequeños volúmenes de datos) y “Cell_DCH” (para elevados volúmenes de datos). El consumo de batería es máximo en Cell_DCH, algo menos en Cell_FACH y el mínimo posible en Idle. Cuando el terminal tiene que enviar/recibir un elevado volumen de información, pasa al estado Cell_DCH y, tras un período de inactividad, se le mueve al estado Cell_FACH, tras el cual pasado un tiempo vuelve de nuevo a Idle. En total para una transición completa de Idle -> Cell_DCH -> Cell_FACH -> Idle el tiempo transcurrido es de varios segundos (adicional al tiempo invertido en la comunicación), y el consumo de señalización en la red es bastante elevado (hasta 30 mensajes RRC). El consumo de batería asociado es alto también (debido a los estados Cell_DCH y Cell_FACH) pero esto no era un problema.
Con la llegada de los smartphones este esquema sí representaba un problema para la batería. Para reducirlo, el estándar contempla dos estados RRC adicionales llamados Cell_PCH y URA_PCH, en los cuales el consumo de batería es menor y también la señalización necesaria para los cambios de estado. Sin embargo estos estados han sido poco o nada implementados en la práctica (según NSN, sólo sus equipos de red los soportan desde el principio).
En su lugar, muchos fabricantes de smartphones hacen uso de una funcionalidad de Release 8 llamada Fast Dormancy, por la cual es el terminal el que acabada la comunicación decide desconectarse completamente de la red (pasar a Idle). Esto ahorra mucha batería, a costa de incrementar el consumo de señalización: cada vez que un smartphone se conecta a la red para pequeñas conexiones (actualizaciones de status en aplicaciones de presencia, mensajería, consultas a servidores de correo, etc.) se requiere un proceso completo de conexión/desconexión.
Desde mediados de 2010 el iPhone hace uso de una versión modificada de Fast Dormancy, en la que la conexión es liberada sólo cuando se apaga la pantalla. Pero otros fabricantes emplean tal cual esta solución que puede crear graves problemas de congestión en Nodos B y RNCs. Hay incluso un documento de la GSMA llamado Fast Dormancy Best Practices, que da idea de la importancia de este tema.
En la actualidad se ha estandarizado en 3GPP Release 8 la llamada “Network Controlled Fast Dormancy”, por la cual el terminal debe emplear el esquema Cell_PCH/URA_PCH en las redes que lo soportan, y Fast Dormancy en las que no.
La moraleja de todo esto es doble: por un lado, hay muchos elementos que influyen en la congestión y prestaciones de una red móvil, siendo a veces el tráfico de datos el menos importante. Y por otro, quizás haría falta “concienciar” a los desarrolladores de terminales y aplicaciones sobre la diferencia existente entre la conectividad móvil y la fija. Acostumbrados a estar “siempre conectados”, muchas aplicaciones no son conscientes de la carga que pueden suponer en una red móvil.
Extraído de La Cofa
Wow, ¡super interesante esta pequeña nota!
Sobretodo en lo que se relaciona al “mito del ancho de banda” que las operadoras usan para justificar sus altos precios. Según las compañías celulares, el ancho de banda disponible es tan limitado, y los costos de mantener sus redes tan altos, que por eso cobran tanto por velocidades tan bajas. Anuncian sus velocidades Mach3 de HSPA+ y al fin del día entregan GPRS.
Leyendo este tipo de notas, no puedo dejar de pensar en las mejora técnicas que se deben poder hacer para sacarle más provecho a la infraestructura que ya se tiene…
¡Muy interesante! 🙂 🙂 🙂
quien en mexico tiene implementado del lado de la infraestructura (bts msc bsc etc…) Fastdormancy?