Determining QoE metrics for Cloud Gaming in 5G

E.T.S. DE INGENIERÍA DE TELECOMUNICACIÓN, UNIVERSIDAD DE MÁLAGA
I
UNIVERSIDAD DE MÁLAGA
ESCUELA TÉCNICA SUPERIOR DE
INGENIERÍA DE TELECOMUNICACIÓN
TRABAJO FIN DE GRADO
Determinación de métricas QoE para Cloud Gaming en 5G
GRADO EN INGENIERÍA DE
SISTEMAS DE TELECOMUNICACIONES
MOHAMED BEN ALI
MÁLAGA, 2023

II

III

IV
Yo, Mohamed Ben Ali, estudiante del Grado en Ingeniería de Sistemas de
Telecomunicación, de la Escuela Técnica Superior de Ingeniería de
Telecomunicación de la Universidad de Málaga, declaro que no se ha utilizado
contenido de fuentes, sin citarlas adecuadamente, en la realización de la
presente memoria y, en consecuencia, la ausencia de plagio.
En Málaga el 23 de enero de 2023
Fdo.: Mohamed Ben Ali

V

VI

VII
Determinación de métricas QoE para Cloud Gaming en 5G
Autor: Mohamed Ben Ali
Tutores: Eduardo Baena Martínez y José Carlos Baena González
Departamento: Ingeniería de Comunicaciones (IC)
Titulación: Grado en Ingeniería de Sistemas de Telecomunicación
Palabras clave: Cloud Gaming, Unreal Engine, WebRTC, Análisis de tráfico, QoE
(Quality of Experience)
Resumen
La nueva generación de red 5G, ha aportado muchos beneficios en todos los
ámbitos gracias a la elevada velocidad de transmisión y la baja latencia que
supone. Esta mejora supone una evolución a todas las infraestructuras que
afecta en el sector gaming para el modo multijugador online (Online Gaming)
pero sobre todo en el juego en la nube (Cloud Gaming). Los juegos en la nube
ofrecen la experiencia de juego en línea a través de un servidor remoto,
permitiendo al usuario disfrutar del juego sin la necesidad de instalar el
programa en el dispositivo. El presente trabajo se centra en el desarrollo de un
juego Cloud Gaming basado en WebRTC mediante Unreal Engine 5, el cual se
analizará en diferentes configuraciones de la red 4G y 5G, obteniéndose así,
las diferentes métricas que influyen en la Calidad de experiencia (QoE, Quality
of Experience) del usuario a la hora de disfrutar de un juego en la nube.

VIII
Determining QoE metrics for Cloud Gaming in 5G
Author: Mohamed Ben Ali
Supervisors: Eduardo Baena Martínez and Jose Carlos Baena González
Department: Communications Engineering (IC)
Degree: Grado en Ingeniería de Sistemas de Telecomunicación
Keywords: Cloud Gaming, Unreal Engine, WebRTC, Traffic analysis, QoE
(Quality of Experience)
Abstract
The new generation of the 5G network has brought any benefits in all areas
thanks to the high transmission speed and low latency. This improvement is an
evolution of all infrastructures that affects the gaming sector for multiplayer Online
Gaming but especially for Cloud Gaming. Cloud gaming offers the online gaming
experience through a remote server, allowing the user to enjoy the game without
the need to install the program on the device. This work focuses on the
development of a Cloud Gaming game based on WebRTC using Unreal Engine
5, which will be analysed in different 4G and 5G network configurations, thus
obtaining the different metrics that influence the Quality of Experience (QoE) of
the user when enjoying a game in the cloud.

IX

X
Índice
1 Capítulo 1. Introducción............................................................................................ 1
1.1. Contexto............................................................................................................. 2
1.2. Objetivos............................................................................................................ 4
1.3. Estructura de la memoria .................................................................................. 5
2 Capítulo 2. Cloud Gaming.......................................................................................... 6
2.1. Concepto............................................................................................................ 7
2.1.1 Evolución del Cloud Gaming....................................................................... 8
2.1.2 Plataformas de Cloud Gaming.................................................................. 10
2.1.3 Cloud Gaming frente a Online Gaming..................................................... 10
2.2. Protocolos........................................................................................................ 11
2.3. Calidad de Experiencia (QoE, Quality of Experience) ...................................... 13
2.4. Conclusiones .................................................................................................... 14
3 Capítulo 3. WebRTC................................................................................................. 15
3.1. Concepto.......................................................................................................... 16
3.1.1. Ventajas e Inconvenientes de WebRTC.................................................... 16
3.1.2. WebRTC en la quinta generación móvil (5G) ........................................... 17
3.1.3. Plataformas compatibles con WebRTC .................................................... 17
3.2. Funcionamiento WebRTC ................................................................................ 18
3.3. Arquitectura WebRTC...................................................................................... 19
3.4. Cloud Gaming con WebRTC............................................................................. 21
3.5. Conclusiones .................................................................................................... 21
4 Capítulo 4. Juego Desarrollado ............................................................................... 22
4.1 Introducción..................................................................................................... 23
4.2 Programación en C++:...................................................................................... 24
4.3 Programación en Blueprint:............................................................................. 31
4.4. Cloud Gaming mediante Pixel Streaming: ....................................................... 35
4.5. Conclusiones .................................................................................................... 37
5 Capítulo 5. Entorno de ensayo................................................................................ 38
5.1 Descripción del Setup ...................................................................................... 39
5.2 Arquitectura..................................................................................................... 40
5.3 Medidas ........................................................................................................... 42
5.4 Conclusiones .................................................................................................... 44
6 Capítulo 6 . Toma de medidas................................................................................. 45
6.1. Introducción..................................................................................................... 46
6.2. Parámetros Generales ..................................................................................... 47
6.3. Velocidad ......................................................................................................... 51
6.4. Latencia............................................................................................................ 55
5.2. Conclusiones .................................................................................................... 60
7 Capítulo 7. Conclusión............................................................................................. 61
Trabajo Futuro ............................................................................................................ 62
ANEXOS....................................................................................................................... 63
BIBLIOGRAFÍA.............................................................................................................. 70

XI
Índice de figuras
Figura 1.1 Aplicaciones ofrecidas en redes 5G........................................................................................2
Figura 2.1 Cloud Gaming........................................................................................................................7
Figura 2.2 Diferencia entre el Cloud Gaming y el Gaming Online .........................................................11
Figura 2.3 Quality of Experience (QoE).................................................................................................13
Figura 3.1 WebRTC...............................................................................................................................16
Figura 3.2 Comunicación entre dos clientes por WebRTC.....................................................................18
Figura 3.3 Comunicación punto a punto (P2P) .....................................................................................19
Figura 3.4 Protocolos comunicación WebRTC ......................................................................................20
Figura 3.5 Pixel Streaming para la comunicación WebRTC ...................................................................21
Figura 4.1 Mapa creado para la realización de pruebas .......................................................................23
Figura 4.2 Elementos predefinidos de Unreal ......................................................................................23
Figura 4.3 Componente básico con movimiento de rotación ...............................................................28
Figura 4.4 Parámetros a modificar para la rotación .............................................................................28
Figura 4.5 Elementos visuales proporcionados por Blueprint...............................................................31
Figura 4.6 Parámetros de la explosión .................................................................................................32
Figura 4.7 Componentes de explosión dentro del mapa ......................................................................33
Figura 4.8 Spline ..................................................................................................................................33
Figura 4.9 Control de Velocidad durante el trayecto............................................................................34
Figura 4.10 Desplazamiento del componente por el mapa...................................................................34
Figura 4.11 Pixel Streaming en Unreal Engine ......................................................................................35
Figura 4.12 Parámetros de Cloud Gaming en Unreal............................................................................35
Figura 4.13 Empaquetamiento del juego .............................................................................................36
Figura 4.14 Se establecen los parámetros de puerto en el acceso directo............................................36
Figura 4.15 Servidor Conectado ...........................................................................................................37
Figura 4.16 Juego transmitido mediante Google Chrome.....................................................................37
Figura 5.1 Comunicación producida por el setup .................................................................................39
Figura 5.2 Arquitectura del setup.........................................................................................................40
Figura 6.1 Comunicación entre dos dispositivos por WebRTC ..............................................................46
Figura 6.2 Estructura de un diagrama de caja.......................................................................................46
Figura 7.1 Unreal Engine 5 ...................................................................................................................64
Figura 7.2 WebRTC-internals para la obtención de los parámetros......................................................66
Lista de Anexos
Anexo A: Unreal Engine..................................................................................................................64
Anexo B: Automatización de las pruebas con Python.....................................................................65

XII
Índice de tablas
Tabla 5.1 Parámetros obtenidos durante los ensayos..........................................................................42
Tabla 5.2 Configuraciones utilizadas durante los ensayos....................................................................43
Tabla 6.1 Parámetros Generales obtenidos .........................................................................................47
Índice de Gráficas
Gráfica 6.1 Fotogramas recibidos por la red 4G y 5G............................................................................48
Gráfica 6.2 Fotogramas perdidos por la red 4G y 5G ............................................................................48
Gráfica 6.3 Fotogramas decodificados por la red 4G y 5G ....................................................................49
Gráfica 6.4 Diagrama de caja de todos los fotogramas decodificados por la red 4G y 5G .....................49
Gráfica 6.5 Diagrama de caja del tiempo total de decodificación por la red 4G y 5G............................50
Gráfica 6.6 Diagrama de caja del tiempo total de ida y vuelta por la red 4G y 5G ................................50
Gráfica 6.7 Tasa de download en curso por la red 4G y 5G...................................................................51
Gráfica 6.8 Tiempo de ida y vuelta en curso por la red 4G y 5G............................................................52
Gráfica 6.9 Diagrama de caja de todas las tasas de download de la red 4G y 5G..................................53
Gráfica 6.10 Tasa de upload en curso por la red 4G y 5G......................................................................53
Gráfica 6.11 Diagrama de caja de todas las tasas de upload de la red 4G y 5G.....................................55
Gráfica 6.12 Retardo del búfer de fluctuación de la red 4G y 5G ..........................................................56
Gráfica 6.13 Fotogramas recibidos de la red 4G ...................................................................................57
Gráfica 6.14 Recuento emitido por el búfer de fluctuación de la red 4G y 5G ......................................57
Gráfica 6.15 Retardo total de procesamiento de red 4G y 5G ..............................................................58
Gráfica 6.16 Fotogramas perdidos de la red 4G y 5G............................................................................58
Gráfica 6.17 Diagrama de caja del retardo total de procesamiento de la red 4G y 5G..........................59

