“INFRAESTRUCTURA MOVIL VIRTUAL (VMI) BASADA EN SOLUCIONES

WEARABLE”

MARIA FERNANDA RAIGOSO ROJAS

ROBERTO LEON ZARATE
FELIPE ALEJANDRO MORALES MENDIVELSO

UNIVERSIDAD SANTO TOMÁS

FACULTAD DE INGENIERÍA ELECTRÓNICA
BOGOTÁ
2017
“INFRAESTRUCTURA MOVIL VIRTUAL (VMI) BASADA EN SOLUCIONES
WEARABLE”

MARIA FERNANDA RAIGOSO ROJAS

ROBERTO LEON ZARATE
FELIPE ALEJANDRO MORALES MENDIVELSO

Proyecto de Grado

Asesor
CARLOS ENRIQUE MONTENEGRO NARVAEZ
Docente Facultad Ingeniería Electrónica

UNIVERSIDAD SANTO TOMÁS

FACULTAD DE INGENIERÍA ELECTRÓNICA
BOGOTA
2017

2
 CONTENIDO

1 INTRODUCCION ........................................................................................................ 1
2 PLANTEAMIENTO DEL PROBLEMA ......................................................................... 2
3 JUSTIFICACION ........................................................................................................ 4
4 OBJETIVO GENERAL ................................................................................................ 6
4.1 OBJETIVOS ESPECÍFICOS................................................................................ 6
5 ESTADO DEL ARTE .................................................................................................. 7
5.1 Infraestructura Móvil Virtual ................................................................................. 9
5.2 Virtualización de Aplicaciones Móviles .............................................................. 11
5.3 Protocolo de visualización Remota .................................................................... 11
5.4 Wearables ......................................................................................................... 15
5.5 Trabajos relacionados ....................................................................................... 17
5.5.1 Nubo........................................................................................................... 17
5.5.2 Sierra.......................................................................................................... 18
5.5.3 Trend Micro ................................................................................................ 19
6 Solución.................................................................................................................... 21
6.1 Virtualización ..................................................................................................... 23
6.2 Hardware ........................................................................................................... 24
6.3 Hipervisor .......................................................................................................... 24
6.4 Máquina virtual .................................................................................................. 29
6.5 Storage o Almacenamiento................................................................................ 32
6.6 Memoria ............................................................................................................ 35
6.7 Asignación de memoria a las máquinas virtuales .............................................. 35
6.8 Protocolo de Comunicación ............................................................................... 36
6.9 RFB (Remote Framebuffer) ............................................................................... 38
6.10 Conexión Inicial ................................................................................................. 38
6.11 Protocolo de visualización ................................................................................. 38
6.12 Protocolo de Entrada ......................................................................................... 39
6.13 Representación de datos de pixeles .................................................................. 39
6.14 Mensajes del protocolo ...................................................................................... 40
6.14.2 Solicitud de Actualización del Framebuffer ................................................. 41

3
 6.14.3 Eventos del Puntero ................................................................................... 42
6.14.4 Actualización del Framebuffer .................................................................... 42
6.14.5 Entradas de mapas de color ....................................................................... 43
6.14.6 Codificación ................................................................................................ 43
6.14.7 Seguridad ................................................................................................... 44
6.14.8 Motion JPEG .............................................................................................. 44
6.15 Hybrid Remote Display Protocol ........................................................................ 46
6.16 Compresión JPEG ............................................................................................. 48
6.17 Color Space Transformation .............................................................................. 49
6.18 Discrete Cosine Transform ................................................................................ 50
6.19 Adaptative quantization ..................................................................................... 54
6.20 “Zigzag” Ordering .............................................................................................. 54
6.21 Run-Lengh Encoding ......................................................................................... 55
6.22 Huffman Coding................................................................................................. 56
6.23 Método de detección de movimiento ................................................................. 58
6.24 Implementación ................................................................................................. 60
6.25 Evaluación de la solución .................................................................................. 61
6.26 Dispositivo Terminal .......................................................................................... 64
6.27 Futuro de los Wearable ..................................................................................... 67
6.28 DATOS DE ENTRADA AL S.O. REMOTO ........................................................ 68
7 CONCLUSIONES ..................................................................................................... 70
8 BIBLIOGRAFIA .......................................................................................................... 72

4
 TABLA DE FIGURAS

Fig. 1 Tendencia Incremento Precios Equipos Samsung Y IPhone.................................... 2

Fig. 2 INFRAESTRUCTURA MÓVIL VIRTUAL .................................................................. 8
Fig. 3 CONCEPTO DE MOBILE CLOUD COMPUTING .................................................. 12
Fig. 4 MARCO DE VISUALIZACIÓN REMOTA ............................................................... 13
Fig. 5 Dispositivos Wearables .......................................................................................... 16
Fig. 6 Estructura Vmi En Nubo......................................................................................... 17
Fig. 7 Estructura Vmi Para Aplicaciones Android De Nubo .............................................. 17
Fig. 8 Aplicación Vmi De Sierra En Dispositivo Móvil ....................................................... 18
Fig. 9 Modelo De Infraestructura Móvil Virtual Trendmicro ............................................... 19
Fig. 10 Configuración de la Arquitectura del Control Remoto ........................................... 21
Fig. 11 Etapas Del Método: Virtualización, Protocolo De Comunicación Y Wearable. ..... 22
Fig. 12 Arquitectura De Virtualización .............................................................................. 24
Fig. 13 Diferenciación Entre Los Dos Tipos De Hipervisores ........................................... 25
Fig. 14 Diferenciación Entre Los Dos Tipos De Hipervisores ........................................... 26
Fig. 15 Recursos Asignados A Máquinas Virtuales En Relación A Recursos Físicos ...... 28
Fig. 16 Procesamiento De Solicitud De Una Aplicación De Vm De Lectura De Disco ...... 29
Fig. 17 Asignación De Recurso De Red A Máquinas Virtuales ........................................ 30
Fig. 18 Solicitud De Red Desde La Aplicación De La Máquina Virtual ............................. 31
Fig. 19 Asignación De Ips A Máquinas Virtuales .............................................................. 32
Fig. 20 Ruta De Solicitud De Datos Desde La Aplicación De La Máquina Virtual Al
Controlador De Almacenamiento ..................................................................................... 34
Fig. 21 Grupo De Discos Separados Agrupados En Recurso Utilizado Por Múltiples
Sistemas. ......................................................................................................................... 34
Fig. 22 Asignación De Memoria A Máquina Virtual .......................................................... 36
Fig. 23 En M-Jpeg Cada Frame Es Codificado Usando La Técnica Jpeg. Esto Proporciona
Acceso Aleatorio A Todos Los Frames. ........................................................................... 45
Fig. 24 Arquitectura Protocolo De Visualización Remota Hibrida En El Servidor ............. 47
Fig. 25 Diagrama De Flujo De La Compresión Jpeg ........................................................ 48
Fig. 26 Visualización De Los Espacios De Color De Rgb................................................. 49
Fig. 27 Subimagen 8x8 Mostrada En Escala De Grises De 8bits ..................................... 51
Fig. 28 Ejemplo Rango De Datos Centrado A Cero ......................................................... 51
Fig. 29 Resultado Aplicación Dtc En Imagen ................................................................... 52
Fig. 30 Transformada Dtc En Un Bloque 8x8 ................................................................... 53
Fig. 31 Ordenamiento Zigzag De Los Componentes De Una Imagen Jpeg ..................... 55
Fig. 32 Áreas Uniformes Y Líneas De Barrido ................................................................. 56
Fig. 33 Enfoque De La Propuesta De Detección De Movimiento ..................................... 59
Fig. 34 Modelo De La Implementación Por Subprocesos................................................. 61
Fig. 35 Consumo De Ancho De Banda De Diferentes Protocolos .................................... 62
Fig. 36 Calidad Del Video De Diferentes Protocolos ........................................................ 63
5
Fig. 37 Consumo De Cpu Del Dispositivo Cliente De Diferentes Protocolos .................... 64
Fig. 38 Arquitectura De Funcionamiento De Dispositivo Wearable .................................. 65
Fig. 39 Formato Del Mensaje Rfb .................................................................................... 66
Fig. 40 Solución Wearable ............................................................................................... 67
Fig. 41 Análisis Actual Y Proyección Para El 2017 Sobre Ventas De Dispositivos Wearable
........................................................................................................................................ 68
Fig. 42 Dispositivo Wearable ........................................................................................... 69

TABLAS

TABLA 1 Estructura Del Formato Del Pixel De Datos ...................................................... 41

TABLA 2 Actualización Del Framebuffer .......................................................................... 42
TABLA 3 Actualización Del Framebuffer -Cliente ............................................................. 42
TABLA 4 Actualización Del Framebuffer –Cliente 2 ......................................................... 42
TABLA 5 Entradas De Mapas De Color ........................................................................... 43
TABLA 6 Numero De Colores .......................................................................................... 43
TABLA 7 Codificación ...................................................................................................... 44
TABLA 8 Representación Símbolos Codificación Huffman .............................................. 57

6
 GLOSARIO

BARE-METAL: “Metal desnudo” es un sistema informático o una red en la que una

máquina virtual se instala directamente en el hardware en lugar de en el sistema
operativo (SO) host.
BYOD (Bring Your Own Device) : Es la tendencia ‘Traiga su propio dispositivo’
que hace referencia a la tendencia de que los empleados utilicen sus dispositivos
móviles para su uso en el trabajo.
CCD (Charge Coupled Device): Sensor con células fotoeléctricas que registran
la imagen.
CODECS: Proviene de una abreviatura de las palabras codificadoras y
decodificadoras, el cual consiste de una especificación de software que permite
comprimir y descomprimir archivos.
CPU (Central Processing Unit): Unidad central de procesamiento, es la parte
encargada de procesar todas las instrucciones y datos del software y del
hardware.
DAS (Direct Attached Storage) : Almacenamiento de conexión directa, es el
almacenamiento informático que está conectado a una computadora y no es
accesible a otras computadoras.
DCT(Discrete Cosine Transform): La transformada de coseno discreta, expresa
una secuencia finita de puntos de datos en términos de una suma de funciones de
coseno oscilando a diferentes frecuencias.
DHCP(Dynamic Host Configuration Protocol): Protocolo de configuración dinámica
de host, es un protocolo cliente / servidor que proporciona automáticamente un
host de Protocolo de Internet (IP).
E-SIM (Embedded-SIM): Una sim embebida, tarjeta SIM electrónica que no
requiere de una SIM física en los dispositivos móviles.
FCC (Fiber-Channel Controller): Tecnología de interconexión de I/O en serie
capaz de soportar múltiples protocolos. Se utiliza principalmente para redes de
área de almacenamiento (SAN).
FRAMEBUFFER: Parte de buffer reservada para mantener temporalmente una
imagen para ser enviada al monitor de un dispositivo.
GARTNER: Consultora especializada en Tecnología Informática.

7
GPU (Graphics Processor Unit) : El tipo de procesamiento al que se dedica es al
de gráficos.
H.264: Especifica la capa del sistema de la codificación. Se desarrolló
principalmente para apoyar la combinación de los métodos de codificación de
video y audio
Handshake: Término utilizado para describir el proceso de un dispositivo que
establece una conexión con otro.
HBA (Host-Bus Adapter): Un adaptador de bus de host es adaptador de circuito
integrado que proporciona procesamiento de entrada y salida y conectividad física
entre un sistema host y un dispositivo de almacenamiento y/o red.
HYPERVISOR: También llamado VMM (Virtual Machine Monitor) ó monitor de
máquina virtual se encarga de gestionar los recursos del sistema principal
exportándolos a la máquina virtual.
IME (Input Method Editor): Método de entrada convierte pulsaciones de teclado en
caracteres a un idioma entendible.
MCC (Mobile Cloud Computing): Computación en la nube móvil, es la combinación
de Computación en la nube y redes cuya finalidad es permitir la ejecución de
aplicaciones móviles en una gran cantidad de dispositivos móviles.
M-JPEG (Motion-JPEG) : Es un algoritmo de compresión de imágenes.
MPEG-2: Designación de codificación de audio y vídeo que fue publicado como
estándar ISO 13818.
NIC (Network Interface Card): La tarjeta de red instala en un computador para que
pueda ser conectado a una red.
QoE(Quality of Experience): La calidad de experiencia es definida como la
aceptabilidad de una aplicación o servicio.
RAM (Random Access Memory) : Memoria de accesos aleatorio, es utilizada por
un procesador para recibir instrucciones y almacenar información.
RFB (Remote Framebuffer): Es un protocolo simple para el acceso remoto a
interfaces gráficas de usuario que permite a un cliente ver y controlar un sistema
de ventanas en otro ordenador
RLE (Run-length encoding): La compresión RLE es un método de compresión de
datos en la que secuencias de datos con el mismo valor consecutivas son
almacenadas como un único valor.

8
SAN (Storage Area Network): Red de área de almacenamiento, red de alta
velocidad dedicada (y subred) que interconecta y presenta agrupaciones
compartidas de dispositivos de almacenamiento a varios servidores.
SCSI (Small Computer System Interface): Una interfaz de transferencia de datos,
es un conjunto de estándares de interfaz paralelos para conectar diferentes
dispositivos.
SSH (Secure SHell): Es un protocolo que facilita las comunicaciones seguras entre
dos sistemas usando una arquitectura cliente/servidor
THIN-CLIENT (cliente ligero): Es decir un dispositivo de reducidas dimensiones y
poco peso con el mínimo número de elementos electrónicos.
VDI (Virtual Desktop Infrastructure): Infraestructura virtual de escritorios es la
práctica de alojar un sistema operativo de escritorio dentro de una máquina virtual
(VM) que se ejecuta en un servidor centralizado.
VDM: Virtualización de dispositivos móviles
VM (Virtual Machine): Una máquina virtual es una implementación de software,
que normalmente emula un ambiente de computación físico donde los recursos de
hardware se abstraen de una infraestructura de hardware físico subyacente.
VNC (Virtual Network Computing): Computación virtual en red, es una tecnología
de escritorio remoto que permite visualizar y controlar la visualización de una
computadora a través de una red.
WNIC (wireless network interface controller): Es una tarjeta de red que se utiliza
para conectar redes de computadoras basadas en radio, en lugar de una red
cableada.

9
 1 INTRODUCCION

En los años recientes, el mundo ha presenciado una constante evolución en los

sistemas móviles. A nivel de hardware los desarrollos tecnológicos se han
centrado en el empleo de CPU multi-core que elevan los niveles de procesamiento
a millones de procesos por segundo mientras a nivel de software el foco de
innovación se extiende a metodologías de virtualización que aíslen y protejan la
información, lo que gracias a esta solución es un modo de cumplir con ello. Este
documento se centra en plantear un método de integración de tecnologías de
virtualización y dispositivos de terminal de usuario conocidos como Wearable que
asocia el concepto de comunicaciones primarias y un espectro de nuevos
servicios que proporcionan una mejor experiencia al usuario.

Similar a los modelos de virtualización de PC, la infraestructura virtual móvil (VMI)

en principio es una tecnología en el que se ejecutan aplicaciones móviles en un
sistema operativo sobre una máquina virtual (VM) alojada en un servidor remoto.
En esos términos, el sistema operativo y las aplicaciones se ejecutan en la VM en
un centro de datos remoto o servidor que junto a un software conocido como
Hipervisor, que asigna automáticamente recursos informáticos según sea
necesario y través de un protocolo de comunicaciones, el OS y las Apps se
entregan al terminal del usuario (Wearable) donde se decodifica por una aplicación
cliente y se visualiza. Este procedimiento permite que el dispositivo se comporte
como si estuviera ejecutando localmente las aplicaciones, pero las accesa para
crear una imagen interactiva en el Display del dispositivo y así interactuar con el
usuario.

Los dispositivos Wearables están a punto de cambiar el mundo, ya que estos se

encuentran en contacto permanente y directo con el usuario. Las barreras
tecnológicas tales como el tamaño y autonomía de energía están desapareciendo
rápidamente, y el diseño centrado en el usuario está simplificando y facilitando la
utilización de Wearables por el público.

El contenido de este documento define tres focos fundamentales que representan

el conjunto de tecnologías a integrar para dar solución al método propuesto. En
una primera instancia se exploran los conceptos y funcionalidades de la
virtualización, seguidamente se introduce en el protocolo de comunicación donde
se discriminan los modelos de compresión para ambientes de alto y bajo
movimiento de imágenes y video y demás funcionalidades, finalmente se introduce
la tecnología Wearable y se determina los requerimientos mínimos para cumplir
con el objeto de la propuesta planteada.
 2 PLANTEAMIENTO DEL PROBLEMA

Ineficiencias en el funcionando del teléfono móvil ocasionan que no se aproveche

en su totalidad la funcionalidad de aplicaciones, recursos de red, memoria y
consumo energético.
Cada vez los equipos móviles requieren de una mayor capacidad de
procesamiento y almacenamiento para soportar aplicaciones que son cada vez
más robustas y complejas; es así que se tendría que adquirir un nuevo dispositivo
que cumpla con los requerimientos ya que no existe un método que posibilite
ampliar las características de hardware de los teléfonos móviles dados los
recursos funcionales con los que han sido adquiridos.

Actualmente, los dispositivos no cuentan con la capacidad de ejecutar de manera

simultánea múltiples sesiones de usuarios, aplicaciones multiplataforma, gestión
de Storage y Backups que son funciones necesarias para garantizar criterios de
seguridad, escalabilidad, flexibilidad y rendimiento de recursos. Los avances de la
tecnología y la creciente demanda de recursos de hardware en los equipos
móviles debido a los lanzamientos de aplicaciones especializadas y robustas, se
hace necesario mantenerse actualizados o ser partícipe de las actualizaciones
tecnológicas representa costos adicionales cada vez superiores, esto se puede
evidenciar con la constante evolución de los dispositivos que se encuentran en el
mercado.

