كان المتوسط سريعاً، لكن الإطار وصل بعد أن تحرّك الرأس

الخلاصة

• يتعامل RFC 9699 مع XR المتنقل كسلسلة مترابطة: التتبع ونموذج الواقع والتسجيل وتوليد الصورة ونقلها وعرضها يجب أن تلحق بمستخدم مستمر في الحركة.
• يخفف offload إلى الحافة ضغط الحرارة والبطارية، لكن تغير الراديو والطابور والتنفيذ والعودة تستهلك ميزانية motion-to-photon نفسها؛ القرب والمتوسط ليسا إيصالاً من طرف إلى طرف.
• يتوقع RFC معلمات تشغيل heavy-tailed وحركة متدفقة على شكل دفعات. يجب ربط كل إطار معروض بوضعيته وحالة النموذج وحسابه وQoE المرصودة.

الفشل المختبئ داخل متوسط سليم

تلتفت زائرة ترتدي نظارة XR نحو قوس. تعرض اللوحة متوسط 11 ms بين الجهاز والحافة. تصل معظم الإطارات بسلاسة، لكن إطاراً واحداً ينتظر خلف دفعة قصيرة. كان مبنياً على وضعية صحيحة عند الإرسال؛ وحين عاد كان الرأس قد تحرك، فسقطت الطبقة الافتراضية بجانب القوس.

المتوسط صحيح، لكنه ليس الدليل الذي تحتاجه التجربة.

يستخدم RFC 9699، وهو وثيقة IETF Informational منشورة في ديسمبر 2024، سياحاً يتحركون في برج لندن. يولد التطبيق مشاهد تاريخية فوق رؤية واقعية متغيرة. يقسم العمل إلى التتبع واكتساب نموذج العالم والتسجيل. يتناول التتبع الوضعية ذات الأبعاد الستة للرأس والعينين والأجسام. يمكن للنموذج أن يجمع mapping على العميل وlocalisation على الخادم. يطابق التسجيل الهندسة والسطوع واللون ويعالج الحجب والتشوه والضبابية والضوضاء. ثم يجب على situated visualisation أن تحافظ على الاتساق الزمني مع حركة الرأس والعين.

تسخن معالجة الفيديو وتوليد الصور الجهاز وتستهلك البطارية. لا تلائم السحابة البعيدة مهل المللي ثانية، لذلك ينتقل الحساب إلى الحافة. لكنه لا يختفي؛ بل يتوزع بين المستشعر وقرار offload والمسار اللاسلكي والقبول والطابور وCPU/GPU ومخزن النموذج والنقل العائد والشاشة.

مهلة واحدة وساعات متعددة

يستشهد RFC لحالته بزمن motion-to-photon لا يتجاوز 20 ms ويفضل 7–15 ms. قد يستهلك تحديث الشاشة وتبديل البكسل 12–13 ms، فلا يبقى إلا 7–8 ms لمعالجة المستشعر والتصيير وRTT. هذه ليست ضمانات لكل منتج، لكنها تثبت أن الشبكة والحساب وعمر الوضعية تتقاسم ميزانية واحدة.

زمن استجابة offload هو الحساب مضافاً إليه RTT. قد يحقق الراديو هدفه ويفشل طابور GPU. قد تنفذ الحافة بسرعة بينما يبطئ uplink بسبب بيانات بصرية إضافية. قد يكون الموقع الأقرب بلا نموذج جاهز. وقد يصل إطار داخل SLO الشبكة لكنه مسجل على هندسة أو وضعية قديمة.

تغير الحركة عرض النطاق والكمون وعلاقات المكونات، وقد تفشل الوصلة. موارد الحافة أقل من السحابة ويمكن لمجموعة زوار أن تغمرها. لذلك يعني «قريب» مساراً قصيراً عالي السعة يفي الآن بمتطلبات التطبيق، لا مجرد مسافة على الخريطة أو عدد hops عند النشر.

ذيل التوزيع جزء من المنتج

يتوقع RFC heavy tails في إشغال buffer وthroughput وكمون العميل والخادم وأزمنة النقل، ويحذر من بطء استقرار متوسط العينة ومن عدم ملاءمة variance وstandard deviation أحياناً. كما يصف دفعات كبيرة تفصلها فترات، واعتماداً طويل المدى وburstiness على مقياس المللي ثانية. يحتاج مثال 6DoF/point cloud إلى 200–1000 Mbps؛ وتنتج الدفعة مع الطابور المتغير jitter قد يسهم في دوار الحركة.

هذا لا يثبت توزيعاً واحداً لكل XR، لكنه يمنع الاعتماد على المتوسط وحده. قد تتجمع الإطارات القليلة التي تفقد وضعيتها أثناء handover أو تدفق الزوار أو جلب النموذج أو تنازع GPU.

يبدأ الإيصال بهوية الإطار: عينة المستشعر ووقتها، قرار offload، الراديو/handover، القبول والطابور والتنفيذ، نسخ النموذج والمشهد، اكتمال التصيير، downlink، الوضعية المستخدمة في التسجيل النهائي، وقت العرض وQoE. حالة غير مرصود مشروعة؛ أما “edge success” فلا يملأ الفراغات.

يقترح RFC placement ديناميكياً ودعم الحركة والطاقة، مع DetNet وراديو موثوق وDiffServ وQoS كخيارات، ويترك الجدوى الاقتصادية مفتوحة. لا يضع إيصالاً عالمياً لكل إطار، ولا يصادق على نشر بعينه، ولا يضمن tail بمجرد القرب. الاستمرارية القابلة للإثبات تبدأ عندما تُدار السلسلة المترابطة كلها كمنتج.

المصادر

السجلات الأولية: RFC 9699، RFC Editor، IETF Datatracker، RFC 8939، RFC 9023، RFC 9450، ودراسة XR من 3GPP. العدسة التحريرية المعلنة: الواقع لا الدعاية.