XIII
Lista de acrónimos
API: Interfaz de Programación de Aplicaciones
CPD: Centro de Procesamiento de Datos
CPE: Customer Premises Equipment
eMBB: enhanced Mobile BroadBand
FCC: Federal Communications Commission
FPS: Frames Per Second
GaaS: Gaming as a Service
IA: Inteligencia Artificial
IoT: Internet of Things
ISP: Internet Service Provider
KQI: Key Quality Indicator
MAC: Media Access Control
NAT: Network Address Translation
PDCP: Packet Data Convergence Protocol
PRB: Physical Resource Block
QoE: Quality of Experience
QoS: Quality of Service
RAN: Radio Access Network
RLC: Radio Link Control
RTP: Real-time Transport Protocol
RTCP: RTP Control Protocol
RTSP: RTP Streaming Protocol
SDP: Session Description Protocol
SIP: Session Initiation Protocol
STUN: Session Traversal Utilities for NAT
TCP: Transmission Control Protocol
UDP: User Datagram Protocol
VR: Virtual Reality
WebRTC: Web Real-Time Communication

1
1 CAPÍTULO 1. INTRODUCCIÓN
1 Capítulo 1. Introducción............................................................................................ 1
1.1. Contexto............................................................................................................. 2
1.2. Objetivos............................................................................................................ 4
1.3. Estructura de la memoria .................................................................................. 5
Sinopsis:
En este capítulo se hará un análisis de la evolución que ha tenido tanto las redes como
el CLOUD GAMING a lo largo de estos años. Además, se exponen los objetivos de este
proyecto y la estructura de la presente memoria.

2
1.1. Contexto
Desde que se lanzó la 1ª red de comunicaciones móviles en Japón en 1979 por NTT
(Nippon Telegraph and Telephone Corporation) [1] las redes han evolucionado
consideradamente y han sufrido cambios con respecto a la naturaleza del sistema,
velocidades, tecnologías/protocolos y la frecuencia para adaptarse a las necesidades
actuales de las personas.
Actualmente nos encontramos en la quinta generación de redes móviles (5G),
aportando grandes beneficios y provocando un gran desarrollo en las tecnologías como
Inteligencia Artificial (IA), Realidad Virtual (VR) y Aumentada (AR), vehículos autónomos,
robótica, Internet de las cosas (IoT) y Cloud Gaming.
Figura 1.1 Aplicaciones ofrecidas en redes 5G
La tecnología 5G utiliza una arquitectura más inteligente, mediante redes de acceso por
radio (RAN) virtuales [2], flexibles e interfaces nuevas que permiten la creación de
puntos de acceso de datos adicionales.

3
A continuación, se enumeran las principales ventajas de la tecnología 5G [3]:
• Mayor velocidad de descarga. La red 5G aumenta su velocidad de descarga
consideradamente con respecto a las redes celulares precedentes, alcanzando
valores de hasta los 10Gbps.
• eMBB (enhanced Mobile BroadBand) [4]. La Banda Ancha Móvil Mejorada es uno
de los avances de la red 5G que se caracteriza por ofrecer acceso de banda ancha
a mediante una amplia área de cobertura permitiendo atender ubicaciones
concurridas.
• Hiperconectividad. Uno de los objetivos de esta nueva generación de redes es la
posibilidad de que cualquier persona pueda acceder a todo tipo de información
en cualquier momento.
• Optimización de procesos. Este desarrollo permite la optimización de sectores
como el industrial y la salud debido a su ultra baja latencia (alrededor a 1
milisegundo) y su elevada conectividad (millones de dispositivos conectados en
tiempo real)
Aunque sean más las ventajas que los inconvenientes, también hay que tener en cuenta
ciertas desventajas [3]:
• Obsolescencia tecnológica. No todos los dispositivos pueden soportar la red 5G,
esto provoca un atraso en la implementación debido a la falta de accesibilidad
inmediata para todo el mundo.
• Riesgo en el manejo de los datos. Una gestión subóptima del acceso a toda la
información ofrecida por este tipo de redes puede suponer problemas de
privacidad, así como incrementar el riesgo del uso malintencionado de datos.
Por consiguiente, el desarrollo de las redes ha facilitado la evolución del gaming online.
La industria gaming no se refiere únicamente a los juegos de consola, abarca también
los juegos para celulares. Según Statista (portal de estadística en línea alemán), el
consumo de juegos en móviles ha aumentado un 63% en 2021 [5] y cabe destacar que
los ‘gamers’ son la segunda clientela más importante en el mundo digital después de los
usuarios de redes sociales.

4
La importancia de las redes 5G sobre el gaming recae en la gran mejora de velocidad de
conexión y su baja latencia haciendo esto posible la implementación de nuevas técnicas
informáticas tales como la VR, AR y la IA.
Gracias a las mejoras de velocidades y de capacidades de conexiones a la red surge el
Cloud Gaming para ofrecer a los usuarios la posibilidad de jugar a través de servidores
de una compañía. En consecuencia, en lugar de tener que jugar de manera local, los
juegos se encuentran en la nube, y son enviados del servidor al cliente a través de la red,
de tal modo que el cliente solo tenga que decodificar las imágenes. Por lo cual, el servicio
depende de la red, de una conexión buena y estable por parte del usuario y por tanto
del streaming del juego.
En el presente, la tecnología 5G aún se encuentra en fase de despliegue en muchas
partes del mundo, por lo que es necesario persistir en obtener la máxima calidad de
experiencia (Quality of Experience, QoE) con respecto a las latencias entre el cliente y el
servidor con ayuda de los indicadores de calidad (Key Quality Indicators, KQI).
1.2. Objetivos
El objetivo de este trabajo es la obtención de las métricas QoE para analizar y evaluar la
mejora que ha supuesto el paso de red 4G a la nueva generación 5G en el Cloud Gaming.
Para ello, se ha diseñado un juego en la nube mediante Unreal Engine [Véase Anexo A]
para la elaboración de las pruebas y obtener parámetros relacionados a la calidad de
experiencia del usuario. La calidad de experiencia (Quality of Experience, QoE), es una
medida del grado de satisfacción de los usuarios ante servicios digitales dependientes
de red como puede ser un servicio de streaming de video.
Es muy importante diferenciar entre Quality of Experience (QoE) y Quality of Service
(QoS) [6]. La primera proporciona información de la experiencia de un usuario individual
a un servicio de Internet que en nuestro caso es Cloud Gaming, mientras que QoS hace
referencia a la calidad que ofrece la red y permite priorizar el tráfico de datos entre
diferentes usuarios del sistema.

5
En este proyecto, se analizará las medidas QoE en las redes 4G y 5G utilizando diferentes
configuraciones, analizando como mejora la transmisión de datos y las latencias.
A continuación, se exponen los objetivos del estudio:
• El objetivo principal de este trabajo consiste en la elaboración del juego en la
nube, para ello se ha utilizado el entorno de desarrollo Unreal Engine que ofrece
una herramienta, Pixel Streaming, que permite transmitir el juego por la nube.
• Automatización de las pruebas mediante Python.
• Obtención de las métricas de QoE durante la comunicación.
• Integración en un entorno experimental de Cloud Gaming.
• Evaluación del juego desarrollado en redes 4G y 5G
1.3. Estructura de la memoria
La memoria se divide en 7 capítulos que estarán apoyados por anexos para dar un
sentido global a toda la investigación y mejorar su comprensión.
El primer capítulo, de introducción, tiene como objetivo poner en contexto con respecto
a la evolución tecnológica a lo largo de la historia y presentar los objetivos del trabajo.
El capítulo 2, explica la tecnología del Cloud Gaming, adentrándose en la arquitectura y
los protocolos que lo componen.
El capítulo 3, se presenta el servicio WebRTC para la transmisión de información desde
la nube y la relación que tiene con el Cloud Gaming.
El capítulo 4, presenta los pasos seguidos para la creación de un juego en la nube
mediante Unreal Engine
El capítulo 5, se describe el entorno de trabajo en el que se realizarán las medidas para
ambas redes, además, se presenta la arquitectura de la comunicación y los parámetros
que se obtendrán durante la toma de medidas.
El capítulo 6, se exponen las medidas obtenidas por las diferentes configuraciones de las
redes 4G y 5G analizando el comportamiento que siguen.
El capítulo 7, de conclusión, tiene como objetivo recopilar toda la información obtenida
durante todo el trabajo y exponer los objetivos logrados.

6
2 CAPÍTULO 2. CLOUD GAMING
2 Capítulo 2. Cloud Gaming.......................................................................................... 6
2.1. Concepto............................................................................................................ 7
2.1.1 Evolución del Cloud Gaming....................................................................... 8
2.1.2 Plataformas de Cloud Gaming.................................................................. 10
2.1.3 Cloud Gaming frente a Online Gaming..................................................... 10
2.2. Protocolos........................................................................................................ 11
2.3. Calidad de Experiencia (QoE, Quality of Experience) ...................................... 13
2.4. Conclusiones .................................................................................................... 14
Sinopsis:
En este capítulo se aborda el concepto del paradigma Cloud Gaming, el desarrollo que
ha tenido a lo largo de los años, los protocolos actuales y los factores que impactan en
la calidad de experiencia.

7
2.1. Concepto
El Cloud Gaming también conocido como juego en la nube o juego bajo demanda, nos
ofrece la experiencia de juego en línea a través de un servidor remoto en un centro de
datos como servicio (GaaS, Gaming-as-a-Service) a usuarios.
El origen surge con el Cloud Computing con el propósito de ofrecer aprovechando la
conectividad y la gran escala de Internet.
El factor "nube" en el juego permite el almacenamiento de juegos en un equipo remoto.
En lugar de descargar y jugar a videojuegos en tus dispositivos externos, puedes jugar y
guardarlos en línea, solventando posibles problemas en el dispositivo de usuario de
almacenamiento o recursos computacionales para la ejecución del juego.
Figura 2.1 Cloud Gaming [8]
La gran ventaja frente al gaming tradicional es la posibilidad para jugar en cualquier
dispositivo sin la necesidad de tener un dispositivo físico que procese el juego y sin la
necesidad de tener una copia en local, es decir, los datos se almacenan fuera de tu
equipo. Esta ventaja cada vez es más importante debido a que actualmente los juegos
son bastante exigentes, en lo que se refiere al rendimiento, lo que hace que muchos
usuarios no puedan disfrutarlo. Gracias al Cloud Gaming, los jugadores no necesitan de
un terminal potente para disfrutar de los videojuegos actuales.

