Résumé

  • Le RFC 9699 décrit une chaîne couplée : suivi, acquisition du modèle réel, recalage, génération, transport et affichage doivent suivre un utilisateur toujours en mouvement.
  • Le déport edge réduit la pression thermique et énergétique, mais radio, attente, exécution et retour consomment le même budget motion-to-photon ; proximité et moyenne ne sont pas une preuve de bout en bout.
  • Plusieurs paramètres attendus sont heavy-tailed et le trafic est en rafales. La preuve doit relier chaque image affichée à sa pose, son état de modèle, son calcul et la QoE observée.

L’échec caché dans une moyenne saine

Une visiteuse équipée d’un casque XR tourne la tête vers une arche. Le tableau de bord affiche 11 ms de moyenne entre terminal et edge. Presque toutes les images sont fluides. Une seule attend derrière une courte rafale. Elle a été calculée avec la pose correcte au départ ; elle revient après le mouvement. La superposition tombe à côté de l’arche.

La moyenne est exacte. Ce n’est simplement pas le reçu dont l’expérience a besoin.

Publié en décembre 2024 comme document IETF Informational, le RFC 9699 suit des touristes dans la Tour de Londres. L’application génère des scènes historiques et les superpose à une vue réelle qui change. Le traitement se décompose en suivi, acquisition d’un modèle du monde et recalage. Le suivi porte sur la pose à six dimensions de la tête, des yeux et des objets visibles. Le modèle peut combiner cartographie côté client et localisation côté serveur. Le recalage aligne géométrie, luminosité et couleur, traite l’occlusion, la distorsion, le flou et le bruit. La visualisation située doit encore conserver la cohérence temporelle pendant que tête et yeux bougent.

Le calcul local de vidéo et d’images chauffe l’appareil et vide sa batterie. Le cloud distant cadre mal avec les contraintes de quelques millisecondes ; le calcul migre donc vers le edge. Mais la charge ne disparaît pas. Elle est répartie entre capteurs, décision d’offload, trajet radio, admission et file, CPU/GPU, stockage du modèle, transport retour et écran.

Un délai, plusieurs horloges

Pour son cas d’usage, le RFC cite un motion-to-photon d’au plus 20 ms, idéalement 7–15 ms. Le rafraîchissement et la commutation des pixels peuvent prendre 12–13 ms, ne laissant que 7–8 ms pour capteurs, rendu et aller-retour terminal-edge. Ce ne sont pas des garanties universelles. L’arithmétique montre néanmoins que latence réseau, calcul et âge de pose sont inséparables.

Le temps de réponse offloadé est la somme du calcul et du RTT. La radio peut respecter sa part tandis qu’une file GPU détruit l’expérience. L’exécution edge peut être rapide tandis que l’uplink charge davantage de données dans un environnement pauvre en repères visuels. Le site le plus proche peut ne pas avoir le bon modèle en mémoire. Une image conforme au SLO réseau peut rester recalée sur une géométrie ou une pose périmée.

La mobilité déplace aussi les frontières. Bande passante et latence radio varient, la liaison peut tomber, et les relations logiques entre composants changent. Un edge, moins doté qu’un cloud, peut être saturé par l’arrivée d’un groupe. « Proche » signifie donc un chemin court et capacitaire qui satisfait maintenant l’application, non une distance cartographique ou un nombre de sauts mesuré une fois.

La queue de distribution fait partie du produit

Le RFC attend des distributions heavy-tailed pour l’occupation des buffers, le débit, la latence client-serveur et les temps de transmission. Il avertit que la moyenne d’échantillon peut se stabiliser trop lentement et que variance ou écart type peuvent être de mauvais indicateurs. Il décrit aussi de grandes rafales séparées par des creux, une dépendance de longue portée et une burstiness aux échelles de la milliseconde. Son exemple 6DoF vidéo/nuage de points exige 200–1000 Mbps ; rafale et attente variable créent du jitter susceptible de contribuer au mal des transports.

Cela ne démontre pas une distribution identique pour toute trace XR. Cela suffit à invalider une approbation fondée sur la seule moyenne. Les rares images qui manquent leur pose peuvent se concentrer au handover, au chargement d’un modèle, à l’arrivée d’une foule ou lors d’une contention GPU.

Un reçu défendable commence par l’identifiant d’image : échantillon de capteur et horodatage, décision d’offload, observations radio/handover, admission, file et exécution, versions de modèle et d’état, fin du rendu, livraison descendante, pose utilisée au recalage, présentation écran et QoE. Non observé est un état légitime ; « succès edge » ne remplit pas les cases absentes.

Le RFC propose placement dynamique des serveurs XR, mobilité et gestion énergétique, avec DetNet, radio fiable, DiffServ ou QoS par connexion comme soutiens possibles. Il rappelle aussi la viabilité économique. Il ne normalise pas un reçu par image, ne certifie aucun déploiement nommé et ne garantit ni compensation prédictive ni conformité des tails par simple proximité. La conclusion sûre est étroite : le XR edge n’est continu que si toute la chaîne couplée est exploitée comme le produit.

Sources

Sources primaires : RFC 9699, fiche RFC Editor, IETF Datatracker, RFC 8939, RFC 9023, RFC 9450 et étude XR 3GPP. Angle éditorial public : la réalité, non le plaidoyer.