XR et métavers : pourquoi la 5G ne suffit pas et pourquoi la 6G est nécessaire

L'arithmétique de latence qui brise la 5G

La réalité virtuelle confortable a une contrainte physiologique non négociable : les photons atteignant les yeux de l'utilisateur doivent se mettre à jour dans les 20 millisecondes environ qui suivent tout mouvement de tête, le confort s'améliorant nettement en dessous de 10 ms. Ce budget total couvre toute la chaîne — les capteurs échantillonnent la pose de la tête, la scène est rendue, la trame est encodée, le lien sans fil la livre, le casque la décode et l'affiche. Chaque maillon de la chaîne grignote des millisecondes.

Sur un casque filaire, le lien sans fil est nul et le budget est confortable. Sur un casque standalone qui rend localement, le budget l'est aussi, mais l'appareil doit porter le poids du GPU et de la batterie. La classe intéressante — celle dont dépend le métavers — est le casque sans fil qui décharge le rendu vers un serveur edge. Cela place le réseau d'accès radio sur le chemin critique, et une cellule 5G NR ajoute 5-10 millisecondes de latence dans les déploiements typiques. Retirez cela d'une cible de 10 ms et il reste moins de 5 ms à toute la chaîne calcul-affichage. Même avec les meilleurs pipelines de rendu edge, c'est trop serré.

La 6G vise 1-3 ms de latence RAN par sens. Cette marge est ce qui rend l'offload XR sans fil viable pour la première fois sans recourir à du matériel dédié co-localisé.

Le problème d'uplink dont personne ne parle

L'essentiel des discussions sur les exigences réseau de la XR se concentre sur le downlink — la scène rendue streamée vers le casque. Mais les casques XR modernes génèrent un trafic uplink énorme que la 5G n'a pas été architecturée pour porter. Les caméras de tracking inside-out à 60-90 fps, les flux eye-gaze à 120 Hz, la pose des mains, la pose du corps, les données IMU et de plus en plus des données biométriques telles que les expressions faciales et l'état physiologique, tout cela retourne vers le serveur edge. Un seul utilisateur peut facilement générer 100-200 Mbps d'uplink soutenu.

Les configurations TDD de la 5G sont biaisées vers le downlink, typiquement 4:1 ou 7:3 en faveur du downlink. Ajouter de la capacité uplink suppose soit de reconfigurer le motif TDD (au prix du débit downlink), soit de passer sur des bandes FDD où le spectre est fragmenté et à fréquence plus basse. Aucune de ces deux options ne passe à l'échelle pour des déploiements XR denses.

La 6G traite cela par un duplexage flexible — y compris le full duplex sur la même fréquence pour les petites cellules — et par des porteuses dédiées biaisées vers l'uplink dans les bandes sub-térahertz, où la largeur de bande étendue rend l'asymétrie moins douloureuse.

Pourquoi le calcul edge doit vivre dans le RAN

Le réflexe naturel quand une application réclame une faible latence est « mets-le sur le edge ». Pour la XR, le edge doit être beaucoup plus proche que ce que permettent les déploiements MEC actuels. Un aller-retour depuis l'appareil de l'utilisateur, en passant par un point d'agrégation urbain, jusqu'à un serveur MEC dans un datacenter régional, et retour, consomme 10-20 millisecondes avant qu'aucun rendu n'ait lieu. À lui seul, cela détruit le budget de latence.

L'architecture 6G pousse le calcul dans la station de base elle-même — parfois appelé « compute-RAN » ou « in-network compute ». Un gNB 6G est conçu pour héberger un petit pool de GPU et rendre les trames pour les utilisateurs qu'il sert à un instant donné, puis pour transférer l'état de rendu lorsque ces utilisateurs passent dans une nouvelle cellule. C'est un écart substantiel par rapport au modèle 5G, où le gNB est un pur point de terminaison radio et où toute la logique applicative vit ailleurs.

L'implication pratique est que les stations de base 6G seront nettement plus grandes et plus chères que celles de la 5G, et que l'économie de leur déploiement dépend de l'existence d'un trafic XR rémunérateur. C'est l'un des problèmes de la poule et de l'œuf qui freine les engagements sur les calendriers 6G.

