La qualité des services mobiles

L'Arcep mène régulièrement des enquêtes ayant pour objectif d'apprécier, sur une base comparative, la qualité des services mobiles offerts aux utilisateurs par les opérateurs mobiles. La qualité de service est mesurée en tenant compte des accords de mutualisation et d'itinérance passés avec d'autres opérateurs. Les résultats reflètent ainsi l'expérience réelle des utilisateurs.

L'enquête vise, au travers de mesures techniques réalisées sur le terrain, à refléter de manière parfaitement comparable la qualité des services mobiles proposés par les opérateurs. Elle ne vise pas à recueillir, par exemple au travers d'un sondage, la perception que pourraient avoir les abonnés de la qualité de bout en bout de ces services, qui peut dépendre de leur usage, du terminal et des applications utilisées. Elle ne vise pas non plus à mesurer la qualité de service de la relation client.

L'enquête vise à être représentative de l'usage des clients des quatre opérateurs mobiles, afin de permettre aux utilisateurs de comparer les services de ces opérateurs entre eux.

Le protocole de l’enquête annuelle d’évaluation de la qualité de service (QoS) des opérateurs mobiles vise à mesurer une qualité de service mobile représentative de l’expérience utilisateur. Les débits mesurés par l’Arcep peuvent être éloignés de ceux obtenus avec certains outils de mesure de débit grand public, qui relèvent la capacité du lien (le débit du tuyau qui relie le terminal à internet), alors que l’Arcep cherche à avoir un débit représentatif d’une utilisation d’internet. Les principales différences entre certains tests de débit grand public et le protocole Arcep sont détaillées ci-dessous :

• Mono-connexion : un test de débit mono-connexion (monothread) mesure le débit via une seule connexion, ce qui permet de remonter un débit représentatif d’une utilisation d’internet. En effet, la grande majorité des usages sur internet utilisent, à un instant donné, une seule connexion avec un débit important. Pour beaucoup de services sur internet, plusieurs connexions sont ouvertes, mais dans la grande majorité des cas, à un instant donné, une seule connexion à la fois est utilisée pour transférer la plupart des données. Par exemple, le transfert va commencer par la connexion « A », avant de basculer sur la connexion « B » puis à la « C » et enfin revenir à la connexion « A ». Il peut y voir des petits éléments qui sont transférés en parallèle, toutefois cela reste minoritaire et globalement, la plupart des usages sur internet sont proches du comportement d’une mesure de débit mono-connexion.
• Multi-connexions : un test de débit multi-connexions (multithread) mesure le débit en cumulant les débits de multiples connexions simultanées. On constate par exemple que de nombreux outils de mesure du débit effectuent un transfert sur 16 connexions simultanées. Ces multiples connexions permettent d’estimer le débit maximum du lien, mais ne sont pas à même de déceler certaines limitations de débit sur les connexions TCP. Ces limitations, qui impactent fortement une seule connexion TCP mais marginalement les connexions multiples en parallèle, peuvent être des pertes de paquets ou/et des saturations ou/et une latence trop importante.

Le choix de l’Arcep : En 2024, comme les années précédentes, le protocole de l’Arcep est mono-connexion afin d’être le plus représentatif des usages de la majorité des clients.

Les résultats des mesures de la QoS dépendent aussi des caractéristiques techniques des serveurs de test, et notamment de leurs algorithmes d’évitement de congestion. Ces algorithmes sont utilisés côté émetteur de données pour décider de la vitesse d’envoi des paquets. Cubic et BBR sont les deux algorithmes les plus utilisés côté serveur pour décider de la vitesse d’envoi des paquets. Déjà utilisé sur YouTube et google.com, BBRv3 améliore les performances de BBRv1 et devrait permettre une meilleure cohabitation avec Cubic, en ce qu'il permet un partage des liens avec ce dernier (BBRv1 a un problème d'équité des flux : sur un même lien où le débit est partagé, comme les fréquences d'un réseau mobile, les connexions BBR vont "prendre la place" des connexions Cubic).

Le choix de l’Arcep : Afin d’être toujours plus représentatif de la majorité d’Internet et suite à l’augmentation significative de serveurs utilisant l’algorithme d’évitement de congestion BBR, l’Arcep fait évoluer sa méthodologie.

• Avant 2022 : 100% des tests étaient réalisés avec l’algorithme d’évitement de congestion Cubic ;
• 2022 : 75 % des tests utilisent Cubic et 25 % BBRv1 ;
• 2023 : 62,5 % des tests (5 tests sur 8) utilisent Cubic et 37,5 % (3 tests sur 8) BBRv1 ;
• 2024 : 50 % des tests utilisent Cubic et 50 % BBRv1 ;
• 2025 : Le pourcentage Cubic sera réévalué, en fonction de la progression de BBRv1 et BBRv3.