Fig. 1 Tendencia Incremento Precios Equipos Samsung Y IPhone.

Fuente: AUTOR

Teniendo como ejemplo las marcas más representativas en el sector (IPhone y

Samsung) se evidencia el aumento de costos como se puede apreciar en la Figura
1, tal incremento se debe en gran medida a los nuevos desarrollos de aplicaciones
2
que demanda el mercado y que a su vez conllevan a realizar actualizaciones en el
sistema operativo para poder ejecutarlas y procesarlas. Uno de los ejemplos en
los que se puede demostrar la dependencia del soporte de aplicaciones del
sistema operativo es WhatsApp, empleada por miles de usuarios alrededor del
mundo. En el año 2016, esta aplicación a través de su blog expresa 1: "mirando
hacia el futuro, queremos enfocar nuestros esfuerzos en plataformas móviles que
la gran mayoría de la gente use" por eso, para finales de dicho año WhatsApp
Messenger dejó de ser compatible con versiones antiguas de algunas plataformas
móviles.

La dependencia al uso de los dispositivos móviles se ve reflejada en que en la

actualidad la mayoría de la población desde cortas edades cuentan uno a varios
teléfonos celulares para mantener una comunicación constante, lo cual representa
que sea portado en la mayor parte del día por todos los usuarios, consiguiendo
que muchas veces estos sean extraviados y representan también un atractivo para
su hurto. Por lo que los usuarios pierden información personal o laboral valiosa
almacenada en estos.

En Colombia, de acuerdo con la Policía Nacional2, en el año 2015 se robaron más

de 22.054 móviles. Adicionalmente, la Comisión de Regulación de
Comunicaciones (CRC), indica que “a pesar de que en Colombia no se permite la
reventa de celulares hurtados que provienen de otros países, en esos territorios
los operadores no bloquean los que llegan procedentes de esta manera ilícita,
motivo por el que el mercado de los celulares robados en las diferentes ciudades
está afuera y sigue creciendo”.

Con la finalidad de utilizar diversos sistemas y mecanismos que surgen de la

evolución tecnológica se plantea la siguiente pregunta:

¿Cómo se podrían integrar tecnologías de dispositivos móviles con soluciones

virtuales para optimizar recursos hardware?

1
(WhatsApp.com. (2017). WhatsApp support for mobile devices. Disponible:
https://blog.whatsapp.com/10000617/Compatibilidad-de-WhatsApp-con-tel%C3%A9fonos-m%C3%B3viles)
2
http://www.eltiempo.com/colombia/otras-ciudades/cifras-sobre-robos-en-colombia-en-2016-33762 (EL
TIEMPO, 2016)
3
 3 JUSTIFICACION

La investigación tecnológica en el campo de la virtualización presenta

características que vinculan mecanismos de innovación que responden a las
necesidades y requerimientos cambiantes de los usuarios y que involucran la
reproducción completa de diversos elementos de hardware, software y servicios
sobre la nube, lo que confluye en ventajas operacionales e independencia de
hardware propias de la virtualización y cuyo valor es mejorar niveles de
satisfacción y estándares en el entorno social.

Aplicaciones especializadas exigen un desempeño y aprovechamiento mayor de

los recursos a nivel de hardware, de allí que evaluar el uso de tecnologías en
ambientes cloud constituye una opción que permite generar un rendimiento mayor
en el desempeño de aplicaciones ya que no cuenta con limitaciones de memoria ni
procesamiento en hardware. Adicionalmente permite acceder a los recursos del
sistema de manera más ágil y efectiva. En el ámbito de seguridad proporciona alta
fiabilidad ante fallas y alteraciones informáticas.

En busca de sustituir la robustez de los teléfonos móviles se pretende investigar

procesos de migración tecnológica a la nube que permita sacarle el máximo
provecho a estos dispositivos sin perder continuidad ni funcionalidad una vez sean
adoptados los recursos primarios a nivel de hardware en nuevos módulos
versátiles y menos robustos que respondan a los mismos servicios de aplicaciones
y comunicaciones y aún otros más sofisticados que envuelvan nuevas
funcionalidades, sin perder los principios de portabilidad y practicidad que es el
punto de convergencia para esta propuesta de innovación.
Los dispositivos Wearable en el mercado global tienen como característica
principal la incorporación de tecnologías a un accesorio portable especializado,
que sirve como un elemento adicional del vestuario, es por esto que son
empleados principalmente como relojes de pulsera, gafas entre otros. Estos se
sincronizan con los teléfonos celulares permitiéndoles cumplir algunas funciones
básicas para que el usuario pueda interactuar con este sin necesidad de hacer uso
directo de su teléfono. Los dispositivos Wearables cuentan con múltiples
características similares a los Smartphone, sin embargo, involucran menor
complejidad en sus características tanto físicas como tecnológicas ya que no
integran todas las funcionalidades de un teléfono robusto.

Es así que se puede realizar un método que permita integrar tecnologías

Wearables con tecnologías de virtualización donde el usuario tenga la capacidad
de ampliar recursos de software sin la necesidad de reemplazar recursos de
hardware ya que esto depende de la capacidad de la máquina virtual en la que el
4
sistema operativo se encuentre almacenado.

El desarrollo de esta propuesta se fundamenta en la investigación de mecanismos

de gestión de la tecnología de virtualización VMI y plataformas, protocolo de
comunicación, tecnologías Wearable y métodos de seguridad para ambientes
virtuales. Con lo anterior se busca establecer un método que correlacione estas
tecnologías para buscar beneficios funcionales y económicos.

5
 4 OBJETIVO GENERAL

Proponer un método de integración entre tecnologías Wearable con soluciones de

virtualización para la sustitución de recursos de hardware de tecnologías móviles.

4.1 OBJETIVOS ESPECÍFICOS

- Especificar qué tecnología de virtualización se adapta al método de

integración propuesto.

- Determinar qué dispositivos Wearable se adaptan al método de integración

propuesto y que permitan la ejecución de los diferentes servicios propios de
los teléfonos móviles.

- Establecer el esquema de comunicación entre el dispositivo Wearable y la

nube que cumpla con los parámetros de visualización remota de las
aplicaciones móviles virtualizadas.

- Determinar las características de la plataforma tecnológica y de

comunicación planteada que se adapte a las necesidades de los usuarios
que usan tecnologías móviles.

6
 5 ESTADO DEL ARTE

La edad de la información está rodeándonos de manera acelerada,

permitiéndonos acceder a pasos agigantados a inmensas cantidades de datos al
instante, dónde teléfonos celulares y otros dispositivos móviles proporcionan
experiencias de acceso a vídeo, audio y otros formatos multimedia en cualquier
instante y en cualquier lugar. La reacción de las personas a todo este bombardeo
de nuevas y mejores experiencias ha impulsado espontánea y exponencialmente
a un crecimiento y a un apoyo en todo este tipo de infraestructuras tecnológicas.
Un servicio que facilita este rápido crecimiento es la virtualización.

Pero ¿Qué es la virtualización?, Wolf C., y Halter E.3 consideran la virtualización

como “el acto de abstraer los límites físicos de una tecnología” y estas
abstracciones físicas están ahora ocurriendo en diversos modos.
La virtualización de dispositivos móviles se está expandiendo hacia varios
campos, al igual que las plataformas y estandarización que siguen emergiendo
desde diversas direcciones, lo que ocasiona un amplio espectro de nuevos
dispositivos y desarrollos innovadores, que en rigor resulta ser una tendencia
prometedora de gran acogida y aceptación.
A nivel general, la virtualización de dispositivos móviles (VDM) es una tecnología
que separa los sistemas operativos y las aplicaciones de los dispositivos
terminales que los accesan. Si bien, para la virtualización de equipos de escritorio
los usuarios acceden remotamente a escritorios Windows o cualquier otro sistema
operativo y sus aplicaciones, en los VDM se ofrecen acceso remoto a sistemas
operativos móviles tales como Android.

Una plataforma VMI transmite cualquier aplicación móvil a un centro de recursos

remoto. Todas las aplicaciones se ejecutan en un servidor dentro centro de datos
seguro, sin dejar datos o aplicaciones en reposo en el terminal físico, de modo
que, si el dispositivo se pierde, los datos y las aplicaciones no se ponen en riesgo.
Sin embargo, existen algunos obstáculos para el éxito de VMI, como la necesidad
de conectividad a Internet y la optimización de los recursos. Sunwook K, Jihyeok C
y Seongwoon Kim4, plantean la manera de diseñar un escritorio virtual que reduce
la carga en el servidor donde se disminuye y optimiza el ancho de banda de la red,
incrementando los usuarios y los servicios, siendo un referente sobre cómo
se realiza la virtualización y migración a la nube, y permite conocer en detalle las
características de esta tecnología emergente que es conceptualmente similar a las
tecnologías de escritorio remoto. Una de las limitaciones de VMI es que no

3
Wolf, C., Halter, E.: Virtualization From the Desktop to the Enterprise. Apress (2005)
4
Sunwook K., Jihyeok C., Seongwoon Kim, and Hagyoung Kim (2016). Cloud-based Virtual Desktop Service
Using Lightweight Network Display Protocol. International Conference on information Networking (ICOIN) 2016

7
funciona sin conexión.

El principio de la virtualización es una máquina virtual (VM), que es un software

aislado que sirve como un contenedor de aplicaciones y que cuenta con un
sistema operativo. Un servidor puede ejecutar simultáneamente múltiples VMs a
través de un software llamado Hipervisor, el cual asigna automáticamente
recursos informáticos a cada VM según sea necesario. Cada máquina virtual es
capaz de ejecutar múltiples sesiones de usuario. Además de ejecutar las sesiones
de usuario nativas, este sistema también es responsable de la activación y
autenticación del usuario y el ciclo de vida de la infraestructura. Cada usuario está
aislado dentro del contenedor virtual, y cada aplicación está aislada de otras
aplicaciones dentro de la zona de pruebas del usuario. Esto proporciona mayor
flexibilidad al tiempo que permite sesiones de usuario que se ejecutan cada vez en
una máquina virtual diferente. También es más fácil para el administrador de TI
gestionar la copia de seguridad y el almacenamiento desde la ubicación central.
En la figura 2 se observa el esquema de infraestructura móvil virtual.

Fig. 2 INFRAESTRUCTURA MÓVIL VIRTUAL

Fuente : AUTOR

Debido a los métodos de virtualización, los teléfonos celulares ya no necesitan un

hardware físico dedicado, como procesadores o memorias con el objeto de correr
sus dominios independientemente. En vez de ello, pueden correr en máquinas
virtuales, donde el hardware del dispositivo móvil se emula sobre otra plataforma
que en este caso es un servidor. Con esta tecnología se tiene la habilidad de
remover la dependencia del hardware y los sistemas operativos.

8
5.1 Infraestructura Móvil Virtual

VMI tiene una gestión de aplicaciones móviles que permite trabajar y administrar
cualquier aplicación en cualquier dispositivo. Al igual que VDI (Virtual Desktop
Infrastructure) que hace referencia al proceso de hospedar un sistema operativo
para computadoras de escritorio en una máquina virtual (VM) que opera desde un
servidor centralizado, la infraestructura móvil virtual (VMI) aloja un sistema
operativo en un centro de datos, los usuarios pueden acceder a él remotamente
desde varios puntos finales. La diferencia con VDI es que alberga un sistema
operativo móvil en lugar de un sistema operativo de escritorio donde los clientes
son aplicaciones móviles y los protocolos de visualización remota están diseñados
específicamente para manejar entradas táctiles y conexiones móviles. Con VMI,
se puede entregar una aplicación móvil alojada en un centro de datos a un
dispositivo móvil que se ejecute en cualquier plataforma.

Debido a que el sistema operativo se ejecuta en el centro de datos, no hay datos

presentes en el dispositivo móvil, lo que hace VMI ideal para ambientes de alta
seguridad.

Hay que tener en cuenta otros aspectos ya que todas las soluciones de VMI tienen
como sistema operativo alojado Android, ya que Apple no permite que iOS
funcione con hardware de terceros ni se controle de forma remota. Esto significa
que todas las aplicaciones para el entorno VMI deben estar disponibles para
Android. Esto puede ser un desafío, ya que muchos proveedores de software
independiente todavía producen aplicaciones sobre IOS primero.

Un sistema de virtualización móvil está dividido en dispositivos móviles y

servidores de virtualización. Los dispositivos móviles y el servidor de virtualización
están conectados por Wi-Fi o por cualquier otro protocolo de acceso al medio. Los
terminales móviles son dispositivos de bajo rendimiento y ligeros, tienen códecs y
sensores mínimos y sólo tienen funciones de decodificación de datos provenientes
del servidor. El sistema de nube basado en servidor de virtualización tiene
máquinas virtuales VM que reciben eventos de las terminales móviles y envían la
información codificada a los dispositivos5.

La virtualización del software ofrece varios beneficios, incluyendo la consolidación

de la infraestructura, la fácil replicación y reubicación, la normalización de
sistemas y aislamiento de recursos. En resumen, VMI da la habilidad de correr
múltiples dispositivos virtuales en un mismo equipo físico y almacenar en él casi
cualquier medio. La capa de virtualización es abstracta, porque el sistema
operativo está construido sobre un hardware idealizado, es así que se puede
cambiar cualquier hardware físico sin impactar en la función de la máquina virtual.

5
Hyun-suk Roh., Hyun-woo Lee., y Sang-ho Lee., 2014, A study on mobile virtualization
9
La capa de virtualización correlaciona el hardware virtualizado con los recursos
físicos terminales.

Respecto a la visualización de contenidos, el sistema operativo se entrega al

dispositivo terminal a través de un protocolo de comunicaciones remoto seguro,
que se decodifica en una aplicación de cliente que se ejecuta en el terminal móvil.
El sistema operativo y las aplicaciones no se tienen que ejecutar de forma local en
el terminal. Algunas aplicaciones de cliente pueden ejecutarse de forma local en el
hardware - tales como GPS, acelerómetros y cámaras – para uso del sistema
operativo a distancia, lo que hace que el sistema operativo y sus aplicaciones se
comporten como si estuvieran ejecutando localmente.

VMI permite un control total sobre el sistema operativo móvil, algo que ha sido casi
imposible en la era de los teléfonos inteligentes, donde se puede personalizar el
sistema operativo, controlar las actualizaciones (tanto las actualizaciones de
aplicaciones como las actualizaciones del sistema operativo), establecer permisos
y, en general, bloquearlos como desee.

Debido a que el tamaño de datos de visualización es mayor que cualquier otra

señal de interfaz, la sesión de visualización utiliza el ancho de banda de red más
que otras sesiones que se requieren para proporcionar el ambiente virtual al
usuario. Para reducir el ancho de banda de la red y el consumo de recursos, el
módulo de procesamiento de la sesión de visualización realiza la optimización de
la señal que consiste en aplicar metodologías de compresión para reducir la
cantidad de datos de la imagen en sí.

El reto con la infraestructura móvil virtual es la necesidad de conectividad de red

en los dispositivos. VMI simplemente no es una opción para usos fuera de línea.
Se puede presentar escepticismo acerca de la latencia y la fidelidad sobre las
conexiones móviles, pero VMI se desarrolló específicamente para este escenario.
La mayoría de los productos VMI ofrecen un rendimiento bastante bueno en
conexiones Wi-Fi y 4G. Mohd F., Ros H. y Muhammad A.6, describen el entorno
de escritorio virtual en la nube y proponen el desarrollo de un servidor de nube,
adicionalmente muestran cómo mejorar la experiencia del usuario y cómo reducir
los costos al ofrecer servicios en la nube y presentan una arquitectura de un
sistema de virtualización y cómo se puede optimizar un dispositivo que se
encuentra constantemente en conexión.

La infraestructura móvil virtual también debe tener en cuenta las necesidades y

requerimientos de los usuarios. Estos productos necesitan encontrar una forma
en que las características del sistema operativo, como las notificaciones Push,

6
Mohd F., Ros H., Muhammad A. Virtual Desktop Environment on Cloud Computing Platform. Control and
System Graduate Research Colloquium (ICSGRC), 2014 IEEE 5th
10
sean redirigidas a las aplicaciones del cliente. Los protocolos remotos necesitan
soportar más que solo eventos táctiles. Para una sólida experiencia de usuario,
tienen que soportar audio, datos de ubicación, orientación, cámaras etc.

Un enfoque del uso de la tecnología VMI hacia un cliente es la flexibilidad respecto

a costos, seguridad y alto desempeño como hace referencia Justin Marston 7 en
sus conferencias sobre tecnología.
5.2 Virtualización de Aplicaciones Móviles

En la virtualización de aplicaciones se encapsula Apps o aplicaciones móviles

desde un sistema subyacente al que se ejecuta. La virtualización completa de
aplicaciones requiere una capa de virtualización8. Las capas de virtualización de la
aplicación reemplazan parte del entorno de ejecución normalmente proporcionado
por el sistema operativo. La capa intercepta todas las operaciones de disco de las
aplicaciones virtualizadas y las redirecciona de forma transparente a una ubicación
virtualizada, a menudo un solo archivo. La aplicación no tiene conocimiento de que
accede a un recurso virtual en lugar de uno físico. Dado que la aplicación ahora
está trabajando con un archivo en lugar de muchos archivos distribuidos por todo
el sistema, se vuelve fácil ejecutar la aplicación en un equipo diferente y las
aplicaciones anteriormente incompatibles se pueden ejecutar lado a lado.
Se virtualiza la aplicación individual y la sesión de usuario en lugar del sistema
operativo móvil completo en sí. Las aplicaciones remotas corren en un servidor
donde los usuarios ven e interactúan con sus aplicaciones vía un protocolo de
visualización remota.
5.3 Protocolo de visualización Remota