8
A continuación, se presentan las ventajas del Cloud Gaming [7]:
• No es necesario ningún tipo de configuración. Esto permite a cualquier usuario
disfrutar del juego siempre y cuando la conexión sea constante. La única
exigencia que tiene el Cloud Gaming es contar con una buena conexión de red.
• Acceso a gran variedad de títulos. Considerando el coste de la suscripción, ofrece
a los gamers un enorme catálogo de juegos otorgando esto la libertad de optar
a jugar varios juegos sin llenar la memoria del dispositivo. Esto hace que sea más
barato debido a que no es necesario comprar los juegos.
• Asequibilidad del juego. El Cloud Gaming permite a cualquier usuario seguir
disfrutando del juego desde cualquier dispositivo y en cualquier momento,
debido a que la progresión y la información del juego se guarda en la nube.
• Asequibilidad económica. Mediante la suscripción, los usuarios pueden disfrutar
de una gran cantidad de juegos sin la necesidad de comparar cada uno.
Frente a estas ventajas, se nombran las siguientes desventajas [7]:
• Mayor latencia. Hay un retardo entre que el usuario realiza una acción y el
servidor la ejecuta. Es una de las razones principales por lo que muchos
jugadores prefieren jugar en PC en vez del Cloud Gaming.
• Se requiere de buena conexión a Internet. Es necesario que el usuario tenga una
conexión buena y estable durante todo el juego, si no esto provocaría un retardo
en la respuesta (Input Lag). Además, las bajadas de conexión provocan
congelaciones en la imagen.
Como se puede observar, el Cloud Gaming tiene tanto ventajas como inconvenientes,
dependiendo del usuario, un jugador casual aprovecha mucho más el servicio (por el
bajo coste y la variedad) que un jugador profesional que busca una mayor resolución y
un retraso mínimo en la respuesta.
2.1.1 Evolución del Cloud Gaming
Las primeras empresas de juegos en la nube utilizaban tecnología propia, pero no se
obtuvo buenos resultados, ya que las retransmisiones tenían problemas de latencia y
los contenidos eran de baja calidad. Este primer fracaso se debe a la limitada tecnología
con la que contaba la empresa de juego y los servidores disponibles eran lentos.
Los servidores en aquel entonces no disponían de muchos centros de datos que
permitiesen una transmisión más rápida y amplia. Además, la tecnología de red, en ese
momento, no estaba avanzada y no ofrecía las capacidades que hoy ofrecen las redes.
Actualmente las empresas disponen de CPD (Centro de Procesamiento de Datos) con
toneladas de servidores distribuidas por todo el mundo para mejorar la experiencia de
juego a los usuarios.

9
La mejora del Cloud Gaming viene dado por la invención de la tecnología de
virtualización que utiliza el software para replicar las características del hardware y
formar un sistema informático virtual. Esto permite ejecutar múltiples sistemas
operativos en un solo servidor.
Acto seguido, se va a exponer la cronología de la evolución de los juegos en la nube [8]:
• En el año 2000, la empresa finlandesa G-Cluster realiza el primer intento de
producir juego en la nube.
• En el año 2005, los desarrolladores alemanes de Crytek crean un videojuego FPS
(First Person Shooter).
• En el año 2007, la investigación de Crytek de los juegos en la nube se detuvo al
realizar estudios económicos, no era viable, en aquel entonces había dudas sobre
la economía de escala.
• En el año 2010, el servicio de Cloud Gaming, OnLive, lanzo el primer servicio de
juegos a la carta para navegadores MAC y PC y se retransmitía en streaming. El
lanzamiento fue un éxito con títulos importantes como Assassin’s Creed.
• En el año 2012, Sony compra el servicio de Cloud Gaming Gaikai para mejorar la
tecnología de juegos en la nube. Esta adquisición le aportó prestigio en los juegos
bajo demanda además de que los juegos de hardware existentes de Sony se han
visto favorecidas por las nuevas funciones de streaming.
• En el año 2013, Nvidia dedica su investigación en los juegos de streaming lanzado
una beta limitada.
• En el año 2014, Sony anunció PlayStation Now, un servicio de Cloud Gaming
disponible para ordenadores, smartphones y televisores. El servicio se diseñó
para que los usuarios pudiesen suscribirse y tener a su disposición diversos
juegos, también se podía alquilar los juegos durante un plazo limitado de tiempo.
• En el año 2015, OnLive cierra sus servicios y vende sus acciones a Sony. Esto
alteró la industria de videojuegos, pero mejoró la transmisión de juegos a partir
de cualquier dispositivo por streaming.
• En el año 2017, Nvidia mejoró su funcionamiento, obteniendo buenos resultados
con respecto a la latencia en los juegos bajo demanda y presentando una
configuración de PC para el Cloud Gaming de gama alta denominado Shadow,
esto permitió que smartphones y otros dispositivos puedan tener acceso
completo a una máquina virtual de Windows.
• En el año 2019, Google lanzo un servicio de Cloud Gaming llamado Stadia. Al
principio los juegos que proporcionaba Stadia tenía el inconveniente de no poder
trabajar en otros servicios, por lo que Google proporcionó un soporte de
guardado cruzado que permitía a los usuarios compartir su progresión entre
dispositivos. En el mismo año, Sony y Microsoft colaboraron para buscar mejorar
los problemas del Cloud Gaming.

10
• En el año 2020, PlayStation Now de Sony alcanza más de 2,2 millones de
suscriptores y debido al gran desarrollo que estaba teniendo el Cloud Gaming se
han incorporado muchas empresas importantes, por ejemplo, Facebook
(PlayGiga), Amazon (Luna), Deutsche Telekom (MagentaGaming), etc.
Lanzamiento xCloud, la plataforma gaming de xBox que está revolucionando el
tema de Cloud Gaming
• En el año 2021, Apple pone trabas al Cloud Gaming, que fue un gran indicio de
que el juego en la nube está ganando bastante popularidad por lo que lo han
regulado en su plataforma.
• En el año 2023, Cierre de Google Stadia, donde el principal problema ha sido el
modelo de negocio.
A lo largo de estas décadas, el Cloud Gaming ha evolucionado tanto convirtiéndose en
un gran servicio de streaming de videojuegos. Hoy en día, con la integración del 5G,
podría revolucionar la industria de los videojuegos obteniendo grandes mejoras en el
servicio.
2.1.2 Plataformas de Cloud Gaming
Debido al auge que está teniendo los juegos en la nube, han aparecido en el mercado
diferentes plataformas de servicio de Cloud Gaming, los principales son [9]:
• PlayStation Now de Sony
• Luna de Amazon
• Xbox Cloud Gaming de Microsoft
• Moonlight de Nvidia
2.1.3 Cloud Gaming frente a Online Gaming
La principal diferencia es que en los juegos en línea, la conexión solo es necesaria para
interconectar con otros jugadores, siendo el volumen de información inferior al del
Cloud Gaming.
Los juegos en la nube se transmiten desde servidores, no es necesario descargarlos en
nuestro dispositivo, aunque en algunos casos, es necesaria una pequeña descarga para
su lanzamiento pero no se trata de la descarga del software completo en nuestro
equipo.
Los juegos en línea simplemente requieren la identificación a la web y ya se podría jugar
con otras personas del mundo, pero se necesitaría de una consola y del juego instalado
en nuestro dispositivo. En su lugar, los juegos bajo demanda te conectas directamente
a un servidor que ejecuta el juego si necesidad de archivos.

11
Figura 2.2 Diferencia entre el Cloud Gaming y el Gaming Online
La principal diferencia ya mencionada anteriormente es que el Cloud Gaming se basa en
un servidor que ejecuta el juego (Remote Game Server) en el cual los usuarios se
conectan mediante streaming gracias a centros de datos (Data Center) con un
renderizado del lado del servidor (Rendering Server) haciendo esto posible que las
peticiones del usuario se procesen de forma casi inmediata. La parte online, lo procesa
el Matchmaking Server que permite emparejar jugadores e influir en los servidores de
emparejamiento. Mientras que para el gaming online, la principal diferencia es la
obligación de tener el juego instalado en el dispositivo, el proceso es similar, el cliente
manda una acción al servidor de su zona que a su vez lo manda al servidor central, este
último en cada instante de tiempo, recibe las acciones de todos los usuarios y calcula el
nuevo estado del juego y lo manda de vuelta al jugador, manteniendo así el flujo de
datos.
2.2. Protocolos
Se considera protocolo como un estándar de comunicación que contiene la información
y las reglas necesarias que permiten el intercambio de paquetes de datos para la
interconexión entre dos dispositivos, en el caso del Cloud Gaming, estas logran el flujo
multimedia.
Estas se forman a partir de los protocolos de transporte UDP (User Datagram Protocol)
o TCP (Transmission Control Protocol). Los más populares son los siguientes:
• RTP (Real-time Transport Protocol) [10]: Se trata de un protocolo basado en
UDP utilizado para la transmisión de información en tiempo real. Tiene el
inconveniente de no garantizar ni la entrega de los paquetes ni una calidad de
servicio (QoS) adecuada. Aunque el protocolo RTP no garantiza la entrega de los
paquetes, se complementa por los dos protocolos RTCP y RTSP para controlar la
entrega y proporcional información de control .
• RTCP (RTP Control Protocol) [10]: Proporciona información de control para un
servicio multimedia RTP, pero no transmite datos multimedia. Su uso se basa en

12
la entrega de paquetes de control a los usuarios para obtener un informe de
calidad del servicio RTP.
• RTSP (Real-Time Streaming Protocol) [10]: Es un protocolo diseñado de apoyo a
RTP para controlar la entrega de datos multimedia, utilizando un protocolo de
señalización, controla la transmisión de datos.
• WebRTC (Web Real-Time Communications) [11]: Protocolo impulsado por
Google que permite el intercambio de datos y el streaming mediante un
navegador web sin la necesidad de instalar extensiones adicionales. Esto es
posible mediante un API (Application Programming Interfaces) JavaScript
permitiendo comunicaciones dentro de sus aplicaciones en tiempo real.

13
2.3. Calidad de Experiencia (QoE, Quality of Experience)
QoE se trata de una medida encargada en recopilar estadísticas y en evaluar los servicios
recibidos por el usuario para obtener un grado de satisfacción, utilizada también para
analizar qué elementos provocan una reducción de rendimientos para mejorar la calidad
del servicio.
Figura 2.3 Quality of Experience (QoE)
Debido a que la suma de la calidad de los componentes no es igual a la calidad de la
suma, la única manera de conocer la calidad experimentada por el al cliente es necesario
conectarse como un usuario. Además, la extracción de parámetros implica una
complejidad debido a la encriptación que tiene como medida de seguridad.
Esto proporciona a las empresas de telecomunicaciones y a los proveedores de servicios
de Internet (ISP, Internet Service Provider) obtener un registro de la calidad de su servicio
y conocer la valoración de los usuarios [12].
En el Cloud Gaming es muy importante, por parte de la empresa que brinda el servicio,
que la calidad de experiencia percibida por el usuario sea la óptima para así poder
disfrutar del juego optimizado y sin latencias. QoE se ve afectada debido a la compresión
video en los juegos en la nube, provocando una reducción en la latencia, a costa de
disminuir la calidad percibida por el usuario.
Los parámetros de mayor importancia para conocer la calidad de experiencia son los
siguiente:
• Tasa de cuadros (FPS, Frames per Second)
• Tasa de bits (Bitrate)
• Resolución de video
• Latencia

14
2.4. Conclusiones
Durante este capítulo se ha expuesto el gran avance que ha supuesto el Cloud Gaming,
como servicio, en la industria de videojuegos.
Analizando la evolución a lo largo de los años, este nuevo servicio solventa algunos de
los problemas surgidos en el campo de los videojuegos. Se espera que en los próximos
años el Cloud Gaming sea la tendencia principal.
Adicionalmente, se han presentado los protocolos que existen y la importancia que tiene
la calidad de experiencia QoE.

