Resumen BEREC – Draft Net Neutrality Regulatory Assessment Methodology

Principalmente en el documento nos debemos centrar en el punto 3., el cual se nos habla
brevemente sobre el 5G:

En el capítulo 3, el objetivo de este capítulo es describir una metodología recomendada para

medir la calidad de las NIC basada en el objetivo combinado de maximizar la precisión de las
mediciones en equilibrio con la necesidad de poder facilitar el acceso del público a la
herramienta de medición, garantizando que los resultados de las mediciones sean
comparables entre los distintos Estados miembros. Los resultados de estas mediciones
también pueden utilizarse para los siguientes fines:

- Permitir al usuario final validar los compromisos adquiridos con su proveedor de NIC;

- Supervisar la calidad general de las NIC para apoyar la confirmación de que el

rendimiento de las NIC se está desarrollando suficientemente a lo largo del tiempo,
teniendo en cuenta la evolución tecnológica (véase el capítulo 6);

- Las ANR también pueden utilizar los datos para aumentar la transparencia (por
ejemplo, mapas interactivos que muestren el rendimiento en una zona geográfica);

- Apoyar la detección de la priorización del tráfico y/o la estrangulación de aplicaciones

seleccionadas en comparación con otras aplicaciones que se ejecutan a través de la
NIC (véase el apartado 4.2).

De acuerdo con el párrafo 166 de las Directrices OI del BEREC [3], "las mediciones deben
realizarse más allá del tramo del ISP" y la velocidad debe calcularse "basándose en la carga útil
del protocolo de la capa de transporte". Además, el párrafo 140 dice que "[l]as velocidades
deben especificarse sobre la base de la carga útil del protocolo de la capa de transporte, y no
sobre la base de un protocolo de capa inferior".

La metodología descrita aquí está orientada a la medición de la calidad de la NIC tanto en el

sentido de subida como de bajada. Cabe destacar que la velocidad de la NIC (apartado 3.1) es
sólo un componente del rendimiento experimentado por los usuarios finales, ya que las
distintas aplicaciones tienen diferentes requisitos relacionados con el retraso de la NIC, la
variación del retraso (apartado 3.2) y la pérdida de paquetes (apartado 3.3).

Para las tareas de medición que afectan tanto a la NIC en su conjunto como a las aplicaciones
individuales que utilizan la NIC, la condición previa fundamental es que las mediciones se
realicen en el borde de la red que proporciona la NIC (es decir, el módem para el acceso fijo o a
través del acceso radioeléctrico para la NIC móvil). También hay que tener en cuenta que en
algunos tipos de red es necesario asignar recursos antes de que esté disponible todo el ancho
de banda y que el periodo de tiempo en el que se produce la asignación de recursos puede
percibirse como una fase de reducción del ancho de banda y, por tanto, de la calidad. En
algunas redes más antiguas (como las redes móviles 2,5G/3G), esta fase de asignación de
recursos puede durar varios cientos de milisegundos y, por tanto, repercutir en la calidad
medida. Este comportamiento transitorio puede registrarse o descartarse en función del
objetivo de la medición.

Cuando las mediciones se realicen con un servidor de pruebas, este servidor deberá estar
situado fuera de la red del SAI. Debe haber una conectividad adecuada entre el servidor y el

1
proveedor de la NIC para minimizar cualquier influencia en las mediciones. Por lo general, esto
puede lograrse ubicando el servidor de medición en el punto nacional de intercambio de
Internet (IXP) o cerca de él. Dependiendo de la situación nacional específica, los servidores de
medición pueden estar ubicados en más de un IXP 1. También podría haber razones específicas
que deberían evaluarse, para su ubicación en otro lugar. El hardware que ejecuta el servidor
de medición debe estar conectado lo más cerca posible del conmutador del IXP, para
minimizar la latencia añadida debido a las vías de comunicación. Esto significa que el número
de saltos entre el conmutador principal del IXP y el servidor de pruebas debe mantenerse al
mínimo. Esto es aplicable tanto si la implementación se ejecuta dentro de la red de un
proveedor de alojamiento como si lo hace directamente en el hardware bajo control de la
propia ANR.

Dado que el tráfico de prueba es tráfico de Internet, el ORECE recomienda que las ANR se
aseguren de que el tráfico de medición se gestiona de forma equitativa al resto del tráfico.

En los casos en que tanto el servidor como el cliente tienen visibilidad de los resultados de las
pruebas (por ejemplo, mediciones de velocidad), generalmente se considera que el receptor
de los datos es la fuente autorizada de los resultados de las mediciones, pero se recomienda
que tanto las mediciones del cliente como las del servidor se almacenen para su análisis.

En muchos casos, el resultado principal de una medición (por ejemplo, la velocidad de

descarga/carga (en bit/s), la latencia (en ms) o la pérdida de paquetes (en porcentaje)) es el
que se proporciona al usuario final. Sin embargo, a menudo es conveniente que se registre un
mayor nivel de detalle del que se muestra al usuario final.

Los mecanismos de supervisión deben mitigar, en la medida de lo posible, los factores de

confusión que son internos al entorno del usuario final. Algunos ejemplos de estos factores
son el tráfico cruzado existente y el uso de interfaces basadas en Wi-Fi. Este tema se trata por
separado en el capítulo 5. La evaluación de los resultados de las mediciones se trata con más
detalle en los capítulos 6 y 7. El mecanismo de control certificado se trata con más detalle en el
capítulo 8.

En el punto 3.1.1. se nos habla de la metodología general de la medición de la velocidad, algo

