\subsection{Computación de niebla vehicular - Z. Ning et al.

\cite{Ning2019}}

Debido al crecimiento tecnológico y vehicular, se estima que para el año 2020 se alcanzará una
cantidad de 150 millones de carros conectados en las vías, de los cuales cada vehículo puede
generar aproximadamente 30 Terabytes de datos cada día. Con esto se conoce que el tráfico móvil
alcanzará la cifra de 360 exabytes en 2020, lo cual es 8 veces mayor que en el año 2015. Se conoce
que el IoT, en este caso, representado en la alta red vehicular que crece año tras año y la cual se
requiere administrar con el fin de optimizar el tráfico vehicular de las ciudades, requiere un alto
procesamiento de datos, pero a la vez una baja latencia en las respuestas, en otras palabras,
requiere una administración de la red vehicular en tiempo real. Para lograr el anterior objetivo el
autor Z. Ning y su grupo, proponen el uso de la tecnología conocida como Fog Computing
(computación en la niebla), siendo esta un complemento para el conocido Cloud
Computing(computación en la nube). Esta tecnología al contrario del Cloud computing, se basa en
una infraestructura descentralizada y distribuida, esto brinda varios beneficios como: baja latencia
en las respuestas debido a la corta distancia entre servidores y usuarios, procesamiento paralelo
de datos, alta seguridad, eficiencia energética, entre otros \cite{NatalliaSakovich2018}. Estos
autores proponen un modelo de tres capas, el cual puede observarse en el gráfico
\ref{grafico:FogTresCapas}, para la implementación de esta tecnología, esas son: Capa cloud, Capa
cloudlet y capa fog.

\newline

La capa cloud está compuesta por un servidor manejador de tráfico y una tercera autoridad
confiable, es usado para realizar un monitorio a nivel de ciudad e informar a los manejadores de
tráfico la toma de acciones. Además, esta es una capa separada de los vehículos para de esta
forma evitar la sobrecarga de conexiones.

\newline

La capa cloudlet es la que se encarga de recibir los datos generados por los vehículos, procesarlos
y si son datos de importancia enviarlos a la capa cloud. Una ciudad debe dividirse por regiones de
impacto, en las cuales, en su centro debe existir dispositivos de cloudlet que son los encargados de
la gestión de los datos subidos por los vehículos. Esta capa se compone de dispositivos de red
como Gateway, routers y puntos de acceso.

\newline

La capa fog consiste en las redes de vehículos conectadas a las redes inalámbricas de
comunicación de largo alcance. La información generada por los vehículos puede ser procesada
para tomar decisiones a nivel de red vehicular o subida a la capa de fog para procesamiento. Se
utilizan los vehículos estacionados o en movimiento para la formación de los nodos de la capa fog
y mediante el uso de RSU en las vías, se decide si estos son procesados en la capa cloudlet o en la
capa fog.

\newline
La arquitectura presentada se enfoca en manejo del tráfico vehicular y la seguridad vial. Los
eventos que se registran son del tipo: trancones de tráfico, accidentes vehiculares y daños viales.
Dicha información es procesada mediante el uso de la capa fog o la capa cloudlet (se usa si la capa
fog no es capaz de procesarlos). Luego estos datos se suben hacia el servidor manejador de tráfico
en la capa de cloud la cual envía un mensaje de multidifusión a todos los vehículos anunciando las
nuevas actualizaciones del manejo de tráfico. Esta arquitectura presenta como su principal
mejora, la disminución del tiempo de respuesta del servidor al balancear la carga de
procesamiento entre todos los nodos de las capas fog y cloudlet.

\newline

La eficacia de este modelo se evaluó mediante los resultados de una prueba realizada en la ciudad
de Shanghái, China. Lugar donde se hizo uso de los RSU ubicados en el centro de dos sub-distritos,
Putuo y Huangpu. Se recolectaron las rutas de 1000 taxis incluyendo ubicaciones de GPS,
direcciones, velocidades y tiempos récord. Dicha información se recopiló cada 10 minutos de viaje,
además, se conoce que hay entre 200 y 600 vehículos parqueados o en movimiento por segundo
en cada RSU. Para la comparación del modelo se usó una estrategia aleatoria de balance, con el fin
de maximizar la carga de trabajo procesadas por los vehículos estacionados y en movimiento. Se
obtuvo como resultado que el modelo propuesto fue más eficiente en el tiempo de respuesta que
la estrategia aleatoria, reduciendo el tiempo de respuesta de 4.2s a 0.6s, esto es debido a que la
arquitectura propuesta puede balancear la carga de procesamiento de una forma eficiente.