15
3 CAPÍTULO 3. WEBRTC
3 Capítulo 3. WebRTC................................................................................................. 15
3.1. Concepto.......................................................................................................... 16
3.1.1. Ventajas e Inconvenientes de WebRTC.................................................... 16
3.1.2. WebRTC en la quinta generación móvil (5G) ........................................... 17
3.1.3. Plataformas compatibles con WebRTC .................................................... 17
3.2. Funcionamiento WebRTC ................................................................................ 18
3.3. Arquitectura WebRTC...................................................................................... 19
3.4. Cloud Gaming con WebRTC............................................................................. 21
3.5. Conclusiones .................................................................................................... 21
Sinopsis:
WebRTC es uno de los protocolos más importantes del Cloud Gaming, en este capítulo,
se explicará con detalle y se analizará su impacto en los juegos en la nube con la
aparición de la nueva red 5G.

16
3.1. Concepto
WebRTC (Web Real-Time Communications) se trata de un proyecto de código abierto
que permite las comunicaciones en tiempo real sin necesidad de extensiones adicionales
gracias a una API JavaScript, esta tecnología está disponible para todos los navegadores
modernos y accesible a todos los usuarios [13].
El protocolo WebRTC permite la transmisión de datos de video y voz gracias a un flujo
de aplicación común, lo que da acceso a los dispositivos multimedia, abrir conexiones y
empezar a transmitir.
Figura 3.1 WebRTC
El uso de esta tecnología de comunicación en tiempo real se extiende por las
aplicaciones web que usan cámara y/o micrófono, permitiendo realizar videollamadas y
el uso compartido de pantallas. Actualmente, existen varias aplicaciones que utilizan
WebRTC: Facetime, Skype, Google Talk, etc.
3.1.1. Ventajas e Inconvenientes de WebRTC
Ventajas de WebRTC [14]:
• Mayor seguridad y estabilidad a pesar de estar en proceso de perfeccionamiento
y desarrollo.
• Mejor calidad de sonido debido a la configuración ajustable del micrófono
incorporado.
• Compatible con la mayoría de los navegadores actuales
• Compatibilidad con soluciones SIP. Los protocolos de inicio de sesión (SIP,
Session Initiation Protocol) que permiten crear redes especializadas para la
transferencia de datos multimedia.

17
Desventajas de WebRTC [14]:
• Se encuentra todavía en desarrollo.
• Incertidumbre con respecto a los códecs. Los códecs son programas que
comprimen o descomprimen archivos multimedia, se considera un
inconveniente debido a que las empresas utilizan códecs diferentes. Es necesario
acordar un códec principal multiplataforma y compatible con todos los
navegadores para evitar este problema a los desarrolladores de software.
3.1.2. WebRTC en la quinta generación móvil (5G)
Actualmente, se espera que la nueva red móvil 5G aporte grandes beneficios [15] para
WebRTC y por consiguiente mejoras en el Cloud Gaming como por ejemplo:
• No requiere instalación de software.
• Comunicación de alta calidad.
• Fiabilidad mayor
• Seguridad y privacidad garantizadas
Gracias a estas mejoras, el uso del WebRTC recae sobre todo a la hora de en el envío de
contenido multimedia en tiempo real. Hoy en día hay plataformas de videoconferencia
que utilizan WebRTC:
• Google Meet
• Jitsi Meet
• BigBlueButton
3.1.3. Plataformas compatibles con WebRTC
Hoy en día, WebRTC es compatible con los siguientes navegadores [11]:
• Google Chrome (ordenador & Android)
• Mozilla Firefox (ordenador & Android)
• Safari
• Opera (ordenador & Android)
• Microsoft Edge
• Vivaldi
• Brave
• Chrome OS
• Firefox OS
• iOS

18
3.2. Funcionamiento WebRTC
WebRTC es una tecnología que permite la conexión directa, segura y en tiempo real
entre dispositivos, sin necesidad de pasar por un servidor.
A continuación, se analizará como se establece la conexión entre dos dispositivos y cómo
funciona WebRTC con la ayuda del siguiente esquema [16]:
Figura 3.2 Comunicación entre dos clientes por WebRTC
1. Como se ha comentado anteriormente, se realiza la comunicación entre dos
dispositivos sin pasar por un servidor intermediario, para que esto sea posible
es necesario que los dispositivos conozcan ciertos datos. En primeras
instancias, participa un servidor STUN (Simple Traversal Utilities for NAT) que
permite a los usuarios conectados a redes locales distintas encontrar sus
direcciones públicas, el tipo de NAT al que se encuentran conectados y el
puerto de internet asociado.
NAT (Network Address Translation) es una forma de asignación de varias
direcciones privadas locales a una pública antes de la transmisión de datos.
2. Para interconectar ambos dispositivos, se utilizan SDP (Session Description
Protocol) basado en cadenas y sirve para compartir códecs entre navegadores.
El cliente A, prepara su SDP de inicialización (Offer SDP), lo guarda en SDP local
y lo comparte al cliente B que lo registra como SDP remoto, luego crea su SDP
local de respuesta (Answer SDP) que lo comparte al cliente A y este lo guarda
como SDP remoto.

19
3. Cuando ambos clientes están conectados y conocen sus datos (dirección local,
puerto...) envían esta información el uno al otro por paquetes ICE Candidate
mediante Signaling Server. Cuando reciben la información, cada cliente prueba
cada dirección IP recibido utilizando pings especiales para crear la conexión.
Cuando un usuario recibe una respuesta, guarda la dirección en una lista con el
tiempo de respuesta y el rendimiento para que el usuario elija la dirección
según el uso que le va a dar.
4. Finalmente, cuando cada cliente tiene ya apuntado las direcciones IP, empieza
la transferencia de datos multimedia mediante RTP (Real Time Protocol)
utilizado para transmitir datos en tiempo real sobre UDP. El servidor STUN se
mantiene para decidir qué puerto utilizar en cada dispositivo en la
comunicación.
Esto es posible gracias al Signaling Server (Servidor de señalización) que gestiona
las conexiones entre dispositivos, no para el tráfico multimedia, si no que permite a
un usuario encotrarse a otro en la red. Además, se utiliza también para enviar
cadenas SDP y ICE candidate entre usuarios.
3.3. Arquitectura WebRTC
WebRTC permite la comunicación entre dos puntos mediante la red P2P (Peer to Peer)
que consiste en un modelo de comunicación que no necesita un servidor central, sino
que cada usuario actúa por igual.
Una red peer-to-peer [17], consiste en un conjunto de nodos que cumplen la función de
servidores y de clientes sin ningún tipo de jerarquía. Cada ordenador se encuentra en
un plano de igualdad con los demás.
Figura 3.3 Comunicación punto a punto (P2P) [17]
Para conocer el comportamiento de la tecnología WebRTC, se hará un análisis de los
elementos y protocolos que lo componen.

20
Figura 3.4 Protocolos comunicación WebRTC
La arquitectura WebRTC se forma a partir de los siguientes protocolos [18]:
• RTCPeerConnection: Es la primera API del WebRTC, esta representa la conexión
WebRTC real y mantiene la transmisión eficiente de datos entre dos puntos.
Permite el envío de datos de audio y video en tiempo real, además es
responsable de controlar el ciclo de vida de cada conexión punto a punto.
• RTCDataChannel: Es la segunda API que forma parte del WebRTC, es el canal
principal por el cual se realiza el intercambio de datos de un par a otro.
• Secure Real-time Transport Protocol (SRTP): WebRTC utiliza SRTP (RTP, pero
con un mecanismo seguridad incorporado) para el transporte en tiempo real
pero con la obligación del cifrado del flujo de información.
• Stream Control Transmission Protocol (SCTP): Se trata de un protocolo similar
al TCP que permite transmitir paquetes de datos orientados a mensajes, similar
a UDP.
• Datagram Transport Layer Security (DTLS): Utilizado para la encriptación de la
información y de los canales de datos.
• Interactive Connectivity Establishment (ICE): Se utiliza para establecer una
conexión entre pares a través de Internet.
• Session Traversal Utilities for NAT (STUN): El servidor STUN determina la
dirección IP y el puerto asociado del usuario. Esto es necesario para establecer
una comunicación P2P.
• Traversal Using Relays around NAT (TURN): El servidor TURN ofrece una
alternativa en caso de fallo en el establecimiento de comunicación P2P.

21
• User Datagram Protocol (UDP): Es un protocolo que permite la transmisión de
datos sin conexión.
3.4. Cloud Gaming con WebRTC
En este trabajo se va a simular un entorno de Cloud Gaming, lo cual se ha creado un
juego mediante Unreal Engine [Véase Anexo A] que cuenta con elementos interactivos
que provocan una constante descarga de datos desde el servidor. El juego se transmite
por la nube mediante Pixel Streaming que es una herramienta que ofrece Unreal Engine
para transmitir el juego en la nube mediante WebRTC.
Figura 3.5 Pixel Streaming para la comunicación WebRTC [19]
Ya logrado el juego en la nube, se ha automatizado las pruebas para obtener los
parámetros ofrecidos por WebRTC en diferentes condiciones tanto para la red 4G como
la 5G.
3.5. Conclusiones
Actualmente WebRTC ofrece bastantes beneficios para el Cloud Gaming facilitando,
aunque siga en fase de desarrollo y se utilice un protocolo de transporte UDP, su
arquitectura va acompañada de otros protocolos que aseguran la entrega de los
paquetes de datos y la seguridad gracias a la encriptación.
Se espera que con la red 5G impulsen más los servicios de la nube y en especial los
juegos.

22
4 CAPÍTULO 4. JUEGO DESARROLLADO
4 Capítulo 4. Juego Desarrollado ............................................................................... 22
4.1 Introducción..................................................................................................... 23
4.2 Programación en C++:...................................................................................... 24
4.3 Programación en Blueprint:............................................................................. 31
4.4. Cloud Gaming mediante Pixel Streaming: ....................................................... 35
4.5. Conclusiones .................................................................................................... 37
Sinopsis:
En este capítulo se presentará el desarrollo del juego en la nube en el entorno de
desarrollo Unreal Engine.

23
4.1 Introducción
Para la realización de pruebas, se ha elaborado un juego básico en Unreal Engine con
diferentes elementos interactivos para conocer las velocidades entre el cliente y el
servidor y los retrasos.
Figura 4.1 Mapa creado para la realización de pruebas
Se ha creado un proyecto en primera persona aprovechando los elementos básicos
ofrecidos por el programa (cámara ya configurada, brazo del personaje y pistola):
Figura 4.2 Elementos predefinidos de Unreal