Un protocolo de comunicaciones es un sistema de reglas en telecomunicaciones

que permite a sistema de comunicaciones transmitir información vía cualquier
variación de una magnitud física. Estos protocolos pueden ser implementados por
hardware, software o una combinación de ambos. Los sistemas de
comunicaciones usan formatos bien definidos para el intercambio de mensajes.
Cada mensaje tiene un significado exacto destinado a obtener una respuesta de
un rango de posibles respuestas predeterminadas para una situación particular.
La información intercambiada entre dispositivos a través de la red u otro medio es
gobernada por reglas y convenciones que son presentadas en especificaciones
técnicas llamadas protocolos de comunicaciones estándar. La naturaleza de una
comunicación, los datos intercambiados y cualquier comportamiento, está definido

7
(Hypori Virtual Mobile Infrastructure Optimizes Android Devices on Intel-Based Clouds. Article “Android Cloud
Environment Now Available for Android Systems Running on Intel-based Servers , 2105)
8
Husain, Amir. "How to build an Application Virtualization Framework". VDIworks. 2008
11
por estas especificaciones. Los sistemas operativos usualmente contienen un
conjunto de procesos que manipulan los datos compartidos para comunicarse el
uno al otro.
Esta comunicación es gobernada por protocolos que se pueden integrar en el
propio código del proceso. Entendiendo que en la nube donde los recursos
informáticos son abundantes y fácilmente disponibles, se espera que cualquier
dispositivo de carácter móvil aproveche los servicios que residen en la
infraestructura de la nube y los extienda al extremo hacia los usuario móviles
como un proceso de integración de computación en la nube y dispositivos móviles.
Fig. 3 CONCEPTO DE MOBILE CLOUD COMPUTING

Aplicaciones

Dispositiv
Conectivida Internet Servidor

Fuente: AUTOR

Como se ilustra en la Figura 3, las aplicaciones de los usuarios y los datos, están
hospedados en el lado de la nube, pero el usuario experimenta como si estuvieran
directamente hospedados en su dispositivo móvil o Wearable.
Estos dispositivos están habilitando nuevas formas de computación móvil y
comunicaciones, llamado computación en la nube móvil (MCC Mobile Cloud
Computing). MCC se define como computación en la nube ampliada por la
movilidad y la infraestructura basada en dispositivos de carácter móvil. En esencia,
a los usuarios les son proporcionados almacenamiento de datos y servicios de
procesamiento en una plataforma de computación en la nube en lugar de los
propios dispositivos móviles. Desde esa perspectiva, puede ser entendido como la
infraestructura donde el procesamiento de datos puede ocurrir fuera de un
dispositivo móvil habilitando la entrega de aplicaciones con cualquier plataforma y
sistema de operación, incluyendo navegación web, email, videoconferencias,
presentaciones, películas, juegos y aplicaciones multimedia.
12
La funcionalidad mínima requerida para que estos dispositivos soporten esta
tecnología es conectividad de red y una interface de usuario, de modo que las
entradas de los usuarios (como pulsaciones de las teclas) y las salidas de las
aplicaciones puedan ser transferidas de/hacia el servidor en la nube. Esto se
puede implementar en un marco de visualización remota. Hay tres clases de
componentes básicos para un marco de visualización remota9 1) Componentes del
lado del servidor que captura y codifica los gráficos de las aplicaciones, 2)
Componentes de interfaz de usuario en el lado del cliente donde los gráficos de
las aplicaciones transmitidas son decodificados y traducidos y 3) Un protocolo de
visualización remota para transferir gráficos de aplicaciones de un servidor a un
cliente y entregar la interacción del usuario desde un dispositivo cliente a un
servidor (Ver figura 4).
Fig. 4 MARCO DE VISUALIZACIÓN REMOTA

Fuente: "How to build an Application Virtualization Framework".(2008)

Entre estos componentes, la investigación respecto a los protocolos de

visualización remota ha sido bastante grande, y ha estado enfocada
principalmente, en cómo convertir imágenes de alta calidad a gran velocidad.
Existen diversos tipos de codificación en VNC (Virtual Network Computing) que es
uno de los protocolos remotos más populares10.
El protocolo VNC es un protocolo simple para el acceso remoto a interfaces
gráficas de usuario. Se basa en el concepto de un Framebuffer remoto o RFB. El
protocolo simplemente permite a un servidor actualizar el Framebuffer que se
muestra en un visor. Debido a que funciona en el nivel Framebuffer es
potencialmente aplicable a todos los sistemas operativos, sistemas de ventanas y

9
Boyun Eom and Hyunwoo Lee. “Power-Aware Remote Display Protocol for Mobile Cloud”. 2013
10
Hyunwoo Lee, and Won Ryu, Boyun Eom, Choonhwa Lee. “An Adaptive Remote Display Scheme to Deliver
Mobile Cloud Services” Member, IEEE, Vol. 60, No. 3, August 2014
13
aplicaciones. Este es realmente un protocolo "Thin-Client". De esta manera, los
clientes pueden ejecutar en la más amplia gama de hardware, y la tarea de
implementar un cliente se hace tan simple como sea posible.
El lado de visualización del protocolo se basa en torno a un único gráfico primitivo:
"poner un rectángulo de datos de píxeles en una posición dada x, y". Puede
parecer una forma ineficiente de dibujar componentes de interfaz de usuario
arbitrarios, pero debido a existe una variedad de esquemas de codificación
diferentes para los datos de píxeles, se puede seleccionar el esquema apropiado
para cada rectángulo a enviarse, y aprovechar al máximo el ancho de banda de la
red, la velocidad de dibujo y la velocidad de procesamiento del servidor.
Una secuencia de estos rectángulos hace una actualización de Framebuffer. Una
actualización representa un cambio de un estado de Framebuffer válido a otro, por
lo que en algunos aspectos es similar a un cuadro de vídeo, pero normalmente
sólo es un área pequeña del Framebuffer que se verá afectada por una
actualización dada. El protocolo de actualización se basa en la demanda del
cliente. Es decir, una actualización sólo es enviada por el servidor en respuesta a
una solicitud explícita del cliente. Esto da al protocolo una calidad adaptativa.
Cuanto más lento sea el cliente y la red, menor será la tasa de actualizaciones.
Cada actualización incorpora todos los cambios a la "pantalla" desde la última
solicitud del cliente. Con un cliente y/o una red lenta, los estados transitorios del
Framebuffer se ignoran, lo que resulta en un tráfico de red reducido y menos
dibujo para el cliente. Esto también mejora la velocidad de respuesta aparente.
Los esquemas fundamentales de codificación soportados en RFB son Raw,
CopyRect, RRE, Hextile, ZRLE, CoRRE, ZLIB, Tight y cada uno muestra un radio
de compresión diferente.
La tecnología “Thin Client” móvil proporciona un modo poderoso de romper las
barreras entre diversas aplicaciones y un ambiente insuficiente local de
hardware/software. Gracias a la centralización de las aplicaciones en los servers,
los servicios pueden ser gestionados más fácilmente a niveles más altos de
seguridad para ser alcanzados. Adicionalmente, los usuarios pueden acceder a
aplicaciones computacionalmente más intensivas, para los cuales los recursos
existentes en un dispositivo cliente móvil son insuficientes para ejecutarlos
localmente. Este tipo de aplicaciones, frecuentemente requieren hardware grafico
(GPU) para traducir sus imágenes.
Un reto clave para la arquitectura de un dispositivo cliente es el retraso entre los
eventos del cliente, como pulsaciones de teclas y/o las actualizaciones de la
visualización correspondiente. Los usuarios están acostumbrados a la nítida
interfaz gráfica de las aplicaciones que se ejecutan localmente y esperan que la

14
infraestructura de computación de cliente ligero ofrezca la misma funcionalidad 11.
Los protocolos actuales de visualización remota, como el protocolo de Framebuffer
remoto (VNCRFB) y el protocolo de escritorio remoto (RDP de Microsoft), están
optimizados para la visualización estática de aplicaciones de oficina, como un
editor de texto o una hoja de cálculo. Los cambios en la pantalla son sólo menores
y tienen una frecuencia suficientemente baja para que el protocolo de visualización
remota pueda hacerle frente. Sin embargo, con la aparición de aplicaciones
multimedia, los protocolos de visualización remota existentes no pueden alcanzar
los altos niveles de interacción en tiempo real que los usuarios han llegado a
esperar. El problema clave es el hecho de que las aplicaciones multimedia a
menudo generan imágenes con patrones de colores finos y complejos y muy poca
correlación entre marcos subsecuentes (secuencia de imágenes). El transporte de
datos multimedia a través de un protocolo de visualización remoto es muy
ineficiente, dando lugar a altos requisitos de ancho de banda para entregar todos
los Frames al cliente de manera oportuna12. Por otro lado, Codecs de video como
MPEG-213 o H.26414, se optimizan para manejar imágenes en movimiento rápido
en un ancho de banda de manera eficiente.
De acuerdo con Pieter Simoens15 es posible manejar protocolos de comunicación
remota hibrida (HRDP), que apalanque la capacidad de presentar aplicaciones
multimedia en tiempo real.
Para ello, el códec usado en el protocolo necesita ser capaz de entregar de
manera eficiente datos comprimidos (para reducir los requerimientos de ancho de
banda) y operar con baja complejidad en los recursos de hardware (para disminuir
la respuesta en latencia y el consumo de energía del dispositivo del cliente).

5.4 Wearables

Diferentes desarrollos entorno a las tecnologías de la información han permitido

que los usuarios puedan acceder a la información en cualquier lugar y en cualquier
momento. El diseño de dispositivos móviles ligeros y Wearables han orientado a
las personas a acceder a información especialmente cuando se encuentran
desplazándose de manera fácil y cómoda, lo cual trae multitud de posibilidades a

11
Wei Tang, Biao Song, Myeong Seob Kim, Nguyen Tien Dung, Eui Nam Huh. “Hybrid Remote Display
Protocol for Mobile Thin Client Computing”. ©2012
12
L. Deboosere, J. D. Wachter, P. Simoens, F. D. Turck, B. Dhoedt, and P. Demeester, “Thin client computing
solutions in low- and highmotion scenarios,” in ICNS ’07: Proceedings of the Third International Conference on
Networking and Services. Washington, DC, USA: IEEE Computer Society, 2007, p. 38.
13
“ISO/IEC 13818-2:2000 Information Technology - generic coding of moving pictures and associated audio
information - part 2: Video.”
14
“ITU-T: h.264, Advanced video coding for generic audiovisual services,” 2005.
15
Pieter Simoens, Paul Praet, Bert Vankeirsbilck, Jeroen De Wachter, Lien Deboosere, Filip De Turck, Bart
Dhoedt, Piet Demeester. “Design and implementation of a hybrid remote display protocol to optimize
multimedia experience on thin client devices”. IBBT - Department of Information Technology, Ghent University
15
la hora de gestionar la información de los usuarios. A medida que la variedad de
tecnologías que se usan continúa creciendo, las TI debe hacer que sea una
prioridad considerar asuntos relacionados con la implementación, regulación y
restricciones de datos personales.
Los Wearables son como pequeñas computadoras que los usuarios usan en sus
cuerpos, por lo general en un accesorio común como un reloj o anteojos. Los
usuarios pueden almacenar datos convenientemente, rastrear ubicaciones e
incluso monitorear datos personales utilizando objetos portátiles.
La accesibilidad que ofrecen los dispositivos Wearables proporciona un medio
más fácil para mantenerse conectado. Loa Wearables también pueden almacenar
datos biométricos para el control de acceso y ofrecer instrucciones paso a paso u
orientación GPS. Incluso pueden traer reducciones de costos en comparación con
las tecnologías más grandes y más complejas. En la figura 5 se representa el
esquema de los dispositivos Wearables.
Fig. 5 Dispositivos Wearables

Fuente: IGOID, G. (2017). Los “Wearable” para mejorar nuestros hábitos de vida. Investigación en
gestiondeportiva.es

No obstante, este tipo de dispositivos se han vuelto una parte esencial para el
rápido desarrollo de redes móviles, y con el soporte de una red, estos sistemas de
clientes ligeros son un enfoque informático alternativo para proporcionar servicios
multimedia a los usuarios. Si se agrega ahora acceso remoto a un sistema
operativo y aplicaciones instaladas en un servidor remoto, se puede disfrutar de un
entorno informático convencional con la utilización de dispositivos portátiles
ligeros.

16
5.5 Trabajos relacionados

5.5.1 Nubo

Dentro de la investigación acerca de referentes teóricos que proporcionaran

información acerca de la virtualización móvil, se encuentran empresas como
NUBO la cual se encarga de manera específica de la aplicabilidad de soluciones
VMI en la empresa. Los ejecutivos de IT (tecnologías de la información)
seleccionan las soluciones de VMI porque proporcionan tranquilidad en que los
datos y las aplicaciones de las empresas se almacenan en un datacenter central
que puede controlarse más firmemente que en miles de dispositivos móviles
diferentes. Un sistema central es mucho más fácil de manejar y mantener.
Fig. 6 Estructura Vmi En Nubo

Fig. 7 Estructura Vmi Para Aplicaciones Android De Nubo

Fuente: IRIMI. (2016). Irimi.it

17
La integración con los recursos de TI locales, como Active Directory, servidor de
correo, CRM y software de ERP, también es mucho más simple desde un sistema
central. Los empleados pueden conectarse desde cualquier dispositivo móvil y
sistema operativo que utilicen. Desde una perspectiva de seguridad empresarial,
las IT puede desconectar el acceso a recursos de red para dispositivos que se han
perdido, robado o comprometido de otro modo. Esto elimina la necesidad de
enfocar esfuerzos de seguridad dentro de los diversos dispositivos y sistemas
operativos que están en uso dentro de la organización (virtual mobile
infrastructure, 2016).

5.5.2 Sierra

SierraVMI ofrece una poderosa plataforma VMI de extremo a extremo para

aplicaciones de Android. A diferencia de las soluciones alternativas que requieren
una instancia de máquina virtual independiente por usuario, SierraVMI combina
contenedores o virtualización de Bare-metal, permitiendo a las organizaciones
servir a miles de usuarios de una gran instancia de VM de nube.
Fig. 8 Aplicación Vmi De Sierra En Dispositivo Móvil

Fuente: www.sierraware.com

En comparación con las soluciones VMI de "una VM por usuario", SierraVMI

cuesta una pequeña fracción del precio; las organizaciones necesitan proporcionar
18
menos servidores para implementaciones en premisa o comprar una milésima
parte del número de instancias virtuales para despliegues en la nube. SierraVMI
también elimina la necesidad de sistemas complicados de orquestación de nubes.
Debido a su arquitectura de alta densidad, las organizaciones pueden
proporcionar acceso a diez mil usuarios de una docena de servidores. Con
SierraVMI, las organizaciones pueden evitar el aprovisionamiento de racks en
racks de servidores. Pueden configurar SierraVMI en horas en lugar de días o
semanas.

5.5.3 Trend Micro

Los dispositivos móviles, incluidos los teléfonos inteligentes y tabletas de

propiedad de los empleados, están ahora integrados en las prácticas
empresariales modernas. La capacidad de los trabajadores para acceder a datos
corporativos y aplicaciones utilizando cualquier dispositivo en el campo es una
necesidad competitiva. Esta tendencia a llevar sus propios dispositivos (BYOD)
puede resultar en un aumento de los riesgos de seguridad de los datos para las
empresas y de los problemas de privacidad para los empleados.
Trend Micro ™ Virtual Mobile Infrastructure garantiza la confidencialidad de los
datos corporativos al proporcionar a los empleados un espacio de trabajo virtual
seguro y no intrusivo diseñado específicamente para sus dispositivos móviles.
Fig. 9 Modelo De Infraestructura Móvil Virtual Trendmicro

Fuente: www.trendmicro.com

19
A través de este espacio de trabajo virtual alojado, los empleados pueden acceder
a los datos de trabajo sin el riesgo de pérdida de datos o fugas, ya que los datos
corporativos nunca se almacenan en sus dispositivos o salen del servidor de su
empresa. Los administradores pueden configurar y desplegar centralmente varias
áreas de trabajo móviles a todos sus usuarios corporativos a través de un panel
central.

20
 6 Solución

Esencialmente, la propuesta se basa en un concepto conocido como virtualización

móvil remota que abarca tanto la virtualización completa del sistema operativo,
denominada infraestructura móvil virtual (VMI), como la virtualización de
aplicaciones y usuarios, denominada virtualización de aplicaciones móviles.

A nivel general, se separa físicamente la interfaz de usuario de la lógica de la

aplicación. Un dispositivo móvil o wearable ejecuta sólo un componente de visor,
que funciona como una visualización remota para las aplicaciones que se ejecutan
en servidores distantes en la nube (Ver Figura 10). En los servidores se asegura
que los datos y aplicaciones se almacenan en una máquina virtual con los
recursos necesarios para dar la sensación al usuario que se están ejecutando en
el mismo dispositivo móvil, y que puede interactuar con ellas gracias a un
protocolo de comunicación eficiente.

Fig. 10 Configuración de la Arquitectura del Control Remoto

Fuente: Autor

La estructura de visualización remota consta entonces de tres componentes y que

