Implementación de un sistema de asignación de precios para servicio de datos móviles en smartphones

PROYECTO FINAL DE CARRERA IMPLEMENTACIÓN DE UN SISTEMA DE ASIGNACIÓN DE PRECIOS PARA SERVICIO DE DATOS MÓVILES EN SMARTPHONES (IMPLEMENTATION OF A PRICING SYSTEM FOR MOBILE DATA SERVICE ON SMARTPHONES) Estudios: Ingeniería de Telecomunicación Autor: Guillermo González Lope Director: Marcos Postigo Boix Año: 2013 3 Colaboraciones Departamento de Telemática de la UPC 5 Agradecimientos Quiero dar las gracias a mi tutor Marcos Postigo por haberme dado la oportunidad de hacer este proyecto y por su paciencia y ayuda en los momentos más complicados de la realización del mismo. Y también, cómo no, a mi familia, por su apoyo incondicional y por cuidar de mí durante todo este tiempo. 7 Resum del projecte Segons diversos estudis, el trànsit de dades mòbils generat es dobla any rere any. Això suposa un desafiament constant per als ISPs (Internet Service Providers). Gran part dels seus costos es basen en l'aprovisionament i manteniment d'una infraestructura amb la capacitat suficient per fer front als pics de congestió. No és d'estranyar doncs, que els ISP busquin mètodes per intentar evitar aquests pics de congestió i reduir despeses, com oferir tarifes de preus en funció del tràfic total consumit (o consumible). No obstant i d'altra banda, els usuaris, volen consumir més dades a menor preu. D'aquest compromís neix la idea d'aquest projecte, que es basa en la realització d'un sistema de tarifació de preus depenent del temps (TDP, Time- Dependent Pricing). Per poder-ho dur a terme, s'ha implementat una aplicació d'Android que controlarà l'usuari (client) i un servidor programat en Java que emularà a l'ISP. Aquest sistema consisteix en poques paraules en oferir descomptes al client en la seva factura a canvi de posposar les seves sessions de trànsit a un altre moment, evitant així congestionar la xarxa. És, en definitiva, un sistema que busca el benefici mutu entre client i ISP. 9 Resumen del proyecto Según varios estudios, el tráfico de datos móviles generado se dobla año tras año. Esto supone un desafío constante para los ISP (Internet Service Providers). Gran parte de sus costes se basan en el aprovisionamiento y mantenimiento de una infraestructura con la capacidad suficiente para hacer frente a los picos de congestión. No es de extrañar pues, que los ISP busquen métodos para intentar evitar estos picos de congestión y reducir así sus gastos, como ofrecer tarifas de precios en función del tráfico total consumido (o consumible). Sin embargo y por otro lado, los usuarios, quieren consumir más datos a menor precio. De este compromiso nace la idea de este proyecto, que se basa en la realización de un sistema de tarificación de precios dependiente del tiempo (TDP, Time-Dependent Pricing). Para poderlo llevar a cabo, se ha implementado una aplicación de Android que controlará el usuario (cliente) y un servidor programado en Java que emulará al ISP. Este sistema consiste en pocas palabras en ofrecer descuentos al cliente en su factura a cambio de posponer sus sesiones de tráfico para otro momento, evitando así congestionar la red. En definitiva, es un sistema que busca el beneficio mutuo entre cliente e ISP. Figura 6.5: Resultados obtenidos en la primera optimización ..................... 71 Figura 6.6: Prices and Discounts. Fase de optimización ............................ 73 Figura 6.7: ClientDB: Discounts (izquierda) y Traffics (Derecha) ................ 73 Figura 6.8: Traffic History ................................................................... 74 Figura 6.9: Estimación del tráfico TIP .................................................... 75 Figura 6.10: Descuento medio ofrecido en función de la impaciencia .......... 76 Figura 6.11: Costes totales del ISP en la tercera semana.......................... 77 Figura 6.12: Uso medio de tráfico de datos ............................................ 79 Figura 9.1: Icono de la aplicación ......................................................... 87 Figura 9.2: Xperia Neo ........................................................................ 87 Figura 9.3: TDP_table en la prueba de funcionamiento de TDP para m=1 .... 88 Figura 9.4: D_table en la prueba de funcionamiento de TDP para m=1 ....... 89 Figura 9.5: TDP_table en la prueba de funcionamiento de TDP para m=3 .... 90 Figura 9.6: D_table en la prueba de funcionamiento de TDP para m=3 ....... 91 Figura 9.7: TDP_table en la prueba de funcionamiento de TDP para m=5 .... 92 Figura 9.8: D_table en la prueba de funcionamiento de TDP para m=5 ....... 93 Sistema de asignación de precios para datos móviles 17 1. Introducción 1.1 Motivación Los Operadores de Telefonía que ofrecen tarifas de datos para el acceso a Internet se encuentran con un dilema: al contrario que sus gastos, sus ingresos no se ajustan a la creciente demanda de ancho de banda de sus clientes. La mayoría de los proveedores ofrecen tarifas planas cuyo precio se ajusta a un cupo de tráfico de datos que se permite al usuario consumir (si bien el usuario puede consumir más, no suele ser al mismo precio o velocidad).Y el problema que esto conlleva, es que llega un punto en que el creciente gasto en expandir la capacidad del operador no se ve compensado por un incremento de los ingresos de la misma magnitud. Esto es debido a que el coste de la infraestructura del operador se ve determinado por las horas de congestión; el ISP (Internet Service Provider) ha de ofrecer una cierta calidad de servicio, esto es, la mínima congestión posible, con lo cual deberá tener una infraestructura capaz de dar servicio a sus clientes en las horas más concurridas del día [1]. Una de las alternativas que han barajado los operadores ha sido eliminar la tarifa plana y cobrar en función del tráfico consumido. Sin embargo ¿ayudaría esto a reducir la congestión? A priori no, ya que regular la cantidad de tráfico no implica regular el momento en el que este se consume. Idealmente el proveedor querría que el uso de tráfico de sus clientes se produjera de forma repartida a lo largo del día, y no concentrado en horas punta. Se han estudiado, a nivel de precios y horarios en las tarifas, diversas formas de combatir la congestión en muchos sectores: mercados energéticos, telefonía (voz), etc. Sin embargo en el ámbito de los datos inalámbricos se ha hecho poco al respecto. Concretamente en los datos móviles, que son aquellos cuyo uso implica pagar un coste al operador que provee la infraestructura. De aquí nace la motivación de este proyecto: Diseñar un sistema que reduzca la congestión de red, proporcionando así una mejor experiencia al cliente, y minimizando los costes del operador. 18 Introducción Para ello, y como hemos unos párrafos atrás, habría que regular tanto la cantidad de tráfico consumido como el momento en el que se consume. Es por eso que para desarrollar este proyecto se ha optado por emplear un método de tarifación dependiente del tiempo (Time-Dependent usage Pricing, en adelante TDP). Ahora bien, ¿en qué consistiría dicho método y como se podría implementar? El TDP se basaría en ofrecer una política de precios para datos móviles con el fin de evitar zonas del día con congestión en la red, minimizando así los costes del operador. Para ello, el ISP debería realizar una serie de medidas: cuánto tráfico consumen sus usuarios y cuando lo hacen. El ISP podría entonces ofrecer incentivos a sus clientes para que éstos consuman su tráfico en horas menos congestionadas del día. Por poner un ejemplo: supongamos que, a cierta hora por la tarde, existe un elevado consumo de tráfico por parte de los clientes que genera lentitud y congestión en la red. El proveedor podría incentivar a sus clientes a esperarse a la noche para conectarse a la red, ofreciéndoles precios más económicos para ese momento del día. Para implementarlo haría falta un sistema que realizase medidas de tráfico, optimización de precios e interfaces de usuario, entre otras cosas que se detallarán en el núcleo de esta memoria. A continuación se detallan los objetivos que se han propuesto para llevar a cabo dicho trabajo. 1.2 Objetivos 1.2.1 Objetivos generales El objetivo principal de este proyecto es diseñar un sistema, formado por una aplicación Android y un servidor, que permita emular una situación cliente-ISP, con el fin de evaluar el funcionamiento de un sistema de precios dependiente del tiempo (TDP). Sistema de asignación de precios para datos móviles 19 Figura 1.1: Esquema de conexión cliente-ISP La aplicación Android se diseñará con el objetivo de proporcionar al cliente (usuario del dispositivo móvil) la interfaz necesaria para poder interactuar con el ISP. En el apartado 3 del capítulo 2 se explican las diversas razones por las cuáles se ha decidido implementar la aplicación en esta plataforma. 1.2.2 Objetivos específicos Instalar y configurar un entorno de desarrollo para poder programar el servidor en Java e integrar el software de desarrollo de Android (SDK). Familiarizarse con el SDK de Android. Aprender a utilizar todas las herramientas que nos proporciona que puedan ser de utilidad. Crear y configurar una conexión entre la aplicación cliente y servidor. Esta conexión permitirá intercambiarse diferentes tipos de datos: desde información acerca del tráfico consumido por el cliente, hasta los descuentos ofrecidos por el ISP. Diseñar la aplicación cliente para que sirva como interfaz de usuario. Comprender en qué consiste el TDP, qué algoritmos utiliza y cómo implementarlo. Programar el servidor con las herramientas necesarias para que pueda implementar las funciones que requiere el TDP. Comprobar el correcto funcionamiento de la aplicación cliente en un dispositivo móvil compatible. Evaluar el sistema completo. Comprobar con los resultados, qué ventajas puede aportar un sistema de TDP. 20 Introducción 1.3 Estructura de la memoria En este documento se va a intentar explicar de la forma más precisa y breve posible todo aquello cuánto este proyecto ha abarcado. Desde todo lo que ha sido necesario para llevarlo a cabo, hasta cómo se ha realizado y qué resultados se han obtenido en el mismo. Los dos primeros capítulos del núcleo de esta memoria (2 y 3) se basaran en describir los medios o tecnologías sobre los que se ha realizado el proyecto. Dado que una aplicación Android compone el sistema diseñado, dedicaremos el segundo capítulo a explicar el sistema operativo Android, y definiremos las características más importantes de esta plataforma que serán necesarias para entender la implementación de la aplicación. De igual forma lo haremos con el servidor, dedicando el tercer capítulo a explicar detalladamente en qué consiste el Time-Dependent Pricing. En el capítulo 4 se realizará una completa descripción del sistema diseñado. Esta descripción será global y funcional, y no entrará en detalles de cómo se han realizado cada una de las partes que componen la estructura. El objetivo es que el lector comprenda, de la forma más sencilla posible, cómo se va a comportar el sistema. De este modo se podrá entender el siguiente capítulo con mayor facilidad, ya que explica detalladamente cómo está implementada tanto la parte de la aplicación (cliente) como la del servidor (ISP). Por lo que respecta a la aplicación, se detallarán todas las partes que la componen, así como cuál es el papel de cada una de ellas. Con la parte del servidor se hará un procedimiento análogo. Finalmente, en el capítulo 6, viene la parte experimental. Se pondrá a prueba dicho sistema, remarcando en qué condiciones (y las limitaciones que ello conlleva) se ha probado y se mostraran los resultados obtenidos. A partir de éstos y junto al resto de la memoria, se enumerarán las diversas conclusiones a las que se han llegado (capítulo 7). Sistema de asignación de precios para datos móviles 21 2. Android 2.1 Introducción En las siguientes páginas de este capítulo se hablará sobre el sistema operativo Android. Como se ha comentado en la introducción del proyecto, el sistema se basa (en parte) en una aplicación que corre bajo esta plataforma. Resulta de gran importancia pues, explicar todo aquello relacionado con el sistema operativo que pueda servir para entender, en los siguientes capítulos, cómo es y cómo está implementada dicha aplicación. Para ello, responderemos en los apartados de este capítulo a tres preguntas básicas: qué es Android, por qué se ha utilizado Android, y cómo se puede programar una aplicación en Android. 2.2 Definición y arquitectura Android es un sistema operativo basado en Linux, diseñado principalmente para móviles con pantalla táctil como teléfonos inteligentes o tabletas inicialmente desarrollados por Android, Inc., que Google respaldó económicamente y más tarde compró en 2005. Android fue presentado en 2007 junto la fundación del Open Handset Alliance: un consorcio de compañías de hardware, software y telecomunicaciones para avanzar en los estándares abiertos de los dispositivos móviles [2]. En la figura 2.1 se puede observar un esquema de la arquitectura de Android. La estructura del sistema operativo se compone de aplicaciones que se ejecutan en un framework 1 Java de aplicaciones orientadas a objetos sobre el núcleo de las bibliotecas de Java en una máquina virtual llamada Dalvik Virtual Machine con compilación en tiempo de ejecución. Las bibliotecas escritas en lenguaje C incluyen un administrador de interfaz gráfica (surface manager), un framework 1 Estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos de software concretos, que puede servir de base para la organización y desarrollo de software 22 Android OpenCore, una base de datos relacional SQLite, una interfaz de programación de aplicación (API, Application Programming Interface 2 ) una interfaz gráfica OpenGL ES 2.0 3D, un motor de renderizado WebKit, un motor gráfico SGL, SSL y una biblioteca estándar de C Bionic. Figura 2.1: Arquitectura de Android [3] El sistema operativo está compuesto por 12 millones de líneas de código, incluyendo 3 millones de líneas de XML, 2,8 millones de líneas de lenguaje C, 2,1 millones de líneas de Java y 1,75 millones de líneas de C++. 2.3 ¿Por qué Android? Actualmente existen multitud de plataformas para desarrollar aplicaciones para smartphones. Sin embargo existen varias razones por las cuáles se ha escogido Android y no otro sistema operativo para desarrollar la aplicación cliente: 2 Conjunto de funciones y métodos que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción. Sistema de asignación de precios para datos móviles 23 Popularidad: Android es el sistema operativo más utilizado en móviles, con mayor número de terminales que lo utilizan (varios cientos de millones) y con mayor número de descargas de aplicaciones (25000 millones) [4]. Lenguaje de programación: Las aplicaciones se programan en Java, lenguaje comúnmente utilizado. Plataforma open-source: Desde el punto de vista del desarrollador, es una gran ventaja ya que implica el respaldo de gran comunidad, donde cualquier persona puede aportar sus ideas, ayudar a mejorar, corregir fallos, etc. Accesibilidad: Desarrollar para Android es gratuito y abierto a todo el mundo. 2.4 Programar en Android 2.4.1 Configuración del entorno Para poder desarrollar una aplicación sobre esta plataforma, hace falta descargar e instalar su Software Development Kit (SDK) disponible en su web [5]. Pero antes, dado que se va a programar en Java, será necesario descargar e instalar el JDK (Java Development Kit) [6]. Este paquete contiene herramientas que nos permiten realizar diferentes funciones en esta plataforma (compilar y ejecutar programas, generar documentación, etc.). También habrá que instalar un Entorno de Desarrollo Integrado (IDE) para poder trabajar. En este caso, se ha utilizado Eclipse [7]. Una vez instalado el IDE sólo queda integrarle el SDK de Android, de esta forma se podrá programar sobre Eclipse utilizando todas las herramientas de la plataforma de Google. 2.4.2 Primeros pasos Lo primero que se debe hacer una vez configurado el entorno de programación es crear un proyecto. En este caso serán dos: uno para el cliente (aplicación Android) y otro para el servidor (aplicación Java), aunque por ahora, nos centraremos en la aplicación Android [8]. 24 Android Clicando la opción New > Project… del menú Archivo nos aparece una ventana para escoger qué asistente utilizar. En nuestro caso seleccionaremos Android Application Project y nos aparecerá el menú de la siguiente figura: Figura 2.2: Creación de proyecto Android Posteriormente habrá que poner el nombre a la aplicación, el icono, algunos detalles del diseño y también determinar para qué versiones de Android será compatible nuestra aplicación. En nuestra aplicación, se requiere como mínimo la versión 4.0.3 (que es la versión sobre la cual está programada) y es compatible con la versión más reciente hasta el momento (4.2). 2.4.3 Estructura de las aplicaciones Android El proyecto está creado, pero antes de empezar a diseñar la aplicación, es necesario saber cómo ésta se estructura por dentro. A continuación se enumeran los componentes más importantes que generalmente forman una aplicación de Android y que a su vez formaran parte de la de nuestra. 1. Activities Rigurosamente hablando, Activity es una clase Java particular de Android que permite, entre otras cosas, interactuar con el usuario. Esto se consigue con Sistema de asignación de precios para datos móviles 25 métodos especiales de la clase que proporcionan una interfaz gráfica para que el usuario pueda realizar una tarea en concreto. Un ejemplo que clarificaría esta definición sería la típica aplicación del correo. Al iniciarla, se crea la actividad principal de la aplicación, que nos abre una ventana (interfaz de usuario) para poder ver nuestros correos y ejecutar diversas acciones (seleccionar, mover, borrar, etc.). Otro ejemplo de aplicación con varias actividades puede ser la agenda de contactos, cuya actividad principal nos muestra la lista de todos los contactos, y al pulsar sobre uno de ellos se nos abriría otra actividad con la información del contacto en cuestión. A efectos prácticos, podemos considerar una actividad a cada una de las diferentes pantallas que se nos muestran en una aplicación y que nos permiten hacer tareas concretas. Las actividades se administran en el sistema mediante una pila. Esto es, cuando una actividad empieza, se coloca encima de la pila. A medida que se crean nuevas actividades se van superponiendo en dicha pila. En función de la memoria RAM que tengamos disponible, las actividades en segundo plano podrán ser terminadas por el sistema. En la figura 2.2 se puede observar el ciclo de vida de una actividad. Los cuadros ovalados son los estados por los que pasa, mientras que los rectángulos son los métodos que se ejecutan en la actividad en ese instante. 32 Time-Dependent Pricing Para computar los precios óptimos que minimizarían la congestión y los costes del ISP, éste deberá prever cuál será la reacción de sus clientes. Esto se podrá conseguir mediante una estimación del perfil de los usuarios a partir de estadísticas de su tráfico y de descuentos previos. El procedimiento será cíclico, de manera que el ISP irá adaptando sus cálculos a los cambios de comportamiento del usuario a lo largo del tiempo. En los siguientes apartados se explica cómo se realizarán cada uno de estos procesos que comprende el sistema de TDP. 3.2 Estimación del perfil del usuario Para poder optimizar los descuentos que se le ofrecerán al cliente, el ISP debe monitorizarle en todo momento el tráfico que consume. Pero eso no es suficiente: También necesita saber qué prioridad impone el usuario al consumo de dicho tráfico en ese momento. En este punto se plantea cómo parametrizar un modelo de impaciencia para obtener una estimación del perfil del usuario. 3.2.1 Modelo de impaciencia Como hemos comentado anteriormente, el grado de disposición de un usuario a consumir tráfico en un momento determinado depende del tipo de actividad que realizará. Por ejemplo, un usuario probablemente pospondría la actualización de sus aplicaciones durante un periodo de tiempo a cambio de un descuento en su factura, sin embargo no haría lo mismo si se tratara de verificar el correo, ya que sería una actividad más urgente para él. Para poder cuantificar esta disposición, se introduce el concepto de función de espera. Esta función indica la probabilidad de posponer el uso de tráfico en función de dos variables: el descuento d ofrecido y el tiempo pospuesto t. La función de espera debe ser una curva que cumpla dos requisitos: que sea creciente con el descuento y decreciente con el tiempo que se difiere. Una de las posibles ecuaciones que modele dicha función podría ser esta: (1) Sistema de asignación de precios para datos móviles 33 Como se puede observar, la función tiene un parámetro p que llamaremos impaciencia. Este valor será positivo, y cuanto más grande sea, significará mayor impaciencia. Será el parámetro que deberemos estimar para determinar qué tipo de usuario es el cliente [13]. A continuación se presentan dos gráficas de la función de espera: El de la izquierda corresponde a un usuario poco impaciente (p = 0.5) y el de la derecha a un usuario muy impaciente (p = 5). Figura 3.2: Probabilidad de posponer el tráfico de datos en función del descuento ofrecido y el tiempo de posposición En el sistema ISP-cliente que se ha realizado se ha particularizado dicha expresión. Se ha partido del supuesto que si el usuario decide posponer su tráfico, siempre lo hará un solo periodo. Además, se ha modificado el denominador del exponente, añadiendo un parámetro que corrige el comportamiento para valores altos de impaciencia. En este caso, la función de espera sólo tendrá una variable y el parámetro de la impaciencia, quedando de la siguiente forma: (2) Utilizando los mismos valores de impaciencia que en el caso anterior y para , así serían las funciones de espera de un usuario poco impaciente (izquierda) y de uno muy impaciente (derecha). 34 Time-Dependent Pricing Figura 3.3: Probabilidad de posponer el tráfico en función del descuento ofrecido 3.2.2 Algoritmo de estimación de impaciencia Una vez modelado el perfil del usuario, toca realizar los cálculos necesarios para obtener su valor numérico. Para ello es necesario someter al cliente a un periodo de prueba. Durante este periodo, el ISP irá ofreciendo descuentos totalmente aleatorios al cliente a lo largo de varios días. El usuario reaccionará, aceptándolos o no, en función del valor del descuento. Una vez el ISP tenga los datos suficientes se procederá a la estimación, que se realizará de la siguiente forma: (3) Donde es el valor medio de los descuentos ofrecidos y es el cociente entre el número de descuentos aceptados y el de descuentos ofrecidos. Es decir, se ha determinado empíricamente la probabilidad de que el usuario posponga el tráfico y sobre qué media de descuentos lo ha hecho. Con estos datos y partiendo de (2), se ha estimado el parámetro de impaciencia p. Como se puede observar, para existen dos discontinuidades, que se darían si el cliente acepta todos los descuentos del periodo de prueba o bien ninguno. Se evitarán añadiendo ruido al valor de para que quede siempre dentro del intervalo (0,1). Transcurrido el periodo de prueba, ya tendremos unos valores de impaciencia inicializados. A partir de dichos valores, el ISP empezará a realizar los cálculos Sistema de asignación de precios para datos móviles 35 necesarios para ofrecer al cliente descuentos optimizados. Tal y como se refleja en la figura 3.1, este procedimiento será cíclico: el usuario tomará la decisión de posponer o no su tráfico, y en función de ello el valor de su impaciencia estimada variará. Al final de cada día se realizará una nueva estimación de su perfil, dando a pie a nuevos descuentos. 3.3 Optimización de los precios El siguiente paso describe cómo usar los valores estimados de la función de espera para calcular los descuentos óptimos del día siguiente. Llegados a este punto, el ISP se enfrenta a un compromiso entre dos costes. El gasto que supone ofrecer descuentos a sus clientes y el gasto que supone congestionar la red. Ahora bien: ¿Hasta qué punto o en qué medida supone la congestión de la red un coste para el operador? Eso dependerá de muchos factores: costes de aprovisionamiento de infraestructura, reducción del flujo de datos, pérdida de calidad de servicio, etc. En definitiva, dependerá de la importancia que el operador dé a la congestión, que a fin de cuentas acabaría transformándose en pérdidas económicas. Reducir el coste de ofrecer descuentos puede suponer aumentar este último. De modo que habrá que buscar un punto de equilibrio para que el coste total del ISP sea el menor posible. Para ello se seguirá el siguiente razonamiento: 1. Supongamos que dividimos el día en n franjas (o periodos). Queremos saber con qué probabilidad el usuario pospondrá su tráfico de la franja i a la k. La función de espera, en este contexto sería: (4) Donde . Es decir, la probabilidad de diferir el tráfico de i a k depende del descuento ofrecido en la franja siguiente y del grado de impaciencia del usuario en la franja en la que quiere transmitir. 36 Time-Dependent Pricing 2. Definiremos tráfico TIP (Time-Independent Pricing) como el tráfico que generaría el cliente sin estar “sometido” al TDP. El tráfico TIP consumido en la franja i se representa como . 3. De ahora en adelante supondremos que el día consta de 3 franjas: mañana (franja 0), tarde (franja 1) y noche (franja 2). Podemos expresar el tráfico pospuesto de la tarde a la noche de la siguiente forma: (5) Definiremos tráfico TDP como el tráfico que genera el usuario cuando está en funcionamiento el TDP. En definitiva, será el tráfico que el ISP medirá una vez esté ofreciendo descuentos óptimos. Lo denotaremos como . 4. Utilizando las ecuaciones anteriores podemos afirmar que: (6) (7) (8) Es decir, el tráfico TDP equivale al tráfico que se generaría sin TDP, añadiéndole el tráfico diferido de la franja anterior y restándole el tráfico que se pospone a la franja siguiente. 5. El ISP ha de enfrentarse al coste de ofrecer descuentos. Estos descuentos se miden en cantidad de dinero partido por unidad de tráfico generado en el periodo correspondiente, de modo que el coste total se puede representar de la siguiente forma: (9) Siendo el tráfico que puede soportar el ISP durante el periodo i, podemos considerar los costes de sobrepasar dicha capacidad como una función lineal (aunque realmente sería lineal a trozos, cada trozo con mayor pendiente que el anterior) dependiente del tráfico consumido. Así Sistema de asignación de precios para datos móviles 37 pues, se modela el coste de exceder la capacidad en el periodo i de la siguiente forma: (10) Donde sería una cantidad fija de dinero por unidad de tráfico. 6. Para obtener los descuentos óptimos, se minimiza la suma de costes: (11) Que substituyendo nos quedaría: (12) Dado que las funciones de espera dependen de los descuentos y del tráfico, obtendremos unos valores óptimos tales que minimicen la expresión (12). 3.4 Actualización de valores Tal y como hemos visto en el apartado anterior, los descuentos óptimos se determinan, en última instancia, a partir de los tráficos TIP y los valores estimados de impaciencia del usuario. En un principio los valores de tráfico TIP se han obtenido midiendo el uso de red antes de poner en marcha el sistema de TDP. Estos valores serán válidos para una primera optimización. Sin embargo, para que el algoritmo funcione correctamente con el paso del tiempo, habrá que re-calcular dichos valores de tráfico TIP. De esta forma el 38 Time-Dependent Pricing proceso de optimización se adapta a los cambios en el uso de red, es decir, a la demanda de tráfico TIP de los clientes. El proceso de actualización de valores de tráfico TIP se producirá cada 3 días, justo después de obtener los descuentos óptimos. Con los valores de tráfico TDP medidos y las probabilidades de posponer tráfico, podemos estimar dichos valores teniendo en cuenta que: (13) Mediante un sistema de 3 ecuaciones (i = 0, 1, 2) y utilizando la técnica de mínimos cuadrados [14], podemos obtener los valores que mejor se ajusten a estas funciones. Estos serán los nuevos valores TIP que se utilizaran en las 3 próximas optimizaciones de descuentos. Sistema de asignación de precios para datos móviles 39 4. Descripción del sistema El sistema diseñado no es más que un ejemplo de comunicación cliente-ISP para valorar las ventajas que ofrecería un sistema de tarifas dependiente del tiempo. En este capítulo se explicará cuáles son las características y funciones más importantes de este sistema para poder cumplir el objetivo mencionado anteriormente. 4.1 Consideraciones previas Llevar a cabo la elaboración de un sistema de TDP real con todas sus posibilidades requeriría más recursos de los disponibles. En este sentido, existen una serie de limitaciones y consideraciones a tener en cuenta: Único usuario real Probablemente la mayor limitación de este sistema es que solo cliente tiene un cliente real o humano. Esto se debe a que por una limitación de recursos, sólo se ha podido probar la aplicación en un dispositivo móvil. Es por eso que, para poder obtener unos resultados coherentes y con una variabilidad más moderada, se han diseñado “usuarios virtuales”. Estos usuarios generarán tráfico en la red y escogerán descuentos basándose en unos patrones previamente establecidos. Serán utilizados para comprobar el correcto funcionamiento del algoritmo de TDP en el capítulo 6. Escalado Para poder ver el funcionamiento del sistema se requerirían varios días. Es por esto que para su realización se ha tomado una escala temporal mucho más reducida: cada periodo o franja horaria tendrá una duración de 1 minuto en la realidad. Dado que en este sistema se ha considerado que cada día tiene 3 franjas/periodos (mañana, tarde y noche), un día transcurrirá en 3 minutos. 40 Descripción del sistema El escalado temporal afecta al consumo de red. Por tanto, todos los valores relacionados con el tráfico (consumo diario, precios, capacidad del servidor) estarán también escalados para adaptarse a este sistema en particular. Android y posposición del tráfico Tal y como se explica en el capítulo anterior, el usuario tiene la opción de posponer su tráfico al siguiente periodo del día a cambio de un descuento en su factura. A nivel de usuario, la plataforma Android no tiene ninguna opción para diferir el tráfico de datos. De modo que, para emular dicha acción, se ha optado por inhabilitar las conexiones de datos móviles del teléfono durante el periodo previo al periodo descontado. 4.2 Funcionamiento general El sistema pasará por 3 fases: la fase TIP, la fase de prueba y la fase de optimización, en este orden. Fase TIP (fase previa) Como bien indica su nombre, en esta fase no entra en juego el TDP. Durante 3 días, el servidor se limitará a medir el tráfico que sus clientes consuman. Esto se producirá gracias al envío diario por parte del cliente de un paquete de datos con la cantidad de tráfico consumida en cada franja del día. El objetivo es saber cuál es el nivel de tráfico que normalmente consumen los clientes sin estar sometidos a descuentos. Esto será muy útil para la fase de optimización. La fase TIP no se producirá en tiempo real, sino que una vez inicie el sistema, se dará por finalizada. Se supondrá que el servidor ya cuenta en su base de datos con las medidas pertinentes realizadas. A partir de aquí se pone en marcha el mecanismo de TDP. Sistema de asignación de precios para datos móviles 41 Fase de prueba La fase de prueba también tiene una duración de 3 días. Desde el instante en que comienza, el servidor ofrecerá diariamente descuentos aleatorios al cliente para cada periodo del día. Esto supone un descuento por la mañana, uno por la tarde y uno por la noche. Con esto se pretende realizar la estimación del perfil de usuario (capítulo 3.2).Además, se seguirá midiendo el tráfico consumido por el cliente (esta vez será tráfico TDP). Una vez enviada la información de tráfico del tercer día se habrá llegado a la fase de optimización. Figura 4.1: Esquema de la fase de prueba Fase de optimización Esta fase es definitiva. El comportamiento del sistema será similar a la fase anterior, sólo que ahora los descuentos serán obtenidos en base a unas optimizaciones. Una vez se tenga una muestra suficiente de las estadísticas de tráfico del cliente (3 días de tráfico TIP y 3 días de tráfico TDP), el servidor realizará lo siguiente: 1. Estimación del perfil de usuario: Mediante el algoritmo explicado en el capítulo anterior, se obtendrán los valores de impaciencia de los clientes. 48 Descripción del sistema  Guardar en la base de datos los tráficos consumidos del cliente durante el día.  Envío de los descuentos (3 números generados aleatoriamente). PETICIÓN “o”: Envío de descuentos optimizados. El cliente la realiza cuando acaba el tercer día de la fase de prueba. Envía la información del tráfico consumido en ese día, y pide descuentos. El servidor, de ahora en adelante, los generará en base a sus cálculos.  Guardar en la base de datos los tráficos consumidos de los clientes durante el día.  Recopilar de la base de datos toda la información necesaria para calcular los descuentos (tráficos, descuentos ofrecidos anteriormente).  Estimación de la impaciencia de los usuarios.  Determinación de los descuentos óptimos mediante Maple.  Envío de los descuentos. Sistema de asignación de precios para datos móviles 49 5. Implementación Hasta ahora sólo se ha hecho una descripción de alto nivel del sistema de TDP. Es decir, se ha descrito desde el punto de vista del usuario, las funciones que realiza y cuáles son los procesos que se llevan a cabo durante su funcionamiento. En este capítulo se explicará detalladamente cómo se ha realizado internamente la implementación de cada uno de los bloques que forman el sistema. De nuevo, se analizará por separado la parte del cliente y la del servidor. De la parte del cliente se definirá primero su estructura general y luego se analizará por separado cada uno de los componentes que forman la aplicación. En el caso del servidor, se ha partido de su esquema funcional para explicar cada uno de los pasos que realiza una vez se ejecuta. 5.1 Cliente La implementación de la parte del cliente se reduce a qué archivos han sido necesarios para diseñar la aplicación Android, qué contiene cada uno de ellos, y qué papel realizarán dentro del programa. Para entender mejor cómo se ha implementado ésta (y cualquier) aplicación de Android, hay que diferenciar entre los diferentes tipos de archivos que habrá que diseñar y que compondrán el programa: Archivos de código fuente (src): Se encuentran en la carpeta src del proyecto. Son todos aquellos archivos que contendrán el código de la aplicación. En nuestro caso serán archivos con extensión .java: o Actividades. o Servicios. o Receptores. o Otras clases secundarias. Archivos de recursos (res): Se encuentran en la carpeta res del proyecto que comprende, entre otros, los siguientes archivos: o Iconos e imágenes de la aplicación. 50 Implementación o Archivos layout 4 (interfaz de usuario de las actividades). o Archivo strings.xml (almacena constantes de cadenas de caracteres que aparecen en la interfaz de la aplicación). Archivo AndroidManifest: Contiene la información de la aplicación. Otros archivos: Como pueden ser las librerías externas que se han necesitado para implementar funciones adicionales, bases de datos creadas por la aplicación y archivos de preferencias compartidas. 5.1.1 Estructura interna En este diagrama se esquematiza la estructura de la aplicación: Figura 5.1: Esquema interno de ClientApp Como puede observarse en la figura 5.1, el programa consta de: 13 archivos de código (.java): o 5 de ellos para las 5 actividades (sombreadas en rojo). 4 Esquema de distribución de los elementos dentro de un diseño Sistema de asignación de precios para datos móviles 51 o 2 servicios (sombreados en azul). o 1 receptor (sombreado en amarillo). o 5 clases secundarias que usaran las clases anteriormente mencionadas. 7 archivos de interfaz (.xml): o 5 correspondientes a las 5 actividades (en la parte superior de la figura, marcadas con el icono de la aplicación). o 1 para el menú de opciones de la actividad principal (menu.xml). o 1 para la apariencia de los objetos listados en la actividad Traffic by Apps (rowlayout.xml). 2 Elementos de almacenamiento de datos: o Base de datos SQLite (ClientDB) o Archivo de preferencias compartidas (shared_prefs.xml) Archivo Strings.xml. Archivo AndroidManifest.xml. Librería aChartEngine 1.0 (.jar) [16]. 5.1.2 Funcionamiento En este apartado se explica qué papel tiene cada uno de los archivos dentro de la aplicación, y se listan sus principales variables y funcionalidades, explicando cómo se ha implementado cada una de ellas. 1. ARCHIVO shared_prefs.xml En este archivo se irán guardando todas aquellas variables necesarias para que la aplicación funcione correctamente. La mayoría de ellas serán utilizadas por más de una actividad o servicio: Nombre Tipo Función BILL float Importe de la factura DBUTTON boolean[3] Indica si se ha escogido el descuento en cada franja DISC String[3] Valor del descuento en cada franja OLD_DISC String[3] Valor del anterior descuento en cada franja SERVERID_T int Nº de filas de la tabla TDP_table del servidor SERVERID_D int Nº de filas de la tabla D_table del servidor 52 Implementación SERVER_IP String Dirección IP externa del servidor SERVER_PORT int Puerto que utiliza el cliente para la conexión STARTED boolean Indica si el sistema está en funcionamiento o no TIME int Indica la franja del día actual TIP float[3] Precios actuales (descuentos incluidos) TIP_DEFAULT float[3] Precios base (por defecto) TINITIAL boolean Indica si el servicio Tmonitor se ha iniciado o no Figura 5.2: Contenido del archivo shared_prefs.xml El archivo de SharedPreferences será mencionado muchas veces a lo largo de este capítulo, de modo que lo denotaremos como SP. 2. ACTIVITIES Al entrar en cada una de las actividades, se ejecutará el código que hay en los archivos fuente. 2.1 Settings.java Código de la actividad Settings. Al entrar, se comprueba el booleano STARTED para saber si el sistema está en funcionamiento. A partir de aquí hay dos posibilidades: a) Sistema en marcha: Se obtienen de las SP los valores actuales de conexión (IP y puerto) y se muestran por pantalla. No se podrán editar. b) Sistema detenido: Se realiza el mismo procedimiento, pero los valores sí serán editables. Al salir de la actividad se guardarán en las variables SERVER_PORT y SERVER_IP de las SP los valores que se han introducido en los cuadros de texto editables. 2.2 Main.java Contiene el código de la actividad principal. Las funciones más destacadas de esta clase son: Iniciar o detener el sistema  Se hará mediante el método voidtoggleService(View), que se ejecuta cada vez que se pulsa el botón de iniciar/detener el servicio. Sistema de asignación de precios para datos móviles 53 a) Iniciar el servicio Sólo se iniciará el servicio si hay conexión a internet. De lo contrario aparecerá un cuadro de diálogo advirtiendo que no ha sido posible iniciar el servicio. Se realizan los siguientes procesos:  Crear la base de datos. Si existe una antigua se borran sus tablas y se crean unas nuevas.  Recuperar los datos de conexión (IP y puerto) de las SP. Se guardarán en variables secundarias y se usaran para la primera petición al servidor.  Configurar alarma (objeto de la clase AlarmManager).Sonará cada minuto, lo que vendrá a notificar el fin de una franja del día. Cada vez que suene, se ejecutará automáticamente el código de Receiver.java, que no es más que un receptor programado para dicha alarma.  Enviar primera petición al servidor (precios TIP). Guardar en las SP (variable TIP) los precios recibidos. b) Detener el servicio Se realizan los siguientes procesos:  Cancelar alarma.  Borrar todo el contenido de las SP. Como sólo hay un botón para iniciar y detener, hace falta verificar previamente si la alarma está activada o no, y en función de ello, realizar a) o b). Además se irá actualizando el valor del booleano STARTED en las SP, así como el texto del botón. El hecho de hacer uso de AlarmManager para ejecutar código periódicamente, se debe a las características del sistema operativo. De este modo se garantiza que aunque la aplicación se termine por falta de memoria, la alarma siempre sonará, y por tanto el receptor se ejecutará este o no activa la aplicación. La primera vez que la alarma suena es cuando el contador de segundos es 0. A partir de ahí, irá sonando cada minuto (tiempo de duración de un periodo). 54 Implementación Actualizar los valores de la pantalla (Runnable rTrafficBill)  Actualiza los valores de tráfico y factura. Se ejecuta al entrar en la actividad. Se realiza del siguiente modo:  Obteniendo de las SP el valor de BILL y colocándolo en pantalla.  Calculando el tráfico de datos móviles consumido haciendo uso de la clase TrafficStats y colocándolo en pantalla. Abrir otras actividades  Para cada una del resto de actividades, se ha creado un método que permite acceder a ellas mediante un Intent. Es el caso también de la actividad Settings, cuyo Intent se encuentra dentro de la función onOptionsItemSelected(MenuItem item), que se ejecuta cuando apretamos una opción del MENU. Refrescar pantalla  Actualiza los valores de la pantalla. Se limita a llamar el método onResume(), el cual se invoca siempre que se entra en la actividad, que a su vez llama al Runnable rTrafficBill. 2.3 Prices.java Contiene el código de la actividad Prices and Discounts. Al entrar en la actividad (o al actualizar mediante el botón Refresh), se ejecuta el método updateUI(), que realiza lo siguiente:  Obtiene los Arrays 5 DBUTTON[], DISC[] y TIP[] de las SP.  Coloca sobre la interfaz los valores de TIP[] Y DISC[] obtenidos. Los de TIP[] corresponden a los precios actuales y los DISC a los descuentos.  Activa o desactiva los botones de los descuentos en función de lo que indique el DBUTTON del descuento correspondiente. Si los descuentos son nulos, se desactivan por defecto. A partir de aquí, si el usuario decide escoger un descuento apretando sobre él, se llamará a applyDiscount_x() (donde x es el número de franja del día: 1 para mañana, 2 para tarde, 3 para noche). Este método abre un cuadro de diálogo pidiendo confirmación. En caso afirmativo: 5 Conjunto de objetos o elementos Sistema de asignación de precios para datos móviles 55  Se desactiva el botón.  Se actualiza DBUTTON[] en la posición del descuento, indicando que está desactivado.  Se sobrescribe la variable DBUTTON[] en las SP.  Se marca en la base de datos local como descuento aceptado De esta forma, aunque la aplicación termine inesperadamente, nunca perderemos los valores ni la configuración de la interfaz de la actividad. Al entrar siempre se nos mostrarán los valores actualizados. 2.4 Graph.java Contiene el código de la actividad Traffic History. Para implementar esta actividad, ha sido necesario importar la librería aChartsEngine.jar, la cual ofrece múltiples herramientas para crear gráficos de todo tipo. En este caso particular, se ha empleado el uso de un gráfico de barras. Para obtener los valores de tráfico, la actividad se conecta a la base de datos de la aplicación y obtiene los 22 últimos registros. De esta forma se consigue el tráfico de cada franja desde 7 días atrás hasta la actualidad. 2.5 Apps.java Contiene el código de la actividad Traffic by Apps. Esta actividad se ha implementado usando una ListView, esto es, una lista de objetos que aparecerá en la interfaz de usuario de la actividad. Los objetos que compongan dicha lista serán del tipo AppsTraffic y estarán formados por:  Una imagen conteniendo el icono de la aplicación.  Un String con el nombre de la aplicación.  Un long con el tráfico consumido por la aplicación. Cada objeto representa una aplicación. Para poder obtener qué aplicaciones han consumido tráfico de datos (y deben aparecer en la lista) hay que acceder a la carpeta del dispositivo /proc/uid_stat/ y obtener el nombre de todos los archivos que aparecen. Esto es así porque cada aplicación instalada en un dispositivo recibe un identificador único llamado uid. Si una aplicación consume datos en el dispositivo, se creará un archivo con su uid de nombre en dicha carpeta, conteniendo información sobre el tráfico usado. 56 Implementación De este modo la actividad obtendrá los uid de todas las aplicaciones que han usado tráfico y a partir de ahí:  Obtendrá el tráfico usado por la aplicación con los métodos TrafficStats.getUidRxBytes() y TrafficStats.getUidTxBytes()  Usando un objeto de clase PackageManager se obtiene el nombre del paquete pn de la aplicación con getNameForUid(uid).  Partiendo del nombre del paquete se obtiene un objeto ApplicationInfo ai mediante getApplicationInfo(pn,0), y a partir de éste, ya se puede obtener el nombre y el icono de la aplicación mediante los métodos getApplicationLabel(ai) y getApplicationIcon(ai) respectivamente. De este modo el objeto que queremos insertar ya contendrá la información pertinente. Se realizará el mismo procedimiento para todos los uids con tráfico asociado y rellenará una ArrayList con todos los objetos. Para poder insertarlos en la ListView, será necesario crear un adaptador (android.widget.ArrayAdapter<String>). La clase MyAdapter.java de la aplicación ClientApp extiende la clase anterior, y será el adaptador particular que inserte los objetos AppTraffic de la ArrayList en la ListView. Para ello hay que proporcionarle un archivo de interfaz de usuario. Este archivo representará un elemento o fila en la ListView: Figura 5.3: Archivo de interfaz rowlayout.xml A partir de cada objeto de la ArrayList que le hemos pasado al adaptador, éste creara un elemento como el de la figura y colocará la información en el lugar correspondiente. Como se puede apreciar en la anterior figura, también se ha añadido una barra de progreso en el archivo de interfaz de fila. De esta forma se podrá ver intuitivamente la cantidad de datos que ha usado cada aplicación en proporción al resto, de modo que la aplicación que más consuma tendrá la barra llena. Sistema de asignación de precios para datos móviles 57 3. SERVICES 3.1 Tmonitor.java Viene llamado por el receptor cada vez que transcurre un periodo del día. Este servicio se ha creado para realizar las siguientes tareas: Guardar en una base de datos local la información de tráfico consumido por el dispositivo, así como todos los descuentos recibidos del servidor. Comunicarse con el servidor: Enviar la información mencionada anteriormente y recibir los nuevos descuentos. Calcular el importe de la factura. La siguiente figura es un esquema funcional del servicio: Figura 5.4: Esquema funcional de Tmonitor.java 64 Implementación Figura 5.8: Conexión entre servidor y Maple La clase CallBacks ha sido implementada a partir de un ejemplo de la web de Maple [18], e implementa la interfaz CallBacksEngine, que permite manejar el output que da el software. Para poder entregar ese output a ServerApp, se ha añadido el método getOutput(), que lo retornará a la clase que lo llama dicho output en forma de String. Este método se llamará en ServerApp una vez le hayamos pasado los comandos al motor mediante el método evaluate(String). Preparar servidor / Escuchar peticiones El siguiente paso es preparar el servidor para escuchar peticiones. Se crea un socket con la dirección privada del ordenador y un puerto que no esté en uso. A partir de aquí la aplicación servidor entra en un bucle infinito: El servidor está preparado para aceptar conexiones. Atender petición según su tipo Cada vez que el cliente realiza una petición, lo primero que hace es enviarle un carácter especificando el tipo de petición. El servidor distingue el tipo de petición mediante un switch y realiza la acción o acciones correspondientes a dicha petición. Posteriormente cierra el socket. 5.2.3 Usuarios virtuales El propio servidor se encargará de emular a un pequeño número de usuarios, dado que con un sólo cliente es difícil analizar el funcionamiento del sistema correctamente. En el capítulo 3 se ha constatado que para estimar la impaciencia, se partía de la proporción de descuentos aceptados frente a los ofrecidos. Dado que el objetivo del algoritmo es obtener un único valor de impaciencia para todos los Sistema de asignación de precios para datos móviles 65 usuarios, habrá que obtener dicha proporción a partir del promedio de proporciones de cada usuario. Para poder emular usuarios virtuales habrá que realizar 3 pasos: 1. Prefijarles un modelo de comportamiento (valores de impaciencia). 2. Generar su tráfico. 3. Simular que posponen tráfico a otras franjas horarias con una frecuencia afín a su impaciencia. La siguiente figura esquematiza brevemente la implementación de los usuarios virtuales en el servidor: Figura 5.9: Esquema funcional de los usuarios virtuales Establecer impaciencia base Antes de preparar el motor de Maple, se prefijan unos valores de impaciencia para cada usuario virtual. Estos valores se obtienen a partir de una variable aleatoria gaussiana de media m y desviación m/5 (m positivo) y se almacenan en una matriz MxN (M el número de usuarios virtuales y N el número de periodos del día). Es decir, cada usuario tiene preestablecido un valor de impaciencia para cada franja del día, y éste será invariable. Denominaremos estos valores como impaciencia base. En el siguiente paso veremos que estos valores influirán en la impaciencia global estimada, pero no tendrán por qué ser similares. 66 Implementación El resto del proceso del esquema anterior se lleva a cabo en la función upload_server(), a la cual llama el servidor cuando recibe una petición “r” u “o” (una vez al día). Se aplicará dicho algoritmo para cada franja del día y para cada usuario. Generar tráfico Para emular correctamente a un usuario hay que simular que éste realiza un cierto uso de la red. El uso que hagan cada uno de los usuarios dependerá del valor total del tráfico TIP actual. Si por ejemplo tenemos un sistema con un total de 10 usuarios y con un tráfico TIP total medido de 300 MB por la mañana, el tráfico de un usuario virtual en esa franja se obtendrá a partir de la división de una variable aleatoria gaussiana de media 300 MB entre 10. Con esto se garantiza que los usuarios se comportan en base a lo medido por el ISP previamente. Decisión de posponer Estos valores generados no serán definitivos, pues hará falta saber si el usuario no prefiere antes aceptar un descuento y posponer su tráfico. Para tomar esta decisión se calculará, en primer lugar, la probabilidad de que posponga su tráfico a partir del descuento ofrecido actual y su impaciencia base. Posteriormente se generará un número aleatorio entre 0 y 1: si éste es inferior a la probabilidad calculada, se aceptará el descuento actual y no se consumirá el tráfico en el periodo, acumulándolo en el tráfico pospuesto. En caso contrario, se rechazará el descuento y se consumirá, no sólo el tráfico previsto para dicho periodo, sino además todo aquel que estaba acumulado como tráfico pospuesto. Subir a la base de datos El procedimiento descrito anteriormente se efectuará para cada uno de los usuarios virtuales y en todos los periodos del día actual. El tráfico que estos usuarios decidan finalmente consumir en cada periodo del día se acumulará en una variable, y se añadirá al tráfico consumido por el usuario real. Finalmente, el total será almacenado en la base de datos del servidor. Sistema de asignación de precios para datos móviles 67 6. Pruebas Como se ha mencionado en el primer capítulo de esta memoria, la finalidad del diseño de este sistema es evaluar su funcionamiento, determinando así hasta que punto un sistema de TDP puede proporcionar ventajas respecto a otro. En este capítulo se proponen una serie de pruebas que reflejan diferentes situaciones con las cuales un ISP se podría encontrar. En el apartado 6.2 se informará de cuáles han sido esas pruebas, que es lo que se ha pretendido evaluar, y qué resultados se han obtenido, así como la justificación de los mismos. Pero antes, se dedicará un apartado a explicar cuál es y cómo se ha configurado el escenario para hacer dichas pruebas. 6.1 Configuración del escenario El servidor se ejecuta en un ordenador de sobremesa, conectado a Internet mediante una red Wi-Fi doméstica. Para poder acceder al servidor, el cliente deberá conocer su dirección IP externa (o pública). Lo ideal sería esta dirección fuera siempre la misma (estática). En nuestro caso es dinámica, con lo cual cada vez que se ha reiniciado el router inalámbrico que da acceso a Internet, ha sido necesario, o bien modificar la aplicación para que se conectara por defecto a la nueva dirección, o cambiar ésta más adelante en los ajustes de la aplicación. Para que el servidor acepte conexiones externas, habrá que mapear los puertos necesarios en el menú de configuración del router, tal y como se muestra en la siguiente figura: Figura 6.1: Mapeado de puertos del router 68 Pruebas En el caso de la figura, el router permitirá las conexiones TCP/UDP al puerto 19400 del dispositivo con IP privada 192.168.1.132 (el servidor), cuando se hagan desde el rango de puertos 19100-19200 (del cliente). Las conexiones del cliente al servidor se harán mediante datos móviles (3G) en todas las pruebas. El sistema funcionaría también utilizando Wi-Fi, siempre que servidor y cliente no compartan la misma red local (en cuyo caso el router denegaría las peticiones por seguridad). El dispositivo móvil para realizar las pruebas será un Sony Ericsson Xperia Neo (ver especificaciones en Anexo B). Se conectará al PC que ejecute el servidor mediante un cable USB. Esta conexión se realizará por dos motivos: para poder instalar la aplicación al dispositivo desde Eclipse y para poder depurarla en tiempo real cuando esté en funcionamiento. Una vez ejecutado el servidor e instalada la aplicación en el dispositivo móvil se podrá dar pie a las pruebas pertinentes. 6.2 Pruebas y resultados Para este sistema se han hecho dos tipos de pruebas: las de funcionamiento general y las de funcionamiento del algoritmo de TDP. En las primeras lo que se ha querido comprobar es que tanto aplicación cliente como servidor funcionan debidamente. Esto es, que tanto las conexiones como la transmisión, recepción y almacenamiento de datos se produzcan correctamente, así como los procesos propios de cada uno. En el caso particular de la aplicación cliente se ha verificado también que la interfaz de usuario esté correctamente implementada y no dé errores. Por otro lado, en las pruebas de funcionamiento del TDP se ha pretendido evaluar íntegramente el comportamiento de dicho algoritmo. Esto es, si funciona de la forma esperada, si los cálculos concuerdan con lo previsto, así como determinar qué ventajas ha ofrecido su uso. Sistema de asignación de precios para datos móviles 69 Como se ha mencionado en el apartado 4.1 de esta memoria, el sistema tiene ciertas limitaciones, que implican que las estadísticas del cliente que utiliza la aplicación no son válidas para poder evaluar el algoritmo de TDP (sólo se dispone de un usuario y la posposición de tráfico no se ha implementado de forma óptima). Es por eso que para las pruebas de este apartado sólo se han empleado usuarios virtuales. 6.2.1 Prueba de funcionamiento general Para evaluar el correcto funcionamiento del sistema se ha prestado especial atención en los siguientes aspectos: Conexión cliente-servidor. Almacenaje de información en las bases de datos. Información mostrada en las actividades. Proceso de optimización. Más allá de si los resultados son coherentes o no, el principal objetivo de esta prueba ha sido comprobar que estos procesos se realizan sin errores. En primer lugar se ha ejecutado el servidor: . Figura 6.2: Inicio del servidor 70 Pruebas Como se puede apreciar en la figura, se inicia el motor de Maple y se obtienen los valores medios del tráfico TIP medido. Además, se envía un comando a Maple para que importe una librería necesaria para realizar las optimizaciones. El servidor ya está preparado para recibir peticiones. Momento en que se ejecuta la aplicación cliente. Una vez hecho, se apretará al botón de Start Service. Aparecerá el cuadro de progreso de la figura de la izquierda y el servicio TDP arrancará. Para comprobar que se ha hecho con éxito, se accede a la actividad Prices & Discounts. En la figura de la derecha se puede apreciar como ya existen tarifas, con lo cual el sistema se ha iniciado correctamente. Figura 6.3: Inicio del sistema TDP a) Cuadro de progreso b) tarifas Empieza la fase de prueba. Tendrá una duración de 3 días, en los cuáles se recibirán diversos descuentos generados aleatoriamente. En el último día de la fase, se han aceptado 2 descuentos, el de la tarde y el de la noche, como se puede apreciar en la siguiente figura: Sistema de asignación de precios para datos móviles 71 Figura 6.4: Aceptación de descuentos Termina el último día de la fase de prueba, y a partir de aquí comienza la fase de optimización. La siguiente figura muestra los resultados obtenidos por el servidor en la primera optimización: Figura 6.5: Resultados obtenidos en la primera optimización En primer lugar, el servidor muestra por pantalla los siguientes datos: 72 Pruebas x[]  Tráfico TDP medio: Estos promedios se empiezan a calcular de ahora en adelante para futuras re-calculaciones de la demanda de tráfico TIP, con lo cual en este momento serán nulos. counta[]  Total de descuentos aceptados por el cliente real. countd[]  Total de descuentos ofrecidos al cliente real. rcounta[]  Total de descuentos aceptados por los usuarios virtuales. rcountd[]  Total de descuentos ofrecidos a los usuarios virtuales. waitf[]  Valor de medido (descuentos aceptados entre ofrecidos). p[]  Parámetro de impaciencia global estimado. XE[]  Valores medios de tráfico TIP estimado. En un principio se obtienen a partir de la tabla TIP_table de la base de datos. Más adelante se obtendrán por medio de una estimación. El proceso de optimización puede no dar un resultado válido al primer intento. Es por eso que aparecen mensajes de error (aparecen en rojo en la figura). El servidor está programado de tal forma que si no se consigue una solución, se vuelva a intentar la optimización. El servidor dispone de hasta 50 intentos para conseguir los descuentos óptimos. En cada uno de ellos se irán variando sensiblemente los datos de entrada. Cuando finalmente se consiguen valores óptimos, éstos se imprimen por pantalla a continuación, así como el coste óptimo que se podría lograr. Este coste no es real, es tan sólo el mínimo coste que tendría que afrontar el ISP en el mejor de los casos. El coste real se tendrá que calcular a posteriori con diferentes medidas: Tráfico que ha sobrepasado la capacidad, descuentos aceptados, etc. Una vez realizada la optimización, el servidor envía los descuentos óptimos al cliente. En la actividad Prices and Discounts nos aparecerá lo siguiente: Sistema de asignación de precios para datos móviles 73 Figura 6.6: Prices and Discounts. Fase de optimización Se puede ver como los descuentos se corresponden con los calculados por el servidor en la figura 6.5. Los 2 primeros están desactivados porque son nulos. Además, las tarifas han cambiado, puesto que el día anterior se aceptaron 2 descuentos. Durante el día actual, consumir datos durante la tarde será un 40% más barato mientras que si se hace por la noche sólo habrá que pagar 0.08 céntimos por MB. Por lo que respecta al almacenamiento de datos, las siguientes figuras muestran el contenido de la base de datos del cliente: Figura 6.7: ClientDB: Discounts (izquierda) y Traffics (Derecha) 80 Pruebas A la hora de realizar las optimizaciones, el servidor se basa en la totalidad de las estadísticas. Cuando a partir de la tercera semana se produce congestión de red en la franja nocturna, el servidor no la tiene en cuenta al instante, ya que su estadística se basa en las tres semanas que lleva el sistema en marcha. Si esta congestión se prolongara entonces el servidor lo advertiría en sus estimaciones, y ofrecería un descuento en la franja de la mañana para contrarrestarla. En el Anexo C se han adjuntado capturas de las tablas del servidor, sobre las cuáles se han creado los gráficos en este capítulo. Sistema de asignación de precios para datos móviles 81 7. Conclusiones Llegados al capítulo final de esta memoria, es el momento para reflexionar qué es lo que se ha conseguido con este proyecto, y cuáles son los aspectos que se deberían mejorar. Es por eso que este capítulo se divide en tres apartados. En el primero, se constatará cuáles han sido los objetivos alcanzados, tanto generales como específicos. En el segundo se hará una valoración global del sistema en función de las pruebas realizadas y de observaciones previas, haciendo hincapié en algunos aspectos concretos que deberían mejorarse. Finalmente, el tercer apartado dará pie a posibles vías de investigación mediante las cuales se podría mejorar la funcionalidad del sistema implementado. 7.1 Conclusiones generales Atendiendo a los objetivos fijados en el primer capítulo de esta memoria, se puede concluir lo siguiente: En primer lugar, se ha conseguido desarrollar la aplicación Android del cliente haciendo uso de las herramientas proporcionadas por la plataforma del sistema operativo. La aplicación es compatible con las versiones más recientes de Android, así como con los diferentes dispositivos que utilizan la plataforma. A falta de realizar alguna optimización de uso de memoria, la aplicación es estable y puede funcionar perfectamente en segundo plano, adaptándose a las condiciones del sistema operativo. Todo ello implica pues que se han asimilado los conocimientos necesarios para programar en la plataforma Android. Por otro lado, se ha logrado programar un servidor que emule a un ISP que utiliza TDP. Para ello se ha comprendido en qué consiste este algoritmo y se ha logrado implementar en el servidor: Se ha propuesto un modelo de estimación de perfil de usuario y se ha utilizado un software externo para realizar los complejos cálculos que el propio código no podía computar. 82 Conclusiones Se concluye pues, que los objetivos preestablecidos se han cumplido. En el siguiente apartado se sacarán más conclusiones fruto de una evaluación más exhaustiva del sistema implementado. 7.2 Conclusiones sobre el sistema A raíz de la prueba de funcionamiento general, podemos constatar varias cosas: En primer lugar, la conexión entre cliente e ISP se ha producido sin errores en todas las fases del sistema, permitiendo una correcta interactuación entre ambos. En segundo lugar, el almacenaje de datos se ha producido de forma adecuada, tanto e nivel de cliente como de servidor. Finalmente, todos los procesos que contienen tanto servidor como cliente se han llevado a cabo correctamente y de forma sincronizada. En este sentido se ha analizado especialmente la parte del servidor, cuyos cálculos y optimizaciones debían hacerse antes dentro del tiempo de conexión. Es por eso que se puede calificar la prueba de funcionamiento general de exitosa. Sin embargo, cabe destacar un par de funcionalidades que no se han podido implementar como se hubiera deseado. Por un lado está la medición de tráfico de la red. Para poder monitorizar el tráfico que el cliente consumía, el servidor se ha basado en información que el propio cliente le entregaba de forma periódica. Este método ha funcionado, pero sin duda carece de la fiabilidad suficiente para un sistema de estas características. Por otro lado está el tema de la posposición de tráfico. En un principio se pretendió que la aplicación pudiera, por sí misma, retrasar las conexiones de datos durante el tiempo necesario, posponiendo el tráfico al siguiente periodo. Finalmente se concluyó que no se poseían los conocimientos ni los recursos suficientes como para poder implementar esa funcionalidad. Es por eso que se Sistema de asignación de precios para datos móviles 83 trató de emular, inhabilitando las conexiones de datos durante el tiempo estipulado. No obstante eso no provoca que el tráfico se posponga. También se ha determinado que, para obtener resultados concluyentes acerca de la eficiencia del sistema de TDP, ha sido necesario introducir usuarios virtuales y no tener en cuenta el cliente real, por dos motivos: Primero porque con un solo cliente real no es posible obtener datos precisos, pues se está realizando un análisis a nivel de una red de acceso que puede albergar muchos usuarios. Y segundo, por la dificultad de simular manualmente que el cliente pospone su tráfico. En los usuarios virtuales se podría simular esto último, tal y como se ha explicado en el apartado 5.2.3 de la memoria. Es por eso que se puede concluir que, a pesar de tener un correcto funcionamiento, la eficiencia del sistema de TDP no se ha podido comprobar aún con usuarios reales. En el apartado 7.4 se han propuesto diversas vías de investigación mediante las cuales se podrían mejorar algunos de estos aspectos del sistema diseñado. 7.3 Trabajo futuro Como se ha mencionado en el apartado anterior, uno de los aspectos a mejorar en el sistema es la implementación de una funcionalidad en la aplicación del cliente que permita posponer el tráfico. Para ello habría que rootear 6 previamente el terminal, pudiendo de este modo tener acceso a las iptables 7 y poder modificarlas. De este modo se podría crear una especie de cortafuegos que gestionaría qué conexiones se realizan y cuándo. A raíz de esto, surge la idea flexibilizar el algoritmo de TDP para distintos tipos de conexiones (correo, streaming, descargas, etc.). En vez de impedir que el usuario se conecte en un periodo del día, se podría tan sólo limitar la cantidad de tráfico que puede enviar. El usuario podría establecer un orden de prioridades 6 Proceso de obtención de privilegios de administrador sobre el dispositivo 7 herramienta de administración para definir reglas que gestionan, filtran y manipulan paquetes de red 84 Conclusiones en sus aplicaciones para decidir cuáles de ellas tendrían preferencia a la hora de transmitir en esos periodos. En cuanto a la medición del tráfico y otras estadísticas del cliente (factura, descuentos aceptados, etc.), queda patente que el servidor precisa de un sistema de monitorización de red. Esto aportaría una mejoría en diversos aspectos: En primer lugar, y como se ha dicho en el apartado anterior, se mejoraría la fiabilidad, ya que las mediciones se harían constantemente y no un número contado de veces al día, además de que no sería el cliente el responsable de medir si no el servidor. Y en segundo lugar, dada la precisión de las medidas del tráfico en la red, se podría aumentar el número de periodos diario, pudiendo así focalizar mejor los momentos del día en los que existe congestión en la red para tratar de reducirla mediante el uso de TDP. Sistema de asignación de precios para datos móviles 85 8. Bibliografía 8.1 Referencias [1] Carlee Joe-Wong, Sangtae Ha, Mung Chiang. Time-Dependent Broadband Pricing: Feasibility and Benefits, ICDCS 2011. Artículo disponible en: http://scenic.princeton.edu/tube/papers/TUBE_ICDCS.pdf [2] Android - Wikipedia: http://es.wikipedia.org/wiki/Android [3] Android Architecture: http://developer.android.com/about/versions/index.html [4] Android | Official blog: http://officialandroid.blogspot.in/2012/09/googleplay-hits-25-billion-downloads.html [5] Android SDK – Android Developers: http://developer.android.com/sdk/index.html [6] Java Development Kit – Java SE Downloads: http://www.oracle.com/technetwork/es/java/javase/downloads/index.html [7] Eclipse – The Eclipse Foundation open source community website: http://www.eclipse.org/ [8] Simon, Jonathan. Head First Android Development. O’Reilly Media, Inc. 2001 [9] Activity | Android developers: http://developer.android.com/reference/android/app/Activity.html [10] Services | Android developers: http://developer.android.com/guide/components/services.html [11] SQLite Home Page: http://www.sqlite.org/ [12] Sangtae Ha, Soumya Sen, Carlee Joe-Wong, Youngbin Im, and Mung Chiang. TUBE: Time Dependent Pricing for Mobile Data. ACM SIGCOMM 2012, Helsinki. Artículo disponible en: http://scenic.princeton.edu/tube/papers/TUBE_Sigcomm.pdf [13] Mung Chiang. Networked Life, 20 Questions & Answers. Cambridge University Press 2012 [14] Least Squares – Wikipedia: http://en.wikipedia.org/wiki/Least_squares 86 Bibliografía [15] Maple, the essential tool for mathematics and modeling: http://www.maplesoft.com/products/maple/ [16] AChartEngine. A charting software library for Android applications: http://www.achartengine.org/ [17] Java OpenMaple Application Program Interface (API): http://www.maplesoft.com/support/help/Maple/view.aspx?path=OpenMapl e/Java/API [18] Java OpenMaple Examples – Maple Help: http://www.maplesoft.com/support/help/Maple/view.aspx?path=OpenMapl e/Java/Examples 8.2 Otros enlaces de utilidad  Package Index | Android Developers: http://developer.android.com/reference/packages.html  Curso de programación Android: http://www.inforjmr.es/?page_id=136  StackOverflow. A question and answer site for professional and enthusiast programmers. http://stackoverflow.com/ Sistema de asignación de precios para datos móviles 87 9. Apéndice A. Especificaciones de la aplicación Nombre: ClientApp Versión: 1.0 (alfa) Desarrollador: Guillermo González Tamaño: 0,97 MB Uso de memoria RAM: 9,5 MB Compatible con: Android OS v4.0 o superior B. Especificaciones del dispositivo móvil utilizado Nombre: Sony Ericsson Xperia Neo (MT15) Red: GSM 850 / 900 / 1800 / 1900 - HSDPA 900 / 2100 ó HSDPA 850 / 1900 / 2100 OS de fábrica: Android OS v2.3 Gingerbread OS instalado: Android OS v4.0 Ice Cream Sandwich Procesador: Qualcomm MSM8255 Snapdragon 1GHz Tamaño de pantalla: 480x854 píxeles Memoria interna: 320 MB Memoria RAM: 512 MB Figura 9.2: Xperia Neo Figura 9.1: Icono de la aplicación 88 Apéndice C. Capturas de las pruebas Contenido de las tablas del servidor TDP_table y D_table tras finalizar las pruebas de funcionamiento de TDP (apartado 6.2.2 de la memoria). C.1 Prueba de funcionamiento de TDP con m=1 TDP_table Figura 9.3: TDP_table en la prueba de funcionamiento de TDP para m=1 Sistema de asignación de precios para datos móviles 89 D_table Figura 9.4: D_table en la prueba de funcionamiento de TDP para m=1