24
Para los elementos interactivos, se ha utilizado el lenguaje de programación C++ y
complementado por el sistema de blueprints.
Blueprint es una forma de programación visual mediante bloques que permite
construir funciones complejas y elementos interactivos a través de un sistema de
nodos.
4.2 Programación en C++:
Unreal ofrece diferentes clases a la hora de programar en C++:
• Actor: Es un objeto que se puede poner en el juego.
• Actor Component: Es un componente reutilizable que se puede añadir a un
actor.
• Pawn: Es un actor que puede ser controlador.
• Character: Es un tipo de Pawn que incluye la habilidad de caminar.
• Scene Component: Es una subclase de Actor que disponen de una
transformación, es decir, una ubicación relativa, rotación y escala.
• Player Camera Manager: Encargado de controlar las componentes de la cámara
para un jugador específico.
• Player Controller: Es una subclase de Actor responsable en controlar el Pawn
usado por un jugador.
• Game Mode Base: Es una clase principal usado para definir las reglas del juego
y especifica las clases predeterminadas.
A la hora de elaborar una clase, se genera un archivo de cabecera .h y otro archivo de
programación orientado a objetos C++.
Se utilizan las siguientes clases creadas por defecto:
Nombre Tipo Descripción
FirstPersonGameMode Game Mode
Base
Establece la clase Pawn a una clase
Character.
FirstPersonCharacter Character Establece las características del
personaje controlado por el jugador y
crea los componentes de la cámara.
TP_WeaponComponent Actor
Component
Crea un arma que puede ser usada por
el personaje (Character)
TP_PickUpComponent Scene
Component
Permite que el personaje pueda
adquirir el arma.
FirstPersonProjectile Actor Crea los proyectiles lanzados por el
arma.

25
Por otra parte se han elaborado diferentes clases que permitan un mejor análisis del
trabajo introduciendo elementos interactivos.
Nombre Tipo Descripción
Rotation Scene Component Realiza la rotación de componentes del juego.
TimerExit Actor Temporizador para finalizar el juego.
SDK Actor Utilizado para obtener parámetros de rendimiento.
Rotation:
Se trata de una clase bastante importante en este trabajo debido a que permite que
haya componentes en constante movimiento durante toda la duración del juego para
conocer las velocidades con la que el cliente recibe los paquetes de datos.
Rotation.h:
En el archivo de cabeceras se declaran las variables y los eventos que forman esta
clase, no obstante hay que tener en cuenta ciertos detalles.

26
UCLASS se utiliza para indicar que una clase C++ formara parte del Unreal’s Reflection
System que otorga la capacidad a un programa para examinarse a sí mismo en tiempo
de ejecución. La variable ClassGroup nos informa que no pertenece a ningún grupo de
clase, mientras que la variable meta otorga la posibilidad de que el componente sea
generado por cualquier blueprints.
GENERATED_BODY () utiliza un constructor por defecto para que el sistema de
propiedades pueda administrarlos correctamente.
En esta parte se definen las variables con la condición de que se puedan editar
(EditAnywhere) debido a que en el juego va a haber componentes con diferentes
velocidades y centros de rotación.
Los eventos son nodos que se llaman desde el código de juego para realizar acciones
en respuesta a eventos de juego.
BeginPlay es el primer evento que será llamado al ejecutar el juego.
TickComponent es un evento que se ejecuta en cada fotograma (frame), es necesario
para provocar el constante movimiento.

27
Rotation.cpp
En el archivo de programación, se establece los valores predeterminados de la rotación
y define los eventos antes nombrados en la cabecera.
El evento URotation establece los valores predeterminados de la rotación, estos
valores pueden ser modificados posteriormente mediante Blueprint al asociarlo con
algún componente.

28
El evento TickComponent provoca el desplazamiento del componente en cada
fotograma del juego.
Se conoce como DeltaTime a la diferencia entre dos fotogramas consecutivos.
Esta clase es utilizada por el sistema Blueprint a la hora de crear componentes con
formas geométricas para el juego se le ha añadido este componente para su rotación.
Figura 4.3 Componente básico con movimiento de rotación
Además, cada elemento puede ser configurado para tener diferentes tipos y
velocidades de rotación.
Figura 4.4 Parámetros a modificar para la rotación

29
TimerExit:
Se trata de una clase Actor que se genera al ejecutarse el juego e inicializa un
temporizador de un minuto que termina con el cierre del juego. Se utiliza para ajustar
los tiempos de ensayo.
TimerExit.h
La estructura es similar a la clase anterior, pero cabe destacar los siguientes
elementos:
TimerHandle es el temporizador el cual se tendrá que ajustar según la aplicación y
ExitGame es la función para finalizar el juego.

30
TimerExit.cpp
La función de esta clase es únicamente iniciar un temporizador cuando empieza el
juego mediante la función GetTimerManager():
GetWorld(): Se obtiene un puntero del mapa actual donde se encuentra el Actor.
GetTimerManager().SetTimer(): Función para iniciar el temporizador TimerHandle, con
la duración de 60 segundos en este caso, cuando finaliza el temporizador ejecuta la
función ExitGame que cierra el juego.

31
4.3 Programación en Blueprint:
El sistema Blueprint Visual Scripting consiste en un sistema completo de comandos de
juego integrado por Unreal Engine que consiste en nodos utilizados para crear
elementos de juego desde Unreal Editor.
Se trata de un sistema flexible y poderoso utilizado para definir clases u objetos
orientado a objetos en el motor de desarrollo.
El sistema Blueprint ofrece componentes visuales adicionales a un determinado juego
creando elementos complejos mediante la unión de nodos, eventos, funciones y
variables.
Además de ser una herramienta rápida de creación de prototipos, Blueprints también
facilita que los no programadores se sumerjan y comiencen a crear secuencias de
comandos.
Figura 4.5 Elementos visuales proporcionados por Blueprint
En este trabajo, se hará uso del sistema Blueprint para la creación de dos elementos
interactivos para el juego: Explotion y SplinePathBP
Explotion:
Se ha elaborado un Blueprint que provoque una explosión después de un determinado
tiempo, ocasionando un gran movimiento en los componentes cercanos, utilizando los
bloques de programacion ofrecidos por el sistema Blueprint.
Esto supone una elevada transferencia de datos desde el servidor al cliente en un corto
instante de tiempo, lo cual se analizará utilizando diferentes configuraciones.

32
El Event Graph de un Blueprint consiste en un gráfico de nodos que utiliza eventos y
llamadas a funciones para realizar acciones en respuesta a eventos de juego. La
interactividad y las respuestas dinámicas se configuran aquí.
Event Graph Explotion:
El primer bloque, Event BeginPlay, se inicia cuando se ejecuta el juego, justo después
empieza un retraso de 30 segundos antes de la explosión. Cuando finaliza el
temporizador se produce la explosión, controlado por la variable Radial Force que
dictamina el radio y la fuerza de la explosión y por la variable Particle System para los
efectos visuales.
Figura 4.6 Parámetros de la explosión

33
A partir de este Blueprint se han creado 4 componentes distribuidos por el mapa para
que haya mayor desplazamiento de los cubos.
Figura 4.7 Componentes de explosión dentro del mapa
SplinePathBP:
Spline es esencialmente una línea con dos extremos utilizado para que un componente
repita un camino.
Figura 4.8 Spline
A partir del del SplinePathBP, se va a crear un Blueprint de tipo Actor, que simulará un
cubo que siga un determinado camino.

34
Event Graph Character Blueprint:
Esto permite que el cubo se desplace en un determinado camino teniendo la
posibilidad de variar la velocidad durante el desplazamiento mediante las
herramientas ofrecidas por Unreal Engine.
Figura 4.9 Control de Velocidad durante el trayecto
Este componente realizará un desplazamiento que repetirá a lo largo de todo el
ensayo.
Figura 4.10 Desplazamiento del componente por el mapa

35
Con el juego ya preparado toca configurarlo para convertirlo en un juego en la nube,
para ello utilizaremos el complemento de Unreal Engine, Pixel Streaming, que permite
la transmisión de una aplicación Unreal Engine desde una computadora a otras
computadoras y dispositivos móviles en la misma red.
4.4. Cloud Gaming mediante Pixel Streaming:
Pixel Streaming es una tecnología que proporciona Unreal Engine para transmitir
aplicaciones 3D interactivas implementadas de forma remota a través de un navegador
desde dispositivos como computadoras y teléfonos móviles
Para transmitir el juego en la nube, toca realizar ciertas configuraciones [18]:
1. Primero se tendría que activar el Plugin Pixel Streaming asociado a la
transmisión de datos mediante WebRTC:
Figura 4.11 Pixel Streaming en Unreal Engine
2. Se establecen los parámetros de lanzamiento en el editor de preferencias:
Figura 4.12 Parámetros de Cloud Gaming en Unreal

36
3. Tras establecer el puerto, toca empaquetar el juego para el sistema operativo
que en este caso es Windows:
Figura 4.13 Empaquetamiento del juego
4. Con el juego ya empaquetado, se va a crear un acceso directo al que se le
añadirán los parámetros de lanzamiento.
Figura 4.14 Se establecen los parámetros de puerto en el acceso directo
Al realizar estos pasos, el juego ya está configurado para ser transmitido en la nube,
para empezar la transmisión, toca iniciar el Signalling Server mediante el PowerShell
ejecutando el siguiente comando
SignallingWebServerplatform_scriptscmdsetup.ps1 para instalar todos los archivos
necesarios, cuando este instalado, se ejecutar el comando
SignallingWebServerplatform_scriptscmdStart_SignallingServer.ps1 para iniciar el
servidor.

37
Figura 4.15 Servidor Conectado
Mientras que el servidor se encuentre activo, se podrá transmitir el juego a cualquier
dispositivo conectado a la red, es necesario que el juego este lanzado para lograr jugar
desde la nube.
Figura 4.16 Juego transmitido mediante Google Chrome
Ya logrado el juego en la nube, ya se podrían realizar las pruebas necesarias y obtener
los parámetros ofrecidos por WebRTC durante la comunicación.
4.5. Conclusiones
Con el juego diseñado, solo faltaría automatizar las pruebas [Véase Anexo B] para
empezar a tomar las medidas de las métricas durante la comunicación WebRTC para
conocer la calidad de experiencia (QoE) del usuario.

38
5 CAPÍTULO 5. ENTORNO DE ENSAYO
5 Capítulo 5. Entorno de ensayo................................................................................ 38
5.1 Descripción del Setup ...................................................................................... 39
5.2 Arquitectura..................................................................................................... 40
5.3 Medidas ........................................................................................................... 42
5.4 Conclusiones .................................................................................................... 44
Sinopsis:
En este capítulo se presentará el setup utilizado para la toma de datos, se analizará la
arquitectura del sistema formado y una exposición de los parámetros que se va a
obtener.