para el objeto de su estudio son tres etapas de análisis: un componente del lado
del servidor que intercepta, codifica y transmite los gráficos de aplicación al
cliente; un protocolo de visualización remota que transfiere las actualizaciones de
la pantalla y los eventos de usuario entre ambos extremos y un componente de
visualización en el cliente. En la Figura 11 se ilustran las fases del método
propuesto.
21
 Fig. 11 Etapas Del Método: Virtualización, Protocolo De Comunicación Y Wearable.

Fuente: AUTOR

En el lado del servidor remoto se interceptan los pixeles de pantalla

(Representación del SO y aplicaciones en la máquina virtual) en el Framebuffer,
que codifica las actualizaciones de pantalla con compresión de diferentes técnicas
y envía las actualizaciones codificadas al cliente.
La codificación de las aplicaciones de gráficos multimedia requiere numerosas
representaciones primitivas porque se deben actualizar grandes partes de la
pantalla a altas tasas de actualización que con frecuencia contienen patrones de
colores finos y complejos. Este tipo de gráficos se codifican de manera más
eficiente utilizando un códec de vídeo, que en visualización remota se conoce
como transmisión interactiva en vivo, ya que los gráficos son principalmente el
resultado de la interacción del usuario con el dispositivo.
Aunque las características de los gráficos de la aplicación determinan
principalmente la elección del formato de codificación, los parámetros de
codificación se adaptan dinámicamente para hacer frente a las fluctuaciones del
ancho de banda inalámbrico y a las capacidades heterogéneas del dispositivo
móvil.

A nivel del cliente, los usuarios pueden acceder de forma remota a sus servicios a
través de una aplicación de visor local y delegar el procesamiento de información
real en el servidor remoto. La aplicación de visor transfiere la entrada del usuario
al servidor y procesa las actualizaciones de visualización recibidas desde el
servidor.

Esta arquitectura cuenta con desafíos técnicos debido en primera instancia a la

disponibilidad de ancho de banda que puede resultar en un cuello de botella. En el
entorno planteado, el protocolo de visualización remota proporciona gráficos
multimedia complejos a través de enlaces inalámbricos y convertir estos gráficos a
un dispositivo móvil con ciertas limitaciones de recursos físicos tecnológicos.

22
6.1 Virtualización

La plataforma Virtual Mobile Infrastructure (VMI) da acceso a dispositivos móviles

virtuales que se ejecutan en la nube. Por lo cual se plantea como una tecnología
que mantiene todos los datos y aplicaciones fuera del dispositivo móvil,
solucionando problemas de seguridad y administración móviles. La plataforma
simplifica enormemente la gestión y el mantenimiento de los dispositivos móviles.
Hacer referencia al funcionamiento de VMI o Infraestructura Virtual Móvil no es
más que hablar de directamente de virtualización y la estructuración, que, aunque
existan diversas aplicaciones, es la misma aplicada en diferentes ámbitos. VMI
permite ejecutar aplicaciones que no se encuentran hospedadas en un dispositivo
móvil sino en una máquina virtual en un servidor remoto. Esta tecnología se usa
como solución al uso de un dispositivo Wearable con funcionalidades de un
teléfono móvil ya que se fundamenta en la virtualización para dispositivos móviles
y así mismo con el propósito de no comprometer la información almacenada en
dicho dispositivo por diferentes factores.
Con el uso de esta tecnología el usuario no requiere de un Wearable con amplias
características técnicas ya que solo se correrá una aplicación sobre este la cual
permitirá el acceso a las aplicaciones e información almacenadas en una máquina
virtual respectiva. El funcionamiento de esta tecnología se integra con el protocolo
de comunicación que es utilizado para que el usuario acceda a los datos
almacenados en el entorno virtual. El marco de funcionamiento de VMI se expresa
de manera detallada a continuación tomando como referencia la Figura 12 que
representa la arquitectura de entornos virtuales que se fundamenta en dos partes
específicas: una virtual y una física.

23
 Fig. 12 Arquitectura De Virtualización

Fuente: Autor

6.2 Hardware

El servidor remoto proporciona los recursos físicos a las máquinas virtuales,

incluyendo recursos RAM y CPU. Estos recursos están divididos entre las
máquinas virtuales hospedadas en este, por lo cual, si una máquina virtual está
ejecutando una aplicación más pesada se deben establecer más recursos para
esta máquina virtual, esta consideración se especifica posteriormente. Los
recursos físicos son abstraídos y asignados a las máquinas virtuales El Hipervisor
se encarga de extraer los recursos de hardware.

6.3 Hipervisor

El Hipervisor es una capa de software que habilita la comunicación entre el

hardware y las máquinas virtuales permitiendo que la virtualización se lleve a cabo
mediante esta capa de abstracción. El Hipervisor es también llamado Monitor de
Máquina Virtual VMM (Virtual Machine Monitor), la diferencia se encuentra en que
un VMM es un software que maneja CPU, memoria, transferencia de datos de
entrada y salida, interrupciones e instrucciones de virtualización, mientras que un
Hipervisor hace referencia al sistema operativo con el monitor de máquina virtual.
En el desarrollo de este documento se considera como un mismo concepto dentro
de la definición de un Hipervisor.

Si no se tuviese un Hipervisor, habría un sistema operativo comunicándose

directamente con el hardware debajo de él. Las operaciones de disco irían
directamente al subsistema de disco y las llamadas de memoria se tomarían
24
directamente de la memoria física. Sin un Hipervisor, más de un sistema operativo
de varias máquinas virtuales querría un control simultáneo lo que daría lugar a un
colapso entre la operación. Con un Hipervisor se gestionan las interacciones entre
cada máquina virtual y el hardware que comparten todos los invitados. En la
siguiente figura se presentan las capas de interacción del Hipervisor con la
máquina virtual y los recursos Hardware.

Fig. 13 Diferenciación Entre Los Dos Tipos De Hipervisores

Fuente: Portnoy, M. (2012). Virtualization essentials.

Las operaciones de las máquinas virtuales son transferidas y, como tal, no pueden
afectar al Hipervisor en el que está soportado. Una máquina virtual sólo puede
dañarse a sí misma, causando un único bloqueo pero ese evento no escapa de los
límites del contenedor de la VM, así, otras máquinas virtuales continúan
procesando, y el Hipervisor tampoco se ve afectado.

6.3.1.1 Tipos de Hipervisores

Dependiendo de su ubicación y gestión de recursos físicos, un Hipervisor puede

dividirse en dos tipos como se presenta en la figura 14.

25
 Fig. 14 Diferenciación Entre Los Dos Tipos De Hipervisores

Fuente: Flexiant, (2017). What does a hypervisor do

6.3.1.1.1 Hipervisor tipo 1

Este Hipervisor no se desarrolla sobre un sistema operativo sino sobre los

recursos hardware. Debido a que no existe una capa intermedia entre el Hipervisor
y el hardware físico, esto también se conoce como una implementación de metal
desnudo (bare-metal). Es decir lo primero que se instala en un servidor como un
sistema operativo será el Hipervisor, así, se comunicará directamente con el
hardware del servidor físico para la gestión de los recursos.

6.3.1.1.2 Hipervisor tipo 2

El Hipervisor tipo 2 se conoce también como un Hipervisor alojado ya que se

instala directamente sobre el sistema operativo existente ya sea Linux o Windows
como cualquier otra aplicación, de tal manera, un Hipervisor de tipo 2 tiene una
mayor compatibilidad con el hardware que el Hipervisor tipo 1 ya que en este caso
es el sistema operativo es el que se encarga de gestionar los drivers. Un beneficio
de este modelo es que puede soportar una amplia gama de hardware, ya que se
hereda del sistema operativo que utiliza. A menudo, los Hipervisores de tipo 2 son
fáciles de instalar e implementar porque gran parte del trabajo de configuración de

26
hardware, como la creación de redes y el almacenamiento, ya ha sido cubierto por
el sistema operativo16.

Para la solución presentada de integración de tecnologías se emplea un Hipervisor

tipo 1 ya que puede comunicarse directamente con los recursos de hardware,
haciéndolo mucho más eficiente que el Hipervisor Tipo 2 debido a que cada vez
que una máquina virtual realiza una lectura de disco, una operación de red o
cualquier otra interacción de hardware, entrega esa solicitud al Hipervisor, igual
que en un entorno de Hipervisor Tipo 1. A diferencia de ese entorno, el Hipervisor
Tipo 2 debe entonces entregar la solicitud al sistema operativo, que maneja las
peticiones de I/O. El sistema operativo devuelve la información al Hipervisor y
luego host, añadiendo dos pasos adicionales, el tiempo y la sobrecarga de
procesamiento a cada transacción17. Este tipo de Hipervisores son menos fiables
porque hay más puntos de error: todo lo que afecta a la disponibilidad del sistema
operativo subyacente también puede afectar al Hipervisor y a los invitados que
soporta. De tal manera, los Hipervisores tipo 1 tienen mejores características de
rendimiento y requieren menor capacidad de procesamiento, lo que significa que
se pueden ejecutar más máquinas virtuales en cada host.
6.3.1.1.3 Características de los Hipervisores y asignación de recursos

Las principales características de los Hipervisores son:

 Proporcionar un entorno idéntico al entorno físico.
 Proporcionar ese entorno con un coste de rendimiento mínimo.
 Mantener el control completo de los recursos del sistema.
Para que muchas máquinas virtuales compartan los recursos físicos de un
servidor o host físico, deben existir dos acontecimientos. Lo primero es que desde
la perspectiva del cliente, tiene que ver y tener acceso a los diversos recursos de
hardware que necesita para funcionar correctamente. El sistema operativo en la
máquina virtual debe ser capaz de utilizar unidades de disco, acceder a la
memoria, realizar llamadas de red, o al menos creer que puede. Aquí es donde
interviene el Hipervisor, engaña a la máquina virtual a creer que realmente puede
ver e interactuar directamente con los dispositivos físicos del host.

16
Flexiant, (2017). Disponible en: https://www.flexiant.com/2014/02/05/what-does-a-hypervisor-do/
17
Portnoy, M. (2012). Virtualization essentials. Retrieved from proquest.com https://ebookcentral.
27
 Fig. 15 Recursos Asignados A Máquinas Virtuales En Relación A Recursos Físicos

Fuente: Portnoy, M. (2012). Virtualization essentials.

A cada máquina virtual se le presenta sólo una fracción de los recursos del host
físico. Un host puede tener 64 GB de memoria física instalada, pero la máquina
virtual puede creer que tiene 4 GB. Una máquina virtual puede estar escribiendo
archivos en una unidad D de 250 GB, pero en realidad está trabajando con una
porción de un sistema de archivos en una red de área de almacenamiento mucho
más grande [17]. Procesamiento y recursos de red funcionan de manera similar:
una VM puede tener dos CPUs virtuales y acceso a una sola tarjeta de interfaz de
red (NIC), pero el host físico tendrá muchos más recursos que estos.
Lo segundo es que el Hipervisor no sólo tiene que abstraer el hardware de cada
uno de los invitados virtuales, también necesita equilibrar esa carga de trabajo.
Cada VM hace constantes demandas en los diversos subsistemas de recursos. El
Hipervisor debe atender todas esas demandas actuando como un intermediario
entre cada VM y los dispositivos físicos, pero también lo hace de una manera que
proporcione recursos oportunos y adecuados a todos.
De esta manera, un Hipervisor se ha convertido en un sistema operativo para el
hardware, pero en lugar de ocuparse de solicitudes de aplicación y programa, el
Hipervisor presta servicios a servidores completos (virtuales). La siguiente figura
muestra cómo se procesa una operación de I/O. Una aplicación en la VM solicita
una lectura de disco y pasa esa solicitud a su sistema operativo. El sistema
operativo de la VM hace una lectura en el disco que ve. Aquí, el Hipervisor entra a
interpretar la solicitud, la traduce a un equivalente físico real y la pasa al
subsistema de almacenamiento. Cuando la respuesta vuelve, el Hipervisor pasa
los datos al sistema operativo de la VM, que lo recibe como si fuera directamente
28
del dispositivo físico.
No sólo el Hipervisor se encarga de todas las solicitudes de I/O de
almacenamiento desde el host, sino también la red de I/O, procesamiento de
memoria y CPU., esto lo hace para todas las VM en el servidor físico en el que se
está ejecutando el Hipervisor. El Hipervisor tiene un proceso de programación de
recursos que asegura que todos los recursos solicitados sean atendidos de una
manera óptima por lo que tienen opciones para dar prioridad a aplicaciones
importantes para que puedan recibir tratamiento preferencial y no sufrir
degradación del rendimiento debido a la contención.
Fig. 16 Procesamiento De Solicitud De Una Aplicación De Vm De Lectura De Disco

Fuente: Portnoy, M. (2012). Virtualization essentials.

6.4 Máquina virtual

A diferencia de un servidor físico, una VM es en realidad nada más que un

conjunto de archivos que describe y comprende el servidor virtual. Los archivos
principales que componen una VM son el archivo de configuración y los archivos
de disco virtual. La abstracción de recursos tiene lugar en el Hipervisor haciendo
que la VM sea independiente del hardware subyacente.

6.4.1.1 CPU en una máquina virtual

Las CPUs son algunos de los recursos utilizados por las máquinas virtuales y que
se abstraen del servidor principal. Una de las principales propiedades de la
virtualización se fundamenta en que no debería existir diferencia en el rendimiento
de los recursos asignados a la máquina virtual y los recursos físicos del servidor.
29
Si algún recurso en ejecución presenta fallos de funcionamiento, entonces, el
rendimiento del servidor virtual se verá afectado de manera completa.

Con herramientas de VM se asignan y regulan los recursos informáticos que cada

VM. Por ejemplo, se pueden asignar múltiples núcleos de CPU a una aplicación
intensiva de CPU en una máquina virtual mientras que otras máquinas virtuales
con aplicaciones en ejecución no críticas, pueden compartir el mismo núcleo de
CPU. Desde el punto de vista del servidor, lo que se ha asignado es la capacidad
de la máquina virtual para programar ciclos de CPU en las CPU disponibles del
servidor.
El servidor no reserva una CPU únicamente para el uso de una VM particular, si
una VM necesita recursos de procesamiento, el Hipervisor toma la solicitud,
programa las operaciones y devuelve los resultados a la VM a través del
controlador de dispositivo apropiado.

6.4.1.2 Recursos de red en una máquina virtual

Cada máquina virtual se puede configurar con una o más tarjetas de interfaz de
red, o NIC, que representan una conexión a una red. Estas tarjetas NIC virtuales
no se conectan con las tarjetas NIC físicas en el sistema host. El Hipervisor
soporta la creación de una red virtual que conecta las NIC virtuales a una red
compuesta de Switch virtuales lo cual se representa en la siguiente figura.

Fig. 17 Asignación De Recurso De Red A Máquinas Virtuales

Fuente: Portnoy, M. (2012). Virtualization essentials.

El flujo de tráfico de la red por medio del entorno virtual, se desarrolla desde la
aplicación en la máquina virtual, esta envía una solicitud de red al sistema
30
operativo que opera y promedio de este es transferida a un controlador NIC virtual.
En este punto, el Hipervisor sigue siendo el gestor entre el trafico entrante y
saliente de la máquina virtual por lo que toma la solicitud del emulador de red y la
envía la red por medio de la tarjeta física NIC que se encuentra en el servidor
principal, una vez llega la respuesta se repite el proceso en sentido contrario [17].
En la siguiente figura se puede apreciar una representación de la solicitud enviada
por este proceso descrito.

Fig. 18 Solicitud De Red Desde La Aplicación De La Máquina Virtual

Fuente: Portnoy, M. (2012). Virtualization essentials.

6.4.1.3 Asignación de IPs a máquina virtual

Teniendo en cuenta una LAN con servidor DHCP, con puerta de enlace por
defecto y DNS, sin restricciones MAC y firewall permita que cualquier dispositivo
de la LAN se conecte a Internet, la asignación de direcciones IP para las máquinas
virtuales se haría como se muestra a continuación en la siguiente figura18.

18
SearchVMware. (2017). Connecting VMware Workstation guest virtual machines to the Internet. Disponible
en: http://searchvmware.techtarget.com/tip/Connecting-VMware-Workstation-guest-virtual-machines-to-the-
Internet
31
 Fig. 19 Asignación De Ips A Máquinas Virtuales

Fuente: SearchVMware. (2017). Connecting VMware Workstation guest virtual machines to the
Internet

El servidor una dirección IP 10.0.0.100 y a su vez cada VM tiene su propia

dirección IP (10.0.0.101, 102 y 103, respectivamente) que son adquiridas del
DHCP. De esta manera, cada VM actúa como su propio nodo IP en la red, así,
cada VM es identificable.

6.5 Storage o Almacenamiento

Para comprender el funcionamiento del Storage en un entorno virtual en la figura

20 se ilustra la ruta que una solicitud de datos hace desde la aplicación de la
máquina virtual al controlador de almacenamiento. La solicitud se dirige al sistema
operativo, que determina el dispositivo de entrada o salida al que debe ir la
solicitud. El almacenamiento conexión directa o DAS es gestionado por un
controlador de almacenamiento, una tarjeta de procesador físico que forma parte
del hardware de un ordenador. Normalmente, una SAN se conecta a través de un
controlador especializado, a veces llamado Fiber-Channel Controller (FCC), o un
Host-Bus Adapter (HBA). Cada una de estas tarjetas de I/O físicas, el controlador
de almacenamiento y los controladores de red, utilizan controladores de
dispositivo que el sistema operativo utiliza para comunicarse con ellos.

32
Las máquinas virtuales en funcionamiento se guardan en el storage mediante
capturas periódicas en una SAN (Storage Area Network). Las VMs con fallas se
recargan rápidamente en el servidor directamente desde el storage, lo que acelera
los tiempos de recuperación tras un fallo del servidor o de la aplicación19.