Internet a évolué et est passé en quelques années d’un protocole HTTP (en clair et sur le port 80) au protocole HTTPS (en chiffré sur le port 443). Les tests dans les applications mobiles de test de débit sont encore majoritairement réalisés en HTTP. Le port utilisé n’est, pour certaines applications, ni le port 80, ni le port 443, ce qui pose le problème de la représentativité. L’Arcep pousse pour plus de transparence en demandant aux outils de mesure conformes au Code de conduite 2020 d’indiquer le port utilisé et le chiffrement ou non des flux de test de débit.

Le choix de l’Arcep : En 2024, comme les années précédentes, tous les tests du protocole de l’Arcep sont réalisés avec le protocole HTTPS sur le port 443.

La transition d’internet vers IPv6 est en cours et d’après le baromètre IPv6 Arcep 2022, 67 % des pages web les plus visitées (données sur le top 730 d’Alexa en France) sont accessibles en IPv6. Certains outils de mesure de débit ont choisi de ne proposer par défaut que des tests en IPv4, tandis que d’autres utilisent IPv6 dès que le serveur et le client ont une connectivité IPv6. L’Arcep incite à plus de transparence en demandant aux outils de mesure conformes au Code de conduite 2020 d’indiquer si les serveurs supportent le protocole IPv6.

Le choix de l’Arcep : En 2024, comme les années précédentes, le protocole de l’Arcep prévoit 50 % des tests réalisés en IPv4 et 50 % des tests réalisés en double pile (dual stack) IPv4/IPv6.

Le débit affiché par les outils de mesure de débit varie selon les outils :

• débit maximum, atteint sur une courte durée pendant le test ;
• débit en régime établi (le débit à la fin du test) ;
• débit moyen après avoir exclu la montée en débit (les premières secondes du test) ;
• débit moyen entre la demande d’un fichier et la réception du dernier paquet.

Afin d’accroitre la transparence sur cet aspect, l’Arcep demande aux outils de mesure qui se sont déclarés conformes au Code de conduite 2020 d’indiquer les indicateurs affichés à l’issue du test. Les outils de mesure doivent également indiquer la durée du test, lorsque le volume maximum n’est pas atteint, ou le volume maximum de données échangées (taille du fichier téléchargé).

Le choix de l’Arcep : le débit est calculé en intégrant l’ensemble des étapes, à savoir la résolution DNS, la connexion TCP, la mise en place d’une couche de chiffrement TLS et le transfert d’un fichier de 250 Mio. Le transfert s’arrête dès que le fichier est entièrement téléchargé ou après expiration d’un délai de 10 secondes. En cas de difficulté sur les étapes de requêtes DNS ou connexion au serveur, le test ne sera pas interrompu avant les 10 secondes.

L’Arcep utilise Ubuntu Server 22.04 LTS pour l’enquête QoS 2023 et 2024. L’enquête QoS 2022 utilisait déjà Ubuntu Server, mais en version 20.04 LTS. Ce choix permet d’être représentatif d’une partie de l’internet.

Le noyau Linux utilisé pour l’enquête QoS 2023 et 2024 est le « generic-hwe » (HWE pour « Hardware Enablement ») proposé dans Ubuntu 22.04 LTS afin de bénéficier d’un noyau récent.

Dans un souci de transparence, l’Arcep publie un document récapitulant les paramètres des serveurs utilisés pour l’enquête QoS mobile Arcep 2024 :

Paramètres des serveurs utilisés pour l’enquête QoS mobile Arcep 2023 :