39
5.1 Descripción del Setup
Para el análisis de las métricas QoE, se ha utilizado el siguiente setup:
Figura 5.1 Comunicación producida por el setup
Para ello se ha utilizado un ordenador que actúa de servidor (P100X) conectado a la
red de la Universidad de Málaga (RED UMA), donde se ha creado un juego [Véase
Anexo B] mediante el entorno de desarrollo Unreal Engine 5. La Red UMA se conecta
mediante ethernet a una estación base con core real basada en software, Amarisoft
[AMARI Callbox Classic][20], ideal para para el desarrollo de redes 4G/5G que,
mediante transmisión radio, decide la red en el CPE (Customer Premises Equipment)
que es un router que tiene conectividad celular. Así, esto lo que hace es convertir la
conexión celular a ethernet. Para los ensayos se ha utilizado un ordenador conectado
al CPE mediante ethernet que ejecute el juego en la nube a través del navegador
Google Chrome y obtener los parámetros QoE ofrecidos por WebRTC.
• Servidor. Ordenador donde se ha desarrollado el juego en la nube gracias a
Unreal Engine. El servidor se activa mediante la herramienta ofrecida por UE,
Pixel Streaming, que permite transmitir una aplicación Unreal Engine desde un
ordenador a otros dispositivos, es imprescindible que el juego este
ejecutándose para que el usuario pueda conectarse al juego en la nube
mediante WebRTC. Esta herramienta empaqueta el juego para ser transmitido
en un determinado puerto y que el cliente pueda disfrutarlo desde cualquier
dispositivo.

40
• RED UMA. Red que ofrece la conectividad al ordenador que actúa de servidor,
también a la red celular basada en software (Amarisoft), que permite el
despliegue de redes 4G y 5G.
• Amarisoft [AMARI Callbox Classic] [20]. Estación base con core real basada en
software. Ofrece soluciones asequibles y de alta calidad para el desarrollo de
redes 4G/5G permitiendo pruebas funcionales y de rendimiento de
dispositivos.
• CPE (Customer Premises Equipment). Es un router con conectividad celular.
• Cliente. Ordenador conectado al CPE, donde se realizarán las medidas de
velocidades y latencia del Cloud Gaming, para ello, se ha preparado un script de
Python [Véase Anexo C] para la automatización de las pruebas que ejecuta
remotamente el juego en el servidor y en el cliente a través del navegador
Google Chrome implementado un movimiento repetitivo desde el cliente para
observar cómo influye en las velocidades y las latencias.
Para un mejor análisis, se han usado diferentes configuraciones de potencia para
ambas redes realizando repetidas iteraciones para comprobar que los datos son
estadísticamente significativos.
5.2 Arquitectura
Durante la comunicación entre el cliente y el servidor, interactúan diferentes
protocolos:
Figura 5.2 Arquitectura del setup

41
Este conjunto de capas representa la comunicación entre un usuario del juego en la nube
y el servidor que lo ofrece, se exponen a continuación:
• PHY (Physical Layer): Primera capa, encargada de las conexiones físicas entre
dispositivos.
• MAC (Medium Access Control): Capa encargada del control el acceso al medio
de transmisión físico en las redes locales.
• RLC (Radio Link Control): Permite enviar los paquetes PDCP de forma fiable entre
eNB y el servidor.
• PDCP (Packet Data Convergence Protocol): Protocolo de convergencia de
paquetes de datos con la función principal de compresión del encabezado de los
paquetes IP.
• IP (Internet Protocol): Permite la interconexión de redes para el transporte de
paquetes de red.
• UDP (User Datagram Protocol): Consiste en un protocolo que establece
conexiones de baja latencia y tolerancia a perdidas entre aplicaciones en
internet.
• APP (Application): En este caso, se trata de la arquitectura del WebRTC. Esta
arquitectura se ha explicado en el capítulo anterior [Véase 3.3. Arquitectura
WebRTC].
Mediante el setup utilizado y los protocolos de comunicaciones ofrecidos por WebRTC
se ofrecen las condiciones idóneas para realizar las medidas QoE necesarias.

42
5.3 Medidas
En cada muestra se van a tomar las siguientes medidas:
INGLES ESPAÑOL
Red (Capa 1) PPrach PPrach
PPucch PPucch
PPusch PPusch
RSRP RSRP
RSRQ RSRQ
RSSI RSSI
Tráfico (Capa 3) Current Connect Time Tiempo de conexión en
curso
Total Connect Time Tiempo de conexión total
Current Download Velocidad de bajada en
curso
Current Upload Velocidad de subida en
curso
Current Download Rate Tasa de velocidad de
bajada en curso
Current Upload Rate Tasa de velocidad de
subida en curso
Total Download Velocidad de bajada total
Total Upload Velocidad de subida total
WebRTC (Capa 7) Bytes Sent Bytes enviados
Bytes Received Bytes recibidos
Frames Decoded Fotogramas
decodificados
Frames Received Fotogramas recibidos
Frames Dropped Fotogramas perdidos
Current Round Trip
Time
Tiempo de ida y vuelta en
curso
Total Round Trip Time Tiempo de ida y vuelta
total
Jitter Buffer Delay Retardo del búfer de
jitter
Jitter Buffer Emitted
Count
Recuento de emisiones
del búfer de jitter
Total Decode Time Tiempo de decodificación
total
Total Processing Delay Retardo de tratamiento
total
Tabla 5.1 Parámetros obtenidos durante los ensayos

43
Para una mejor comprensión de los parámetros, cabe conocer estas definiciones:
• PPRACH (Power Physical Random Access Channel): Potencia del canal físico de
acceso aleatorio.
• PPUCCH (Power Physical Uplink Control Channel): Potencia del canal de control
físico de velocidad de subida.
• PPUSCH (Power Physical Uplink Shared Channel): Potencia del canal físico
compartido de velocidad de subida.
• RSRP (Reference Signal Received Power): Medida del nivel de potencia recibido
de una red.
• RSRQ (Reference Signal Received Quality): Proporciona información sobre la
interferencia y la intensidad de la señal deseada.
• RSSI (Received Signal Stength Indicator): Medida de la capacidad de un
dispositivo para escuchar la señal de un punto de acceso o un router.
• Upload (Velocidad de subida): Velocidad con la que se envía información desde
el ordenador a Internet.
• Download (Velocidad de bajada): Velocidad con la que se envía información
desde el Internet al ordenador.
• Jitter Buffer: Se trata de un búfer de almacenamiento para guardar paquetes de
datos recibidos.
Durante la toma de datos, las configuraciones se ven afectadas por tres parámetros:
1. PRB (Physical Resource Block): Son los recursos radio disponibles en la red celular
que se despliega. Cuanto mayor sea su valor más recursos tiene para repartir
entre los usuarios. Durante nuestro ensayo, al contar con un solo usuario, este
recibirá más recursos por lo que tendrá una mayor tasa de transferencia de bits.
2. Gain: es la ganancia que se le introduce a la señal transmitida.
Las configuraciones son las siguientes:
Configuración No. PRB Gain (dB)
1 25 0
2 50 0
3 75 0
4 100 0
5 25 -10
6 50 -10
7 75 -10
8 100 -10
Tabla 5.2 Configuraciones utilizadas durante los ensayos
Realizadas las medidas, se ha obtenido todos los parámetros expuestos en 8
configuraciones diferentes para las redes 4G y 5G realizando, en cada una, 10 iteraciones
para garantizar los resultados y obtener un análisis más detallado del comportamiento.

44
5.4 Conclusiones
Gracias a los parámetros expuestos en las diferentes capas de la comunicación se
obtendrá un análisis completo de las métricas QoE entre las redes 4G y 5G. Para ello se
ha creado un entorno de trabajo para lograr automatizar y simular todas las pruebas
necesarias.

45
6 CAPÍTULO 6 . TOMA DE MEDIDAS
6 Capítulo 6 . Toma de medidas................................................................................. 45
6.1. Introducción..................................................................................................... 46
6.2. Parámetros Generales ..................................................................................... 47
6.3. Velocidad ......................................................................................................... 51
6.4. Latencia............................................................................................................ 55
5.2. Conclusiones .................................................................................................... 60
Sinopsis:
Los parámetros que más influyen en la calidad de servicio de un usuario son las latencias
y las velocidades tanto de subida como de bajada.
Para ello, se ha realizado los ensayos oportunos mediante la tecnología WebRTC en
diferentes configuraciones para obtener las métricas necesarias que expliquen el
comportamiento.

46
6.1. Introducción
Durante la toma de medidas, se han obtenido parámetros de WebRTC, de red y de
tráfico para la realización de un análisis completo del Quality of Experience (QoE) de
un usuario a la hora de conectarse al juego en la nube.
Figura 6.1 Comunicación entre dos dispositivos por WebRTC
Se hará un estudio apoyado por gráficas y por diagramas de caja para un mejor
entendimiento de los resultados.
Un diagrama de caja es un tipo de gráfico que resume una gran cantidad de datos en
seis medidas descriptivas.
Figura 6.2 Estructura de un diagrama de caja
Los parámetros durante la comunicación WebRTC se obtiene en un archivo .txt
mediante chrome://webrtc-internals que es una pestaña interna de Chrome que
contiene las estadísticas de las sesiones WebRTC en curso. Estos archivos se analizan
mediante Python para su depuración y representación de los valores más significativos
sobreponiendo las 10 iteraciones para tener un mejor conocimiento de la
comunicación.
Por otra parte, se obtendrán los parámetros del CPE en relación con el tráfico y la red,
estos datos se guardarán en un archivo .json [Véase ¡Error! No se encuentra el origen d
e la referencia.] y se analizarán mediante Python para conseguir las gráficas
necesarias.

47
A partir de estas herramientas, se obtendrán los parámetros de latencia y de velocidad
entre el cliente y el servidor para obtener información del rendimiento que tiene el
Cloud Gaming en las redes 4G y 5G.
Se ha dividido los parámetros obtenidos en 3 grupos para un mejor entendimiento del
comportamiento que sigue las diferentes configuraciones y una conclusión para
completar el análisis unificando todos los grupos.
6.2. Parámetros Generales
A continuación se van a presentar los parámetros generales obtenidos por WebRTC,
exponiendo en primera estancia los valores constantes para todas las configuraciones
para cada red:
Nombre en
inglés
Nombre en
español
Valor red 4G Valor red 5G Unidades
Upload
Bandwidth
Ancho de banda de
subida
20 20 MHz
Download
Bandwidth
Ancho de banda de
bajada
20 20 MHz
PPrach Potencia del canal
de acceso aleatorio
-5 -5 dBm
RSRP Potencia recibida
de la señal de
referencia
-58 -56 dBm
RSSI Indicador de fuerza
de la señal recibida
-51 -32 dBm
Tabla 6.1 Parámetros Generales obtenidos
La potencia de señal recibida de referencia (RSRP, Reference Signals Received Power)
obtenida nos indica que la señal para ambas redes es excelente.
El indicador de fuerza de la señal recibida (RSSI, Received Signal Strength Indicator) es
una medida de referencia para el nivel de potencia de las señales recibidas por un
dispositivo conectado a la red. Para ambas redes es excelente, pero la red 5G aporta una
mejora de cobertura.
Partiendo de la premisa de que para cada configuración se han realizado iteraciones casi
idénticas (hay que tener en cuenta un retraso mínimo a la hora de ejecutar el navegador
y el juego), se podrá analizar el comportamiento que sigue para cada red.
Los frames o fotogramas es una medición de la cantidad de imágenes que aparecen en
pantalla y crean una ilusión de movimiento. Por lo general, se decodifican todos los
frames recibidos pero hay ciertos casos para ambas redes donde se pierden algunos
fotogramas o no se logran decodificar.
Se realizará un análisis de un caso para cada red donde se haya descartado fotogramas
a la hora de decodificar.