La virtualización del almacenamiento ayuda al administrador a realizar tareas tales

como copia de seguridad, storage y recuperación de datos más fácilmente, y en
menos tiempo, ocultando la complejidad real de una red de área de
almacenamiento SAN.
Virtual SAN virtualiza los recursos de almacenamiento físico local del servidor y los
convierte en agrupaciones de almacenamiento que se pueden dividir y asignar a
máquinas virtuales.

En el caso de una solicitud de información que reside en un disco local o en el

interior del equipo, esa solicitud se dirige al controlador SCSI. La solicitud de
controlador SCSI, que en un servidor físico va al controlador de almacenamiento
físico, es tomada por el Hipervisor en el entorno virtualizado. La máquina virtual ve
un controlador SCSI presentado por el hardware, pero en realidad es simplemente
una abstracción que el Hipervisor utiliza para enviar y recibir peticiones de I/O de
almacenamiento. El emulador SCSI clasifica la solicitud y la coloca en una cola
con I/O de almacenamiento de todas las máquinas virtuales del host. Las
solicitudes se pasan al controlador del dispositivo de almacenamiento del
Hipervisor, que está conectado al controlador de almacenamiento del host físico.
El controlador de almacenamiento ejecuta la solicitud y recibe los bloques de
datos que satisfacen la solicitud de la aplicación de la máquina virtual. Los bloques
de datos siguen entonces el camino inverso, enviado al VM solicitante correcto por
el Hipervisor. El sistema operativo de la máquina virtual recibe la información del
controlador de almacenamiento virtual y la pasa a la aplicación, cumpliendo la
solicitud.

19
SearchStorage. (2017). What is virtual storage area network (VSAN)? - Definition from WhatIs.com. Disponible en:
http://searchstorage.techtarget.com/definition/virtual-storage-area-network
33
Fig. 20 Ruta De Solicitud De Datos Desde La Aplicación De La Máquina Virtual Al Controlador De
Almacenamiento

Fuente: Portnoy, M. (2012). Virtualization essentials.

Existen nuevas soluciones que permiten que un grupo de discos separados, como
las unidades de disco de servidor interno, se agrupe en un recurso compartido que
puede ser visto y utilizado por múltiples sistemas. Una ilustración sencilla de esto
se muestra en la siguiente figura:
Fig. 21 Grupo De Discos Separados Agrupados En Recurso Utilizado Por Múltiples Sistemas.

Fuente: Portnoy, M. (2012). Virtualization essentials.

34
6.6 Memoria

La memoria, al igual que la unidad central de procesamiento (CPU), es una parte

crucial de la máquina virtual. A diferencia de la CPU, la memoria suele ser el
recurso que se consume más rápido. Los Hipervisores abstraen la memoria
manejando bloques de datos entre la memoria física del servidor y lo que se ha
asignado a las máquinas virtuales. La gestión de recursos de memoria por el
Hipervisor y el administrador es importante para el uso eficaz de los recursos
físicos.

Más que cualquier otro recurso, la memoria es la que tiene el mayor impacto qué
tan bien funcionará el entorno virtual. Al igual que con la virtualización de la CPU,
el Hipervisor abstrae la memoria utilizando la memoria del servidor físico en
nombre de las máquinas virtuales que admite.

Los bloques de memoria se denominan páginas, y por lo general se mueven en

tamaños uniformes; en la arquitectura de hoy en día, un tamaño de página de
memoria típica es de 4 KB. Cuando los bloques de memoria necesitan ser
liberados para poder cargar la información más reciente, los bloques más antiguos
y menos usados se escriben en el disco. El disco actúa como una extensión de la
memoria física y el proceso de copiar las páginas en el disco se llama paginación.
El archivo al que se copian las páginas de memoria normalmente se denomina
archivo de página. Los procesadores tienen memoria física, llamada caché, como
parte de su maquillaje, donde el trabajo se pone en cola antes de entrar en la CPU
[17].
6.7 Asignación de memoria a las máquinas virtuales

La cantidad de memoria que se asigna a la máquina virtual es lo que puede

utilizar. El host físico en el que reside puede tener cientos de gigabytes
disponibles, pero cada máquina virtual individual no tiene conocimiento de los
recursos mayores. La siguiente figura muestra una ilustración simple de este
modelo. Se han asignado 4 GB y 2 GB de memoria a las dos máquinas virtuales,
respectivamente, siendo toda la memoria de la que tienen conocimiento los
sistemas operativos de dichas máquinas virtuales. El host físico realmente tiene 16
GB de memoria física. Con 6 GB de memoria por las dos máquinas virtuales,
todavía hay 10 GB de memoria disponible en el host para su uso, pero eso no es
del todo exacto.

35
 Fig. 22 Asignación De Memoria A Máquina Virtual

Fuente: Portnoy, M. (2012). Virtualization essentials.

El propio Hipervisor necesita reservar parte de la memoria para sus propios

procesos, de la misma manera que un sistema operativo reserva memoria.
Anteriormente, esta sería una parte significativa de la memoria física, más del 20
por ciento en algunos casos, pero Hipervisores más recientes, han reducido
drásticamente ese número. Para cada máquina virtual que se ejecuta en el host,
también se reserva una pequeña porción de memoria, además de la memoria
asignada para el uso de la máquina virtual. Esta memoria adicional se utiliza para
funciones operativas tales como tablas de asignación de memoria, que conectan
las direcciones de memoria de la máquina virtual a las direcciones de memoria
física.

6.8 Protocolo de Comunicación

Utilizando la infraestructura tecnológica de los dispositivos móviles o Wearables,

es posible que los usuarios puedan acceder de forma remota a sus servicios en un
cloud por ejemplo, a través de la instalación de un visor local y delegar el
procesamiento de la información real en un servidor remoto. La aplicación del visor
transfiere la entrada del usuario al servidor y este procesa las actualizaciones de
visualización recibidas desde el servidor. Las soluciones de visualización remota
se pueden clasificar en categorías estructuradas y codificación basada en pixeles.
En un dominio de codificación estructurado, un servidor de visualización remota
intercepta comandos de dibujo elementales desde una tarjeta gráfica, y las traduce
a un formato que es ejecutable en el dispositivo móvil y envía las instrucciones
traducidas al usuario. Las instrucciones son recibidas por el usuario y ejecutadas

36
en el dispositivo móvil para generar la visualización en la pantalla.
Por otro lado, en las soluciones basadas en pixeles, el servidor de visualización
remota intercepta los pixeles en la pantalla desde un Framebuffer, codifica las
actualizaciones de la pantalla con diferentes técnicas de compresión y envía las
actualizaciones de la pantalla al cliente. Los Framebuffer, son dispositivos gráficos
que representan cada uno de los pixeles de una pantalla como ubicaciones en la
memoria de acceso aleatorio RAM, donde todos y cada uno de los pixeles
desplegados en cualquier instante determinado en la pantalla, están almacenados
en una porción de la memoria principal en forma de octetos binarios20.
Debido a la variedad de técnicas de compresión, las prestaciones de las
soluciones de codificación basadas en pixeles existentes difieren entre sí. La
solución dada en [21], se divide la visualización en regiones lentas y de
movimiento alto, que están codificadas respectivamente por medio de tramas VNC
primitivas y tramas MPEG-4 AVC (H.264). Esta solución elimina totalmente el
problema del alto consumo de ancho de banda causado por la codificación VNC.
Tecnología de compresión RFB basado en JPEG es usado en TightVNC y
TurboVNC para reducir el consumo de ancho de banda en la CPU del dispositivo
móvil, donde se utiliza la tecnología JPEG para codificar la diferencia entre los
Frames vecinos en lugar del propio Frame. Si JPEG es aplicado a cada Frame,
todo el proceso puede ser visto como proceso de codificación Motion JPEG (M-
JPEG). De acuerdo con [19], M-JPEG tiene las siguientes ventajas: (i) latencia
mínima en el procesamiento de imágenes y (ii) flexibilidad en el
redimensionamiento. Incluso si unos pocos paquetes de red contienen información
de un cuadro, se han perdido durante la transmisión, M-JPEG puede aún
proporcionar un flujo continuo mientras que la tecnología de compresión JPEG
basada en RFB puede no funcionar correctamente.
Bajo las existentes soluciones de comunicación remota, este documento se
basará en un protocolo de comunicación remota hibrida para sistemas móviles21.
El protocolo RFB (Remote Framebuffer) y el protocolo Motion JPEG (M-JPEG) se
han asignado para manejar las tareas de visualización remota en las regiones de
movimiento lento y regiones de movimiento alto, respectivamente.
Previo a la definición del protocolo de visualización remota hibrida planteada es
indispensable primero conocer de manera detallada las características y
funcionamiento de los protocolos RFB (Remote Framebuffer) y el protocolo Motion

20
http://www.sunhelp.org/faq/FrameBuffer.html#00
21
Biao Song ·Wei Tang · Tien-Dung Nguyen · Mohammad Mehedi Hassan · Eui Nam Huh. “An optimized
hybrid remote display protocol using GPU-assisted M-JPEG encoding and novel high-motion detection
algorithm”. © Springer Science+Business Media New York 2013

37
JPEG (M-JPEG).
6.9 RFB (Remote Framebuffer)

Es un protocolo simple para el acceso remoto a interfaces gráficas de usuario22.

Debido a que funciona en el nivel de Framebuffer es aplicable a cualquier sistema
de ventanas y aplicaciones. El punto final donde se encuentra el usuario se llama
cliente RFB, en contraste, el punto donde se originan los cambios en el
Framebuffer (es decir, el sistema de ventanas y aplicaciones) se conoce como
servidor RFB.
RFB es un protocolo de cliente ligero. El énfasis en el diseño del protocolo RFB
está en hacer que el dispositivo cliente cuente con muy pocos recursos, y desde
esta perspectiva, se pueden ejecutar desde una amplia gama de hardware. El
protocolo cuenta con algunas particularidades. Si un cliente se desconecta de un
servidor determinado y posteriormente se vuelve a conectar al mismo servidor, se
mantiene el estado de la interfaz de usuario, donde el usuario verá exactamente la
misma interfaz gráfica original. En ese efecto, la interfaz con las aplicaciones del
usuario se vuelve completamente móvil. Siempre que exista una conectividad de
red adecuada, el usuario puede acceder a sus propias aplicaciones personales y
el estado de esas aplicaciones se conserva entre accesos desde diferentes
ubicaciones. Esto proporciona al usuario una visión familiar y uniforme de la
infraestructura de computación donde quiera que se encuentren.
6.10 Conexión Inicial

Un servidor RFB es típicamente un proceso de larga duración que mantiene el

estado de un Framebuffer. Los usuarios de RFB normalmente se conectan, se
comunican con el servidor durante un periodo de tiempo para usar y manipular el
Framebuffer, para luego desconectarse. Posteriormente, una sesión de RFB que
se inicialice, continuará donde se detuvo una sesión anterior, con el estado del
Framebuffer intacto. Un cliente RFB se contacta con el servidor a través del puerto
5900 TCP. En sistemas con múltiples servidores RFB, el servidor N típicamente
escucha el puerto 5900+N.
6.11 Protocolo de visualización

El lado de visualización del protocolo está basado en una única unidad primitiva de
gráficos: “poner un rectángulo de datos de pixeles en una posición dada x, y”. Si
bien, puede parecer ineficiente, permite varias codificaciones diferentes para los
datos de pixeles, lo que da un grado de flexibilidad en cómo intercambiar varios
parámetros como el ancho de banda de la red, la velocidad de dibujo en el cliente
y la velocidad de procesamiento en el servidor. Una secuencia de estos

22
https://tools.ietf.org/html/rfc6143
38
rectángulos hace una actualización del Framebuffer. Una actualización representa
un cambio de un estado de Framebuffer válido a otro, por lo que en algunos
aspectos es similar a un cuadro de video.
El protocolo de actualización se basa en la demanda del cliente. Es decir, una
actualización solo se envía desde el servidor al cliente en respuesta a una solicitud
explicita del cliente. Esto da al protocolo una calidad adaptativa. Cuando más lento
sea el cliente y la red, menos será la tasa de actualizaciones, y los estados
transitorios del Framebuffer pueden ser ignorados, dando por resultado menos
tráfico de la red y menos dibujo para el cliente.
Después de la secuencia inicial de Handshake, el protocolo es asíncrono, con
cada lado enviando mensajes según sea necesario. Una actualización sólo se
debe enviar en respuesta a una solicitud del cliente. Cuando varias solicitudes del
cliente están pendientes, una sola actualización del servidor puede satisfacer
todas ellas.
6.12 Protocolo de Entrada

En el lado de entrada del protocolo en el dispositivo del cliente, los eventos son
simplemente enviados al servidor por el cliente cada vez que el usuario presiona
una tecla o cada vez que se mueve el dispositivo apuntador o también desde otros
dispositivos de E/S no estándar. Por ejemplo, un mecanismo de reconocimiento de
escritura a mano basado en la pluma puede generar eventos de teclado.
6.13 Representación de datos de pixeles

La interacción inicial entre el cliente RFB y el servidor implica una negociación del
formato y codificación de los datos de pixeles. El servidor siempre debe ser capaz
de suministrar datos de pixeles de forma deseada por el cliente. El formato de los
pixeles se refiere a la representación de colores individuales por valores de
pixeles. Los formatos de pixeles más comunes son 24-bit o 16-bit, donde los
campos de bits dentro del valor del pixel se traducen directamente a intensidades
de rojo, verde y azul. Los valores del pixel son índices en una tabla de 256
entradas que contiene las intensidades RGB reales.
La codificación se refiere a la forma en que un rectángulo de datos de pixeles se
enviará al cliente. Cada rectángulo de datos de pixeles está prefijado por un
encabezado que da la posición X, Y del rectángulo en la pantalla, el ancho y la
altura del rectángulo y un tipo de codificación que especifica la codificación de
datos de pixeles. Los datos mismo entonces, siguen utilizando la codificación
especificada. Los tipos de codificación definidos son: Raw, CopyRect, RRE, TRLE,
Hextile y ZRLE. En la práctica, los servidores utilizan codificaciones ZRLE, TRLE y
CopyRect, ya que proporcionan la mejor compresión.

39
6.14 Mensajes del protocolo

El protocolo RFB puede operar sobre cualquier transporte fiable, ya sea flujo de
bytes o basado en mensajes. Por lo general, opera a través de una conexión
TCP/IP.
Hay tres etapas en el protocolo. Primero es la fase de Handshake , cuyo propósito
es acordar la versión del protocolo y el tipo de seguridad que se va a usar. La
segunda etapa es la etapa de iniciación donde el cliente y el servidor intercambian
mensajes ClientInit y ServerInit. La tercera etapa es la interacción normal del
protocolo. El cliente puede enviar los mensajes que quiera, y puede recibir
mensajes del servidor como resultado. Todos estos mensajes comienzan con un
byte de tipo de mensaje, seguido de datos específicos de mensaje. Los mensajes
de protocolo utilizan los tipos básicos U8, U16, U32, S8, S16 y S32, estos
representan, respectivamente, enteros sin signo de 8, 16 y 32 bits y enteros con
signo de 8, 16 y 32 bits. El tipo pixel significa un valor de pixeles de bytes
bytePerPixel, donde bytePerPixel es el número de bits por pixel dividido por 8.
Varios formatos de mensaje incluyen bits de relleno o bytes. Para una
compatibilidad máxima, los mensajes deben generarse con el relleno establecido
en cero, pero los destinatarios del mensaje no deben asumir que le relleno tiene
un valor particular.
6.14.1.1 Mensajes Handshake

Cuando un cliente RFB y el servidor se conectan por primera vez, intercambian

una secuencia de mensajes de Handshake que determinan la versión del
protocolo, que tipo de seguridad de conexión usar, una comprobación de
contraseña si el tipo de seguridad lo requiere y alguna información de
inicialización.
6.14.1.2 Mensajes de Iniciación

Una vez que el cliente y el servidor están de acuerdo y tal vez validar un tipo de
seguridad, el protocolo pasa a la etapa de inicialización. El cliente envía un
mensaje ClientInit. A continuación, el servidor envía un mensaje ServerInit.
6.14.1.3 Estructura del formato del pixel de datos

Varios mensajes de servidor a cliente incluyen un PIXEL_FORMAT, una estructura

de 16 bytes que describe la forma en que se transmite un píxel.

40
 TABLA 1 Estructura Del Formato Del Pixel De Datos
+--------------+--------------+-----------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+-----------------+
| 1 | U8 | bits-per-pixel |
| 1 | U8 | depth |
| 1 | U8 | big-endian-flag |
| 1 | U8 | true-color-flag |
| 2 | U16 | red-max |
| 2 | U16 | green-max |
| 2 | U16 | blue-max |
| 1 | U8 | red-shift |
| 1 | U8 | green-shift |
| 1 | U8 | blue-shift |
| 3 | | padding |
+--------------+--------------+-----------------+
Fuente: https://tools.ietf.org/html/rfc6143

Bits-per-pixel es el número de bits utilizados para cada valor de pixel en el cable.

Esto debe ser mayor o igual que la profundidad (depth), que es el número de bits
útiles en el valor de pixel. Big-endian-flag es distinto de cero (verdadero) si los
pixeles de varios bytes se interpretan como big-endian. Si true-color-flag es
distinto de cero (verdadero), los seis últimos elementos especifican cómo extraer
las intensidades de rojo, verde y azul del valor del pixel. Red-shift es el número de
turnos necesarios para obtener el valor rojo en un pixel al bit menos significativo.

6.14.2 Solicitud de Actualización del Framebuffer