2023 : communiqué de presse (publication le 26 octobre 2023) / L’Arcep publie les résultats de sa campagne de mesures 2023 : les indicateurs évoluent pour refléter au mieux la réalité des usages (débits par seuils et qualité des appels via une application de messagerie)
2022 : communiqué de presse (publication le 20 octobre 2022) / Publication des résultats de la campagne de mesures 2022 : la qualité de service mobile reste stable, en dépit d’une baisse des débits observée en 2022
2021 : communiqué de presse (publication le 19 novembre 2021) / Mesures de qualité de service mobile 2021 dans les lieux de vie, les transports (TGV et métros), et premières mesures de la qualité de service 5G.
2020 : communiqué de presse (publication le 8 décembre 2020) / Mesures de qualité de service mobile 2020 dans les TGV et métros, et nouvelles mesures d’acteurs tiers : communiqué de presse (publication le 11 mars 2021)
2019 : communiqué de presse (publication le 22 octobre 2019 - mis à jour le 28 novembre 2019)
2018 :  communiqué de presse (publication le 17 octobre 2018)
2017 : rapport / communiqué de presse (publication le 21 juin 2017)
2016 : rapport / communiqué de presse (publication le 12 juillet 2016)
2015 : rapport / communiqué de presse (publication le 30 juillet 2015)
2014 : synthèse / rapport / communiqué de presse
2012 : bilan 
2011 : rapport / communiqué de presse 
2009 - 2010 : rapport / communiqué de presse
2008 : rapport / communiqué de presse 
2007 : rapport / communiqué de presse 
2006 : rapport / communiqué de presse
2004 / 2005 : rapport / communiqué de presse
2003 / 2004 : rapport / communiqué de presse 
2002 : rapport / communiqué de presse
2001 : rapport / communiqué de presse
2000 : rapport / communiqué de presse 
1999 : rapport 
1998 : rapport
1997 : communiqué de presse

Les résultats détaillés des campagnes de mesure de la qualité de service mobile sont présentés sur l’outil cartographique monreseaumobile.arcep.fr, qui compare également la couverture des quatre opérateurs de réseaux mobiles métropolitains, et, depuis juillet 2018, des opérateurs d’Outre-mer.

L’Arcep les met également à disposition en open data, ouvrant ainsi la possibilité à tous les acteurs qui le souhaitent d’utiliser ces données, et de créer de nouveaux comparateurs de performance.

Sur internet, un serveur émetteur de données n’a pas de connaissance du débit disponible de bout en bout. Il est pourtant primordial d’émettre la bonne quantité de données : en envoyer à un débit trop élevé, c’est prendre le risque de saturer une connexion bas débit. En envoyer trop peu ne permet pas d’exploiter efficacement la bande passante des connexions fibre. C’est un algorithme d’évitement de la congestion qui va estimer la capacité du lien entre le serveur et le client, en se basant sur la latence et la perte de paquets. L’algorithme, la latence et la perte de paquets sont 3 facteurs cruciaux pour permettre la disponibilité d’un bon débit.

L’emplacement géographique est trompeur. Prendre le serveur géographiquement le plus proche de son domicile ne signifie pas que le serveur est proche d’un point de vue réseau et que la latence sera faible. Par exemple, un habitant de Nice peut penser pertinent d’utiliser un serveur hébergé dans sa ville. Toutefois, il est tout à fait possible qu’il soit nécessaire de passer par Paris pour joindre ce serveur si ce dernier n’est pas hébergé sur le réseau de son fournisseur d’accès à internet.

La latence influe sur la montée en débit et donc sur le débit moyen. La latence est moins importante pour les outils qui affichent le débit en régime établi.

La latence est le délai de transmission aller-retour d’une information sur le réseau.

La latence est liée à 3 facteurs :

1. La technologie d’accès à internet. Voici la latence typique (aller/retour) rajoutée par technologie :
   • La fibre FttH (technologies Gpon, XGS-Pon ou 10G-Epon) : < 1 milliseconde ;
   • Le réseau câble (Docsis 3.0) : entre 6 et 7 millisecondes ;
   • Le réseau 5G « standalone » : 1 milliseconde ; Le réseau mobile 4G : entre 15 et 30 millisecondes ;
   • Le réseau cuivre (technologies xDSL) : entre 5 et 45 millisecondes en fonction du paramétrage de « l’interleave 7 » pour protéger de la perte de paquets ;
   • Le réseau mobile 3G : entre 25 et 50 millisecondes ;
   • Le réseau mobile 2G : entre 100 et 200 millisecondes.
2. La distance de fibre optique. La latence aller-retour de la fibre optique est estimée à 1,2 ms de latence aller-retour pour 100 kilomètres de fibre¹. Il convient de noter que la fibre optique empruntée n’utilise généralement pas un chemin en ligne droite, comme le fait un faisceau hertzien.
3. Les mémoires-tampons (buffers), notamment en cas de congestion. Quand un lien reçoit plus de données qu’il ne peut en écouler, les paquets supplémentaires sont mis en attente dans une mémoire-tampon. Quand le buffer est plein, les paquets entrants supplémentaires sont supprimés. Le paramétrage de la taille des buffers dans les équipements télécoms est une opération complexe :
   • Si le buffer est trop petit, les paquets sont rapidement supprimés, sans que l’algorithme d’évitement de congestion arrive à déterminer la capacité disponible sur le lien. Les débits seront alors anormalement faibles.
   • Si le buffer est trop grand, l’algorithme d’évitement de la congestion peut ignorer que la liaison est encombrée. Il ne commencera à prendre des mesures correctives (diminuer le débit envoyé) qu’une fois que la mémoire-tampon déborde et que des paquets sont supprimés.