48
Fotogramas recibidos red 4G: Fotogramas recibidos red 5G:
Gráfica 6.1 Fotogramas recibidos por la red 4G y 5G
En primera estancia cabe tener en cuenta los siguientes detalles:
• En la red 5G se obtiene una mayor cantidad de frames lo que permitiendo que
el juego vaya más rápido y fluido.
• Se observa que la duración del ensayo es diferente para cada red, esto se debe
que, a la hora de realizar un ensayo, se tiene que acceder al navegador,
conectarse al servidor WebRTC y ejecutar el juego en la nube, estas acciones
suponen un retraso a la hora de empezar la toma de medidas que es mayor para
la red 4G.
Fotogramas perdidos red 4G: Fotogramas perdidos red 5G:
Gráfica 6.2 Fotogramas perdidos por la red 4G y 5G
Como se ha comentado anteriormente, no es común pero hay algunas iteraciones donde
se han descartado frames debido a la congestión de la red, este fenómeno se produce
cuando una red ofrece más tráfico del que puede procesar. Este comportamiento
también se puede observar en los frames decodificados.

49
Fotogramas decodificados red 4G: Fotogramas decodificados red 5G:
Gráfica 6.3 Fotogramas decodificados por la red 4G y 5G
Los fotogramas decodificados mantienen una forma similar a los fotogramas recibidos,
pero se puede observar en la gráfica como se tuerce la muestra que, en ese mismo
instante, supone un descarte de frames para decodificar.
Aunque en la mayoría de los casos no hay perdidas de fotogramas durante la
comunicación entre el cliente y el servidor cabe tener en cuenta que en ciertos casos ,
debido a problemas de conexión, se pierden frames lo que significa que hay cortes de
video durante la transmisión del juego.
Para tener una mejor visión de la mejora de fotogramas decodificados entre la red 4G y
5G, se ha hecho una media de todos los datos obtenidos mediante las iteraciones de
todas las configuraciones, utilizandose boxplot para poder representarlo.
Diagrama de caja de los fotogramas decodificados:
Gráfica 6.4 Diagrama de caja de todos los fotogramas decodificados por la red 4G y 5G
Por lo que se puede observar, entre la red 4G y 5G hay una mejora en la cantidad de
fotogramas decodificados a lo largo de la transmisión del juego en la nube que es
directamente proporcional al tiempo de decodificación.

50
Diagrama de caja del tiempo total de decodificación:
Gráfica 6.5 Diagrama de caja del tiempo total de decodificación por la red 4G y 5G
Al observar que la red 5G transmite más fotogramas durante la transmisión del juego,
esto supone un mayor tiempo de decodificación con respecto a la red 4G. Este tiempo
es contrastado por el aumento de velocidad que supone la nueva red provocando una
disminución del tiempo de ida y vuelta de los datos.
Diagrama de caja del tiempo total de ida y vuelta:
Gráfica 6.6 Diagrama de caja del tiempo total de ida y vuelta por la red 4G y 5G
En la gráfica 6.6 se obtiene una media de la suma acumulativa de todas las mediciones
de tiempo de ida y vuelta en segundos desde el comienzo de la sesión entre el envío
de solicitudes STUN y la recepción de las respuestas durante la comunicación.
La red 5G tiene un menor tiempo de ida y vuelta provocado provocado por la mejora
de velocidad con respecto a la red 4G.
Se concluye esta primera parte del analisis confirmando la mejora de los parámetros
generales otorgados por WebRTC ofreciendo una mayor cantidad de fotogramas que
permiten que el jugador reciba una experiencia mas fluida de juego y una disminución
en los tiempos de ida y vuelta en el envío de solicitudes al servidor STUN.

51
6.3. Velocidad
Para este apartado, se tendrán en cuenta la velocidad de bajada y de subida
La velocidad de bajada (Download) es el tiempo que tarda la información en ser
transmitida al cliente desde el servidor, mientras que la velocidad de subida (Upload) es
la velocidad con la que un usuario transmite información al servidor.
En el juego diseñado [Véase Anexo B] implementando varios componentes en
movimiento que provocan una variación de ambas velocidades. En lo que se refiere al
Download, el juego cuenta con diferentes componentes en constante movimiento a
esto se le añade cuatro explosiones que provocan un pico de descarga de datos que se
analizará a continuación. Por otra parte, el Upload se verá afectado por el constante
movimiento automatizado de la cámara [Véase ¡Error! No se encuentra el origen de la r
eferencia.] por parte del cliente.
Para la explicación del análisis se utilizará la siguiente configuración (prbs= 100, gain= 0)
para ambas redes que luego se derivara a un análisis mas genérico de las velocidades de
bajada ofrecidas por todas las configuraciones.
Partiendo de la premisa de que todas las iteraciones de una configuración tiene el mismo
comportamiento se analizará la tasa de velocidad de bajada en curso medida en el CPE
(Current Download Rate) para las redes 4G y 5G.
Tasa de velocidad de bajada en curso red 4G: Tasa de velocidad de bajada en curso red 5G:
Gráfica 6.7 Tasa de download en curso por la red 4G y 5G
El comportamiento de la velocidad de bajada es el siguiente:
1. La velocidad se inicializa en 0 kbps al no transmitir datos desde el servidor.
2. Hay una primera pequeña subida de velocidad producida por el movimiento de
los componentes del juego.
3. Se logra el pico de la velocidad tras producirse la explosión, esto supone una gran
transmisión de datos por parte del servidor al usuario al producirse el
desplazamiento de muchos componentes en un instante de tiempo.

52
4. Vuelve a un valor constante por el simple movimiento de componentes.
Se confirma que las muestras obtenidas de una configuración tienen el mismo
comportamiento, aunque presenten diferentes picos y retardos.
A pesar de que el pico de velocidad de bajada es similar en ambas redes, se tiene que
tener en cuenta que para la red 4G solo se logra superar los 90000kbps en tres de las
10 iteraciones mientras que en la red 5G lo logra en todas las iteraciones, por lo que se
entiende que para la red 5G el Download es mas elevado y más estable.
Las iteraciones presentan cierto retraso que provoca que el pico se alcance en un tiempo
más tardío, para entender este comportamiento, se analizará el tiempo de ida y vuelta
de los datos.
Tiempo de ida y vuelta en curso red 4G: Tiempo de ida y vuelta en curso red 5G:
Gráfica 6.8 Tiempo de ida y vuelta en curso por la red 4G y 5G
Mediante la gráfica 6.8, se explican los siguiente sucesos:
1. En la red 5G, la muestra 4 alcanza el pico de la explosión con un retraso. Este
retraso también se ve en el tiempo de ida y vuelta de los paquetes que en
primeras estancias, la muestra presenta un tiempo de ida y vuelta elevado
provocando un retraso en los procesos desembocando en una explosión más
tardía en relacion a la demas iteraciones.
Aunque para la muestra 3, que también tiene un tiempo de ida y vuelta de los
paquetes elevado, la explosión se haya realizado en el mismo instante que las
demás iteraciones, se puede observar que para esta muestra, la primera subida
de velocidad de bajada que es provocada por el movimiento de los componentes
básicos sufre un retraso.
2. La red 4G, tiene un tiempo de ida y vuelta mucho menor que el 5G. Se observa
que las diferentes muestras sufren subidas y bajadas del tiempo de ida y vuelta
de los paquetes, provocando que las iteraciones tengan un retraso a la hora de
lograr el pico de la velocidad de bajada.
Analizando la muestra 6 que alcanza el mayor pico de velocidad de bajada,
cuenta con un tiempo de ida y vuelta de paquetes contante y menor.

53
Para finalizar el análisis de la velocidad de bajada, se ha generado un diagrama de caja
con todos los valores obtenidos por las iteraciones de la configuración escogida.
Diagrama de caja tasa de velocidad de bajada:
Gráfica 6.9 Diagrama de caja de todas las tasas de download de la red 4G y 5G
La velocidad de bajada por parte del servidor se concentra en valores pequeños,
producido por el movimiento de los componentes básicos, por otra parte, hay valores
críticos que representan los picos obtenidos por la explosión en el juego.
Para el analisis de la velocidad de subida, se utilizará la misma configuración.
Aunque para los usuarios, lo que más improta es la velocidad de bajada a la hora de
reproducir contenidos en Streaming y recibir datos, es esencial una velocidad de subida
alta para las acciones realizadas por el cliente tengan un menor retraso.
Se parte de la misma premisa de que todas las iteraciones siguen un comportamiento
igual por parte del usuario del juego en la nube.
Tasa de velocidad de subida en curso red 4G: Tasa de velocidad de bajada en subida red 5G:
Gráfica 6.10 Tasa de upload en curso por la red 4G y 5G
La velocidad de subida se ve afectada en el juego por las acciones:
1. El cliente carga el juego en el navegador e inicializa el WebRTC.
2. Tras un pequeño tiempo de espera, el cliente empieza a realizar movimientos de
cámara hacia la izquierda y la derecha repetivamente, lo que provoca un
aumento considerado de la velocidad de subida.

54
3. El movimiento es cíclico, con un pequeño tiempo de espera entre cada
desplazamiento.
Se mantiene un comportamiento similar entre las iteraciones, con la diferencia de
algunos picos que se consiguen a lo largo de la transmisión.
En esta caso, la velocidad de subida del 5G es menor que la del 4G, esto se puede deber
por la configuración 5G. Tiene modo duplexación TDD (duplexación en tiempo) lo que
puede provocar que tenga menos slots de upload asociados, y por lo tanto, la subida de
UL sea menor. Por otro lado, 4G está emitiendo en la banda 7, la cual es FDD
(duplexación en fecuencia) lo que significa que el DL/UL se transmiten por frecuencias
distintas, teniendo el mismo número de slots disponibles.
Los dos factores que más influyen en la velocidad de carga son el proveedor de servicios
de Internet (ISP) y el ancho de banda de Internet, aunque se puede deber a diferentes
razones:
• Saturación de la red.
• Aplicaciones en segundo plano utilizando ancho de banda
• Una mala configuración del firewall.
Según la Comisión Federal de Comunicaciones (FCC), se recomienda tener al menos 2
Mbps de velocidad de subida para tener una experiencia de juego decente. Se debe
tener en cuenta ciertos detalles producidos durante la tranmisión del juego en la nube:
1. Para la red 4G, la muestra 6 alcanza un buen pico de velocidad tanto de subida
como de bajada y lo mismo pasa para la muestra 7.
2. La muestra 4 de la red 5G presenta una velocidad de subida baja durante toda la
transmisión, cabe destacar que para esta iteración, se ha obtenido peores
resultados de velocidad de subida y de bajada. Mientras tanto la muestra 10,
ofrece un valor elevando para ambas velocidades.
Para finalizar el análisis de la velocidad de subida, se ha generado un diagrama de caja
con todos los valores obtenidos por las iteraciones de la configuración escogida.