que incumbe a la implantación del 5G, una red más rápida que el 4G y que influirá en el
Internet de las Cosas:

El ORECE ha basado este trabajo de metodología de medición en los siguientes requisitos de la

NRA para las mediciones de la NIC, en particular las mediciones de velocidad, en un contexto
normativo:

- Multiplataforma: cuando una medición de velocidad es iniciada por un usuario final

humano, debe ser posible ejecutarla a través del equipo que habitualmente utiliza
para acceder a la NIC. Ninguna restricción artificial en la metodología debe impedir
que la medición se ejecute en otro hardware, como consolas de juegos/clientes de
módem/cajas de televisión, etc.
1
Si bien la calidad general del acceso a Internet se caracteriza mejor de la forma descrita, algunos
puntos finales específicos de Internet pueden tener una calidad diferente y, por tanto, justificar
mediciones adicionales. Dichos puntos finales pueden ser redes de distribución de contenidos (CDN)
específicas o algún punto final en el borde (implementando el amplio concepto de computación de
borde que se menciona a menudo en el contexto de la 5G). La instalación de componentes de servidores
de medición en estos puntos finales específicos podría ser difícil, ya que normalmente está bajo el
control de un tercero.

2
 - Los usuarios finales que midan su velocidad de NIC deben seguir siendo admitidos
dentro de un navegador web o dentro de la caja de arena restringida de una aplicación
en el dispositivo; la metodología no debe requerir ni prohibir la instalación de software
cliente para ordenadores personales.

- La medición de la velocidad resultante debe reflejar objetivamente la velocidad

disponible para el usuario final, que podría verse afectada por factores como la
pérdida de paquetes o la latencia.

- El tiempo requerido para ejecutar una medición de velocidad individual debe ser lo
suficientemente corto como para permitir que un usuario final complete una medición
sin frustración. La duración de la medición también debe tener en cuenta el volumen
de datos transferidos y hacerla transparente para el usuario final.

- Si bien se reconoce que cualquier aplicación de medición tendrá un límite

inferior/superior de velocidades por encima del cual se obtiene una precisión
aceptable, la metodología debe soportar las velocidades típicas disponibles en los
mercados pertinentes. En particular, la metodología debe estar preparada para
soportar las velocidades suministradas por las redes ópticas y 5G.

- La metodología debe soportar tanto IPv4 como IPv6.

- Aunque estos requisitos se centran principalmente en las mediciones de velocidad, se

consideran pertinentes para todas las mediciones de NIC en este capítulo.

Para maximizar la compatibilidad en un entorno real, se sigue recomendando medir las

velocidades de carga/descarga basándose en el tiempo de ejecución de un conjunto paralelo
de transferencias de datos controladas a través de HTTP(S). De este modo, la velocidad puede
medirse basándose en la carga útil del protocolo de la capa de transporte, como se indica en el
apartado 140 de las Directrices OI del BEREC [3].

Esta metodología está soportada por la más amplia gama de plataformas relevantes, y se
ajusta a los requisitos anteriores. Como tal, se considera un equilibrio adecuado entre las
exigencias de precisión, agnosticidad de la plataforma, facilidad de aplicación y transparencia.
Esta posición también está respaldada por el uso generalizado de HTTP(S) por parte de las
aplicaciones y servicios normales de Internet y, por tanto, refleja el uso típico de la NIC por
parte de los usuarios finales.

Para saturar la ruta que se está midiendo, generalmente se recomienda utilizar múltiples
conexiones de la capa de transporte durante una prueba de velocidad. El número de
conexiones puede establecerse en función de las características del trayecto (incluidas la
velocidad y la latencia estimadas). Esta estimación puede basarse en una prueba previa o en el
rendimiento estimado del servicio basado en otra información.

La prueba debe diseñarse de forma que la carga de procesamiento en el lado emisor y

receptor sea baja para permitir la medición precisa de las conexiones de alta velocidad incluso
en dispositivos con una potencia de cálculo limitada.

3
En aras de la transparencia y la facilidad de uso, el ORECE reconoce las ventajas de
proporcionar información provisional sobre la prueba, como la visualización de un gráfico que
ilustre una aproximación del rendimiento medido durante la duración de la prueba. Por ello, la
prueba se especifica de forma que permita registrar el progreso de la transferencia de datos en
cada conexión durante la prueba en intervalos de tiempo cortos (por ejemplo, 50-200 ms).
Esto puede lograrse registrando el progreso de la prueba en cada conexión a intervalos de
tiempo fijos o mediante la organización de una transferencia de bloques de datos de medición
de un tamaño determinado. En caso de que se utilice una implementación basada en bloques,
el tamaño del bloque (y, por tanto, la frecuencia de recepción de bloques) puede establecerse
en función de una prueba previa o del rendimiento estimado del servicio. Una consideración
de este diseño es la necesidad de controlar los recursos necesarios en los puntos finales para
procesar los datos recibidos.

El ORECE reconoce que las pérdidas de paquetes y las consiguientes retransmisiones de

paquetes tienen un impacto negativo en el rendimiento de los protocolos fiables de la capa de
transporte, en este caso el TCP (Protocolo de Control de Transmisión), y por lo tanto en la
velocidad de la NIC medida.

La metodología recomendada por el BEREC sigue unos cuantos pasos conceptuales, que se
describen a continuación. Estos pasos pretenden ser agnósticos de la versión exacta de
HTTP(S) utilizada (cuando sea aplicable), y de si las conexiones están actualizadas para usar
sockets web o no.