La bonne taille du buffer est ainsi la plus petite taille qui permet à l’algorithme d’évitement de congestion de comprendre où est la limite du débit du lien. Pour un lien de grande capacité agrégant les connexions de milliers d’utilisateurs, un buffer ne doit contenir que le strict minimum de données pour pouvoir remplir le lien pendant une saturation. Si le nombre d’octets du tampon ne descend jamais sous une certaine limite, alors cela veut dire qu’il est possible de diminuer le tampon d’autant. Ainsi on conserve les performances, tout en réduisant au maximum les latences de type « bufferbloat ».

^[1] Le calcul de la latence aller-retour de la fibre optique prend en compte la vitesse de la lumière au cœur de la silice, la longueur des love (surplus de câble dans les chambres télécoms) et la présence potentielle de bobines de compensation de la dispersion chromatique.

La perte de paquets se produit quand des paquets n’arrivent pas à destination. La perte est exprimée en pourcentage de paquets perdus par rapport aux paquets envoyés. Les deux causes de la perte de paquets sont :

• Un réseau fibre défectueux, une ligne ADSL bruitée ou un réseau sensible aux interférences (c’est notamment le cas des réseaux sans fil -Wi-Fi, 4G, 5G, etc.) peut entrainer des pertes de paquets. Une interférence ou un signal trop affaibli peut entraîner la corruption ou la perte des paquets en transit. La perte de paquets est mesurée par le BER (Bit Error Rate). Il est normal qu’un réseau Wi-Fi perde des paquets, 0,1% de paquets perdus est typiquement acceptable. Une connexion ADSL peut également perdre des paquets si la ligne est bruitée et que l’interleave est réduit. Le manque de fiabilité du réseau peut également être dû à un matériel endommagé, à un bogue logiciel ou à un câble de mauvaise qualité.
• Une congestion réseau qui peut entraîner des pertes de paquets. Une fois la mémoire-tampon (buffer) remplie, les paquets entrants supplémentaires sont supprimés. C’est un mécanisme sain en cas de congestion, conserver trop de paquets dans le buffer entraînant du « bufferbloat ».

Ces algorithmes sont utilisés côté émetteur de données pour décider de la vitesse d’envoi des paquets. Il existe de nombreux algorithmes d’évitement de congestion et ces algorithmes évoluent.

Cubic et BBR sont les deux algorithmes les plus utilisés côté serveur pour décider de la vitesse d’envoi des paquets.

• Cubic, créé en 2006, s’appuie sur la perte de paquets comme signal pour réduire le débit. Cubic est l’algorithme d’évitement de congestion utilisé par défaut sous Linux (qui équipe la majorité des serveurs sur internet), mais aussi Android et macOS.

• BBR : Google a développé en 2016 BBR (pour « Bottleneck Bandwidth and Round-trip propagation time »), qui utilise un modèle différent, s’appuyant sur la bande passante maximale et le temps d’aller-retour (RTT ou « round trip time »). Cette approche permet à BBR, quand une connexion perd des paquets, de proposer un débit nettement plus élevé que ceux offerts par les algorithmes s’appuyant sur la perte de paquets, comme Cubic. Aujourd’hui, BBR est de plus en plus utilisé par certains grands acteurs de l’Internet, notamment sur les serveurs proposant HTTP/3, la nouvelle norme HTTP de troisième génération. Cependant, BBR n’est pas encore généralisé sur internet, notamment en raison de problématiques d’équité des flux. En effet, sur un même lien où le débit est partagé entre utilisateurs (exemple : les fréquences du réseau mobile ou un lien fibre), les connexions BBR vont « prendre la place » des connexions Cubic. Une version « BBRv2 » sera finalisé en 2023. Déjà utilisé sur YouTube et google.com, BBRv2 améliore les performances de BBR et devrait permettre une meilleure cohabitation avec Cubic, en ce qu’il permet un partage de liens avec ce dernier.

Part des algorithmes de contrôle de congestion déployés par nombre de sites web, dans le Top 20 000 Alexa² :

Les algorithmes reposant sur la perte de paquets (comme Cubic) sont légèrement plus utilisés que ceux utilisant la bande passante maximale (comme BBR et BBRv2).

