شبکه‌ها تلاش می‌کنند هم توان عملیاتی بالا و هم تأخیر کم را ارائه دهند. با این حال، زمانی که تعداد بسته‌هایی که از طریق شبکه در حال حرکت هستند به حد مجاز خود می‌رسد، صف‌ها شروع به ایجاد می‌کنند که منجر به تاخیر/ازدحام می‌شود.
بنابراین تراکم باید مدیریت شود، اما مکانیسم‌های تشخیص تراکم قدیمی به از دست دادن بسته به عنوان معیاری که می‌تواند برای تطبیق نرخ‌های ارسال استفاده شود، تکیه می‌کند… اما زمانی که بسته‌ها از دست می‌روند، تاخیر و لرزش از قبل رخ می‌دهد.
سه سال پیش، ما شاهد رسمی شدن چارچوب توان عملیاتی با تاخیر کم، کم تلفات و مقیاس پذیر برای مدیریت تراکم شبکه بودیم. این تکنیک که بیشتر به عنوان L4S شناخته می شود، مبادله بهتری را مدیریت می کند و تأخیرهای بسیار کم را بدون کاهش توان عملیاتی امکان پذیر می کند.
این به طور موثر به عنوان یک چراغ راهنمایی هوشمند در یک تقاطع کار می کند، با عناصر شبکه به طور فعال سیگنال ازدحام در مراحل اولیه قبل از از دست دادن بسته رخ می دهد. این توسط اعلان تراکم سریع (ECN) همراه با معماری مدیریت صف فعال (AQM) مرتبط با دو صف مدیریت می‌شود. پذیرندگان اولیه شامل Comcast و Apple (در iOS 17) هستند، و استفاده از آن در حال رشد است، اما این رویکرد به دور از پذیرش جهانی است.
بنابراین در این وبلاگ، معنی L4S برای مهندسین 5G RAN و Core را بررسی خواهیم کرد، چرا اعتبارسنجی آن یک چالش پیچیده و دو جانبه است، و چگونگی ایجاد یک استراتژی آزمایشی قوی برای اطمینان از استقرار موفقیت آمیز.
Bufferbloat در 5G
در هر شبکه و به‌ویژه در محیط‌های موبایل، تأخیر فلج‌کننده می‌تواند در هر نقطه‌ای اتفاق بیفتد، حتی در شبکه 5G با اولویت بالایی برای بازی‌های ابری. RAN (شبکه دسترسی رادیویی) ذاتاً متغیر است و به محض اینکه یک قطعه اشباع می شود، تکنیک های مدیریت ازدحام قدیمی به صف ها اجازه می دهد تا در gNB و UPF ایجاد شوند و در نتیجه تأخیر افزایش یابد.
تأخیر برای سرویس های پخش ویدیوی یک طرفه بافر مانند Netflix مشکلی نیست. اما برای بازی‌های ابری، هر چیزی بیش از 100 میلی‌ثانیه تأخیر از bufferbloat قابل توجه خواهد بود – تقریباً غیرممکن است بازی کنید. در واقعیت افزوده، همین افزایش تاخیر می تواند منجر به بیماری سایبری شود. و در رباتیک از راه دور یا سیستم های خودروی خودران V2X، این تاخیر یک نقض ایمنی قابل توجه خواهد بود.
برای رفع این مشکل، 3GPP L4S را در نسخه 18 سال گذشته برای 5G Advanced ادغام کرد. این مشخص می‌کند که چگونه NG-RAN و/یا UPF می‌توانند ترافیک L4S را برای XR و سایر سرویس‌های حساس به تأخیر شناسایی/ علامت‌گذاری کنند، و (در تئوری) به این معنی است که برنامه‌های تعاملی می‌توانند از ۱۰۰ درصد پهنای باند موجود با تاخیرهای صف صفر (یا نزدیک به صفر، حداقل) استفاده کنند.
معماری 5G L4S
برای اینکه L4S موثر باشد، نیاز به همکاری کامل بین شبکه 5G و دستگاه کاربر نهایی دارد.
همانطور که در بالا ذکر شد، AQM دو طرفه برای سمت شبکه مورد نیاز است، با استانداردهای 3GPP که اجازه می دهد آن را در NG-RAN (gNB) یا در عملکرد صفحه کاربر هسته 5G (UPF) پیاده سازی کنید. از آنجایی که به اضافه بار رادیویی نزدیک است، gNB احتمالا بهترین است.
صرف نظر از مکان، مکانیسم یکسان است و ترافیک از نظر فیزیکی به دو صف برای ترافیک قدیمی (کلاسیک) و L4S-aware (L) تقسیم می شود. این صف “L” برای جلوگیری از تاخیر بسیار کوتاه نگه داشته می شود.
به طور مشابه، برای هر دو مکان AQM، gNB برای کشف در صف برنامه ریزی رادیویی آن استفاده می شود. تفاوت در نحوه به دست آوردن علامت ECN است، اگر AQM در آنجا قرار دارد، gNB باید این اطلاعات را به UPF برای ECN ارسال کند. اما اگر در NG-RAN قرار گیرند، هم کشف و هم برچسب گذاری در یک مکان انجام می شود.
اگر اکنون به سمت مشتری برویم. در اینجا، سیستم عامل موبایل اتحادیه اروپا باید یک کنترل‌کننده تراکم مقیاس‌پذیر را راه‌اندازی کند، با دستگاه‌های مجهزی که قابلیت‌های خود را با علامت‌گذاری نقطه کد ECT(1) روی بسته‌ها علامت‌گذاری کنند. از طریق این سیگنال، به gNB یا UPF دستور داده می شود که بسته را به صف L تحویل دهد.
اگر تراکم تشخیص داده شود، AQM ECT(1) را به نقطه کد CE تغییر می دهد. در هنگام دریافت، کنترلر L4S UE یک کاهش کوچک اما فوری در نرخ ارسال ایجاد می کند و بنابراین نمی توان صف تشکیل داد. در واقع، ثابت شده است که L4S به طور قابل توجهی صف را کاهش می دهد و تأخیر را به محدوده میلی ثانیه پایین می آورد.
برخورد با ترافیک قدیمی
با این حال، پیاده‌سازی L4S خطری جدی برای اپراتور تلفن همراه دارد و کسانی که این فناوری را به کار می‌گیرند باید تدابیری را برای جلوگیری از گرفتن پهنای باند موجود در جریان‌های L4S سریع‌تر فراهم کنند. این امر به طور موثر جریان های کلاسیک مورد استفاده اکثر کاربران را از بین می برد و کیفیت تجربه (QoE) را برای آنها کاهش می دهد.
این مشکل توسط بخش AQM دو دم L4S حل می شود. در اینجا، AQM یک مکانیسم انصاف داخلی را پیاده‌سازی می‌کند و اگر صف کلاسیک شروع به شلوغ شدن کند، به صف L4S سیگنال داده می‌شود که بسته‌های L4S را با CE زودتر و با شدت بیشتری علامت‌گذاری کند.
و در حالی که از نظر فنی امکان علامت گذاری ترافیک به عنوان L4S حتی پس از ارسال هشدارهای تراکم وجود دارد، AQM قادر است در برابر برنامه هایی که این کار را انجام می دهند محافظت کند. این باعث می‌شود بسته‌ها در صف L انباشته شوند، و اگر این اتفاق بیفتد، استراتژی‌های AQM برای شناسایی بسته‌ها به‌عنوان ناهماهنگ و کاهش رتبه برای خنثی کردن تلاش‌ها برای جعل سیستم طراحی شده‌اند.
اعتبار سنجی پیاده سازی L4S
در اینجا باید گفت که علیرغم مزایایی که به ارمغان می‌آورند، مکانیسم‌های AQM مرتبط و کشف تقلب تا حد زیادی قابلیت اتصال و بازی را ندارند. در واقع، هر یک از اینها یک چالش اعتبارسنجی پیچیده را ایجاد می کند که باید قبل از اجرای آنها بر آن غلبه کرد.
اول نیاز به اثبات این است که مکانیسم انصاف در مقیاس کار می کند و از سازگاری عقب مانده با میلیون ها UE که از کنترل تراکم آگاه L4S پشتیبانی نمی کنند اطمینان حاصل می کند. خطر خرابی اپراتور خدمات قدیمی آسیب دیده است.
فراتر از آن، نیاز به آزمایش تعاملات بین سیگنالینگ مبتنی بر ECN و سیاست‌های شکل‌دهی ترافیک 5G موجود و بخش‌های QoS است.
سومین چالش اعتبار سنجی مربوط به امنیت و ثبات است. هر رفتار جدیدی از پروتکل باید کاملاً از نظر استحکام در برابر سوء استفاده آزمایش شود. برای آزمایش این، مهم است که به طور فعال در برابر پیکربندی نادرست آزمایش کنید و برنامه‌های «سرکش» را شبیه‌سازی کنید تا ثابت کنید که مکانیسم کاهش رتبه AQM می‌تواند هر بار آنها را خنثی کند.
و سپس اعتبار QoE وجود دارد. این امر مستلزم اعتبارسنجی با شبیه‌سازی برنامه‌های کاربردی در دنیای واقعی است تا نشان دهد که به هدف دست می‌یابد و کیفیت کیفیت بهتری را در مجموعه‌ای از موارد کاربری متنوع ارائه می‌دهد – به همین دلیل است که در وهله اول پیاده‌سازی شد.
نتیجه گیری: آینده ای هوشمندتر و سریع تر
استقرار L4S در حال تسریع است و چندین اپراتور اصلی دیگر متعهد به استقرار آن شده اند. قابل ذکر است که وودافون و تی موبایل این کار را انجام داده اند و T-Mobile این فناوری را یکی از “مهم ترین قابلیت های” 5G Advanced می نامد. اما همانطور که اشاره کردیم، این یک راه حل ساده “تغییر سوئیچ” نیست و اعتبار سنجی آزمایشگاهی ضروری است.
VIAVI قادر است چندین سرویس آزمایشی را برای L4S ارائه دهد، با پلتفرم TeraVM™ که می‌تواند به عنوان یک شبیه‌ساز شبکه و برنامه جامع عمل کند که قادر به تایید استقرار قبل از استقرار در مقیاس بزرگ است. از طریق TeraVM، اپراتورها می‌توانند کل اکوسیستم 5G را در مقیاسی شبیه‌سازی کنند، از جمله هزاران UE آگاه از L4S (در حال اجرا TCP پراگ) که با ترافیک قدیمی ترکیب شده است. این سیستم همچنین قادر به آزمایش تعاملات L4S با بخش‌های QoS 5G، شبیه‌سازی برنامه‌های «سرکش» و ارائه اعتبار QoE در دنیای واقعی برای برنامه‌های حساس به تأخیر است.
برای کسب اطلاعات بیشتر در مورد این موضوع، لطفاً از صفحه راه حل های امنیتی ما برای حامل های بی سیم دیدن کنید.