Un mensaje FramebufferUpdateRequest notifica al servidor que el cliente está

interesado en el área del Framebuffer especificada por una posición-x, una
posición-y, ancho y altura. El servidor generalmente responde a un
FramebufferUpdateRequest enviando un FramebufferUpdate. El servidor asume
que el cliente guarda una copia de todas las partes del Framebuffer en las que
está interesado. Esto significa que normalmente el servidor sólo necesita enviar
actualizaciones incrementales al cliente.
En el caso de un cliente rápido, el cliente puede regular la velocidad a la que envía
el FramebufferUpdateRequest incrementales para evitar el tráfico de red excesivo.

41
 TABLA 2 Estructura del Mensaje de Actualización Del Framebuffer

+--------------+--------------+--------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+--------------+
| 1 | U8 [3] | message-type |
| 1 | U8 | incremental |
| 2 | U16 | x-position |
| 2 | U16 | y-position |
| 2 | U16 | width |
| 2 | U16 | height |
+--------------+--------------+--------------+
Fuente: https://tools.ietf.org/html/rfc6143

6.14.3 Eventos del Puntero

Un mensaje PointerEvent indica un movimiento del puntero. Cada movimiento en

la pantalla puede ser representado por un vector posición (posición x, posición y).
6.14.4 Actualización del Framebuffer

Una actualización del Framebuffer consiste en una secuencia de rectángulos de

datos de pixeles que el cliente debe poner en su Framebuffer. Se envía una
respuesta a un FramebufferUpdateRequest del cliente.
TABLA 3 Encabezado del Mensaje de Actualización Del Framebuffer -Cliente

+--------------+--------------+----------------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+----------------------+
| 1 | U8 [0] | message-type |
| 1 | | padding |
| 2 | U16 | number-of-rectangles |
+--------------+--------------+----------------------+
Fuente: https://tools.ietf.org/html/rfc6143

Este encabezado es seguido por rectángulos de número de rectángulos de datos

de pixeles. Cada rectángulo comienza con un encabezado de rectángulo:
TABLA 4 Actualización Del Framebuffer –Cliente

+--------------+--------------+---------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+---------------+
| 2 | U16 | x-position |
| 2 | U16 | y-position |
| 2 | U16 | width |
| 2 | U16 | height |
| 4 | S32 | encoding-type |
+--------------+--------------+---------------+
Fuente: https://tools.ietf.org/html/rfc6143

42
6.14.5 Entradas de mapas de color

Cuando el formato de pixeles utiliza un “mapa de color”, este mensaje le dice al

cliente que los valores de pixeles especificados deben ser asignados a los valores
RGB dados. Los valores de mapa de color son siempre de 16bits, con el rango de
valores de 0 a 65535 independientemente del hardware de pantalla en uso. El
mensaje comienza con un encabezado que describe el rango de las entradas del
mapa de color que se van a actualizar

TABLA 5 Entradas De Mapas De Color

+--------------+--------------+------------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+------------------+
| 1 | U8 [1] | message-type |
| 1 | | padding |
| 2 | U16 | first-color |
| 2 | U16 | number-of-colors |
+--------------+--------------+------------------+
Fuente: https://tools.ietf.org/html/rfc6143

El encabezado es seguido por valores RGB de número de colores, cada uno de

los cuales está en el siguiente formato:

TABLA 6 Encabezado Formato De Colores RGB

+--------------+--------------+-------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+-------------+
| 2 | U16 | red |
| 2 | U16 | green |
| 2 | U16 | blue |
+--------------+--------------+-------------+
Fuente: https://tools.ietf.org/html/rfc6143

6.14.6 Codificación

RFB puede ser configurado para trabajar con diversos tipos de codificación, no
obstante, las versiones más usadas y adaptables son las que aplican el tipo de
codificación RLE (Ver Tabla 7).

43
 TABLA 7 Tipos de Codificación

+--------+-----------------------------+
| Number | Name |
+--------+-----------------------------+
| 0 | Raw |
| 1 | CopyRect |
| 2 | RRE |
| 5 | Hextile |
| 15 | TRLE |
| 16 | ZRLE |
| -239 | Cursor pseudo-encoding |
| -223 | DesktopSize pseudo-encoding |
+--------+-----------------------------+
Fuente: https://tools.ietf.org/html/rfc6143

6.14.7 Seguridad

El protocolo RFB no proporciona seguridad más allá de la comprobación de la

contraseña criptográficamente débil que es opcional. En particular no proporciona
ninguna protección contra la observación o alteración del flujo de datos.
Generalmente se ha utilizado en redes física o virtuales seguras. Métodos de
seguridad más allá de los descritos por el protocolo se pueden utilizar para
proteger la integridad de los datos. El cliente y el servidor pueden acordar utilizar
un tipo de seguridad extendida para cifrar la sesión, o la sesión puede ser
transmitida a través de un canal seguro como IPsec o SSH.
6.14.8 Motion JPEG

La técnica Motion JPEG es una extensión de JPEG para manejar imágenes en

movimiento23. Motion JPEG comprime cada Frame en una secuencia de video
usando compresión JPEG. Motion JPEG también incluye técnicas para la
compresión de flujo de datos de audio asociados con el flujo de datos de video.
Motion JPEG es una versión muy simplificada de MPEG. De hecho, si la
compresión MPEG se realizara sin compensación de movimiento sería
cercanamente idéntica a Motion JPEG. Más específicamente, Motion JPEG es
MPEG con la ausencia de codificación inter-Frame, en otras palabras, todos los
Frames son sólo comprimidos con respecto a ellos mismos. A tales Frames se les
conoce como intra-Frames.

23
[Borko Furht, Joshua Greenberg, Raymond Westwater. “Motion Estimation Algorithms for Video
Compression”. Springer Science & Business Media, 6/12/2012 - 164 páginas]
44
Aunque las relaciones de compresión alcanzadas por el movimiento jpeg no son
tan altas como las de MPEG, Motion JPEG tiene muchas ventajas. Una de las
mayores desventajas de MPEG es que la fase de codificación requiere un número
muy grande de búsquedas. Estas búsquedas son muy lentas y hacen que el
proceso de codificación MPEG requiera hasta diez veces más tiempo de
procesamiento que la técnica Motion JPEG. Es imposible considerar MPEG sin
tener en cuenta estas búsquedas. Se utilizan para encontrar los vectores de
movimiento que dan a MPEG su relación de compresión característicamente alta.
Sin embargo, también son estas búsquedas que hacen que MPEG sea mucho
menos factible para la codificación en tiempo real en plataformas de hardware no
especializadas. A pesar de la complejidad adicional de las búsquedas de
compensación de movimiento, Motion JPEG es por mucho una técnica de
compresión en tiempo real más factible.
El acceso aleatorio, el avance rápido, el rebobinado rápido y muchas otras
técnicas de edición de vídeo en tiempo real o más rápido que en tiempo real
tienen requisitos especiales que son compatibles muy bien con Motion JPEG,
como se muestra en la siguiente figura. Dado que todos los Frames en Motion
JPEG son intra-Frames (codificados sólo con respecto a ellos mismos), nunca hay
una necesidad de descompresión de ningún Frame distinto al deseado. Las
funciones de avance rápido y retroceso rápido se pueden ejecutar fácilmente a
cualquier velocidad de tiempo ya que todos los Frames de la secuencia están
codificados intra-Frame. Por lo tanto, para las tareas de edición de vídeo, Motion
JPEG tiene algunas ventajas.

Fig. 23 En M-Jpeg Cada Frame Es Codificado Usando La Técnica Jpeg. Esto Proporciona Acceso
Aleatorio A Todos Los Frames.

Fuente: Borko Furht, Joshua Greenberg, Raymond Westwater. “Motion Estimation Algorithms for
Video Compression”. 2012. Pag. 22

45
MPEG requiere que los cuadros se transmiten y se muestren en un orden
diferente de aquél en el que se comprimieron. Esto se debe al uso de inter-
Frames. Estos Frames predictivos no pueden ser descodificados hasta que los
Frames sobre los que se basan han sido decodificados. Estos Frames usados
para la predicción son a menudo Frames futuros, y por lo tanto el orden de
codificación / decodificación no es el mismo que el orden de reproducción /
transmisión. Esto hace que un requisito de almacenamiento en búfer mantenga
hasta los Frames predichos que se utilizarán en la descompresión del Frame
actual. Motion JPEG no tiene tales requisitos y por lo tanto tiene una
implementación más eficiente en el espacio. De hecho, MPEG requiere
típicamente seis veces más espacio de compresión de buffer que Motion JPEG.
Además, el procesamiento de Motion JPEG es mucho más sencillo ya que el
orden de las tramas es siempre el mismo que el orden de secuencia original de las
tramas. El MPEG no sólo codifica las tramas fuera de servicio, sino que tampoco
tiene un orden estándar de los Frames. Por lo tanto, el número de inter-Frames y
intra-Frames no se conocen hasta el tiempo de ejecución. Por estas razones,
Motion JPEG es más fácil de implementar y mucho menos complejo en términos
de espacio y tiempo.
Teniendo en cuenta todas las ventajas anteriores, Motion JPEG suena como un
competidor muy fuerte contra el MPEG. Sin embargo, en defensa de MPEG, debe
decirse que las relaciones de compresión para MPEG exceden con mucho las de
Motion JPEG. Motion JPEG alcanza proporciones de aproximadamente 10: 1 a 15:
1, igual que para JPEG. MPEG, sin embargo, puede obtener buenos resultados en
relaciones de 30: 1, y también ser útil en proporciones tan altas como 100: 1.

6.15 Hybrid Remote Display Protocol

Unidades de procesamiento grafico (GPU) se utilizan para realizar las tareas de

compresión JPEG en tiempo real. Como M-JPEG cuenta con un enfoque intra-
Frame, el redimensionamiento y el corte de los Frames M-JPEG se pueden hacer
de forma transparente. Siempre que el algoritmo de detección de movimiento
cambie el tamaño o la posición de la región de alto movimiento, la continuidad de
la entrega de la pantalla siempre se conserva. El algoritmo puede detectar varias
regiones de alto movimiento teniendo en cuenta los siguientes factores: (i) el
número de pixeles cambiados, (ii) el entorno de la red, (iii) la utilización de los
recursos en el lado del servidor y (iv) la calidad del video del lado del usuario [21].
El algoritmo de detección de movimiento asigna primero a cada región de
visualización 8*8 un valor QoE que muestra que la compresión M-JPEG supera la
codificación RFB con respecto a esa región. A continuación, los valores QoE se
utilizan para formar una matriz QoE, y el problema de detección de la región de
46
alto movimiento se resuelve utilizando un algoritmo de programación dinámica
para obtener la submatriz con suma máxima.
Uno de los requisitos básicos de la visualización remota es la capacidad de
comprimir eficientemente las imágenes de la pantalla del lado del servidor para
que puedan ser transportadas a través de una red y visualizadas en una pantalla
del usuario. Cualquier códec utilizado para este propósito debe ser capaz de
ofrecer compresión efectiva (para reducir los requisitos de ancho de banda de red)
y operar con baja latencia (para permitir interacciones eficientes con la aplicación
remota). El protocolo de visualización remota hibrida utiliza la combinación del
protocolo RFB y el M-JPEG para enviar la salida gráfica de una aplicación a un
dispositivo móvil o Thin Client (cliente ligero). En la figura XX muestra una vista
esquemática de la arquitectura del protocolo de visualización remota del lado del
servidor, donde las actualizaciones gráficas son enganchadas desde el
Framebuffer de la tarjeta gráfica. El detector de movimiento divide toda la pantalla
en una región de movimiento lento y una región de movimiento alto. Cuando el
resultado de detección de una región de visualización es lenta, el módulo RFB es
utilizado como el protocolo de visualización remota ya que consume menos
recursos en el servidor.

Fig. 24 Arquitectura Protocolo De Visualización Remota Hibrida En El Servidor

Fuente: Biao Song ·Wei Tang. “An optimized hybrid remote display protocol using GPU-assisted M-
JPEG encoding and novel high-motion detection algorithm”. 2013

Para regiones de movimiento alto, el módulo M-JPEG es responsable de la

codificación en tiempo real. Después de empaquetar, el protocolo de transmisión
47
de red se aplica para enviar los datos codificados M-JPEG y RFB.
La Figura 25 se aprecia el diagrama de flujo de la compresión JPEG usando GPU
y CPU. La transformación de espacio de color, transformación de coseno discreta,
cuantificación adaptativa y ordenamiento en "zigzag" se asignan a la GPU, ya que
estas tareas consisten en muchas tareas de computación independientes que
coinciden con la característica de paralelismo de nivel de datos en GPU. Por el
contrario, la codificación de longitud de ejecución y la codificación de Huffman son
asignadas a la CPU para ser procesadas para el primer cuadro o Frame cuando
GPU está procesando sus funciones respectivamente.
La cuantificación adaptativa es un componente especial en el algoritmo de
compresión JPEG. Se han preparado varias tablas de cuantificación para lograr
diferentes relaciones de compresión. Basándose en la capacidad de la red del
usuario o en la preferencia del usuario, la relación de compresión puede variar
dinámicamente, por lo que el protocolo puede garantizar la calidad del video, lo
que significa que el usuario puede recibir imágenes de pantalla fluidas
independientemente de lo inestable de la red.

6.16 Compresión JPEG

Fig. 25 Diagrama De Flujo De La Compresión Jpeg

Fuente: Biao Song ·Wei Tang. “An optimized hybrid remote display protocol using GPU-assisted M-
JPEG encoding and novel high-motion detection algorithm”. 2013

48
6.17 Color Space Transformation

El color es el resultado perceptual de la luz en la región visible del espectro, que

tiene longitudes de onda en la región de 380 nm a 780 nm. La retina humana tiene
tres tipos de células cono Fotorreceptoras de color, que responden a la radiación
incidente con curvas de respuesta espectral algo diferentes. Debido a que hay
exactamente tres tipos de Fotorreceptores de color, tres componentes numéricos
son necesarios y teóricamente suficientes para describir un color24.
Debido a que obtenemos información de color de archivos de imagen que
contienen sólo valores RGB sólo tenemos que conocer para cada espacio de color
el RGB a las fórmulas de transformación de espacio de color.
Tradicionalmente, los espacios de color utilizados en los gráficos por ordenador
han sido diseñados para dispositivos específicos: p. RGB para pantallas CRT y
CMY para impresoras. Por lo general dependen del dispositivo.
El espacio de color RGB es el espacio de color producido en una pantalla CRT
cuando se aplican valores de píxeles a una tarjeta gráfica o mediante un sensor
CCD (o similar). El espacio RGB puede mostrarse como un cubo basado en los
tres ejes correspondientes a rojo, verde y azul.
Fig. 26 Visualización De Los Espacios De Color De Rgb

Fuente: Philippe Colantoni and Al. ”Color Space Transformation” 2004

Ahora bien, toda imagen se debe convertir de RGB en un espacio de color

diferente llamado Y'CBCR (o, informalmente, YCbCr). Tiene tres componentes Y ',

24
Philippe Colantoni and Al. ”Color Space Transformation” 2004
49
CB y CR: el componente Y' representa el brillo de un píxel, y los componentes CB y
CR representan la crominancia (dividida en componentes azul y rojo).
La conversión del espacio de color Y'CBCR permite una mayor compresión sin un
efecto significativo sobre la calidad de la imagen perceptual (o una mayor calidad
de imagen perceptual para la misma compresión). La compresión es más eficiente
porque la información de brillo, que es más importante para la eventual calidad
perceptual de la imagen, se limita a un solo canal. Esto corresponde a una
percepción del color más cercana al sistema visual humano. La transformación del
color también mejora la compresión mediante la correlación estadística.
Una conversión particular a Y'CBCR se especifica en el estándar JFIF, y se debe
realizar para que el archivo JPEG resultante tenga la máxima compatibilidad. Sin
embargo, algunas implementaciones JPEG en el modo de "calidad más alta" no
aplican este paso y en su lugar conservan la información de color en el modelo de
color RGB, donde la imagen se almacena en canales separados para
componentes de brillo rojo, verde y azul. Esto resulta en una compresión menos
eficiente, y probablemente no se utilizaría cuando el tamaño del archivo es
especialmente importante.

6.18 Discrete Cosine Transform

Cada bloque 8×8 de cada componente (Y,CB,CR) se convierte en una

representación en el dominio de la frecuencia, utilizando una transformada coseno
discreta (DCT) de tipo II normalizada, de dos dimensiones25.
A modo de ejemplo, una de estas subimágenes de 8 bits y 8 bits podría ser:

25
N. Ahmed, T Natarajan y KR Rao. “Discrete Cosine Transform”. 1974

50
 Fig. 27 Subimagen 8x8 Mostrada En Escala De Grises De 8bits

Fuente: N. Ahmed, T Natarajan y KR Rao.

Antes de calcular la DCT del bloque 8×8, sus valores se desplazan de un rango
positivo a uno centrado en cero. Para una imagen de 8 bits, cada entrada en el
bloque original se encuentra en el rango [0,255] [0,255]. El punto medio del rango
(en este caso, el valor 128) se resta de cada entrada para producir un rango de
datos que está centrado en cero, de modo que el rango modificado es [-128,127] [-
128,127]. Este paso reduce los requisitos de rango dinámico en la etapa de
procesamiento DCT. Este paso resulta en lo siguiente

Fig. 28 Ejemplo Rango De Datos Centrado A Cero

Fuente: N. Ahmed, T Natarajan y KR Rao.

51
El siguiente paso es tomar la DCT bidimensional, que viene dada por:

∑∑ [ ]

Dónde:

Es la frecuencia espacial horizontal, para los enteros