^[2]Source Ayush Mishra, IETF 109 du 20 novembre 2020. Mesures réalisées entre juillet et octobre 2019 depuis des serveurs localisés à Singapour, Bombay, Paris, Sao Paulo et Ohio.

Les tests présentés ci-dessous ont été réalisés par les services de l’Arcep en environnement « contrôlé » : un serveur mis en place pour l’occasion est dédié aux tests et relié directement au client par un câble Ethernet à 1 Gbit/s de 2 mètres. La latence et la perte de paquets sont rajoutées avec le logiciel NetEm, intégré au noyau Linux. Le protocole suivi est celui des campagnes de mesure de la QoS mobile de l’Arcep : un fichier de 250 Mio³ (fichier utilisé pour l’enquête QoS mobile 2023) est téléchargé en HTTPS avec un serveur Ubuntu 22.04. Le test est arrêté une fois les 250 Mio atteints, ou après expiration du délai de 10 secondes, conformément au protocole QoS mobile 2023.

L’Arcep a réalisé plus de 58 000 tests, en faisant varier la latence, les pertes de paquet et l’algorithme d’évitement de la congestion.

Détails des tests réalisés (ods - 5.75Mo) (fichier au format OpenDocument, lisible dans un tableur).

^[3] Mio, symbole d’unité du mébioctet valant 1024 Kio (Kibioctet) = 1024 x 1024 octets, soit 1 048 576 octets. Un Mo (mégaoctet) vaut 1000 Ko soit 1 000 000 octets.

Cette latence extrêmement faible se rencontre principalement en entreprise, quand clients et serveurs sont sur le même site.

On note que le débit avec l’algorithme d’évitement de congestion Cubic baisse significativement par rapport à BBR à partir de 0,2 % de perte de paquets.

Débit en fonction de la perte de paquets pour une latence aller-retour de 4 millisecondes.
Cette latence se rencontre principalement sur les réseaux FttH, quand le client et le serveur sont dans la même région et que le client est sur le même réseau que le serveur (ou que l’interconnexion entre les deux réseaux se fait également dans la région. Cela concerne essentiellement les Parisiens qui utilisent un serveur parisien, via une interconnexion située en région parisienne).

On note que le débit avec l’algorithme d’évitement de congestion Cubic baisse significativement par rapport à BBR à partir de 0,05 % de perte de paquets et passe sous les 100 Mbit/s quand on dépasse 1 % de paquets perdus.

Cette latence se rencontre principalement sur les réseaux FttH, quand le client et le serveur traversent plusieurs régions. Par exemple, la latence peut être de 16 millisecondes pour un client situé en région Auvergne-Rhône-Alpes qui utilise un serveur situé à proximité de son domicile, si le réseau du serveur est interconnecté avec celui du client à Paris. Le trajet réalisé peut être « client » ⇒ « Lyon (réseau du client) » ⇒ « Paris (réseau du client) » ⇒ « point de peering » ⇒ « Paris (réseau du serveur) » ⇒ « Lyon (réseau du serveur) » ⇒ « Serveur ».

On note que le débit avec l’algorithme d’évitement de congestion Cubic baisse significativement par rapport à BBR à partir de 0,05 % de perte de paquets. Le débit avec 0,5 % de perte de paquets est limité à 55 Mbit/s avec Cubic, contre 840 Mbit/s avec BBR.

Cette latence se rencontre principalement sur les réseaux 4G avec un serveur proche, ou sur le FttH, quand le serveur est situé hors de France (mais en Europe).

Le débit avec 0,5 % de perte de paquets est limité à 44 Mbit/s avec Cubic, contre 759 Mbit/s avec BBR.

Cette latence se rencontre principalement sur les réseaux 4G, quand le serveur est situé hors de France (mais en Europe).

On note que le débit avec l’algorithme d’évitement de congestion Cubic baisse significativement par rapport à BBR à partir de 0,02 % de perte de paquets et passe sous les 100 Mbit/s quand on dépasse 0,3 % de perte de paquets.

Cette latence se rencontre principalement sur les réseaux 4G, quand le serveur est situé outre-Atlantique.

Le débit n’est plus que de 9 Mbit/s s’il y a 0,5 % de perte de paquets avec Cubic.

Une perte de paquets de 0,1 % peut facilement se rencontrer sur un réseau Wi-Fi et une perte de 1 % sur un réseau qui subit une congestion.

On voit que l’impact sur le débit dépend fortement de la latence et de l’algorithme d’évitement de congestion.