Communication et sensing conjoints pour les ancres spatiales

La XR persistante — la promesse fondatrice du métavers d'un espace virtuel partagé ancré au monde réel — exige que le réseau lui-même comprenne la géométrie spatiale. Aujourd'hui, cela se fait avec la vision : SLAM tournant sur le casque, plus des ancres cloud téléversées vers des services comme ARCore. La précision est bonne pour un utilisateur unique mais se dégrade lorsque plusieurs partagent un espace et que l'éclairage change.

La capacité de communication et sensing conjoints (JCAS) de la 6G utilise les mêmes formes d'onde radio pour la transmission de données et le sensing de l'environnement. Le résultat est une carte spatiale côté réseau, mise à jour en temps réel, précise au centimètre et disponible pour tous les utilisateurs authentifiés sur cette cellule. Pour la XR multi-utilisateur — collaboration, gaming, formation — c'est la différence entre chaque utilisateur maintenant sa propre carte approximative et tous les utilisateurs partageant une vérité de référence unique.

JCAS n'est pas gratuite. Elle exige des formes d'onde qui sacrifient un peu d'efficacité pure de données pour conserver des propriétés de sensing, et elle ajoute des exigences de calcul et de stockage au RAN. Les opérateurs la traiteront comme un slice plutôt que comme un mode par défaut, mais pour les lieux à forte consommation XR comme les stades, les parcs d'attractions et les centres de formation d'entreprise, ce slice sera la raison entière de l'existence de la cellule.

Les cas d'usage qui en ont réellement besoin

Toutes les applications XR ne réclament pas la 6G. Le gaming solo sur casque standalone fonctionne très bien aujourd'hui. La collaboration de bureau avec avatars et partage d'écran tourne sur du Wi-Fi 6E. La classe « 6G ou rien » est plus étroite mais à forte valeur.

Lieux immersifs multi-utilisateurs : attractions de parcs à thème, arènes esports, VR location-based. Des centaines d'utilisateurs dans un bâtiment, chacun exigeant un motion-to-photon sous 10 ms, partageant une scène synchronisée. La 5G ne livre pas cette densité aujourd'hui.

Opération à distance : robotique chirurgicale, téléopération d'engins lourds, pilotage de drones à l'échelle. La latence est durement bornée par la physique et la réglementation de sécurité. La bande passante est modérée, mais l'exigence de déterminisme est extrême.

Jumeaux numériques industriels : des ouvriers d'usine portant des overlays AR affichant des données capteurs en temps réel ancrées à des machines physiques. Cela exige des ancres spatiales de qualité JCAS plus des mises à jour sous 5 ms depuis la couche IoT de l'usine.

Communication holographique : le cas d'usage « téléprésence » promis depuis longtemps, où un participant distant apparaît comme un hologramme volumétrique. La demande downlink est de 10-50 Gbps par session, l'uplink pour la capture est similaire, la tolérance de latence est de 50-100 ms. La 6G est le premier standard explicitement conçu pour ce profil.

En conclusion

La 5G peut faire de la XR pour un utilisateur unique avec un lien filaire vers un serveur co-localisé. La 6G est la première génération cellulaire conçue pour faire de la XR à l'échelle, avec mobilité, et sur un réseau partagé. Les choix de conception qui les distinguent — spectre sub-térahertz, calcul dans le RAN, communication et sensing conjoints, ordonnancement déterministe — ne sont pas des améliorations incrémentales mais des engagements architecturaux qui n'ont de sens économique que si la XR devient une vraie catégorie grand public.

Le métavers reste un terme contesté et son marché grand public n'est pas démontré. Mais la question d'ingénierie est tranchée : si la XR sans fil grand public arrive, elle arrivera sur la 6G. Les opérateurs qui parient sur une 6G commerciale en 2030 parient, en pratique, sur l'arrivée du métavers selon un calendrier qui justifie leurs plans d'investissement. L'un comme l'autre des paris peut être faux, mais c'est le même pari.