Resumo

  • O RFC 9699 trata XR móvel como cadeia acoplada: rastreamento, modelo real, registro, geração, transporte e tela precisam acompanhar alguém em movimento.
  • O edge alivia calor e bateria, mas variação sem fio, fila, execução e retorno consomem o mesmo orçamento motion-to-photon; proximidade e média não são recibo ponta a ponta.
  • O RFC espera parâmetros heavy-tailed e tráfego em rajadas. Cada quadro precisa ser ligado à pose, ao estado do modelo, ao cálculo e à experiência observada.

A falha escondida numa média saudável

Uma visitante com headset XR vira para um arco. O painel mostra média de 11 ms entre dispositivo e edge. Quase todos os quadros chegam bem. Um espera atrás de uma rajada curta. Foi renderizado com a pose correta na saída e voltou depois do movimento; o overlay cai ao lado do arco.

A média é verdadeira. Apenas não é a evidência que a experiência exige.

O RFC 9699, IETF Informational de dezembro de 2024, acompanha turistas na Torre de Londres. O app gera cenas históricas sobre a visão real em mudança. Separa o processamento em rastreamento, aquisição de modelo do mundo e registro. O rastreamento cobre pose em seis dimensões de cabeça, olhos e objetos. O modelo pode combinar mapeamento no cliente e localização no servidor. O registro alinha geometria, brilho e cor, trata oclusão, distorção, blur e ruído. A visualização situada ainda precisa preservar coerência temporal enquanto cabeça e olhos se movem.

Vídeo e geração de imagens no dispositivo aquecem e gastam bateria. A nuvem distante não cabe bem em prazos de milissegundos; o cálculo vai para o edge. A carga, porém, se divide entre sensor, decisão de offload, rádio, admissão e fila, CPU/GPU, modelo, retorno e tela.

Um prazo, muitos relógios

Para o caso, o RFC cita motion-to-photon de no máximo 20 ms, preferencialmente 7–15 ms. Refresh e troca de pixels podem gastar 12–13 ms, restando 7–8 ms para sensor, render e RTT. Não são garantias universais, mas deixam claro que rede, computação e idade da pose compartilham o orçamento.

O tempo de resposta do offload soma computação e RTT. A rádio pode cumprir enquanto a fila da GPU falha. O edge pode executar rápido e o uplink atrasar com dados visuais extras. O site mais próximo pode estar sem o modelo correto. Um quadro dentro do SLO de rede pode estar registrado em geometria ou pose antiga.

Com mobilidade, largura de banda e latência variam, links falham e relações entre componentes mudam. O edge tem menos recursos que a nuvem e pode saturar com um grupo. “Próximo” significa caminho curto e capaz naquele momento, não apenas distância no mapa ou hops no planejamento.

A cauda faz parte do produto

O RFC espera heavy tails em buffer, throughput, latência e tempos de transmissão; alerta que a média amostral estabiliza lentamente e que variância e desvio padrão podem ser inadequados. Descreve rajadas grandes separadas por pausas, dependência longa e burstiness em milissegundos. O exemplo 6DoF/point cloud pede 200–1000 Mbps; rajada com fila variável produz jitter que pode contribuir para enjoo.

Isso não prova a mesma distribuição para todo XR. Impede aprovar apenas pela média. Poucos quadros podem perder sua pose, concentrados em handover, chegada de público, fetch de modelo ou contenção GPU.

O recibo começa na identidade do quadro: amostra e timestamp do sensor, decisão de offload, rádio/handover, admissão, fila, execução, versões de modelo e cena, fim do render, entrega, pose usada no registro, apresentação e QoE. Não observado é um estado; “edge success” não substitui campos ausentes.

O RFC sugere placement dinâmico, mobilidade e energia, com DetNet, wireless confiável, DiffServ e QoS como apoios, e mantém a viabilidade econômica aberta. Não define recibo universal, certifica implantação ou garante tails por proximidade. Continuidade verificável só existe quando o caminho acoplado inteiro é operado como produto.

Fontes

Registros primários: RFC 9699, RFC Editor, IETF Datatracker, RFC 8939, RFC 9023, RFC 9450 e estudo XR do 3GPP. Lente editorial pública: realidade, não defesa.