generaciÓn y puesta en marcha de un modelo...
TRANSCRIPT
GENERACIÓN Y PUESTA EN MARCHA DE UN MODELO PARA LA
HOMOLOGACIÓN DE TERMINALES MÓVILES A TRAVÉS DEL DESARROLLO
DE UNA APLICACIÓN SOBRE EL SISTEMA OPERATIVO ANDROID
WBEYMAR CARVAJAL PINZÓN
UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS
MAESTRIA EN TELECOMUNICACIONES MÓVILES
FACULTAD DE INGENIERIA, PROGRAMA DE ELECTRÓNICA
BOGOTÁ
2018
GENERACIÓN Y PUESTA EN MARCHA DE UN MODELO PARA LA
HOMOLOGACIÓN DE TERMINALES MÓVILES A TRAVÉS DEL DESARROLLO
DE UNA APLICACIÓN SOBRE EL SISTEMA OPERATIVO ANDROID
WBEYMAR CARVAJAL PINZÓN
COD: 20161027005
TESIS DE GRADO
DIRECTOR
PhD, JUAN CARLOS GÓMEZ PAREDES
UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS
MAESTRIA EN TELECOMUNICACIONES MÓVILES
FACULTAD DE INGENIERIA, PROGRAMA DE ELECTRÓNICA
BOGOTÁ
2018
Nota de Aceptación: ______________________________
______________________________
______________________________
______________________________
______________________________
______________________________
______________________________
Firma del presidente del jurado
______________________________
Firma del jurado
______________________________
Firma del jurado
Bogotá (19, 02, 2018)
A mi familia que siempre me ha apoya
Incondicionalmente
AGRADECIMIENTOS
Agradezco principalmente a mi familia, quienes me han apoyado en todo el
proceso de consecución de esta maestría. Al profesor Juan Carlos Gómez
Paredes, quien me ha prestado su ayuda y compromiso en el desarrollo de este
trabajo de investigación, y en general a todos los docentes de la Universidad
quienes entregaron un poco de su conocimiento para permitirnos avanzar en
nuestros propósitos profesionales.
CONTENIDOS
INTRODUCCIÓN ............................................................................................................................ 11
1. PLANTEAMIENTO DEL PROBLEMA .................................................................................... 12
2. JUSTIFICACIÓN ........................................................................................................................ 15
3. OBJETIVOS ................................................................................................................................ 17
3.1 Objetivo general ................................................................................................................... 17
3.2 Objetivos específicos .......................................................................................................... 17
4. MARCO TEORICO .................................................................................................................... 18
4.1 HOMOLOGACIÓN EN COLOMBIA .................................................................................. 18
4.1.1 RESOLUCIÓN CRT 087 DE 1997 ................................................................... 18
4.1.2 EJEMPLO DE APLICACIÓN DE SW, PARA EL DISEÑO DE UN ESQUEMA DE
HOMOLOGACIÓN EN UNA LINEA DE PRODUCIÓN. ............................................. 21
4.2 SISTEMA OPERATIVO ANDROID ................................................................................... 21
4.2.1 Versiones de Android ....................................................................................... 23
4.2.2 GOOGLE MAPS .............................................................................................. 25
4.2.3 EJEMPLOS DE APLICACIÓN ......................................................................... 26
5. METODOLOGIA ......................................................................................................................... 28
5.1 DISEÑO DEL SET DE PRUEBAS COMUNES QUE CONFORMARAN LA
APLICACIÓN MOVIL, TENIENDO EN CUENTA LA FRECUENCIA DE USO Y LAS
HERRAMIENTAS DISPONIBLES. .......................................................................................... 28
5.2 DISEÑO DE LA INTERFAZ GRAFICA Y FUNCIONAL DEL APLICATIVO. .............. 33
5.2.1 GENERAR LLAMADAS ................................................................................... 34
5.2.2 GENERAR SMS .............................................................................................. 37
5.2.3 INFORMACION DE MMS ................................................................................ 40
5.2.4 MENU DE THROUGHPUT .............................................................................. 42
5.2.5 MENÚ BATERIA .............................................................................................. 45
5.2.6 MENU DE DRIVE TEST .................................................................................. 49
5.2.7 MENÚ HARDWARE ........................................................................................ 53
5.2.8 INFORMACIÓN GENERAL ............................................................................. 56
5.3 EJECUCIÓN DE PRUEBAS CON LA APLICACIÓN ..................................................... 59
5.3.1 Generación de llamadas. ................................................................................. 59
5.3.2 Generación de SMS. ........................................................................................ 63
5.3.3 Información MMS ............................................................................................. 64
5.3.4 Prueba de throughput ...................................................................................... 66
5.3.5 Prueba de batería ............................................................................................ 66
5.3.6 Drive test ......................................................................................................... 68
5.3.7 Elementos de hardware ................................................................................... 71
5.3.8 Información general ......................................................................................... 74
5.4 ANALISIS DE RESULTADOS ........................................................................................... 75
6. APORTES DE LA INVESTIGACIÓN ...................................................................................... 76
TRABAJOS FUTUROS ................................................................................................................. 81
CONCLUSIONES ........................................................................................................................... 82
REFERENCIAS. ............................................................................................................................. 83
ANEXOS .......................................................................................................................................... 84
LISTA DE FIGURAS
Figura 1. Ventas teléfonos inteligentes segundo trimestre de 2017 ...................................... 13
Figura 2. Normas técnicas ............................................................................................................ 20
Figura 3. Versiones de Android .................................................................................................... 24
Figura 4. Diseño preliminar generación de llamadas ............................................................... 29
Figura 5. Diseño preliminar menú Throughput .......................................................................... 30
Figura 6. Diseño preliminar menú Drive test .............................................................................. 31
Figura 7. Diseño preliminar menú elementos de HW ............................................................... 32
Figura 8. Diseño preliminar menú General ................................................................................ 33
Figura 9. Configuración inicialización del administrador de llamadas ................................... 34
Figura 10. Diseño layouts menú llamadas ................................................................................. 35
Figura 11. Diagrama de flujo menú de llamada ......................................................................... 36
Figura 12. Configuración de inicialización del administrador de mensajes cortos ............... 37
Figura 13. Diseño layout menú SMS ........................................................................................... 38
Figura 14. Diagrama de flujo menú de SMS .............................................................................. 39
Figura 15. Configuración SmsManager menú información MMS ........................................... 40
Figura 16. Comparación servicio MMS activo ........................................................................... 40
Figura 17. Diseño layout menú información MMS .................................................................... 41
Figura 18. Diagrama de flujo menú de información MMS ........................................................ 42
Figura 19. Configuración PhoneStateListener menú throughput ............................................ 43
Figura 20. Velocidades y conversión a Mbps ............................................................................ 43
Figura 21. Diseño layout menú throughput ................................................................................ 44
Figura 22. Diagrama de flujo menú trhoughput ......................................................................... 45
Figura 23. Configuración inicial estado de la batería ................................................................ 46
Figura 24. Obtención y publicación nivel de batería ................................................................. 46
Figura 25. Configuración objeto de video ................................................................................... 47
Figura 26. Diseño layout menú batería ....................................................................................... 47
Figura 27. Diagrama de flujo menú batería ................................................................................ 48
Figura 28. Configuración PhoneStateListener menú drive test ............................................... 49
Figura 29. Llave de autenticación servicio Google Maps......................................................... 49
Figura 30. Configuración de maps en el view ............................................................................ 50
Figura 31. Configuración cliente API de localización ................................................................ 50
Figura 32. Diseño layout menú drive test ................................................................................... 51
Figura 33. Diagrama de flujo menú drive test ............................................................................ 52
Figura 34. Código lista de sensores soportados ....................................................................... 53
Figura 35. Obtención y publicación de información del acelerómetro ................................... 54
Figura 36. Búsqueda y publicación dispositivos cercanos WIFI ............................................. 54
Figura 37. Búsqueda y publicación dispositivos cercanos Bluetooth ..................................... 55
Figura 38. Método reproducción prueba de parlante ................................................................ 55
Figura 39. Diseño layouts menú HW ........................................................................................... 55
Figura 40. Diagrama de flujo menú elementos de HW............................................................. 56
Figura 41. Obtención IMEI y TAC ................................................................................................ 57
Figura 42. Código versión de android y zona horaria ............................................................... 58
Figura 43. Layout menú general .................................................................................................. 58
Figura 44. Diagrama de flujo menú general ............................................................................... 58
Figura 45. Ejecución set de llamadas Blade A602 .................................................................... 59
Figura 46. Ejecución set de llamadas Blade A320 .................................................................... 61
Figura 47. Ejecución set de SMS Blade A602 ........................................................................... 63
Figura 48. Ejecución set de SMS Blade A320 ........................................................................... 64
Figura 49. Información de MMS Blade A602 ............................................................................. 65
Figura 50. Información de MMS Blade A320 ............................................................................. 65
Figura 51. Ejecución prueba throughput Blade A602 ............................................................... 66
Figura 52. Ejecución prueba batería Blade A602 ...................................................................... 67
Figura 53. Ejecución prueba batería Blade A320 ...................................................................... 67
Figura 54. Drive test Blade A602 ................................................................................................. 68
Figura 55. Elementos de hardware soportados Blade A602 ................................................... 72
Figura 56. Funcionamiento elementos de hardware soportados Blade A602 ...................... 72
Figura 57. Elementos de hardware soportados Blade A320 ................................................... 73
Figura 58. Funcionamiento elementos de hardware soportados Blade A320 ...................... 73
Figura 59. Información general Blade A602 ............................................................................... 74
Figura 60. Información general Blade A320 ............................................................................... 74
LISTA DE TABLAS
Tabla 1. Lista de elementos menú MMS .................................................................................... 40
Tabla 2. Lista de sensores menú de elementos de HW ........................................................... 53
Tabla 3. Lista de elementos menú general ................................................................................ 57
Tabla 4. Resultados set de llamadas Blade A602 .................................................................... 60
Tabla 5. Resultados set de llamadas Blade A320 .................................................................... 61
Tabla 6. Análisis drive test Blade A602 ...................................................................................... 69
Tabla 7. Beneficios utilización de la aplicación HomologationTrial ........................................ 76
INTRODUCCIÓN
En el siguiente documento se plantea el diseño de un aplicativo Android, que
permite facilitar el proceso de homologación, que se realiza para todos los
terminales móviles que pretenden ingresar en funcionamiento en las redes
celulares de los diferentes operadores (Claro, Tigo, Movistar, etc.). Dentro del
proceso de homologación existen muchos procesos que se pueden automatizar, y
que con esta aplicación se optimizan y además ven una mejora en el tiempo de
ejecución. La reducción de tiempo es de suma importancia debido a factores
económicos de los diferentes actores que participan en este proceso.
En el desarrollo de la investigación, se realizó primero un estudio para encontrar
los menús de pruebas más adecuadas, de tal manera que puedan ser ejecutadas
automáticamente y así incluirlas en la aplicación que se propone. La aplicación se
desarrolló con la herramienta de programación libre “Android studio”, que entrega
todas las librerías necesarias para el diseño de aplicaciones en el sistema
operativo Android. Finalmente, se realizó una prueba de funcionamiento con una
versión de software de mantenimiento de los equipos ZTE Blade A602 y ZTE
Blade A320, con el fin de evaluar la efectividad de la herramienta en un proceso
de homologación de terminales móviles.
El presente documento, entrega el planteamiento del problema de la investigación,
los objetivos que se deben cumplir al final de esta, un marco teórico con los temas
más relevantes relacionados con el proyecto, y finalmente la metodología con la
que se abordó la investigación, en donde se incluye los resultados de la misma y
los beneficios que trajo la utilización de esta herramienta en la ejecución de las
pruebas.
1. PLANTEAMIENTO DEL PROBLEMA
Los dispositivos que se conectan a las redes de telefonía celular como muchos
otros deben someterse a un proceso conocido como homologación, en el cual se
valida el correcto funcionamiento de ciertas características y el cumplimiento de
estándares nacionales e internacionales. En el caso de los dispositivos celulares,
los equipos deben aprobar un proceso de homologación para que se les permita
funcionar de forma legal en las diferentes redes móviles.
En Colombia por ejemplo, los equipos deben pasar por dos tipos de
homologación. La primera relacionada con el gobierno colombiano y con la entidad
encargada de regular el funcionamiento de las telecomunicaciones, la CRC
(Comisión de regulación de comunicaciones), esta entidad certifica que los
equipos cumplen con los mínimos requisitos técnicos establecidos por las leyes
nacionales, de tal forma que solo se permite la comercialización y distribución de
aquellos dispositivos que pasan las pruebas y tienen la aprobación por parte de la
entidad. [1] La segunda homologación se desarrolla entre fabricante (Samsung,
Iphone, Huawei, ZTE, etc.) y operadores, con este proceso se busca que los
terminales funcionen de la mejor manera en la red de cada operador, ya que cada
una tiene sus características específicas de cobertura, bandas de frecuencia
utilizadas, funciones de red (MIMO, VoLTE, etc.) y prioridades de acuerdo al
usuario, todo esto con el fin de optimizar el funcionamiento de sus propias redes.
Cuando hablamos de tecnologías que han revolucionado al mundo en los últimos
años, una de las más importantes es la de los teléfonos inteligentes, que a día de
hoy son sino indispensables, una herramienta que todos debemos tener, ya que
nos proveen un sin número de posibilidades, desde momentos de ocio, una fuente
de investigación y lo más importante un medio de comunicación con todo el
mundo sin importar el lugar en el que nos encontremos. Todos estos desarrollos
en los teléfonos inteligentes se llevan a cabo por medio de aplicaciones que hacen
uso de los diferentes elementos de hardware que lo componen, y que en su
mayoría en el mercado de hoy utilizan el sistema operativo Android. De acuerdo a
las estadísticas publicadas por la firma estadounidense Gartner para el segundo
trimestre de 2017, Android lideraba el mercado con una cuota de 87,7%
aproximadamente 366,2 millones de unidades vendidas. [2] La figura 1 muestra
las ventas de los diferentes fabricantes durante este segundo trimestre.
Figura 1. Ventas teléfonos inteligentes segundo trimestre de 2017
Fuente: Gartner (Agosto de 2017) [2]
Es por esto que el desarrollo de aplicaciones Android ha venido en auge durante
los últimos años, además de que las plataformas de desarrollo son de uso libre lo
cual hace que sean las preferidas por los desarrolladores.
En muchos casos los procesos de homologación se ven retrasados por la cantidad
de pruebas que se deben realizar con el fin de obtener las aprobaciones
necesarias antes de alcanzar la certificación. Razón por la cual en este documento
se muestra el desarrollo de una aplicación móvil, que permite optimizar los
procesos de homologación en teléfonos inteligentes, por medio de la
automatización de una serie de pruebas comunes a todos los procesos. Estas
pruebas son ejecutadas por la aplicación, después de ser configuradas por el
usuario, permitiéndole mantener un control del funcionamiento del equipo y tomar
decisiones de manera más rápida cuando se detecta una anomalía. Se pretende
con este proyecto además de ayudar al ingeniero homologador en la ejecución de
un set de pruebas, el disminuir los tiempos de obtención de las aprobaciones por
parte de los operadores, que son un punto crítico durante los procesos, ya que
una mínima demora puede retrasar las líneas de producción de las fábricas y
provocar que los productos no se encuentren en el mercado en las fechas
requeridas para obtener una mayor demanda de ventas. ¿Qué beneficios
representar el diseño de un aplicativo Android, para el proceso de homologación
realizado entre fabricante y operador?
2. JUSTIFICACIÓN
La tecnología es hoy en día una parte fundamental de la vida de las personas, la
podemos encontrar en una gran cantidad de actividades cotidianas, desde hacer
una compra en un supermercado hasta tomar un transporte. Es así como día a día
se generan nuevos conocimientos que permiten la actualización de las tecnologías
y procesos ya existentes, para hacerlos más eficientes o reemplazarlos por
nuevos y mejores.
Desde hace unos años se está viviendo una gran revolución de las
comunicaciones inalámbricas, y todos estos avances se los debemos a grandes
inventores como Marconi, Bell y Tesla entre otros que gracias a sus
investigaciones y desarrollos permitieron que las comunicaciones inalámbricas
llegaran hasta donde se encuentran [3].
Las redes de telefonía celular han transformado el acceso de las personas a los
servicios de telefonía, ya que les permiten estar en contacto el 100% del tiempo y
además desde la tercera generación les ofrecen otro tipo de servicios que les
dejan realizar un gran número de actividades a través del internet o de un sinfín de
aplicaciones que facilitan la ejecución de tareas.
Con la aparición de sistemas operativos como Android en los dispositivos
inteligentes, el uso de estos terminales se ha vuelta casi indispensable para
cualquier persona que esté en contacto con la tecnología. Android es un sistema
operativo para dispositivos móviles inteligentes propietario de Google, que se
encuentra en la gran mayoría de equipos del mercado, gracias a su versatilidad,
gran cantidad de funciones, facilidades para el desarrollo y economía. Porque es
claro que la utilización en masa de dispositivos con sistema operativo Android, es
porque a los fabricantes se les facilita su utilización, y en ningún caso significa que
sea de mala calidad, sino simplemente que se puede adaptar al hardware
presente en cualquier Smartphone.
Dados estos acontecimientos y la necesidad que ha tomado la humanidad por
recibir un crecimiento tecnológico rápido y constante, obliga a los investigadores a
presentar propuestas innovadoras y de gran alcance para suplir las necesidades
de las personas.
El proceso de homologación es un ámbito muy importante que se debe realizar en
todos los sectores tecnológicos para validar el correcto funcionamiento de los
dispositivos en los diferentes ambientes a los que se encontraran expuestos
durante su ciclo de vida. En el caso de las telecomunicaciones, los dispositivos
móviles (Smartphone, Smartwatch, módems, etc.), deben someterse a este
proceso para garantizar un nivel de calidad adecuado a los usuarios finales. Es
importante además, porque el funcionamiento en líneas generales de un
dispositivo lleva consigo la reputación de los diferentes fabricantes, y al mismo
tiempo del operador que presta el servicio sobre dicho terminal, lo que significa
que una homologación bien llevada, desembarque en el éxito comercial de un
producto o a una percepción de mala calidad.
Para la homologación de un dispositivo, es necesaria la ejecución de un gran set
de pruebas (Llamadas, SMS, MMS, drive test, calidad de servicio, etc.) que
garantizaran un correcto funcionamiento. Muchas de estas pruebas conllevan un
gran tiempo en su ejecución y análisis, por lo cual muchas veces los procesos se
ven retrasados, lo que puede generar un gran impacto, ya que en la mayoría de
ocasiones, los productos se requieren en el mercado con prioridad, y al no
completar la homologación en los tiempos estipulados en un principio, se demora
su lanzamiento en el mercado.
Con el desarrollo de este aplicativo, se pretende como objetivo fundamental
facilitar la ejecución de algunas de las pruebas necesarias durante el proceso de
homologación de un terminal móvil, entregándole al ingeniero homologador una
herramienta que le permita optimizar los procesos y con esto disminuir los
tiempos de aprobación.
3. OBJETIVOS
La necesidad de desarrollar un aplicativo móvil que permita optimizar los procesos
de homologación existentes entre fabricantes y operadores, plantea a la presente
propuesta de investigación, los siguientes objetivos a desarrollar.
3.1 Objetivo general
Generar y poner en marcha un modelo que permita optimizar los
procesos de homologación para teléfonos inteligentes, a través del
desarrollo de un aplicativo sobre el sistema operativo Android.
3.2 Objetivos específicos
Analizar los procesos de homologación existentes en los operadores
móviles colombianos, para el diseño de un set de pruebas comunes que
conformaran la aplicación móvil.
Desarrollar la interfaz gráfica y funcional del aplicativo, utilizando la
herramienta libre de programación “Android studio”
Validar el funcionamiento de la aplicación en un entorno de pruebas real,
para conocer su impacto definitivo.
4. MARCO TEORICO
4.1 HOMOLOGACIÓN EN COLOMBIA
De acuerdo a lo señalado en el Articulo 22, numeral 8, de la ley 1341 de 2009,
corresponde a la Comisión de regulación de comunicaciones determinar los
estándares y certificados de homologación internacional de equipos, terminales y
otros elementos técnicos indispensables para el establecimiento de redes y la
prestación de servicios de telecomunicaciones aceptables en el país, así como
señalar las entidades o laboratorios nacionales autorizados para homologar bienes
de esta naturaleza.
Durante los últimos años, se han realizado muchos ajustes a la regulación
referente al campo de las homologaciones en telecomunicaciones, con el fin de
que se mantengan actualizadas de acuerdo a los mercados internacionales y a los
nuevas tecnologías en las redes, como la adjudicación de espectro que se realizó
en 2013 para las bandas AWS (1700-2100 MHz) y banda 7 (2500-2690 MHz), por
tanto era necesario que dentro del proceso de homologación establecido, se
verificara el cumplimiento de las normas y estándares aplicable a estas nuevas
bandas . En 2014 se expidió la resolución CRC 4507, en la cual se modificaron y
adicionaron los numerales 13.1.2.6 y 13.1.2.7 al capítulo I del título XIII, y se
adiciono el Anexo 013 a la resolución CRC 087 de 1997, finalmente con la
resolución 5031 de 2016, se modifica el artículo 13.1.2 de la resolución CRT 087
de 1997 y la Tabla 1, referente a normas técnicas, contenidas en el artículo
13.1.2.6 del Capítulo I del título XIII de la misma resolución [4].
4.1.1 RESOLUCIÓN CRT 087 DE 1997
En el título XIII, capítulo I, se establecen todas las disposiciones para la
homologación de equipos terminales de telecomunicaciones en Colombia.
El interesado en homologar un equipo terminal, debe presentar ante la CRC con el
lleno de requisitos por cada modelo de terminal, presentados en esta resolución o
cualquier otra norma que entre a modificarlos. En el caso de que un modelo ya
homologado, sea objeto de una modificación estructural técnica, que no afecte su
funcionamiento o interacción con la red o el espectro radioeléctrico, y siga
cumpliendo las normas bajo las cuales fue homologado originalmente, se debe
obtener una ampliación de la homologación por parte de la comisión de regulación
de comunicaciones. En caso de que se altere su funcionamiento, interacción con
la red o el espectro radioeléctrico que utiliza, debe realizarse un nuevo proceso de
homologación[5].
Los requerimientos establecidos por la CRC para la homologación de terminales
inalámbricos, es decir para equipos que radian ondas electromagnéticas en la
gama de frecuencias de 300 Hz a 3GHz, además de las normas técnicas que
fueron actualizadas en la resolución 5031 de 2016 y que se muestran en la figura
2, se debe certificar el cumplimiento de los límites de exposición establecidos en el
estándar IEEE Std C.95.1 o por el ICNIRP para los niveles de seguridad con
respecto a la exposición humana a los campos electromagnéticos (CEM) de
radiofrecuencia. Esta certificación puede obtenerse mediante la aplicación de los
procedimientos de medición de la tasa especifica de absorción (SAR) según lo
dispuesto por la UIT en la recomendación K.52, numeral 7 [5].
Figura 2. Normas técnicas
Fuente: Resolución 5031 de 2016 [4].
Después del cumplimiento de los requerimientos establecidos, la CRC procederá a
efectuar la verificación del cumplimiento a partir de los certificados de conformidad
recibidos, y en caso de que estos se ajustes a lo requerido, efectuara el registro en
la base de datos habilitada para tal fin, después procederá a informar al solicitante
y finalmente a publicar en la página WEB, la comunicación oficial de la
homologación del equipo incluyendo el número de registro asignado. Este registro
tiene una vigencia indefinida[6].
En caso de que algún equipo cause daño a la red de telecomunicaciones del
estado, interfiera en la prestación de algún servicio de telecomunicaciones,
incumpla los límites de radiación o la información suministrada para la
homologación del equipo sea inconsistente, la CRC ordenara la cancelación del
registro y la persona natural o jurídica, que incurra en esta acción estará sujeta a
las sanciones previstas en el artículo 53 del decreto ley 1900 de 1990.
4.1.2 EJEMPLO DE APLICACIÓN DE SW, PARA EL DISEÑO DE UN ESQUEMA
DE HOMOLOGACIÓN EN UNA LINEA DE PRODUCIÓN.
Un equipo de estudiantes del instituto de tecnología de aeronáutica brasileño,
desarrollaron un software embebido en tiempo real, con el fin de general una
inspección final y el análisis de causas para resolución de problemas. Todo esto a
través de la generación de un reporte de no conformidad durante la inspección
final.
La creación de esta herramienta permitió a la organización encargada, a través de
los reportes de no conformidad, generar correcciones encontradas en
componentes específicos, en camino de diseñar un esquema de homologación, a
través de la reparación de todos los registros de no conformidad. El sistema fue
diseñado para verificar, validar y homologar el desarrollo de sistemas de software
para computadoras, con la capacidad de complementar la información reportada
en el informe de no conformidad en la inspección final, con el objetivo de prevenir
la propagación errores en operación.
Por medio de la utilización de una inspección final y el análisis de causas para la
resolución de problemas, se ha mejorado significativamente la calidad y
productividad, previniendo la introducción de defectos en nuevos productos, por
ejemplo[7].
4.2 SISTEMA OPERATIVO ANDROID
A mediados de junio del 2005 Google compró una pequeña compañía llamada
AndroidInc, la cual se dedicaba al desarrollo de aplicaciones para dispositivos
móviles, en aquellos tiempos dicha compañía era desconocida para el mundo de
las tecnologías, pero el grupo de fundadores entre ellos Andy Rubín quien tenía
gran experiencia en telecomunicaciones, en plataformas web y aplicaciones
móviles y luego sería el director de división de plataformas móviles de Google,
desarrollaron las primeras muestras de Android que no eran muy atractivas, pero
que pasado el tiempo fueron evolucionando y empezaron a aparecer los primeros
demos no oficiales e información del prototipo con un nivel importante de
fiabilidad. Toda información fue guardada en reserva hasta que en noviembre del
2007 se anunciara la creación de la Open Handset Alliance, una organización
cuyo objetivo fue la difusión de la plataforma móvil Android. Con esfuerzos de
fabricantes de equipos y prestadores de servicio tecnológico lograron lanzar el
primer sistema operativo abierto para móviles, que no estaría atado a una marca o
equipo, sino que gracias a su kernel de Linux, podría ser adaptado a casi cualquier
dispositivo.
La primera versión de un Teléfono móvil con Android fue el G1 T-Mobile G1/HTC
Dream anunciado el 23 de septiembre del 2008 que se lanzó en el mercado
estadounidense y cuyas características se pueden observar en la página oficial de
HTC. Así mismo se lanzó una versión DevPhone 1 con una serie de
características adicionales que les permiten a los desarrolladores tener privilegios
(root) en la administración de móvil y sus productos. Otro modelo es el HTC
Magic ,fue una versión sin teclado anunciado el 18 de febrero de 2009 la cual
estaría disponible en España y Francia a partir de Abril de 2009 y se estimuló así
que se lanzaran al mercado seis nuevos teléfonos con sistema operativo Android,
además de HTC otras marcas como Lenovo, Sony Ericsson, Motorola, LG, y
Samsung [8].
Android es un sistema operativo inicialmente pensado para teléfonos móviles, al
igual que iOS, Symbian y Blackberry OS. Su gran diferencia es que está basado
en Linux, un núcleo de sistema operativo libre, gratuito y multiplataforma.
El sistema permite programar aplicaciones en una variación de Java llamada
Dalvik. El sistema operativo proporciona todas las interfaces necesarias para
desarrollar aplicaciones que accedan a las funciones del teléfono (como el GPS,
las llamadas, la agenda, etc.)
Existe además un entorno de desarrollo SDK, que proporciona un plugin para el
IDE de Eclipse y APIs necesarias para empezar a desarrollar aplicaciones en la
plataforma Android usando un lenguaje de programación java el cual incluye un
emulador de dispositivo, herramientas para la depuración, memoria y rendimiento
de perfiles.
Entre sus principales características encontramos una máquina virtual que es
optimizada para dispositivos móviles, SqLite para almacenamiento de datos
estructurados, soporte para medios con formato común de audio, videocode,
imágenes planas, Bluetooth, EDGE, 3G y Wifi (dependiente del hardware),
Cámara, GPS, brújula, y acelerómetro. Posee un ambiente rico de desarrollo
incluyendo un emulador de dispositivo, herramientas para depurar, perfiles de
memoria y rendimiento, y un plugin para el IDE Eclipse. Todas estas herramientas
han sido incluidas en los diferentes SW desarrollados para la programación de
aplicaciones en el sistema operativo Android, lo que permite que exista una gran
variedad de opciones a la hora de diseñar nuevas aplicaciones. Entre estas
encontramos Eclipse, Androidstudio o Xamarinstudio[9].
Entre otras opciones que encontramos en Android, el Play store permite que las
aplicaciones sean, gratuitas o de pago, todas se encuentran almacenadas en el
servidor de Google, y solo hace falta pagar una pequeña cuota de acceso para
poder publicar todas las aplicaciones que se quiera.
4.2.1 Versiones de Android
El sistema operativo Android se inició con el lanzamiento de Android beta en
noviembre de 2007. Su primera versión comercial, Android 1.0 fue lanzada en
septiembre de 2008. Este sistema operativo móvil desarrollado por Google y la
Open Handset Alliance ha lanzado diversas versiones desde su origen. Estas
actualizaciones típicamente corrigen fallos de programa y agregan nuevas
funcionalidades. Desde abril de 2009, Las versiones de Android han sido
desarrolladas bajo un nombre en clave y lanzamiento en orden alfabético:
Cupcake, Donut, Éclair, Froyo, Gingerbread, Honeycomb, Ice CreamSandwich,
JellyBean, Kitkat, lollipop, Marshmallow, Nougat y la más reciente versión que
saldrá al mercado en 2018 “Oreo”. Como se puede ver, los nombres de todas las
versiones de Android, están relacionadas con postres[8]. La figura 3, muestra
todas las versiones de Android existentes hasta el día de hoy.
Figura 3. Versiones de Android
Android posee una amplia comunidad de desarrolladores y usuarios los cuales se
reúnen en foros y grupos para intercambiar información, así como en salas de IRC
como en el servidor freenode en el canal Android.
Además de estas herramientas de comunicación los desarrolladores anualmente
pueden participar en eventos organizados por Google como lo es el Google IO y la
competencia de desarrollo de aplicaciones AndroidDeveloperChallenge, por ser un
sistema operativo de código abierto, se pueden producir desarrollos con
requerimientos específicos de empresas o instituciones, generando de esta
manera empleos con excelente calidad y evitando monopolios. Todas las
aplicaciones que se crean con Android se pueden compartir con otros usuarios de
forma libre o vender para poder financiar dichos desarrollos.
4.2.2 GOOGLE MAPS
Google Maps es un servidor de aplicaciones de mapas en la Web. En la que se
ofrecen imágenes de mapas desplazables, fotos satelitales del mundo, como
también la ruta entre diferentes ubicaciones o imágenes con sus calles (Google
Street View). Tiene gran parecido a Google Earth, una aplicación
Windows/Mac/Linux que ofrece vistas del globo terráqueo, sea de día o de noche,
pero que no es fácil de integrar a páginas Web. Está disponible para Android y
Java ME.
Dentro de sus características básicas google maps ofrece la capacidad de
acercamientos o alejamientos para mostrar un mapa por medio de una barra
deslizante ya sea en la pantalla o con el mouse. Los usuarios pueden ingresar una
dirección, una intersección o un área en general para buscar en el mapa.
Los resultados de la búsqueda pueden ser restringidos a una zona, gracias a
Google Local. Las coordenadas de Google maps están en el sistema WGS84 y
se nos mostrará la latitud y la longitud, positiva para Norte y Este, negativa para
Sur y Oeste.
En abril de 2005, Google añadió un RideFinder (en español, indicador de
vehículo), en el cual una persona puede ubicar un taxi o un transporte público en
una gran ciudad en tiempo real. En junio de 2005, los mapas de carreteras de los
Estados Unidos, Puerto Rico, Canadá y el Reino Unido fueron integrados a
Google Maps.
A mediados de julio de 2005, Google comienza la versión japonesa de Google
Maps y Google Local.
El 22 de julio de 2005, Google lanza una vista dual de su Google Maps. Esta vista
combina el par y la vista satelital con mapas ilustrados y los nombres de calles en
las imágenes del mundo real. Esto hace más fácil encontrar rutas entre dos puntos
[10].
La API de google maps ha sido implantada en localización de rutas y medida de
distancias, esta interfaz ha sido utilizada en un amplio rango de proyectos que se
encuentran disponibles en el mercado. Uno de los más populares ha sido un
sistema administrador móvil de desastres, utilizando Android, para tratar con los
desastres naturales muy recurrentes en filipinas. Existen muchas aplicaciones
similares y han cambiado el camino investigativo de muchos proyectos[10].
4.2.3 EJEMPLOS DE APLICACIÓN
El desarrollo de aplicativos en el sistema operativo Android es sumamente popular
hoy en día, por las facilidades que se tienen para su desarrollo, a continuación se
enumeraran algunas aplicaciones que realizan mediciones técnicas a los
terminales móviles:
a. SIM card: Esta aplicación muestra información relacionada con la SIM card.
b. G net track: Entrega información relacionada con los niveles de señal
presentes en diversas tecnologías, los handover que ocurren, información
de celdas vecinas, también permite la configuración de pruebas de
establecimiento de llamada y sesiones de datos en su versión pro, además
traza un mapa de los niveles de señal presentes en la zona que nos
encontremos. Es una aplicación muy utilizada por los ingenieros de RF,
quienes deben evaluar la locación de nuevas estaciones base.
c. Speed test velocidad: Aplicación utilizada para medir la velocidad de
conexión de los dispositivos, ya sean móviles o Wi-Fi.
d. Antutu: Es una aplicación mundialmente conocida para evaluar el
desempeño de hardware de los terminales móviles, entregando un puntaje
para cada uno dependiendo del comportamiento. Usualmente es utilizado
para hacer comparaciones, mostrando información relacionada con el
hardware de cada uno de los dispositivos involucrados en la comparación.
e. Calidad celular 2.0: Es una APP perteneciente al ministerio de
telecomunicaciones colombiano, que evalúa y compara la calidad de
servicio de voz y datos de los operadores. La aplicación tiene como
objetivos mostrar las ubicaciones más frecuentes donde se presentan
caídas de llamada, degradación de datos y puntos de cogestión. Todo esto
a nivel general, es decir realiza las mediciones con equipos de diferentes
fabricantes, para encontrar y reportar a los operadores las zonas de mala
calidad de servicio.
Con Android se pueden realizar una infinidad de aplicaciones, como el control de
un robot a través de una interfaz virtual utilizando comunicación Wi-Fi, 4G o
incluso bluetooth [11], la detección de humedad y temperatura para la
automatización de irrigación y el control de un cultivo remotamente [12], o incluso
para monitorear la frecuencia respiratoria basado en la información proveniente de
sensores externos [13]. Todo esto demuestra que Android como herramienta
tecnológica se ha convertido en una revolución que se implementa en todos los
campos para ayudar en su desarrollo.
5. METODOLOGIA
En este capítulo se hará la descripción del desarrollo de cada uno de los objetivos
que se debieron cumplir para la presente investigación. Se desglosara objetivo por
objetivo mostrando como fueron cumplidos cada uno.
5.1 DISEÑO DEL SET DE PRUEBAS COMUNES QUE CONFORMARAN LA
APLICACIÓN MOVIL, TENIENDO EN CUENTA LA FRECUENCIA DE USO Y LAS
HERRAMIENTAS DISPONIBLES.
Para la selección del set de pruebas comunes necesario para el desarrollo del
aplicativo Android, se debió realizar un estudio de los diferentes procesos de
homologación presentes en el mercado colombiano, para establecer cuáles eran
las pruebas e información que eran requeridas en todos los procesos y que
podrían ayudar de manera consistente en la ejecución del proceso.
Se encontró que todos los operadores que prestan servicios de telefonía móvil,
tienen un proceso de homologación propio, que difiere en mayor o en menor
medida uno de otro, dependiendo de las características propias de cada red y de
los servicios que presten. Por ejemplo para operadores como ETB o Avantel, que
prestan servicios sobre redes de telefonía móvil propias solamente en LTE, el
proceso de homologación es menos extenso. En cambio para operadores como
Movistar, TIGO o Claro que prestan servicios sobre todas las tecnologías (2G, 3G
y 4G), la homologación es más extensa, debido a que se debe validar que los
terminales soporten una gran cantidad de características propias de cada red.
Dentro de los set de pruebas presentes en cada uno de los procesos de
homologación, se pudo encontrar algunas similitudes en cuanto a las pruebas
realizadas, hay que aclarar que los set de pruebas específicos de cada operador
no se presentan en este documento ya que son información confidencial.
Finalmente, se determinó diseñar el aplicativo con las siguientes pruebas e
información que son comunes a todos los set de pruebas de los operadores, y que
se podían realizar u obtener con un terminal con sistema operativo Android:
I. Generación de llamadas: Generar un menú que permita establecer
llamadas automáticamente a los números de servicio de los diversos
operadores, con el objetivo de evaluar el comportamiento de las llamadas
en el terminal, los cambios de tecnología que se pueden producir, si se
pierde conexión de datos y los niveles de señal. La figura 4 muestra el
diseño preliminar de este menú.
Figura 4. Diseño preliminar generación de llamadas
II. Generación SMS: Generar un menú que permita generar SMS (Short
Message Service). Con el objetivo de validar el correcto envió y recepción
de los mismos, en escenarios como llamada activa o codificación de 7 bits
(necesaria para utilizar solamente los 128 primeros caracteres de ASCCI).
III. Información MMS: Generar un menú que despliegue información relevante
relacionada con los MMS (Multimedia Message Service). Esta información
es importante para conocer cómo están funcionando este tipo de mensajes
en los terminales. Por ejemplo, el tamaño máximo que pueden enviar, que
siempre es un requisito por parte de los operadores, con el objetivo de no
saturar la plataforma, y de igual forma la altura y el ancho máximo de una
imagen que se puede enviar por este medio.
IV. Menú Throughput: Una de las pruebas más comunes e importantes que se
ejecutan durante un proceso de homologación, es la validación de la
calidad de servicio, en cuanto a velocidad de tráfico tanto en subida
(uplink), como en bajada (downlink). Esto es de suma importancia ya que
permite conocer si el terminal está cumpliendo con los estándares
internacionales (3GPP) relacionados con cada tecnología. Para el caso
particular de Colombia se evalúa este ítem en HSPA+ y LTE, que son las
tecnologías que se utilizan para descarga de contenido en la red móvil.
Este menú deberá permitir monitorear la velocidad de subida y bajada en
tiempo real, junto con una gráfica que permitirá evaluar el desempeño de
toda la prueba al terminarla. Igualmente se incluirá una opción para
controlar el tiempo y así tener diferentes posibilidades. La figura 5 muestra
el diseño preliminar de este menú:
Figura 5. Diseño preliminar menú Throughput
V. Menú Drive test: Otra de las pruebas importantes para el desarrollo de un
proceso de homologación, es el drive test. Este es un recorrido en carro por
un área de cobertura diseñada específicamente con este objetivo, en la cual
se presentan una gran cantidad de eventos relacionados con la cobertura,
como cambios de tecnología (handover), perdidas de servicio, zonas de
bajos niveles de señal pero con un piso de ruido muy bajo (campo lejano),
zonas de caídas de llamada, etc. Todo esto con el objetivo de evaluar el
comportamiento de un terminal ante todos estos posibles escenarios.
Este menú permitirá monitorear los diferentes eventos que ocurran durante
el recorrido, poniendo un marcador sobre el mapa para saber dónde
ocurrieron y así determinar si fueron normales al finalizar la prueba.
Igualmente permitirá generar llamadas y mostrara los niveles de señal y la
tecnología en tiempo real para tener un control más fácil. La figura 6
muestra el diseño preliminar de este menú:
Figura 6. Diseño preliminar menú Drive test
VI. Menú batería: Para evaluar la duración real de la batería en los terminales.
Es necesario ejecutar ciertas pruebas, que permiten dar una idea de la
duración de la batería en dos diferentes escenarios. Uno de esto escenarios
es con llamada activa en tecnología 3G y 2G, el otro es con un streaming
activo, es decir un tráfico de downlink constante y un video
reproduciéndose. Esto es necesario conocerlo, ya que es un aspecto que
se tiene muy en cuenta por los usuarios en el momento de escoger un
equipo, igualmente al hacer una comparación con equipos de
características similares, se puede deducir si el gasto de batería es el
correcto.
VII. Menú elementos de HW: Todo terminal móvil, tiene ciertos elementos de
hardware incluidos en su construcción, como lo son el WIFI el Bluetooth o el
sensor de luz. La calidad y la cantidad de estos elementos depende de la
gama del terminal. Es necesario por tanto conocer cuáles son los
elementos de hardware que son incluidos dentro de un terminal y si estos
están funcionando de manera correcta. Con este menú se pretende
conocer los sensores y dispositivos provistos en cada terminal y de qué
manera funcionan. La figura 7 muestra el diseño preliminar de este menú:
Figura 7. Diseño preliminar menú elementos de HW
VIII. Menú general: Dentro de las muchas pruebas que se deben realizar en un
proceso de homologación, existe cierta información del terminal, que es
necesario tener presente. Dentro de esta información se puede destacar, el
IMEI del equipo, el TAC, el PLMN o el serial de la SIM card. La figura 8
muestra el diseño preliminar de este menú:
Figura 8. Diseño preliminar menú General
5.2 DISEÑO DE LA INTERFAZ GRAFICA Y FUNCIONAL DEL APLICATIVO.
Después de concluido el diseño preliminar del menú de la aplicación, se pasó al
diseño de la interfaz gráfica y funcional de la aplicación utilizando la herramienta
de programación "Android studio". En los siguientes apartes, se hará una
explicación más detallada del diseño y programación de cada uno de los menús.
Incluyendo las clases y bibliotecas que se utilizaron en cada uno:
5.2.1 GENERAR LLAMADAS
Para acceder a los servicios relacionados con telefonía en los terminales que
utilizan el sistema operativo Android, es necesario incluir la biblioteca
"android.telephony.TelephonyManager", que permite el acceso a todos los
servicios como llamadas, SMS, MMS, etc. Para tal fin se debe inicializar un objeto
de tipo "TelephonyManager" y el servicio "TELEPHONY_MANAGER". Con esta
configuración el terminal ya estará habilitado para monitorear los diferentes
estados del teléfono, ahora es necesario generar un "PhoneStateListener"
indicando cuales son los estados del teléfono, de los cuales se recibirá
información cada vez que se produzca un cambio en ellos. La figura 9, muestra la
configuración del "TelephonyManager" de este menú:
Figura 9. Configuración inicialización del administrador de llamadas
Los dos estados del teléfono que se monitorean en el menú de teléfono son
“LISTEN_CALL_STATE”, que entrega tres estados diferentes cuando el teléfono
inicia una llamada.
A. IDLE: Entrega este estado cuando el terminal no tiene ninguna
llamada activa
B. RINGING: Entrega este estado cuando está recibiendo una llamada
C. OFFHOCK: Entrega este estado cuando se activa una llamada
El otro estado que se monitorea es el “LISTEN_SIGNAL_STRENGTHS”, que
captura información cada vez que ocurre un cambio en los niveles de señal, no
importa la tecnología.
Con la lectura de estos estados se diseñó un algoritmo que permite generar un set
de llamadas continuamente, es decir se termina una llamada y automáticamente
se inicia una nueva, hasta completar el número de llamadas establecidas por el
usuario.
Las líneas a las cuales se generan las llamadas de prueba, son usualmente las
líneas de servicio de los diferentes operadores, por tanto se generó un spinner que
despliega varias opciones de llamada dependiendo del operador en el cual se
realice el test.
Se encontró además que por políticas de seguridad de Android no es posible
finalizar una llamada manualmente, por lo cual para determinar si una llamada ha
sido exitosa o fallida se implementó un temporizador de acuerdo a la duración de
la llamada en cada una de las líneas de servicio.
Finalmente, al finalizar el set de llamadas se genera un informe donde se muestra
si las llamadas fueron ejecutadas exitosamente, la tecnología en la cual se
encontraba cuando la llamada termino, si la conexión a datos estaba activa y el
nivel de señal. Toda esta información es importante ya que permite deducir las
razones de las caídas de llamadas y conocer cómo se está comportando el
terminal durante el establecimiento de llamadas. La figura 11, corresponde al
diagrama de flujo de este menú y la figura 10, muestra el diseño final, de los 2
layouts correspondientes a este menú.
Figura 10. Diseño layouts menú llamadas
Figura 11. Diagrama de flujo menú de llamada
5.2.2 GENERAR SMS
Al igual que en el menú de generar llamadas, para el envío de mensajes cortos en
el sistema operativo Android, es necesario incluir la biblioteca
“android.telephony.TelephonyManager”. Igualmente se inicializa un objeto de tipo
“TelephonyManager” y el servicio "TELEPHONY_MANAGER". Con esta
configuración el terminal ya estará habilitado para monitorear los diferentes
estados del teléfono. Para este caso en lugar de inicializar un
“PhoneStateListener”, se utiliza un objeto de tipo “BroadcastReceiver”, este
permite mantener un monitoreo de los estados del teléfono, aun cuando la
aplicación este en segundo plano. Para el caso de este menú se generaron 2
“BroadcastReceiver”, uno para monitorear los SMS salientes y otro para los
entrantes. La figura 12, muestra la configuración del “TelephonyManager” de este
menú.
Figura 12. Configuración de inicialización del administrador de mensajes cortos
Los estados que nos provee Android y se pueden producir cuando se envía un
mensaje de texto se enumeran a continuación:
A. RESULT_OK: El terminal ha enviado el mensaje de texto correctamente.
B. RESULT_ERROR_GENERIC_FAILURE: Se genera cuando se produce un
error en él envió del mensaje, usualmente por que no se tiene saldo para
realizar él envió.
C. RESULT_ERROR_NO_SERVICE: Se produce cuando el terminal esta
fuera de servicio, para enviar el mensaje.
D. RESULT_ERROR_NULL_PDU: Error genérico de envió de mensaje.
E. RESUL_ERROR_RADIO_OFF: Se produce cuando el terminal se
encuentra en modo avión.
Para conocer si se ha recibido un mensaje y la información que este contiene, se
utiliza un objeto de tipo “Bundle”, contenido en un “Extra”. Se utiliza además, la
clase “SmsMessage” para decodificar el contenido del mensaje y poderlo
comparar y publicar.
El menú de mensajes cortos, se diseñó para realizar tres diferentes pruebas
durante la ejecución del test. Primero, se debe ingresar el número de línea del
terminal, de esta manera se puede monitorear tanto los mensajes salientes, como
los entrantes, el terminal enviara 10 mensajes, los primeros tres con el terminal en
idle, los siguientes tres generara llamadas a los números de servicio, con la
llamada activa envía el mensaje, esto con el objetivo de validar los SMS con
llamada activa, después envía 2 mensajes con codificación de 7 bits, para validar
que el terminal solo este enviando los 128 primeros caracteres del alfabeto
ASCCI, esto evita un mayor tráfico en la red, los 2 últimos mensajes se envían
nuevamente con el terminal en idle.
El algoritmo está configurado para mantener constante lectura de los mensajes
recibidos y hacer una comparación de la información que llega con la que se
envió. De esta manera reporta cuando el mensaje ha sido recibido y si ha llegado
correctamente. La figura 14, corresponde al diagrama de flujo de este menú y la
figura 13, muestra el diseño final, del layout correspondiente a este menú.
Figura 13. Diseño layout menú SMS
Figura 14. Diagrama de flujo menú de SMS
5.2.3 INFORMACION DE MMS
Para obtener la información relacionada con los MMS y SMS que contiene el
terminal es necesario hacer un llamado al objeto “SmsManager” a través de la
clase “getCarrierConfigValues”, que entrega una lista con valores configurados
por defecto en el terminal. La figura 15 muestra la configuración del “SmsManager”
en este menú.
Figura 15. Configuración SmsManager menú información MMS
Como algunos de los parámetros contenidos dentro de esta clase, no son
desplegados por todos los dispositivos, es necesario hacer una comparación uno
a uno de los elementos para conocer cuáles son los valores que tiene, por ejemplo
en el caso de si el terminal tiene activo los servicios de MMS, se utiliza la etiqueta
“enabledMMS”. La figura 16, muestra cómo se realizó la comparación de este
elemento.
Figura 16. Comparación servicio MMS activo
En total se obtiene información de 18 características que son útiles durante un
proceso de homologación. La tabla 1 muestra cada una de estas características.
Tabla 1. Lista de elementos menú MMS
MMS habilitado Máximo tamaño de
mensaje
Ancho máximo de la
imagen
Altura máxima de la
imagen
Soporte de envió de
audio
User Agent Profile TAG
nombre
Soporta contenido MMS Reporte de entrega de Reporte lectura de MMS
MMS
Longitud máxima del
asunto
Reporte de entrega de
SMS
Soporta encabezado
HTTP
Tiempo de espera
socket HTTP
Cierre de conexión de
MMS
Configuración de
CellBroadcast
Habilitado grupo de
MMS
Envió de múltiples SMS
separados
Envió de múltiples SMS
Finalmente, toda esta información es desplegada en la actividad principal del
menú, con su correspondiente estado en el teléfono. La figura 18 corresponde al
diagrama de flujo de este menú y la figura 17, muestra el diseño final del layout
correspondiente a este menú.
Figura 17. Diseño layout menú información MMS
Figura 18. Diagrama de flujo menú de información MMS
5.2.4 MENU DE THROUGHPUT
Al igual que en los menús anteriores relacionados con servicios de telefonía. Fue
necesario incluir la biblioteca “TelephonyManager” y hacer un llamado al servicio
“TELEPHONY_SERVICE”. Se generó un “PhoneStateListener” para monitorear el
estado de conexión de datos. La figura 19, muestra la configuración del
“PhoneStateListener” en este menú.
Figura 19. Configuración PhoneStateListener menú throughput
La información que nos proporciona el “PhoneStateListener” con el servicio
“LISTEN_DATA_CONNECTION_STATE”, son el estado de conexión y el tipo de
red al cual está conectado. Los estados de conexión de datos que entrega el
sistema operativo Android para este caso son:
A. DATA_DISCONNECTED: No hay conexión a datos
B. DATA_CONNECTING: Se encuentra en proceso de conexión a la red de
datos
C. DATA_CONNECTED: Conexión a datos establecida correctamente
D. DATA_SUSPENDED: Conexión a datos suspendida
Para obtener la información de velocidad cuando se está realizando una descarga
o carga de contenido se utiliza la librería “android.net.TrafficStats” y las clases
“getTotalRxBytes” y “getMobileTxBytes”. Que entregan la velocidad de subida y
bajada en Bytes por segundo respectivamente. Como normalmente esta
información es desplegada en megabits por segundo fue necesario hacer la
conversión a estas unidades. La figura 20 muestra el código utilizado para la
obtención de la información y la conversión de unidades.
Figura 20. Velocidades y conversión a Mbps
Para graficar la información de uplink y downlink, se hizo uso de la clase canvas a
través de la librería “android.graphics.Canvas”. Esta permite dibujar diferentes
elementos en pantalla como líneas y polígonos por medio de la clase “pincel”. En
el layout que se diseñó para este menú, se incluyó el canvas en un menú que
ocupa solo una porción de la pantalla, de tal manera que se pueda desplegar la
información relevante en tiempo real, sin que afecte el funcionamiento del canvas.
Además, fue necesario incluir un elemento de tipo “Runnable”, este funciona como
un hilo secundario, que se ejecuta cada segundo para obtener los valores de
uplink, downlink, tipo de tecnología, estado de la conexión a datos y redibujar el
canvas.
El menú de throughput se diseñó para ejecutar la prueba en tres periodos
diferentes 1 minuto, 5 minutos y 10 minutos, estos son los tiempos más comunes
en los que se realiza la validación de calidad de servicio en los procesos de
homologación, permitiendo conocer el comportamiento del terminal en este
escenario. Cabe aclarar que es necesario ejecutar la descarga o carga de
contenido previo a la ejecución de la prueba, este menú solamente cumple la
función de monitorear el estado de la conexión, las velocidades de tráfico y
graficar el comportamiento durante el tiempo seleccionado. Al finalizar mostrara un
mensaje de prueba terminada junto con los promedios de velocidad tanto en
subida como en bajada. La figura 22, corresponde al diagrama de flujo de este
menú y la figura 21, muestra el diseño final, de los layouts correspondientes a este
menú.
Figura 21. Diseño layout menú throughput
Figura 22. Diagrama de flujo menú trhoughput
5.2.5 MENÚ BATERIA
Para el menú de batería, las librerías más importantes que se utilizaron, fueron
“android.content.IntentFilter” y “android.os.BatteryManager”, que permiten conocer
el nivel de energía actual de la batería, a través del servicio
“ACTION_BATTERY_CHANGED”. Igualmente se incluyó la librería
“android.telephony.TelephonyManager”, para el control de los estados de llamada,
ya que una de las pruebas que se puede ejecutar en este menú es con una
llamada activa conocer el comportamiento de la batería, finalmente las librerías
“android.net.Uri” y “android.widget.VideoView”, para la inclusión de un elemento de
video en uno de los layouts secundarios. La figura 23, muestra la configuración
inicial para conocer el estado de la batería.
Figura 23. Configuración inicial estado de la batería
Se generó un algoritmo que solicita el nivel de la batería cada 5 minutos durante
30 minutos, es decir a los 5, 10, 15, 20 y 25 minutos, para al final realizar un
promedio de la energía consumida por la batería y entregar un estimado del
tiempo total que duraría utilizando datos constantemente o en una llamada
continúa. Al igual que en el menú anterior para obtener la información sin afectar
los procesos principales de la aplicación, se hizo uso de un objeto “Runnable”, que
permite ejecutar un hilo secundario. La figura 24 muestra el código de cómo se
obtiene el nivel de la batería, se hace la conversión a las unidades
correspondientes y se publica en una caja de texto.
Figura 24. Obtención y publicación nivel de batería
Se diseñaron 2 tipos de prueba para este menú, una relacionada con el
comportamiento de la batería durante una llamada activa y el segundo durante un
streaming de datos. Para la ejecución del streaming de datos fue necesario
configurar una dirección URL de un video que no tuviera derechos de autor y así
poderlo utilizar sin ningún tipo de repercusión legal. La figura 25 muestra la
inclusión de la dirección URL, dentro del objeto de video del layout.
Figura 25. Configuración objeto de video
La figura 27, corresponde al diagrama de flujo de este menú y la figura 26,
muestra el diseño final, de los layouts correspondiente a este menú.
Figura 26. Diseño layout menú batería
Figura 27. Diagrama de flujo menú batería
5.2.6 MENU DE DRIVE TEST
Para el diseño del menú de drive test, se hizo uso de muchas de las librerías que
se utilizaron en menús previos para el monitoreo de las llamadas, estado de datos,
y estado de tráfico de datos. Estas librerías son
“android.telephony.TelephonyManager”, “android.Telephony.SignalStrength” y
“android.telephony.PhoneStateListener”. Además de estas funciones en este
menú se hizo la inclusión del servicio maps de Google para lo cual se utilizó la
librería “com.google.android.gms.maps.GoogleMap”. La figura 28 muestra la
configuración de todos los estados del “PhoneStateListener” para este menú.
Figura 28. Configuración PhoneStateListener menú drive test
La lectura de los parámetros se realiza de la misma manera que se describió para
los anteriores menús, el cambio radica en la publicación de la información en el
servicio de maps. Para configurar este en cualquier aplicación es necesario
obtener una llave asociada a la cuenta de gmail del desarrollador, que permitirá
autentificar el servicio. Esta llave se incluye dentro del archivo android manifest. La
figura 29, muestra la inclusión de la llave en el aplicativo.
Figura 29. Llave de autenticación servicio Google Maps
La inclusión del mapa en el aplicativo se realiza a través de la clase
“MapFragment”. La figura 30 muestra la configuración del maps en el view del
aplicativo.
Figura 30. Configuración de maps en el view
Para poder obtener la ubicación del terminal, es necesario implementar el método
“LocationListener” a través del “GoogleApiClient”, indicándole que tipo de servicios
y el modo de localización que se realizara. La figura 31, muestra la configuración
realizada para el cliente API en este menú.
Figura 31. Configuración cliente API de localización
Después de obtener la posición y tener en constante monitoreo los estados del
teléfono, se publica la información en el mapa por medio de marcadores. A cada
cambio en el estado se le asignó un marcador, a continuación se presenta cada
uno.
1. Buen nivel de señal ( ): Cuando el indicador de señal del terminal del
teléfono se encuentra en la línea 5 o 4. La aplicación mostrara un rastro
verde en el mapa.
2. Nivel de señal medio ( ): Cuando el indicador de señal del terminal
del teléfono se encuentra en la línea 3. La aplicación mostrara un rastro
amarillo en el mapa.
3. Nivel de señal bajo ( ): Cuando el indicador de señal del terminal del
teléfono se encuentra por debajo de la línea 3. La aplicación mostrara un
rastro rojo en el mapa.
4. Inicio de recorrido ( ): Se dibuja en el mapa al iniciar el recorrido.
5. Desconexión de datos ( ): Cuando ocurre una desconexión de datos.
6. Conexión de datos ( ): Cuando se conecta a datos.
7. Cambio de tecnología ( ): Cuando ocurre un cambio de tecnología.
8. En servicio ( ): Cuando retoma servicio, después de venir de un estado de
sin servicio o estado de solo llamadas de emergencia.
9. Sin servicio ( ): Cuando ocurre una pérdida de servicio.
10. Solo emergencias ( ): Cuando ocurre una desconexión total de la red
móvil.
11. Inicio de llamada ( ): Cuando se inicia una llamada.
12. Finalización de llamada ( ): Cuando finaliza una llamada.
13. Finalización de recorrido ( ): Cuando se da por terminado el drive test.
Cuando la prueba se ejecuta, comienza a monitorear todos los estados del
teléfono y la posición. En el mapa cada vez que ocurre un cambio en la posición,
la cámara se reubica para mantener la posición centrada, después cada vez que
ocurra uno de los eventos anteriormente descritos se generara un marcador en el
mapa. Para terminar la prueba, se debe seleccionar el botón de finalizar, el cual
termina la actualización de posición, el monitoreo de los estados y envía el
marcador de finalización. Al terminar, la información contenida en el mapa permite
conocer el comportamiento del terminal durante el recorrido realizado y establecer
si hubo algún evento que pueda ser considerado para estudio o si por el contrario
todos los eventos ocurridos se encontraron dentro de lo esperado. La figura 33,
corresponde al diagrama de flujo de este menú y la figura 32, muestra el diseño
final, de los layouts correspondiente a este menú.
Figura 32. Diseño layout menú drive test
Figura 33. Diagrama de flujo menú drive test
5.2.7 MENÚ HARDWARE
Para acceder a la información provista por los diferentes sensores que tienen los
terminales se utiliza la librería “android.hardware.SensorManager”, con esta se
podrá conocer todos los sensores que tiene provistos el terminal. Además de
estos dispositivos todos los teléfonos inteligentes tienen WIFI, bluetooth y
micrófono por lo cual se diseñaron pruebas específicas para cada uno, las librerías
que se utilizaron para esto fueron “android.net.wifi.WifiManager”,
“android.bluetooth.BluetoothDevice” y “android.media.MediaPlayer”.
Como primer paso, se ejecuta la clase “SensorManager”, para conocer cuáles son
los sensores soportados por el terminal. La tabla 2, muestra una lista con todos los
posibles sensores que se pueden encontrar en un terminal.
Tabla 2. Lista de sensores menú de elementos de HW
Acelerómetro Magnetómetro Sensor de orientación
Giroscopio Sensor de luz Sensor de proximidad
Sensor de gravedad Sensor lineal Sensor de rotación
La figura 34 muestra el código para obtener la lista de sensores soportada por un
terminal.
Figura 34. Código lista de sensores soportados
Después de conocer los sensores soportados, se ejecuta una prueba obteniendo
la información provista por cada uno y publicándola en pantalla, de esta manera se
determina si está funcionando correctamente. Para este caso se ponen las
opciones de “prueba exitosa” y “prueba fallida”, para que sea el usuario quien
determine si están funcionando correctamente. La figura 35, muestra cómo se
obtiene y publica la información para el acelerómetro. El procedimiento es muy
similar para los demás sensores.
Figura 35. Obtención y publicación de información del acelerómetro
Para la prueba del WIFI, se realiza una búsqueda de los dispositivos disponibles y
se publica. Con esto se puede corroborar que el elemento está correctamente
instalado y configurado. Para este fin se utiliza un “BroadcastReceiver” que
mantiene la búsqueda de los dispositivos cercanos hasta que completa 3, en ese
momento lanza un mensaje de prueba satisfactoria. La figura 36 muestra el código
utilizado para esto.
Figura 36. Búsqueda y publicación dispositivos cercanos WIFI
La prueba de Bluetooth es muy similar en su funcionamiento con la de WIFI, ya
que igualmente se realiza una búsqueda de los dispositivos cercanos y cuando se
completan 3, se muestra un mensaje de prueba exitosa. Lo que cambio es la
estructura del código, ya que a diferencia del WIFI, la biblioteca de bluetooth
entrega unos estados en el “BroadcastReceiver” que permiten conocer si está
apagado, encendido, buscando dispositivos y cuando ha terminado de buscarlos.
La figura 37, muestra el estado cuando encuentra un dispositivo, allí se toma la
información del dispositivo y se publica. Al completar 3 elementos la búsqueda se
da por terminada con el método “cancelDiscovery”.
Figura 37. Búsqueda y publicación dispositivos cercanos Bluetooth
Como última prueba se ejecuta la grabación y reproducción de un mensaje. Con
esto se puede validar tanto el funcionamiento del micrófono, como de los
parlantes. Para esto se utiliza la clase “MediaRecorder”, que permite almacenar la
información parcialmente del audio en la memoria RAM, para luego ser
reproducido. La figura 38, muestra el método de reproducción de esta prueba.
Figura 38. Método reproducción prueba de parlante
Finalmente, La figura 40, corresponde al diagrama de flujo de este menú y la
figura 39, muestra el diseño final de los layouts correspondiente a este menú.
Figura 39. Diseño layouts menú HW
Figura 40. Diagrama de flujo menú elementos de HW
5.2.8 INFORMACIÓN GENERAL
Para obtener la información del terminal, se utilizó la librería
“android.telephony.TelephonyManager” y el servicio “TELEPHONY_SERVICE”. A
través de diferentes métodos contenidos en esta clase, se obtiene la información.
La tabla 3, muestra cada uno de los métodos utilizados, junto con la información
extraída de cada uno.
Tabla 3. Lista de elementos menú general
getDeviceId = IMEI getDeviceId = TAC
getLine1Number = línea de la SIM getMmsUAProfUrl = USER AGENT
PROFILE
getMmsUserAgent = MMS USER
AGENT
getNetworkCountryIso = Indicador
de país en la SIM card
getNetworkOperatorName = nombre
del operador contenido en la SIM
getSimSerialNumber = Serial de la
SIM card
getSubscriberId = IMSI de la SIM
card
getVoiceMailNumber = número de
buzón de voz almacenado en la SIM
getVoiceMailAlphaTag = Nombre de
buzón de voz almacenado en la SIM
La figura 41, muestra un ejemplo de cómo se extrae la información desde la clase
“TelephonyManager”.
Figura 41. Obtención IMEI y TAC
Además de la información contenida en esta clase, se publica también la versión
de Android que utiliza el terminal y la zona horaria que trae configurada por
defecto. La figura 42 muestra el código de cómo se obtiene esta información del
terminal.
Figura 42. Código versión de android y zona horaria
Finalmente, La figura 44, corresponde al diagrama de flujo de este menú y la
figura 43, muestra el diseño final del layout correspondiente a este menú.
Figura 43. Layout menú general
Figura 44. Diagrama de flujo menú general
5.3 EJECUCIÓN DE PRUEBAS CON LA APLICACIÓN
Para la validación del comportamiento de la aplicación, se utilizaron dos terminales
con chipsets de diferentes fabricantes (Mediatek y Qualcomm) el ZTE Blade A602
y el ZTE Blade A320 y una nueva versión de software de mantenimiento que se
requiere validar cada 3 meses. A continuación se mostrara los resultados
obtenidos con cada menú.
5.3.1 Generación de llamadas.
Para el terminal 1, ZTE Blade A602, se ejecutó un set de 30 llamadas a la línea de
servicio de Claro. La figura 45, muestra el paso a paso de ejecución de la prueba:
Figura 45. Ejecución set de llamadas Blade A602
La tabla 4 muestra los resultados obtenidos en cada una de las llamadas
ejecutadas.
Tabla 4. Resultados set de llamadas Blade A602
Llamada Nivel de señal Cambio de tecnología
Tecnología Llamada
completada Estado datos
1 -78 Hubo HSPA+ Exitosa Conectado
2 -75 Hubo HSPA+ Exitosa Conectado
3 -65 Hubo HSPA+ Exitosa Conectado
4 -72 Hubo HSPA+ Exitosa Conectado
5 -79 Hubo UMTS Exitosa Conectado
6 -79 Hubo UMTS Exitosa Conectado
7 -79 Hubo UMTS Exitosa Conectado
8 -76 Hubo HSPA Exitosa Conectado
9 -74 Hubo HSPA Exitosa Conectado
10 -74 Hubo HSPA Exitosa Conectado
11 -77 Hubo UMTS Exitosa Conectado
12 -66 Hubo HSPA Exitosa Conectado
13 -71 Hubo HSPA+ Exitosa Conectado
14 -69 Hubo HSPA Exitosa Conectado
15 -67 Hubo HSPA Exitosa Conectado
16 -72 Hubo HSPA Exitosa Conectado
17 -70 Hubo HSPA Exitosa Conectado
18 -67 Hubo HSPA Exitosa Conectado
19 -73 Hubo HSPA Exitosa Conectado
20 -73 Hubo UMTS Exitosa Conectado
21 -70 Hubo HSPA Exitosa Conectado
22 -71 Hubo HSPA Exitosa Conectado
23 -65 Hubo HSPA Exitosa Conectado
24 -76 Hubo HSPA Exitosa Conectado
25 -72 Hubo HSPA+ Exitosa Conectado
26 -71 Hubo HSPA Exitosa Conectado
27 -70 Hubo HSPA Exitosa Conectado
28 -75 Hubo HSPA Exitosa Conectado
29 -72 Hubo HSPA+ Exitosa Conectado
30 -76 Hubo HSPA+ Exitosa Conectado
Como se puede ver en los resultados entregados por la aplicación, el
establecimiento de llamadas está funcionando correctamente, al igual que los
cambios de tecnología y la conexión a datos no se pierde en ningún momento. Por
tanto, la prueba fue exitosa.
Para el terminal 2, ZTE Blade A320, se ejecutó un set de 40 llamadas a la línea de
servicio de Claro. La figura 46, muestra el paso a paso de ejecución de la prueba:
Figura 46. Ejecución set de llamadas Blade A320
La tabla 5 muestra los resultados obtenidos en cada una de las llamadas
ejecutadas.
Tabla 5. Resultados set de llamadas Blade A320
Llamada Nivel de
señal Cambio de tecnología
Tecnología Llamada
completada Estado datos
1 -65 Hubo HSPA+ Exitosa Conectado
2 -65 No hubo HSPA+ Exitosa Conectado
3 -57 No hubo HSPA+ Exitosa Conectado
4 -59 No hubo HSPA+ Exitosa Conectado
5 -73 No hubo HSPA+ Exitosa Conectado
6 -63 No hubo HSPA+ Exitosa Conectado
7 -65 No hubo HSPA+ Exitosa Conectado
8 -67 No hubo HSPA+ Exitosa Conectado
9 -69 No hubo HSPA+ Exitosa Conectado
10 -71 No hubo HSPA+ Exitosa Conectado
11 -69 No hubo HSPA+ Exitosa Conectado
12 -63 No hubo HSPA+ Exitosa Conectado
13 -63 No hubo HSPA+ Exitosa Conectado
14 -63 No hubo HSPA+ Exitosa Conectado
15 -57 No hubo HSPA+ Exitosa Conectado
16 -57 No hubo HSPA+ Exitosa Conectado
17 -63 No hubo HSPA+ Exitosa Conectado
18 -63 No hubo HSPA+ Exitosa Conectado
19 -57 No hubo HSPA+ Exitosa Conectado
20 -63 No hubo HSPA+ Exitosa Conectado
21 -57 No hubo HSPA+ Exitosa Conectado
22 -63 No hubo HSPA+ Exitosa Conectado
23 -61 No hubo HSPA+ Exitosa Conectado
24 -61 No hubo HSPA+ Exitosa Conectado
25 -61 No hubo HSPA+ Exitosa Conectado
26 -73 No hubo HSPA+ Exitosa Conectado
27 -61 No hubo HSPA+ Exitosa Conectado
28 -59 No hubo HSPA+ Exitosa Conectado
29 -75 No hubo HSPA+ Exitosa Conectado
30 -67 No hubo HSPA+ Exitosa Conectado
31 -65 No hubo HSPA+ Exitosa Conectado
32 -65 No hubo HSPA+ Exitosa Conectado
33 -65 No hubo HSPA+ Exitosa Conectado
34 -65 No hubo HSPA+ Exitosa Conectado
35 -73 No hubo HSPA+ Exitosa Conectado
36 -59 No hubo HSPA+ Exitosa Conectado
37 -61 No hubo HSPA+ Exitosa Conectado
38 -65 No hubo HSPA+ Exitosa Conectado
39 -69 No hubo HSPA+ Exitosa Conectado
40 -59 No hubo HSPA+ Exitosa Conectado
Como se puede ver en los resultados entregados por la aplicación, el
establecimiento de llamadas está funcionando correctamente, a pesar de que no
hubo cambios de tecnología constantes, esto también es un comportamiento
dentro de lo esperado, ya que se puede ver los buenos niveles de señal en los que
se mantuvo el terminal durante la ejecución de la prueba, además la conexión a
datos no se pierde en ningún momento. Por tanto, la prueba fue exitosa.
5.3.2 Generación de SMS.
Para el terminal 1, ZTE Blade A602 se ejecutó la prueba de SMS, con una SIM
card pospago que permite él envió de mensajes cortos, recordando que la prueba
se ejecuta enviando los mensajes al mismo terminal desde donde se corre la
prueba. La figura 47, muestra los resultados de la prueba.
Figura 47. Ejecución set de SMS Blade A602
Como se observa, la prueba fue ejecutada exitosamente a pesar de haber tenido
un problema en él envió del mensaje 6 (“ERROR GENERICO DE ENVIO”), los
demás mensajes fueron enviados y recibidos correctamente. Lo que representa un
correcto funcionamiento en el terminal.
Para el terminal 2, ZTE Blade A320 se utilizó tanto una SIM pospago como una
SIM card prepago, de tal manera que se pueda mostrar los mensajes entregados
por el terminal, cuando la SIM card no soporta el envío de mensajes cortos. La
figura 48, muestra la ejecución de ambas pruebas.
Figura 48. Ejecución set de SMS Blade A320
Cuando se ejecuta la prueba con una SIM card que no está habilitada para el
envío de SMS, se generan errores al intentar el envío, o se queda realizando el
envío un largo tiempo. Al realizar la prueba con la SIM card aprovisionada, se
puede observar como el terminal realizo el envío y la recepción de los mensajes
sin inconvenientes. Con lo cual, la prueba fue exitosa.
5.3.3 Información MMS
La figura 49, muestra la información de mensajes multimedia extraída del terminal
ZTE Blade A602.
Figura 49. Información de MMS Blade A602
Con esta información, se pudo conocer que los mensajes multimedia están
habilitados en el terminal, y que están correctamente configurados, de acuerdo a
los parámetros exigidos por el operador. Para el terminal Blade A320, la figura 50
muestra la información de MMS.
Figura 50. Información de MMS Blade A320
Al igual que con el Blade A602, la información provista por el menú del Blade A320
cumple con los parámetros exigidos por el operador, y por tanto funciona
correctamente.
5.3.4 Prueba de throughput
Para el terminal 1, ZTE Blade A602 se conectó a un PC compartiendo servicio de
internet por medio de un cable USB, se ejecutó la descarga de un archivo pesado
desde un servidor, después se estableció la prueba en la aplicación con una
duración de 10 minutos. Las condiciones de tráfico y nivel de señal, fueron
estándar para una red LTE. La figura 51 muestra el paso a paso de la ejecución de
la prueba en este terminal.
Figura 51. Ejecución prueba throughput Blade A602
La prueba entrega como resultado final, un promedio en descarga de 13,770666
Mbps tras una descarga de 8262,399 Mb en 10 minutos. Lo que es un
comportamiento normal, para unas condiciones de red como en las que se
ejecutaron la prueba.
5.3.5 Prueba de batería
Se realizó la prueba de batería en el terminal 1, ZTE Blade A602 en ambos
escenarios, es decir tanto en llamada constante como en streaming. Los
resultados se muestran en la figura 52.
Figura 52. Ejecución prueba batería Blade A602
Al terminar la prueba, la aplicación entrego como resultado que el terminal tendrá
una duración promedio de 500 minutos con llamada constante en 3G, y de 600
minutos con reproducción de streaming constante, lo cual está dentro de lo
esperado para un terminal con una pantalla de 5.5 pulgadas y una batería de 3000
mAh.
Para el terminal 2, ZTE Blade A320 en ambos escenarios, es decir tanto en
llamada constante como en streaming. Los resultados se muestran en la figura 53.
Figura 53. Ejecución prueba batería Blade A320
Al terminar la prueba, la aplicación entrego como resultado que el terminal tendrá
una duración promedio de 375 minutos con llamada constante en 3G, y de 375
minutos con reproducción de streaming constante, lo cual está dentro de lo
esperado para un terminal con un pantalla de 5 pulgadas y una batería de 2200
mAh.
5.3.6 Drive test
Para este caso, se realizara un análisis del drive test realizado con el terminal ZTE
Blade A602, para conocer cada uno de los eventos que se reportaron en el mapa,
y si estos fueron normales o no, teniendo en cuenta los niveles de señal y las
características de la zona. La figura 54, evidencia el recorrido realizado con el
terminal.
Figura 54. Drive test Blade A602
El recorrido se realizó por la avenida circunvalar, desde la calle 94 hasta la calle 6,
una zona con diferentes niveles de señal, cambios de tecnología y sectores con
comportamientos anormales en ocasiones. En la tabla 6 se muestran los eventos
más destacados y un análisis de los mismos.
Tabla 6. Análisis drive test Blade A602
EVENTO EVIDENCIA ANALISIS
Inicio recorrido
El inicio de la prueba se
realiza en una zona de
cobertura 4G, con buenos
niveles de señal y
conexión a datos.
Llamada iniciada
Se inicia una llamada,
partiendo de 4G, en
niveles medio bajos de
señal y conexión a datos
correcta.
Cambio de tecnología
Inmediatamente después
de iniciar la llamada, se
produce un cambio de
tecnología de LTE a
HSPA. Esto es normal,
debido a que Claro aún
no tiene implementado el
servicio de voz en 4G.
Cambio de tecnología
Durante el recorrido
ocurren múltiples eventos
de cambio de tecnología
entre HSPA y HSPA+ y
viceversa. Lo cual es
normal.
Zona de baja cobertura
Se encuentra una zona
de baja cobertura en 3G,
sin que se produzca la
caída de la llamada ni
perdida de servicio.
Caída de llamada
Se produce una caída de
llamada estando
conectado en HSPA, con
buenos niveles de señal.
Fuera de servicio
Inmediatamente después
de la caída de llamada se
produce un fuera de
servicio en una zona de
mediana cobertura.
En servicio
Al instante se produce la
reconexión a la red en
UMTS con niveles
medios de señal. Este
evento se debe analizar
por medio de tráfico de
red.
Llamada iniciada
Se genera una nueva
llamada, estando en
HSPA+, con buenos
niveles de señal.
Finaliza la prueba
Finaliza el recorrido sin
ningún otro evento a
tener en cuenta.
Al finalizar el recorrido, se pudo observar un comportamiento normal del terminal.
A tener en cuenta la perdida de servicio producida después de la caída de
llamada, pero como ocurrió una reconexión inmediata y además es una zona
donde generalmente se producen caídas de llamada, no se considera un
problema.
5.3.7 Elementos de hardware
Al ejecutar el menú de elementos de HW, se conocen cuáles son los dispositivos
soportados por el terminal, la figura 55 muestra que el equipo Blade A602, soporta
acelerómetro, sensor de luz, proximidad, micrófono, bluetooth y wifi.
Figura 55. Elementos de hardware soportados Blade A602
Después de conocer los elementos de hardware soportados por el terminal, se
realizó la prueba específica para cada uno de estos. Los resultados se muestran
en la figura 56.
Figura 56. Funcionamiento elementos de hardware soportados Blade A602
Todos los elementos de hardware funcionaron correctamente, por tanto la prueba
fue exitosa. Para el terminal Blade A320, los elementos soportados se muestran
en la figura 57.
Figura 57. Elementos de hardware soportados Blade A320
Después de conocer los elementos de hardware soportados por el terminal, se
realizó la prueba específica para cada uno de estos. Los resultados se muestran
en la figura 58.
Figura 58. Funcionamiento elementos de hardware soportados Blade A320
Todos los elementos de hardware funcionaron correctamente, por tanto la prueba
fue exitosa.
5.3.8 Información general
La figura 59, muestra la información general extraída del terminal ZTE Blade A602.
Figura 59. Información general Blade A602
Para el terminal Blade A320, la figura 60 muestra la información general.
Figura 60. Información general Blade A320
Toda la información extraída de este menú, es necesaria en el proceso de
homologación.
5.4 ANALISIS DE RESULTADOS
Durante el desarrollo de la investigación, se cumplieron la totalidad de los
objetivos propuestos para la misma. Se evidencio el buen desempeño de la
aplicación en un proceso de homologación real (Validación de versión de
mantenimiento para un terminal que se encuentra a la venta), facilitando y
optimizando los procesos requeridos para la realización de algunas de las pruebas
que se requieren, y entregando información que se debe conocer y validar en
todos los terminales que pasan por una homologación.
La reducción de los tiempos de ejecución de las pruebas se evidencio, ya que se
pudieron probar dos terminales al mismo tiempo, debido a que era la aplicación
quien realizaba el monitoreo constante de cada equipo y al final entregaba el
reporte que podía ser evaluado.
En este caso se puede decir que la reducción de tiempo fue del 50%, pero esto
puede ser mayor o menor, dependiendo de los recursos que se tengan para la
realización de las pruebas.
6. APORTES DE LA INVESTIGACIÓN
La tabla 7, muestra los beneficios que se encontraron con la utilización de cada
uno de los menús de la aplicación.
Tabla 7. Beneficios utilización de la aplicación HomologationTrial
MENÚ BENEFICIOS
Generar llamadas 1. La prueba se ejecuta
automáticamente sin ningún tipo
de supervisión, después de dar
el inicio por parte del usuario.
2. Entrega información importante
que puede ser utilizada para
determinar comportamientos
anormales del establecimiento
de llamadas.
3. Es posible configurar un número
de llamadas entre 1 y 100. De tal
manera que se pueden generar
informes estadísticos más
detallados del comportamiento
de los terminales.
4. Se pueden generar test en
todas las tecnologías existentes
en el mercado actual, sin ningún
fallo.
Generar SMS 1. La prueba se ejecuta
automáticamente sin ningún tipo
de supervisión, después de dar
el inicio por parte del usuario.
2. Realiza diferentes pruebas,
dentro del mismo test, lo que
permite ahorrar tiempo.
3. Permite generar pruebas de
envío de mensajes cortos en
todas las tecnologías 2G, 3G y
4G.
Información MMS 1. Suministra algunos de los datos
que se requieren durante el
proceso de homologación,
anteriormente era necesario
solicitarlos a las casas matrices
de los fabricantes, ya que no
existía ningún otro medio para
obtenerlos.
2. Reúne información en un solo
menú, que para conocer
anteriormente era necesario
desplazarse entre varias
opciones y aplicaciones del
terminal.
Throughput 1. Permite establecer la prueba en
diferentes tiempos, sin
necesidad de una supervisión
constante.
2. Muestra gráficamente el
desarrollo de la prueba.
Permitiendo tener un control de
la misma.
3. Entrega información en tiempo
real.
4. Las estadísticas obtenidas al
final de la prueba son totalmente
fiables, ya que las velocidades
de subida y bajada son extraídas
directamente del sistema
operativo Android.
5. Facilita le ejecución de la prueba
Batería 1. La prueba se ejecuta
automáticamente sin ningún tipo
de supervisión, después de dar
el inicio por parte del usuario.
2. Se pueden ejecutar dos tipos de
prueba. Una en llamada
constante y la otra con tráfico
constante.
3. Al finalizar la prueba entrega un
informe con la información de
promedio de duración de la
batería en los diferentes
escenarios.
Drive test 1. Realiza el monitoreo de los
eventos que ocurren durante un
drive test de manera automática.
2. Muestra de manera gráfica y
amigable para el usuario los
eventos que ocurren durante el
recorrido.
3. Entrega datos importantes, que
sirven para evaluar los eventos
que ocurran y al final el
comportamiento que tuvo el
terminal durante el drive test.
4. Muestra en tiempo real, el
estado de conexión de red, de
datos y permite establecer una
llamada, sin necesidad de acudir
a otras aplicaciones del sistema
operativo.
Elementos de hardware 1. Permite conocer los elementos
de hardware soportados por
cada terminal, además de
evaluar el funcionamiento
correcto de cada uno de estos.
No existe ninguna aplicación
dentro del sistema operativo que
cumpla esta función.
2. Reúne toda la información de los
elementos de hardware en una
sola interfaz amigable para el
usuario.
Información general 1. Suministra algunos de los datos
que se requieren durante el
proceso de homologación,
anteriormente era necesario
solicitarlos a las casas matrices
de los fabricantes, ya que no
existía ningún otro medio para
obtenerlos.
2. Reúne información en un solo
menú, que para conocer
anteriormente era necesario
desplazarse entre varias
opciones y aplicaciones del
terminal, o la descarga de otras
herramientas no propietarias
desde el play store.
Como se puede ver en la tabla anterior, todos los menús representaron beneficios
en el desarrollo de las pruebas requeridas durante un proceso de homologación.
Se puede concluir entonces, que la aplicación es funcional y de utilidad durante el
proceso, permitiendo reducir en pequeña escala los tiempos de ejecución, y
entregando información más precisa para generar estadísticas y conclusiones del
funcionamiento de los terminales en los redes móviles de los diferentes
operadores Colombianos.
TRABAJOS FUTUROS
En el campo de la homologación y las telecomunicaciones, este caso de estudio
puede ser utilizado para otros desarrollos como:
- Diseño de una versión para computadora en dispositivos que no utilicen el
sistema operativo Android, como los Routers, módems y trackers.
- Adaptar la aplicación a los próximos cambios que sucederán en la red
móvil, como la inclusión de VoLTE, VoWIFI y en un futuro más lejano 5G.
- Extender el alcance de la aplicación a dispositivos con otros sistemas
operativos como IOS y Windows Phone, o cualquier otro que surja en los
siguientes años.
CONCLUSIONES
1. Existen muchos factores de seguridad que se deben tener en cuenta al
momento de diseñar y desarrollar una aplicación móvil en Android. Ya que
algunas de las funciones tienen como prioridad proteger la integridad de la
información de los usuarios.
2. La automatización de algunos de los procesos ejecutados durante una
homologación por medio de aplicaciones del sistema operativo Android,
facilita y optimiza el proceso que se lleva a cabo entre los operadores y
fabricantes.
3. La posibilidad de obtener información, como los niveles de señal, el estado
de conexión, el estado de llamada y todos los diferentes eventos que
pueden ocurrir a un terminal móvil durante su funcionamiento cotidiano,
además de la localización donde ocurren. Permiten tener un concepto más
claro del funcionamiento del terminal, generar estadísticas y reportes más
exactos, y generar soluciones más rápidas y eficientes.
4. La posibilidad de extraer la información directamente del terminal. Hace que
sea mucho más fiable el resultado de las pruebas.
5. La reducción en los tiempos de homologación no es tan evidente con la
utilización de la aplicación, ya que la mayoría de las pruebas tienen un
tiempo establecido para su ejecución (1 hora, 30 minutos, etc.). La
reducción se hace evidente cuando se trabaja más de un proceso al mismo
tiempo y cuando se realiza el análisis de los resultados con la información
provista por la aplicación.
REFERENCIAS.
[1] “Mercado EE.UU. y FCC Certificación,” 2017. [Online]. Available: http://www.sicomtesting.com/blog/es/certificazione-fcc-come-e-perche-certificare-la-conformita-agli-standard-usa/ .
[2] J. Rachal, “Android arrasa en el mercado del móvil con el 87% de cuota,” 2017. [Online]. Available: https://www.muycanal.com/2017/08/28/mercado-del-movil.
[3] G. I. Zysman, J. A. Tarallo, R. E. Howard, J. Freidenfelds, R. A. Valenzuela, and P. M. Mankiewich, “Technology Evolution for Mobile and Personal Communications,” Wiley Online Libr., no. March, pp. 107–129, 2000.
[4] “Resolucion 5031 de 2016.pdf.” .
[5] “Reolucion 087 de 1997,” no. 087, 1997.
[6] A. Cliente, “Respuesta a Comentarios Homologación de Equipos Terminales – Actualización de Normas Técnicas – Documento Amarillo,” 2016.
[7] D. D. Fernandes, D. Á. Montini, G. De Souza, P. Moreira, F. Rafael, and M. Cardoso, “Final Inspection for Design Pattern Homologation using a Real Time Embedded Software in a Production Line,” 2009.
[8] Google, “The Android Story,” 2017. [Online]. Available: https://www.android.com/history/#/marshmallow.
[9] A. Khatoon, G. S. Member, and P. Corcoran, “Android permission system and user privacy- A review of concept and approaches,” pp. 153–158, 2017.
[10] P. Bhatt, S. Gupta, P. Singh, and P. Dhiman, “Accident and Road Quality Assessment using Android Google Maps API,” pp. 1061–1064, 2017.
[11] C. T. Nugroho, R. Nugraha, and A. Rusdinar, “Robot Control Design Using Virtual Path from Android Smartphone,” pp. 0–3, 2017.
[12] B. T. Scholar, E. Knowledge, and C. Technical, “Cloud Based Automated Irrigation And Plant Leaf Disease Detection System Using An Android Application,” pp. 211–214, 2017.
[13] R. Bhattacharya, N. Bandyopadhyay, and S. Kalaivani, “Real time Android App Based Respiration Rate Monitor,” pp. 709–712, 2017.
ANEXOS
El código de la aplicación en android studio, se encuentra en el documento
“Código fuente HomologationTrial”, adjunto a este paper.