Es la frecuencia espacial vertical, para los enteros

, si
√

o 1, de otro modo
Es el valor del pixel en la coordenada (x,y)

Es el coeficiente DCT en la coordenada (u,v)

Si se aplica esta ecuación se obtiene lo siguiente:

Fig. 29 Resultado Aplicación Dtc En Imagen

Fuente: N. Ahmed, T Natarajan y KR Rao.

52
 Fig. 30 Transformada Dtc En Un Bloque 8x8

Fuente: N. Ahmed, T Natarajan y KR Rao.

Figura 30 La DCT transforma un bloque 8 × 8 de valores de entrada en una

combinación lineal de estos 64 patrones. Los patrones se denominan las
funciones de base DCT bidimensionales, y los valores de salida se denominan
coeficientes de transformación.
Se observa que la entrada de la esquina superior izquierda con la magnitud
bastante grande. Este es el coeficiente DC (también llamado componente
constante), que define el matiz básico para todo el bloque. Los restantes 63
coeficientes son los coeficientes AC (también llamados los componentes
alternantes). La ventaja de la DCT es su tendencia a agregar la mayor parte de la
señal en una esquina del resultado. La etapa de cuantificación a seguir acentúa
este efecto mientras que simultáneamente reduce el tamaño total de los
coeficientes de DCT, dando como resultado una señal que es fácil de comprimir
eficientemente en la etapa de entropía.
La DCT incrementa temporalmente la profundidad de bits de los datos, puesto que
los coeficientes DCT de una imagen de 8 bits / componentes toman hasta 11 o
más bits (dependiendo de la fidelidad del cálculo DCT) para almacenar. Esto
puede obligar al códec a utilizar temporalmente números de 16 bits para contener
estos coeficientes, duplicando el tamaño de la representación de la imagen en
este punto; Estos valores se reducen típicamente de nuevo a valores de 8 bits por
el paso de cuantificación. El aumento temporal de tamaño en esta etapa no es un
problema de rendimiento para la mayoría de las implementaciones de JPEG, ya
que típicamente sólo una parte muy pequeña de la imagen se almacena en forma
DCT completa en cualquier momento dado durante el proceso de codificación o
decodificación de imagen.

53
6.19 Adaptative quantization

El ojo humano es bueno al ver pequeñas diferencias de brillo en un área

relativamente grande, pero no tan bueno para distinguir la fuerza exacta de una
variación de brillo de alta frecuencia26. Esto permite reducir enormemente la
cantidad de información en los componentes de alta frecuencia. Esto se hace
simplemente dividiendo cada componente en el dominio de frecuencia por una
constante para ese componente, y luego redondeando al entero más cercano.
Esta operación de redondeo es la única operación con pérdidas en todo el proceso
(excepto el submuestreo cromático) si el cálculo DCT se realiza con una precisión
suficientemente alta. Como resultado de esto, es típicamente el caso de que
muchos de los componentes de mayor frecuencia son redondeados a cero, y
muchos del resto se convierten en pequeños números positivos o negativos, que
requieren muchos menos bits para representar.
6.20 “Zigzag” Ordering

Un zigzag es un patrón compuesto de pequeñas esquinas en ángulos variables,

aunque constante dentro del zigzag, trazando un camino entre dos líneas
paralelas; Se puede describir tanto como irregular y bastante regular27.
Desde el punto de vista de la simetría, puede generarse un zigzag regular a partir
de un motivo simple como un segmento de línea mediante la aplicación repetida
de una reflexión de deslizamiento.

26
Phuc-Tue Le Dinh and Jacques Patry. Video compression artifacts and MPEG noise reduction.
Video Imaging DesignLine. February 24, 2006. Retrieved May 28, 2009.
27
Ken Cabeen and Peter Gent. “Image Compression and Discrete Cosine Tranform”. College of the
Redwoods.

54
 Fig. 31 Ordenamiento Zigzag De Los Componentes De Una Imagen Jpeg

Fuente: Ken Cabeen and Peter Gent. “Image Compression and Discrete Cosine Tranform”. College
of the Redwoods

6.21 Run-Lengh Encoding

La idea detrás de este enfoque de la compresión de datos es la siguiente: Si un

elemento de datos se produce veces consecutivas en el flujo de entrada,
reemplace las ocurrencias con el único par . Las ocurrencias consecutivas
del elemento de datos se denominan longitud de ejecución de , y este
acercamiento a la compresión de datos se llama codificación de longitud de
ejecución o RLE28.
RLE es un candidato natural para comprimir datos gráficos. Una imagen digital
consiste en pequeños puntos llamados píxeles. Cada píxel puede ser un bit,
indicando un punto negro o blanco, o varios bits, indicando uno de varios colores o
tonos de gris. Entendemos que los píxeles se almacenan en una matriz llamada
un mapa de bits en la memoria, por lo que el mapa de bits es el flujo de entrada
para la imagen. Los píxeles se disponen normalmente en el mapa de bits en las
líneas de exploración, por lo que el primer píxel de mapa de bits es el punto en la
esquina superior izquierda de la imagen y el último píxel es el de la esquina
inferior derecha.
La compresión de una imagen usando RLE, se basa en la observación de que, si
seleccionamos un pixel en la imagen al azar, existe una buena probabilidad de

28
David Salomon. “Data Compression”. Springer Science & Business Media, 20/03/2007 - 1092 páginas
55
que sus vecinos tendrán el mismo color. Por lo tanto, el compresor explora el
mapa de bits fila por fila, buscando ejecuciones de píxeles del mismo color. Si
comienza el mapa de bits, con 17 píxeles blancos, seguido por 1 píxel negro,
seguido de 55 blancos, etc., sólo se necesitan escribir los números 17, 1,55... En
el flujo de salida.
El tamaño del flujo comprimido depende de la complejidad de la imagen. Cuanto
más detalle, peor es la compresión.
Fig. 32 Áreas Uniformes Y Líneas De Barrido

Fuente: David Salomon. “Data Compression”. Springer Science & Business Media, 20/03/2007 -
1092 páginas

La figura anterior muestra que las líneas de exploración atraviesan una región
uniforme. Una línea entra a través de un punto en el perímetro de la región y sale
por otro punto, y estos puntos no son "utilizados" por ninguna otra línea de
exploración. Ahora está claro que el número de líneas de exploración que
atraviesan una región uniforme es aproximadamente igual a la mitad de la longitud
(medida en píxeles) de su perímetro. Puesto que la región es uniforme, cada línea
de barrido aporta dos carreras al flujo de salida para cada región que cruza. Por lo
tanto, la relación de compresión de una región uniforme es aproximadamente igual
a la relación

6.22 Huffman Coding

Los códigos de Huffman son códigos óptimos que asignan un símbolo a una
palabra de código. Se supone que cada intensidad de píxel tiene asociada una
cierta probabilidad de ocurrencia, y esta probabilidad es espacialmente invariante.
La codificación de Huffman asigna un código binario a cada valor de intensidad,
56
con códigos más cortos que van a intensidades con mayor probabilidad. Si las
probabilidades se pueden estimar apriori entonces la tabla de códigos de Huffman
se puede fijar tanto en el codificador como en el decodificador. De lo contrario, la
tabla de codificación debe enviarse al decodificador junto con los datos de imagen
comprimidos29 . Los parámetros implicados en la codificación de Huffman son los
siguientes:
- Entropía
- Longitud promedio
- Eficiencia
- Diferencia
La codificación Huffman usa un método específico para elegir la representación de
cada símbolo, que da lugar a un código prefijo (es decir, la cadena de bits que
representa a un símbolo en particular nunca es prefijo de la cadena de bits de un
símbolo distinto) que representa los caracteres más comunes usando las cadenas
de bits más cortas, y viceversa.
TABLA 8 Representación Símbolos Codificación Huffman

Fuente: D.A. Huffman, "A method for the construction of minimum-redundancy codes", Proceedings of the

29
S. Jayaraman, S Esakkirajan, T Veerakumar. “Digital Image Processing”. Tata McGraw-Hill Education, 2011
- 723 páginas (S. Jayaraman, 2011)
57
 I.R.E., sept 1952, pp 1098-1102

Para un grupo de símbolos con una distribución de probabilidad uniforme y un

número de miembros que es potencia de dos, la codificación Huffman es
equivalente a una codificación en bloque binaria, por ejemplo, la codificación
ASCII.
6.23 Método de detección de movimiento

Ya que se aplica la codificación RFB y la codificación JPEG a la región de

movimiento lento y región de movimiento alto respectivamente, la decisión de
detección debe hacerse teniendo en cuenta dos factores: el recurso del servidor y
el ancho de banda de la red, consumidos por cada método de codificación [21].
Es importante considerar los recursos del servidor y las condiciones de la red ya
que pueden ser limitaciones potenciales. Con el fin de proporcionar una solución
en tiempo real, se adopta un algoritmo de programación dinámica para reducir la
complejidad computacional.
El primer paso para la detección de movimiento es dividir el área completa de la
pantalla en pequeños rectángulos 8bits*8bits. Para cada región de pantalla 8*8, se
debe calcular un valor QoE, mostrando cuándo supera la codificación JPEG a la
codificación RFB. La ventaja de la codificación RFB es que es una tecnología
ligera en términos de consumo de recursos del servidor. Por otro lado, la
codificación JPEG consume una cantidad considerable de recursos de CPU y
GPU al comprimir la actualización de la pantalla. La codificación RFB es una
solución que aprovecha mejor el consumo de recursos en el servidor, además que
la complejidad de la decodificación en el lado del usuario presenta características
similares respecto a que consume un poco menos recursos de la CPU que la
decodificación JPEG. Para la simplicidad de los cálculos, todos los parámetros
relativos al consumo y al estado se definen de forma porcentual. Consideremos
Cada región de la pantalla 8*8, sea la matriz de consumo de
recursos de la CPU sobre la codificación RFB donde se define como la
sobrecarga de la CPU para el manejo de la región 8*8 siempre que se use la
codificación RFB. es la matriz de consumo de recursos de la
CPU sobre la codificación JPEG donde se define como la sobrecarga de
la CPU para el manejo de la región 8*8 siempre que se use la codificación
JPEG. es la matriz de consumo de GPU sobre la codificación
JPEG donde se define como la sobrecarga de la GPU para el manejo de
la región 8*8 siempre que se use la codificación JPEG.

58
 Fig. 33 Enfoque De La Propuesta De Detección De Movimiento

Fuente: Biao Song ·Wei Tang · “An optimized hybrid remote display protocol using GPU-assisted
M-JPEG encoding and novel high-motion detection algorithm”. 2013

Como la complejidad de la codificación es la misma entre todas las regiones 8*8,

simplemente se puede utilizar
∑ ∑ ∑
, y

para obtener el consumo de la CPU y la GPU en cada región la codificación RFB y

JPEG respectivamente. Ya que la sobrecarga CPU / GPU para cualquier región
8*8 con un cierto número de pixeles cambiados ha sido pre-estimada a través de
59
benchmarking, la parte del cálculo de QoE solo trae una sobrecarga de CPU
insignificante al servidor, durante el tiempo de ejecución.
Otro factor QoE en este sistema es el consumo de ancho de banda. Si se
considera describe el tamaño de los datos JPEG codificados en la región
8*8, y el tamaño del resultado RFB codificado en la región 8*8 y
basado en la preferencia del usuario respecto a la calidad JPEG, se puede
fácilmente obtener el tamaño de archivo de la pantalla completa de la imagen
JPEG representada como ∑ . El tamaño del resultado RFB depende del
número de píxeles cambiados entre Frames vecinos. Dado el número de píxeles
cambiados, también se puede obtener el consumo esperado de ancho de banda
∑ en un modo de pantalla completa a través de benchmarking. Entonces
∑ ∑
se usa y para obtener el consumo de ancho
de banda para la codificación en la región con RFB y JPEG, respectivamente.
Luego se define el factor de consumo del ancho de banda :

( )

Donde es el factor del ancho de banda de la red

∑

El paso final es calcular en el factor , , usando dos factores y un parámetro

de peso sintonizable .

En esta fórmula, la afinación de puede hacerse con diferentes consideraciones.

Por ejemplo, un valor mayor asignado a denota que el consumo de ancho de
banda se enfatiza más y dará como resultado una región de movimiento alto más
grande y una región de cámara lenta más pequeña.
Después de generar el valor de diferencia QoE para cada región 8 * 8, obtenemos
una matriz { }. Para cualquier un valor positivo significa que la
aplicación de la codificación JPEG a la región correspondiente es más beneficiosa.

6.24 Implementación

En toda la solución, se usan cuatro subprocesos para mejorar la velocidad de

procesamiento. Los procesos han sido diseñados de una manera casi

60
independiente para que se logre el paralelismo. Utilizan un búfer global para
comunicarse entre sí, y trabajan de forma asíncrona. Una vez que se generan los
nuevos datos, los datos antiguos del búfer global se descartan para garantizar que
sólo el último Frame se codifique y se transmite al cliente. Este modelo soporta la
ejecución paralela en copias de memoria, GPU, CPU y E/S de red. Se combina el
módulo de captura de pantalla y el módulo de detección de movimiento en un
subproceso ya que cada uno de ellos consume sólo una pequeña cantidad de
recursos informáticos.
Como la GPU y la CPU pueden funcionar al mismo tiempo, se divide el módulo de
codificación en dos subprocesos.
Fig. 34 Modelo De La Implementación Por Subprocesos.

Fuente: Biao Song ·Wei Tang · “An optimized hybrid remote display protocol using GPU-assisted M-JPEG
encoding and novel high-motion detection algorithm”. 2013

6.25 Evaluación de la solución

Para validar el funcionamiento del presente protocolo, el autor evalúa el tamaño de

la transmisión de datos desde el servidor al cliente (dispositivo móvil), donde se
analiza el consumo de la red de ancho de banda, el consumo de la CPU en el lado
del cliente y la calidad del video. Para ello, se realiza una comparación con
diversos protocolos para que se contraste la funcionalidad de diferentes
tecnologías. Con el uso de un dispositivo móvil ligero con la aplicación
PocketCloud como cliente RDP y cliente RemoteFX y junto a la aplicación
61
androidVNC como cliente Tight/UltraVNC y monitor de CPU para medir el uso de
la CPU en el dispositivo con un sistema operativo Android.
En la siguiente figura se muestran los resultados del consumo del ancho de banda
en la red en tres escenarios distintos. En un escenario de movimiento lento, RDP y
RemoteFX funcionan mejor que los demás, sin embargo, el consumo de la red de
RDP, RemoteFX, y UltraVNC aumentar drásticamente cuando los datos se
convierten en alto movimiento.

Fig. 35 Consumo De Ancho De Banda De Diferentes Protocolos

Fuente: Biao Song ·Wei Tang · “An optimized hybrid remote display protocol using GPU-assisted M-JPEG
encoding and novel high-motion detection algorithm”. 2013

Para el método propuesto (Hybrid) supera el consumo de ancho de banda en el

modo de movimiento alto. Consume menos ancho de banda que otros, incluso si
el tamaño de la ventana se ajusta. En comparación, en modo de alto movimiento,
el consumo de ancho de banda de Hybrid se incrementa trivialmente mientras que
otros requieren una enorme cantidad de ancho de banda para la transmisión de la
información.
La Figura XG muestra la calidad de los resultados de vídeo en tres escenarios
diferentes. Entre estos protocolos, TightVNC ofrece la peor calidad de vídeo,
especialmente en el escenario de alto movimiento.
RDP, RemoteFX y UltraVNC no funcionan bien cuando el entorno de prueba es de
alto movimiento y gran tamaño de ventana. El protocolo propuesto tiene un
rendimiento consistente y excelente para todos los casos, por lo que supera a las
62
soluciones existentes al ahorrar una gran cantidad de ancho de banda mientras se
preserva la calidad del video

Fig. 36 Calidad Del Video De Diferentes Protocolos

Fuente: Biao Song ·Wei Tang · “An optimized hybrid remote display protocol using GPU-assisted M-JPEG
encoding and novel high-motion detection algorithm”. 2013

La siguiente figura muestra el consumo de CPU en el cliente, en los tres diferentes

escenarios. El protocolo propuesto consume menos uso de la CPU que los
métodos restantes en el modo de cámara lenta debido a la comparación de la
diferencia entre dos tramas sucesivas.

63
 Fig. 37 Consumo De Cpu Del Dispositivo Cliente De Diferentes Protocolos

Fuente: Biao Song ·Wei Tang · “An optimized hybrid remote display protocol using GPU-assisted M-JPEG
encoding and novel high-motion detection algorithm”. 2013

En el modo de ventana grande de movimiento alto, el Ultra VNC consume una

pequeña cantidad de uso de la CPU porque se reduce el número de tramas
transmitidas por segundo. Sin embargo, en comparación con RDP, RemoteFX y
UltraVNC, el protocolo Hibrido propuesto consume una cantidad similar de
capacidad de CPU en el lado del cliente móvil.

6.26 Dispositivo Terminal

Al ejecutar independientemente aplicaciones en una plataforma a distancia, la

interfaz de usuario sería de este modo, una imitación virtual de las aplicaciones
que se ejecutan en el servidor y se visualiza en el dispositivo como una imagen
interactiva. Todas las aplicaciones móviles virtuales se transferirán en forma de
una sola aplicación ligera en el dispositivo final del usuario donde se visualiza a
través de una interfaz de alta resolución.
Para llegar a esto, se necesita que el dispositivo cuente con unos requerimientos
técnicos mínimos (Ver Figura 38) que permita una óptima ejecución de los
procesos entre la nube y el Wearable. Un requisito crítico para cualquier diseño
utilizable es el empleo de un procesador "always on" para manejar la
monitorización continua de sensores y dispositivos de posicionamiento global. El
procesador tiene que gestionar algoritmos complejos mediante el filtrado y la
interpretación de datos de todos los sensores y módulos de comunicación para
proporcionar una mejor información para el usuario. Se necesita un núcleo
64
procesador de 32 bits para mantener todo el procesamiento en el dispositivo,
reduciendo así la cantidad de datos transmitidos y manteniendo el consumo de
energía al mínimo.
Fig. 38 Arquitectura De Funcionamiento De Dispositivo Wearable