55
Diagrama de caja tasa de velocidad de subida:
Gráfica 6.11 Diagrama de caja de todas las tasas de upload de la red 4G y 5G
Por lo que se puede analizar que durante la toma de datos, la red 4G ha obtenido
mayores velocidades de subida que la red 5G proporcionando al usuario una mejor
experiencia a la hora de realizar acciones y enviar información al servidor.
Se concluye la parte de las velocidades observando que para la red 5G, se ha podido
comprobar que la nueva generación de red logra una velocidad de bajada elevada y a
su vez estable, pero el en el caso de la velocidad de subida, no se ha podido conseguir
una mejora debido al modo duplexación TDD explicado anteriormente.
6.4. Latencia
La latencia o delay es simplemente el tiempo que tarda un paquete de datos en hacer
un viaje de ida y vuelta entre el transmisor y el receptor a través de la red, mientras más
alto sea la latencia más lento será el envío de datos en la nube. Para el Cloud Gaming,
es imprescindible que el delay sea mínimo para que el gamer tenga una excelente
experiencia del juego en la nube.
Durante la experiencia de juego, la latencia es muy importante para juegos que
requieran una reacción al instante debido a que cada milisegundo es fundamental.
Se va a observar el comportamiento de la latencia durante la transmisión del juego en
la nube mediante los parámetros ofrecidos por WebRTC.

56
Retardo del búfer de jitter red 4G: Retardo del búfer de jitter red 5G:
Gráfica 6.12 Retardo del búfer de fluctuación de la red 4G y 5G
El Jitter Buffer o búfer de fluctuación se utiliza para contrarestar la latencia y paquetes
descartados. Almacenan temporalmente los paquetes de datos que llegan para
minimizar la inestabilidad y descartar los paquetes que llegan demasiado tarde.
El parámetro JitterBufferDelay proporciona información sobre el rendimiento de la red
y su influencia en la fluidez de la reproducción. Este retardo define la cantidad de tiempo
en segundos que los fotogramas de vídeo pasan en el búfer de fluctuación antes de ser
decodificados por lo que un retardo mayor supondría que la red está muy
congestionada.
La gráfica 6.12 nos presentan el valor acumulado de los retardos del búfer de fluctuación
para ambas redes, donde se puede observar que para la red 4G se alcanza mayores
valores de latencia que la red 5G. También se debe tener en cuenta que para la red 5G,
las iteraciones mantienen un desarrollo similar.
Esta métrica aumenta con las muestras o fotogramas que salen, habiendo completado
su tiempo en el búfer (e incrementando jitterBufferEmittedCount).
Para explicar el comportamiento de la muestra 5, al tratarse de una elevada latencia del
búfer, hay que analizar el comportamiento de los fotogramas recibidos.

57
Fotogramas recibidos red 4G:
Gráfica 6.13 Fotogramas recibidos de la red 4G
Se puede observar que el desajuste proviene desde el envío de fotogramas por lo que
se podría confirmar que el aumento de fotogramas es proporcional al aumento del
retraso del búfer de fluctuación que a su vez, es proporcional al recuento de emisiones
del búfer de fluctuación.
Contador búfer de fluctuación red 4G: Contador búfer de fluctuación red 5G:
Gráfica 6.14 Recuento emitido por el búfer de fluctuación de la red 4G y 5G
El parámetro JitterBufferEmittedCount es el número total de cuadros de video que han
salido del búfer de fluctuación.
Mediante la gráfica 6.14, se confirma que es proporcional al retardo del búfer de
fluctuación a través de los siguientes detalles:
1. En la red 4G, la muestra 5 tiene el mismo comportamiento anómalo a las gráficas
de retardo de búfer y fotogramas recibidos.
2. En la red 5G, la muestra 1 alcanza el valor más pequeño al igual que en el búfer
de fluctuación.
Por otra parte, se va a analizar otro parámetro importante de latencia, se trata del
retardo total de procesamiento.

58
Retardo total de procesamiento red 4G: Retardo total de procesamiento red 5G:
Gráfica 6.15 Retardo total de procesamiento de red 4G y 5G
El parámetro TotalProcessingDelay es la suma del tiempo, en segundos, que se toma
para cada cuadro de video desde el momento en que se recibe el primer paquete RTP
(Reception TimeStamp) hasta el momento en que se decodifica el cuadro
correspondiente.
Esta métrica no incrementa cuando los fotogramas no se codifican, por lo que
utilizaremos las gráficas de fotogramas perdidos para entender el comportamiento de
este parámetro.
Fotogramas descartados red 4G: Fotogramas descartados red 5G:
Gráfica 6.16 Fotogramas perdidos de la red 4G y 5G
Para ambas redes, se observa que la muestra 1 ha descartado 13 fotogramas lo que
provoca que que el retardo total de procesamiento sea menor al nos procesarse estos
frames. Esto confirma que ambos parámetros son inversamente proporcionales, por lo
que cuanto mayor sea la cantidad de fotogramas descartados menor sera el retardo
total de procesamiento durante el juego.
Aunque por lo general se busca disminuir el retardo, el parametro total processing delay
proporciona la información para conocer si se han perdidos fotogramas durante la
transmisión del juego.
Finalmente se ha analizado todos los valores obtenidos a partir de las diferentes
configuraciones juntandolos y representandolos mediante un diagrama de caja

59
Diagrama de caja retardo total de procesamiento:
Gráfica 6.17 Diagrama de caja del retardo total de procesamiento de la red 4G y 5G
A partir de la gráfica 6.17, se puede confirmar que en al red 4G se descartan mas
fotogramas lo que provoca un menor retardo total de procesamiento.
Se concluye el apartado de la latencia afirmando que la red 5G aporta beneficios a la
hora de transmitir el juego, obteniendose latencias más bajas en las diferentes
configuraciones en relación a la red 4G.
La importancia de la latencia hace que muchas empresas investiguen en mejoras del
sistema para lograr proporcionar al jugador una experiencia completa.

60
5.2. Conclusiones
A partir de esta investigación, se entiende mejor cómo actúa el Cloud Gaming mediante
la tecnología WebRTC y la importancia que tiene tanto la velocidad como la latencia.
Mediante las medidas obtenidas por la red 5G, hay una mayor estabilidad con respecto
a la red 4G a la hora de transmitir información. Cuanto mayor estabilidad tenga la red,
menos perdidas de fotogramas se produce, por lo que el juego en la nube se percibirá
sin cortes, logrando que el usuario tenga una experiencia muy buena de juego.
Esta estabilidad se ve favorecida adicionalmente por un aumento de la velocidad de
bajada que permite al usuario recibir una mayor cantidad de fotogramas por parte del
servidor. El aumento de frames hace que el juego en la nube con mayor fluidez logrando
una mayor inmersión en el juego.
La inmersión, que forma parte de la calidad de experiencia, es la capacidad del juego en
provocar que el jugador se vea envuelto en el mundo virtual, mediante contantes
interacciones.
Aunque no se hayan obtenido los resultados deseados para la velocidad de subida, se
espera que para futuros trabajos con una mejor implementación de la red 5G y el
desarrollo de WebRTC se alcancen valores óptimos logrando latencias mínimas.
La configuración que mejor ha respondido a la hora de simular el entorno Cloud Gaming
es el siguiente:
PRB = 100, Gain = 0 dB
Es un resultado lógico tratándose de que se está entregando una mayor cantidad de los
recursos disponibles de la red al usuario.

61
7 CAPÍTULO 7. CONCLUSIÓN
A lo largo de esta investigación, se ha realizado un recorrido a lo largo de la evolución
de las redes y del Cloud Gaming.
Se ha diseñado un juego en la nube mediante Unreal Engine, desde cero, que provoca
una constante comunicación entre el servidor y el cliente a partir del cual se han extraído
métricas en red real. Estás métricas se han procesado y analizado mediante Python para
obtener gráficas que nos permiten comparar entre la red 4G y 5G.
Se observa una mejora con respecto a la red 4G y aunque se logren condiciones
favorables al usuario para disfrutar de los juegos en la nube se puede seguir mejorando
para lograr una calidad de experiencia óptima.
Debido a la transmisión estable de la red 5G, se aportará grandes beneficios para el
Cloud Gaming gracias a la mejora de velocidad que desemboca en una disminución de
la latencia.
Aunque no es posible lograr una latencia nula ya que siempre habrá un tiempo de
procesamiento o de envío de información, las empresas siguen investigando para
mejorar las condiciones de la red y que la arquitectura de la nube sea lo más ideal.
En un futuro, el Cloud Gaming alcanzará una importancia inmensa lo que va a provocar
que las personas ya no dispongan de juegos físicos, sino que mediante suscripción
tendrá acceso a todo tipo de juego al momento y con una latencia mínima guardándose
toda la información en la nube.
Este hecho hace que ya todas las grandes empresas del sector gaming dediquen parte
de su investigación en el Cloud Gaming.
Un entorno de nube virtual bien organizado permite reducir los retrasos en los juegos
en la nube, por eso Google predice mejoras en la tecnología que darán como resultado
juegos basados en una nube más rápida y con mayor capacidad de respuesta, llegando
incluso a sugerir que los juegos se ejecutarán más rápido en línea que si se jugaran
localmente.
Se espera que para el 2030 se implementará la sexta generación de red, 6G, que
permitirá al Cloud Gaming convertirse en un sector principal de gaming reduciendo la
latencia a la décima parte.

62
Trabajo Futuro
Estos avances del Cloud Gaming es solo un inicio, se espera que en los próximos años
haya bastantes mejoras por parte de las empresas, esto se debe a que es un campo de
investigación abierto y novedoso y con mucho recorrido en el futuro.
Después de los resultados obtenidos, quedan muchos frentes abiertos de cara a
próximos trabajos:
• Diseñar otro tipo de juegos
• Realizar les pruebas en más escenarios y en diferentes condiciones para conocer
cómo responde WebRTC.
• Obtención de más métricas durante la comunicación.
• Análisis del Cloud Gaming mediante otros protocolos de streaming para
comparar.
• Un estudio más en profundidad con más parámetros.
• A parte de los parámetros expuestos en este trabajo, WebRTC ofrece una gran
cantidad de parámetros que pueden ser analizados para conocer que provoca
las caídas de velocidad o la subida de retardo.
• Obtención de las métricas en todas las capas durante la comunicación entre el
servidor y el cliente lo que dará un amplio conocimiento al funcionamiento del
Cloud Gaming, permitiendo así, su mejora.
• Análisis de la estación base y realización de las pruebas para la velocidad de
subida
Aunque no se haya obtenido los resultados deseados para la velocidad de subida en la
red 5G, las demás métricas han sufrido una mejora confirmando que la red 5G va a
otorgar muchas mejoras para el Cloud Gaming.

Determining QoE metrics for Cloud Gaming in 5G

Determining QoE metrics for Cloud Gaming in 5G

Recommended

Recommended

More Related Content

Similar to Determining QoE metrics for Cloud Gaming in 5G

Similar to Determining QoE metrics for Cloud Gaming in 5G (20)

Recently uploaded

Recently uploaded (20)

Determining QoE metrics for Cloud Gaming in 5G