Fuente: Likhyani, S. “ARM Processors is The Power Behind Wearable Electronics”. 2017

En términos de funcionalidad, un dispositivo básico, debe contar con un sistema

operativo simple junto con una pantalla a color, un sistema de audio, módulos
Bluetooth y Wi-Fi, además de añadir un sistema de gráficos, posicionamiento
global, conectividad celular y cámara, potencialmente con capacidad de vídeo HD.
En términos de arquitectura, trae la necesidad del procesador más una DRAM,
una GPU y, potencialmente, una unidad de procesamiento de pantallas (DPU) y/o
una unidad de procesamiento de video (VPU).
Simoens30 señala algunas dificultades principales que enfrentan este tipo de
desarrollos son la duración de la batería del dispositivo y la latencia de interacción.
Para superar el obstáculo en la prolongación de la duración de la batería, para
poder soportar la comunicación con los servicios en la nube, cada vez que el
servidor recibe un mensaje de petición de actualización del buffer desde el cliente,
éste comprueba el nivel de batería del dispositivo en el mensaje, y si el nivel de
batería es bajo, entonces el servidor cambia el esquema de codificación basado
en el comportamiento de consumo de energía y compresión.

30
P. Simoens, F. Turck, B. Dhoedt, and P. Demeester, “Remote display solutions for mobile cloud
computing,” Computer, vol. 44, no. 8, pp. 46- 53, Aug. 2011.
65
 Fig. 39 Formato Del Mensaje Rfb

Fuente: Autor

Para desarrollar estrategias para optimizar el balance energético, se estudia el

consumo de energía WNIC, que es el producto del número de bytes
intercambiados a través de la interfaz inalámbrica y el coste energético por byte. El
coste medio de energía por byte se determina por la distribución del tiempo en los
cuatro posibles estados WNIC: envío, recepción, inactividad y sueño. Debido a
que un conjunto específico de componentes WNIC se activan en cada estado, el
consumo de energía varía ampliamente entre los estados.

Aunque los modos de envío y recepción consumen la mayor cantidad de energía,

los enfoques de ahorro de energía deben centrarse en los grandes tiempos de
inactividad. Estos tiempos de inactividad son una consecuencia de la frecuencia
limitada de las interacciones del usuario impuestas por el tiempo de ida y vuelta de
la red. Después de alguna interacción, los usuarios deben esperar hasta que los
resultados se vuelvan visibles en la pantalla antes de continuar su trabajo.

Se esperan grandes ahorros de energía cuando el WNIC (Tarjeta Inalámbrica)

pasa al modo de ahorro de energía durante estos intervalos de inactividad. El
modo de reposo consume de tres a cinco veces menos energía que el modo
inactivo porque la interfaz de radio está apagada. Por supuesto, esto implica que
el WNIC se perderá cualquier información entrante cuando está en modo de
reposo. En cuanto a parámetros físicos, un dispositivo Wearable que se adapte a
los requerimientos de la propuesta planteada debe integrar características de
funcionamiento que permitan una interacción adecuada y cómoda para el usuario.
Debe contar con una interfaz de visualización para que el usuario controle las
diferentes aplicaciones hospedadas en la nube, de modo que una pantalla es
indispensable para que esto se pueda satisfacer. Partiendo de esta premisa y
considerando los diferentes dispositivos Wearable del mercado, se establece que
los tipo pulsera son los únicos que cuentan actualmente con pantalla de
interacción, además, la mayoría de las personas están más familiarizadas con
este dispositivo dada su facilidad para acceder a las aplicaciones que con
frecuencia suelen usar, especialmente cuando se encuentran desplazándose, lo
cual trae multitud de posibilidades a la hora de gestionar información y de usar los
servicios que puede ofrecer esta tecnología.

Así mismo, los dispositivos de pulsera son los primer Wearable en tener
compatibilidad con la e-sim31 que es una apuesta llamativa tomando en cuenta

31
https://www.unocero.com/especiales/resumenes-anuales/resumen-2016/los-mejores-wearables-de-
66
que este es el futuro de la telefonía móvil. Esta tecnología permite adicionalmente
proveer credenciales de un operador seleccionado a la SIM y su activación o
desactivación de manera remota para facilitar la movilidad y seguridad, igualmente
permite de manera sencilla y rápida cambiar de operador.

Fig. 40 Solución Wearable

Fuente: AUTOR

Un modelo de Wearable con las características y funcionalidades básicas es

presentado en la siguiente Figura 40 que está diseñado para buscar la comodidad
del usuario y ser un producto innovador en el ámbito de estas tecnologías, que
establece una pantalla removible de modo que aumente el nivel de manipulación y
pueda adaptarse a las necesidades de los usuarios. Cuenta adicionalmente con
un diseño llamativo, versátil y cómodo. Incorpora sensores multipropósito, cámara
y controles para su configuración.

6.27 Futuro de los Wearable

Gartner afirma que el mercado de los Wearables en general se encuentra en

aumento. Según estudios realizados en el año 2017, afirma un incremento en
ventas de smartwatch de más del doble del valor dado en el 2015. Se pronostica
también que otros Wearable tales como los lentes de realidad virtual tengan un
aumento significativo.

2016
67
 Fig. 41 Análisis Actual Y Proyección Para El 2017 Sobre Ventas De Dispositivos Wearable

Fuente: Felix R., (2016). Statista.com

6.28 DATOS DE ENTRADA AL S.O. REMOTO

El dispositivo Wearable ejecuta el sistema operativo Android. En general el

sistema operativo Android es también conocido como un sistema operativo móvil
de pantalla táctil para dispositivos que no integran un teclado sino que en su lugar,
cuentan con una pantalla táctil. En consecuencia, el sistema operativo Android,
tiene disposiciones para un editor de método entrada o IME (Input Method Editor)
que básicamente es un componente propio del sistema operativo que permite
ingresar caracteres o símbolos que no se encuentran en el Wearable. Android
presenta un marco de IME extensible ya que permite a las aplicaciones
proporcionar a los usuarios métodos de entrada alternativos que pueden ser
teclados de pantalla e incluso entradas de voz. En este sistema operativo solo se
podrá correr un IME a la vez, por lo cual para esta solución se tomará como
referencia la utilización del teclado táctil común. El usuario envía entradas de texto
hacia un sistema operativo remoto usando un IME local del sistema operativo
almacenado en el dispositivo Wearable. Las entradas de texto son recibidas por
un IME local de una aplicación cliente, el cual proporciona las entradas de texto a
un IME virtual que se ejecuta en el sistema operativo Android remoto. El IME
virtual proporciona las entradas de usuario a la aplicación remota correspondiente
que se ejecuta en el sistema operativo Android remoto32.

32 Virtual mobile infrastructure for mobile devices Patent (September 13, 2016) Disponible en:
68
 Fig. 42 Dispositivo Wearable

Fuente: AUTOR

La representación en el lado del cliente minimiza el consumo de ancho de banda

de la red al no tener que transmitir la imagen final de la pantalla.

http://patents.justia.com/patent/9444912

69
 7 CONCLUSIONES

La alta dependencia del uso de dispositivos móviles y la amplia exigencia de los

usuarios en buscar mejores experiencias en el uso de este tipo de tecnologías ha
llevado a que se propongan nuevas alternativas innovadoras que proporcionen
gran comodidad y faciliten el acceso a aplicaciones y recursos que con frecuencia
suelen usar, con la posibilidad de adaptarse a conveniencia de cada usuario. Es
por ello que se identifica que los wearables pueden convertirse en una opción que
sustituya los equipos móviles ya que permite fácilmente aplicar diferentes
tecnologías para asemejarse a las funcionalidades de los teléfonos inteligentes lo
que se convierte en una opción practica y viable para aplicar este tipo de
soluciones.
Para hacer aterrizable esta solución, es indispensable considerar la reducción de
requerimientos físicos y recursos computacionales ajustables a la arquitectura y
características propias de los Wearables, que suelen ser ligeros y simples entorno
a su hardware. En respuesta a ello, es necesario implementar una arquitectura
que aproveche las tecnologías Cloud y de virtualización, pues proporcionan un
entorno rico en recursos físicos, disponibles para los usuarios móviles, permitiendo
ampliarlos de manera lógica sin comprometer los del wearable y así aliviar la
ejecución de aquellas aplicaciones robustas que consumen amplios recursos
hardware.
Este tipo de tecnologías nos introducen en el campo de la visualización remota
pues presenta características que vinculan mecanismos de innovación que
responden a las necesidades de los usuarios y que involucran la reproducción
completa de elementos de hardware, software y otros servicios en ambientes
externos al de la interfaz de interacción del usuario. La evaluación de tecnologías
en ambientes cloud constituye una opción de un mejor desempeño de las
aplicaciones ya que no cuenta con limitantes en memoria o procesamiento. Al
expandirnos a campos como el de la virtualización, se amplía el espectro de
opciones para el uso de nuevas tecnologías, se separa los sistemas operativos y
las aplicaciones de la infraestructura física del Wearable y se hospedan en otro
dispositivo al cual se accede remotamente sin que el usuario lo diferencie. La
denominada infraestructura móvil virtual o VMI es una solución de virtualización
para dispositivos móviles donde todas las aplicaciones se ejecutan en un servidor
en un centro de datos seguro, lo que proporciona un ambiente de gran fiabilidad y
seguridad para la información personal de los usuarios, así mismo proporciona
gran flexibilidad en la ejecución de los programas y gestión de los recursos. Con el
uso de esta tecnología se tiene la posibilidad de remover la gran dependencia del
hardware que es una de las razones por las cuales se consideró evaluar esta
opción para el método propuesto de integración tecnológica. No obstante, emular
el dispositivo móvil sobre otra plataforma genera una serie de desventajas

70
principalmente en términos de conectividad entre los dos extremos. Limitaciones
de ancho de banda móvil y adicional en los recursos de memoria y procesamiento
del dispositivo Wearable llevó a analizar diferentes tecnologías de comunicación
donde se selecciona dentro del marco de estudio un protocolo de visualización
remota híbrida HRDP para el sistema de comunicación. Este protocolo es una
solución que optimiza de manera estructural la transmisión en doble vía de datos
entre un servidor y el dispositivo cliente. Utiliza el protocolo RFB para manejar las
tareas de visualización remota de movimiento lento y M-JPEG para las tareas de
visualización en movimiento alto. Utiliza unidades de procesamiento gráfico (GPU)
para realizar una parte de las funciones de compresión JPEG, y paralelamente
adapta un algoritmo de detección de movimiento transparente para reducir el
consumo de ancho de banda de la red y el consumo de recursos informáticos en
el servidor y en el dispositivo cliente.
Esta opción de comunicación representa una aproximación respecto al enfoque
actual del uso de los dispositivos móviles y Wearables desde el punto de vista de
la ejecución de aplicaciones. Generar hardware de gama alta es costoso, requiere
mucha energía y requiere mucho esfuerzo en desarrollar tecnologías inminentes.
Los teléfonos inteligentes no son un almacenamiento de datos intrínsecamente
seguro. La seguridad de los datos y la privacidad son vulnerables debido al riesgo
de mal funcionamiento, robo y pérdida del dispositivo etc. Sin embargo, desarrollar
soluciones basadas en cloud computing que se extienden al dominio móvil
cumplen con el objetivo de reducir la necesidad de hardware de gama alta,
minimiza el costo de propiedad y mantenimiento de forma amortizada y mejorar la
seguridad y privacidad de los datos.
Todas estas tecnologías han permitido adaptar y converger de manera eficiente
todo un método de visualización soluciones virtualizadas con dispositivos
Wearables.

71
 8 BIBLIOGRAFIA

[1] WhatsApp.com. (2017). WhatsApp support for mobile devices. Disponible:

https://blog.whatsapp.com/10000617/Compatibilidad-de-WhatsApp-con-
tel%C3%A9fonos-m%C3%B3viles
[2] CIFRAS SOBRE ROBOS EN COLOMBIA 2016, Disponible en:
http://www.eltiempo.com/colombia/otras-ciudades/cifras-sobre-robos-en-colombia-
en-2016-33762 (EL TIEMPO, 2016)
[3] Wolf, C., Halter, E.: Virtualization from the Desktop to the Enterprise. Apress
(2005)
[4] Sunwook K., Jihyeok C., Seongwoon Kim, and Hagyoung Kim (2016). Cloud-
based Virtual Desktop Service Using Lightweight Network Display Protocol.
International Conference on information Networking (ICOIN) 2016
[5] Hyun-suk Roh., Hyun-woo Lee., y Sang-ho Lee., 2014, A study on mobile
virtualization
[6] Mohd F., Ros H., Muhammad A. Virtual Desktop Environment on Cloud
Computing Platform. Control and System Graduate Research Colloquium
(ICSGRC), 2014 IEEE 5th
[7] Hypori Virtual Mobile Infrastructure Optimizes Android Devices on Intel-Based
Clouds. Article “Android Cloud Environment Now Available for Android Systems
Running on Intel-based Servers , 2105
[8] Husain, Amir. "How to build an Application Virtualization Framework".
VDIworks. 2008
[9] Boyun Eom and Hyunwoo Lee. “Power-Aware Remote Display Protocol for
Mobile Cloud”. 2013
[10] Hyunwoo Lee, and Won Ryu, Boyun Eom, Choonhwa Lee. “An Adaptive
Remote Display Scheme to Deliver Mobile Cloud Services” Member, IEEE, Vol.
60, No. 3, August 2014
[11] Wei Tang, Biao Song, Myeong Seob Kim, Nguyen Tien Dung, Eui Nam Huh.
“Hybrid Remote Display Protocol for Mobile Thin Client Computing”. ©2012
[12] L. Deboosere, J. D. Wachter, P. Simoens, F. D. Turck, B. Dhoedt, and P.
Demeester, “Thin client computing solutions in low- and highmotion scenarios,” in
ICNS ’07: Proceedings of the Third International Conference on Networking and
Services. Washington, DC, USA: IEEE Computer Society, 2007, p. 38.

72
[13] “ISO/IEC 13818-2:2000 Information Technology - generic coding of moving
pictures and associated audio information - part 2: Video.”
[14] “ITU-T: h.264, Advanced video coding for generic audiovisual services,” 2005.

[15] Pieter Simoens, Paul Praet, Bert Vankeirsbilck, Jeroen De Wachter, Lien
Deboosere, Filip De Turck, Bart Dhoedt, Piet Demeester. “Design and
implementation of a hybrid remote display protocol to optimize multimedia
experience on thin client devices”. IBBT - Department of Information Technology,
Ghent University
[16] Flexiant, (2017). Disponible en: https://www.flexiant.com/2014/02/05/what-
does-a-hypervisor-do/
[17] Portnoy, M. (2012). Virtualization essentials. Retrieved from proquest.com
https://ebookcentral.
[18] SearchVMware. (2017). Connecting VMware Workstation guest virtual
machines to the Internet. Disponible en:
http://searchvmware.techtarget.com/tip/Connecting-VMware-Workstation-guest-
virtual-machines-to-the-Internet
[19] SearchStorage. (2017). What is virtual storage area network (VSAN)? -
Definition from WhatIs.com. Disponible en:
http://searchstorage.techtarget.com/definition/virtual-storage-area-network
[20] http://www.sunhelp.org/faq/FrameBuffer.html#00
[21] Biao Song ·Wei Tang · Tien-Dung Nguyen · Mohammad Mehedi Hassan · Eui
Nam Huh. “An optimized hybrid remote display protocol using GPU-assisted M-
JPEG encoding and novel high-motion detection algorithm”. © Springer
Science+Business Media New York 2013
[22] https://tools.ietf.org/html/rfc6143
[23] [Borko Furht, Joshua Greenberg, Raymond Westwater. “Motion Estimation
Algorithms for Video Compression”. Springer Science & Business Media,
6/12/2012 - 164 páginas]
[24] Philippe Colantoni and Al. ”Color Space Transformation” 2004
[25] N. Ahmed, T Natarajan y KR Rao. “Discrete Cosine Transform”. 1974
[26] Phuc-Tue Le Dinh and Jacques Patry. Video compression artifacts and MPEG
noise reduction. Video Imaging DesignLine. February 24, 2006. Retrieved May 28,
2009.

73
[27] Ken Cabeen and Peter Gent. “Image Compression and Discrete Cosine
Tranform”. College of the Redwoods.
[28] David Salomon. “Data Compression”. Springer Science & Business Media,
20/03/2007 - 1092 páginas
[29] S. Jayaraman, S Esakkirajan, T Veerakumar. “Digital Image Processing”. Tata
McGraw-Hill Education, 2011 - 723 páginas (S. Jayaraman, 2011)
[30] P. Simoens, F. Turck, B. Dhoedt, and P. Demeester, “Remote display
solutions for mobile cloud computing,” Computer, vol. 44, no. 8, pp. 46- 53, Aug.
2011.
[31] https://www.unocero.com/especiales/resumenes-anuales/resumen-2016/los-
mejores-wearables-de-2016
[32] Virtual mobile infrastructure for mobile devices Patent (September 13, 2016)
Disponible en: http://patents.justia.com/patent/9444912

74