چین Shenzhen Olax Technology CO.,Ltd اخبار شرکت

با توجه به پیکربندی پیچیده سنتی CLI و SNM و عدم پشتیبانی از مکانیزم تراکنش، پروتکل مدیریت شبکه NETCONF در سیستم 5G فعال شده است و به NMS (سیستم مدیریت شبکه) اجازه می‌دهد تا پیکربندی دستگاه‌های شبکه متصل به روترها، eNodeB، gNodeB، DU، CU یا RU را صادر، اصلاح و حذف کند. اصل کار، ساختار و جلسه سرویس به شرح زیر است؛   I. اصل کار سیستم NETCONF حداقل شامل یک NMS است که تمام دستگاه‌های شبکه را مدیریت می‌کند، همانطور که در شکل زیر نشان داده شده است. معماری NETCONF شامل دو نقش است: کلاینت و سرور     II. ویژگی‌های ساختار سیستم NETCONF حداقل شامل یک NMS است که تمام دستگاه‌های شبکه را مدیریت می‌کند، از جمله:   2.1 کلاینت عملکردهای زیر را ارائه می‌دهد:   از NETCONF برای مدیریت دستگاه‌های شبکه استفاده کنید. درخواست‌های RPC را به سرور NETCONF ارسال کنید تا یک یا چند مقدار پارامتر را پرس و جو یا اصلاح کنید. با توجه به آلارم‌ها و رویدادهای ارسال شده توسط سرور NETCONF دستگاه مدیریت شده، وضعیت دستگاه مدیریت شده را درک کنید. 2.2 هنگامی که سرور درخواستی را از کلاینت دریافت می‌کند، درخواست را تجزیه و به کلاینت پاسخ می‌دهد. هنگامی که یک دستگاه مدیریت شده با یک خطا یا نوع دیگری از رویداد مواجه می‌شود، سرور NETCONF آلارم یا رویداد را از طریق یک مکانیزم اعلان به کلاینت گزارش می‌دهد و به کلاینت اجازه می‌دهد تا وضعیت دستگاه مدیریت شده را درک کند.   III. جلسه NETCONF: همانطور که در شکل زیر نشان داده شده است، کلاینت و سرور با استفاده از مکانیزم RPC ارتباط برقرار می‌کنند. ارتباط فقط پس از برقراری یک جلسه امن مبتنی بر اتصال بین آنها مجاز است. کلاینت یک درخواست RPC را به سرور ارسال می‌کند که درخواست را پردازش کرده و پاسخی را به کلاینت برمی‌گرداند. کلاینت و سرور NETCONF با استفاده از مکانیزم RPC ارتباط برقرار می‌کنند. ارتباط فقط پس از برقراری یک جلسه امن مبتنی بر اتصال مجاز است. فرآیند ایجاد و خاتمه جلسه به شرح زیر است:       کلاینت یک اتصال SSH را با سرور برقرار می‌کند و پس از تکمیل احراز هویت و مجوز، یک جلسه NETCONF را با سرور برقرار می‌کند. کلاینت و سرور پیام‌های Hello را برای مذاکره در مورد قابلیت‌ها تبادل می‌کنند. کلاینت یک یا چند درخواست RPC را به سرور ارسال می‌کند. برخی از درخواست‌های نمونه در زیر فهرست شده‌اند:  اصلاح و تایید پیکربندی؛  پرس و جو داده‌های پیکربندی یا وضعیت؛  انجام عملیات نگهداری روی دستگاه؛  کلاینت جلسه NETCONF را خاتمه می‌دهد؛  اتصال SSH خاتمه می‌یابد.

  NETCONFنام کامل پروتکل پیکربندی شبکه است که یک پروتکل مدیریت شبکه است که اجازه می دهد NMS (سیستم مدیریت شبکه) صادر شود،تغییر و حذف پیکربندی از دستگاه های شبکه متصل (روتر)، eNodeB، gNodeB، DU، CU یا RU).IETFدر حالی که برای O-RAN، این موضوع تحت مسئولیت WG (گروه کاری 4) است.     پروتکل NETCONFاز کدگذاری داده های XML (Extensible Markup Language) برای پردازش داده های پیکربندی و پیام های پروتکل استفاده می کند.این بر اساس مفهوم سرور و مشتری است و از مکانیسم RPC (Remote Procedure Call) برای دستیابی به ارتباطات بین سرور و مشتری استفاده می کند.. فرآیند مشتری بر روی NMS اجرا می شود، که می تواند یک اسکریپت یا برنامه باشد، و سرور یک دستگاه شبکه معمولی است.   II. ویژگی های NETCONFبه شرح زیر است: این یک چارچوب پروتکل لایه دار را اتخاذ می کند، که آن را برای شبکه های مورد نیاز، خودکار و مبتنی بر ابر مناسب تر می کند. از آن برای صدور، اصلاح و حذف پیکربندی دستگاه های شبکه استفاده می شود. XML (Extensible Markup Language) برای کدگذاری داده های داده های پیکربندی و پیام های پروتکل استفاده می شود. بر اساس مفهوم سرور و مشتری، NMS به عنوان یک مشتری عمل می کند و دستگاه شبکه به عنوان یک سرور عمل می کند. ارتباطات بین سرورها و مشتریان با استفاده از مکانیسم RPC (Remote Procedure Call) انجام می شود. عملیات بر اساس مدل YANG اجرا می شود، که باعث کاهش خرابی شبکه ناشی از اشتباهات پیکربندی دستی می شود. NETCONF نیازهای اتوماسیون شبکه را برآورده می کند. این مکانیسم مکانیزم های امنیتی مانند احراز هویت و مجوز را برای اطمینان از انتقال امن پیام فراهم می کند. همچنین مکانیسم های تراکنش را ارائه می دهد که از طبقه بندی داده ها، ذخیره سازی و مهاجرت، انجام مرحله ای و جداسازی پیکربندی پشتیبانی می کند. از تحویل، تأیید و بازگشت پیکربندی جامع پشتیبانی می کند و تأثیر آن بر خدمات شبکه را به حداقل می رساند. به فروشندگان اجازه می دهد تا عملیات پروتکل خود را برای پیاده سازی قابلیت های مدیریت منحصر به فرد تعریف کنند. 3چرا NETCONF لازم است؟ یکی از الزامات اصلی شبکه های ابری اتوماسیون شبکه برای ارائه سریع خدمات بر اساس تقاضا و مدیریت خودکار عملیات است.روش های سنتی مانند CLI و SNM نمی توانند این نیاز را برآورده کنند.. آنها محدودیت های زیر را دارند که NETCONF به آنها رسیدگی می کند.   31معایبCLIاول، پیکربندی پیچیده است. دوم، این موارد: CLI ها از یک فروشنده به دیگری متفاوت هستند و نیاز به یادگیری و سازگاری اسکریپت های CLI برای هر فروشنده دارند. تغییرات مکرر در ساختار و نحو CLI حفظ اسکریپت های CLI را دشوار می کند. خروجی فرمان غیر ساختاری، غیر قابل پیش بینی و به راحتی قابل تغییر است که تجزیه خودکار اسکریپت های CLI را دشوار می کند. 3.2معایب SNMP: SNMP از تراکنش ها پشتیبانی نمی کند، که منجر به پیکربندی ناکارآمد می شود. SNMP از پروتکل داده گرامی کاربر (UDP) استفاده می کند که انتقال داده های قابل اعتماد و دنباله دار را ارائه نمی دهد و فاقد مکانیسم های امنیتی موثر است. SNMP فاقد مکانیزم برای ارسال تراکنش های پیکربندی است. SNMP پیکربندی دستگاه را بر اساس هر دستگاه مدیریت می کند و از پیکربندی سطح شبکه یا همکاری پیکربندی چند دستگاه پشتیبانی نمی کند.

NETCONF نام کامل پروتکل پیکربندی شبکه است که یک پروتکل مدیریت شبکه است که به NMS (سیستم مدیریت شبکه) اجازه می دهد پیکربندی دستگاه های شبکه متصل (روترها، eNodeB، gNodeB، DU، CU یا RU) را صادر، اصلاح و حذف کند. NETCONF توسط IETF توسعه و استاندارد شده است. در حالی که برای O-RAN، این پروتکل تحت مسئولیت WG (گروه کاری 4) است.   1. پروتکل NETCONF از رمزگذاری داده XML (زبان نشانه گذاری توسعه پذیر) برای پردازش داده های پیکربندی و پیام های پروتکل استفاده می کند. این پروتکل بر اساس مفهوم سرور و کلاینت است و از مکانیسم RPC (فراخوانی رویه از راه دور) برای برقراری ارتباط بین سرور و کلاینت استفاده می کند. فرآیند کلاینت روی NMS اجرا می شود که می تواند یک اسکریپت یا برنامه باشد و سرور یک دستگاه شبکه معمولی است.   2. ویژگی های NETCONF به شرح زیر است: این پروتکل یک چارچوب پروتکل لایه ای را اتخاذ می کند و آن را برای شبکه های درخواستی، خودکار و مبتنی بر ابر مناسب تر می کند. برای صدور، اصلاح و حذف پیکربندی ها برای دستگاه های شبکه استفاده می شود. XML (زبان نشانه گذاری توسعه پذیر) برای رمزگذاری داده های پیکربندی و پیام های پروتکل استفاده می شود. بر اساس مفهوم سرور و کلاینت، NMS به عنوان کلاینت و دستگاه شبکه به عنوان سرور عمل می کند. ارتباط بین سرورها و کلاینت ها با استفاده از مکانیسم RPC (فراخوانی رویه از راه دور) انجام می شود. عملیات بر اساس مدل YANG اجرا می شود و خطاهای شبکه ناشی از خطاهای پیکربندی دستی را کاهش می دهد. NETCONF نیازهای اتوماسیون شبکه را برآورده می کند. این پروتکل مکانیسم های امنیتی مانند احراز هویت و مجوز را برای اطمینان از انتقال امن پیام فراهم می کند. همچنین مکانیسم های تراکنش، پشتیبانی از طبقه بندی داده ها، ذخیره سازی و انتقال، تعهد فازی و جداسازی پیکربندی را ارائه می دهد. از تحویل، تأیید و بازگشت پیکربندی جامع پشتیبانی می کند و تأثیر بر خدمات شبکه را به حداقل می رساند. به فروشندگان اجازه می دهد تا عملیات پروتکل خود را برای پیاده سازی قابلیت های مدیریتی منحصر به فرد تعریف کنند.     3. چرا به NETCONF نیاز است؟ یک نیاز کلیدی شبکه های ابری، اتوماسیون شبکه برای ارائه سریع و درخواستی خدمات و مدیریت عملیات خودکار است. رویکردهای سنتی مانند CLI و SNM نمی توانند این نیاز را برآورده کنند. آنها محدودیت های زیر را دارند که NETCONF آنها را برطرف می کند.     31. معایب CLI: اول، پیکربندی پیچیده است. دوم، موارد زیر: CLIs بسته به فروشنده متفاوت است و از کاربران می خواهد که اسکریپت های CLI را برای هر فروشنده یاد بگیرند و با آنها سازگار شوند. ساختار و نحو CLI اغلب تغییر می کند و نگهداری اسکریپت های CLI را دشوار می کند. خروجی دستورات غیرساختاری، غیرقابل پیش بینی و به راحتی قابل تغییر است و تجزیه خودکار اسکریپت های CLI را دشوار می کند.     3.2 معایب SNMP: SNMP از تراکنش ها پشتیبانی نمی کند و در نتیجه پیکربندی ناکارآمد است. SNMP از پروتکل داده گرام کاربر (UDP) استفاده می کند که انتقال داده قابل اعتماد و متوالی را ارائه نمی دهد و فاقد مکانیسم های امنیتی موثر است. SNMP فاقد مکانیسمی برای ارسال تراکنش های پیکربندی است. SNMP پیکربندی دستگاه را به صورت دستگاه به دستگاه مدیریت می کند و از پیکربندی در سطح شبکه یا همکاری پیکربندی چند دستگاهی پشتیبانی نمی کند.

  در سیستم 5G، یک درخواست تغییر مسیر (PATH SWITCH REQUEST) یک درخواست برای ترمینال (UE) برای ایجاد یک اتصال سیگنال با 5GC است و در صورت لزوم،درخواست انتقال لینک پایین حامل حمل NG-U به یک گره جدید سرویساین درخواست می تواند به دلایل مختلف شکست بخورد؛ 3GPP آن را در TS 38.413 به شرح زیر تعریف می کند.   I. خرابی عملیات درخواست مسیر   همانطور که در شکل 8 نشان داده شده است.4.4.3-1 در زیر، یک درخواست شکست معمولا توسط AMF پس از گره NG-RAN پس از انتشار "PATH SWITCH REQUEST" پاسخ داده می شود.       II. سناریوهای شکست عملیات درخواست به طور معمول به شرح زیر است:   اگر 5GC نتوانست نقطه پایانی اتصال پایین حامل حمل NG-U را به نقطه پایانی جدید (خدمات) برای تمام منابع جلسه PDU تغییر دهد،AMF باید یک پیام PATH SWITCH REQUEST FAILURE را به گره NG-RAN ارسال کند..   The NG-RAN node shall release the corresponding QoS flows and consider the PDU Sessions indicated in the PDU Session Resource Release List IE contained in the PATH SWITCH REQUEST FAILURE message as released.   ارزش علت مربوط به هر جلسه PDU منتشر شده در پیام PATH SWITCH REQUEST FAILURE در Path Switch Request Unsuccessful Transfer IE وجود دارد.   III. درخواست عملیات های غیرطبیعی   اگر AMF پیامی را دریافت کند که حاوی چندین ID جلسه PDU باشد که به همان مقدار تنظیم شده اند (در منبع جلسه PDU که به IE در لیست لینک پایین تغییر می کند) ،AMF باید یک پیام PATH SWITCH REQUEST FAILURE را به گره NG-RAN ارسال کند.علاوه بر اين   به عنوان یک استثناء، AMF ممکن است یک درخواست تغییر مسیر را ایجاد کند.   اگر یک IE NSSAI به طور جزئی مجاز در یک پیام PATH SWITCH REQUEST ACKNOWLEDGE دریافت شود و تعداد کل S-NSSAI موجود در NSSAI مجاز و NSSAI به طور جزئی مجاز بیش از 8 باشد،گره NG-RAN باید این روش را شکست خورده در نظر بگیرد..   اگر هر S-NSSAI موجود در NSSAI IE به طور جزئی مجاز نیز در NSSAI IE مجاز وجود داشته باشد، گره NG-RAN باید روند را شکست خورده در نظر بگیرد.

انتقال وضعیت RAN فرآیند انتقال اطلاعات وضعیت بالادست و پایین‌دست یک ترمینال (UE) از یک گره شبکه دسترسی رادیویی (RAN) منبع به یک گره RAN هدف در یک شبکه 5G است. این معمولاً در طول هنداور یا سناریوهای اتصال دوگانه رخ می دهد. در طول این فرآیند، AMF اطلاعات مربوط به داده‌های پایین‌دست (به عنوان مثال، تعداد بسته‌های ارسال شده)، همراه با وضعیت SN و شماره توالی PDCP (پروتکل همگرایی داده‌های بسته) و وضعیت شماره فریم فوق‌العاده (HFN) را برای داده‌های بالادست و پایین‌دست به RAN هدف منتقل می‌کند.   I. انتقال وضعیت بالادست RANهدف آن فعال کردن هنداورهای بدون ضرر بر روی NG-RAN است. فرآیند انتقال از سیگنالینگ مرتبط با UE استفاده می کند. فرآیند خاص در شکل 8.4.6.2-1 در زیر نشان داده شده است، که در آن:گره NG-RAN منبع این فرآیند را با متوقف کردن تخصیص PDCP SN ها برای SDUs پایین‌دست و ارسال پیام UPLINK RAN STATUS TRANSFER به AMF زمانی که وضعیت فرستنده/گیرنده را منجمد می‌داند، آغاز می کند.   برای هر DRB که حفظ وضعیت PDCP-SN و HFN قابل اجرا است، گره NG-RAN منبع باید DRB ID IE، UL COUNT IE و DL COUNT IE را در DRB Subject Status Transfer List IE در داخل RAN Status Transfer Transparent Container IE از پیام UPLINK RAN STATUS TRANSFER قرار دهد. برای هر DRB که گره NG-RAN منبع یک درخواست ارسال بالادست را از گره NG-RAN هدف پذیرفته است، گره NG-RAN منبع همچنین ممکن است SDUs بالادست از دست رفته و دریافت شده را در UL PDCP SDUs IE از پیام UPLINK RAN STATUS TRANSFER قرار دهد. II.   انتقال وضعیت پایین‌دست RANهدف آن پیاده‌سازی روش‌های انتقال هنداور بدون ضرر مبتنی بر NG-RAN با استفاده از سیگنالینگ مرتبط با UE است. فرآیند خاص در شکل 8.4.7.2-1 در زیر نشان داده شده است، که در آن: AMF این روش را با ارسال پیام DOWNLINK RAN STATUS TRANSFER به گره NG-RAN هدف آغاز می کند. گره NG-RAN هدف که این هنداور را طبق TS 38.300 انجام می دهد و از یک پیکربندی کامل استفاده می کند، باید اطلاعات دریافتی در این پیام را نادیده بگیرد.     برای هر DRB در RAN Status Transfer Transparent Container IE که مشمول State Transfer List IE است، گره NG-RAN هدف نباید هیچ بسته داده بالادستی را با PDCP-SN کمتر از مقدار UL Count Value IE منتقل کند. برای هر DRB در RAN Status Transfer Transparent Container IE که مشمول State Transfer List IE است، گره NG-RAN هدف باید از مقدار DL COUNT Value IE اولین بسته داده پایین‌دستی که هنوز PDCP-SN به آن اختصاص داده نشده است، استفاده کند. اگر حداقل یک DRB در RAN Status Transfer Transparent Container IE از پیام DOWNLINK RAN STATUS TRANSFER حاوی وضعیت دریافت UL PDCP SDUs IE باشد، گره NG-RAN هدف ممکن است از آن در پیام‌های گزارش وضعیت ارسال شده به UE از طریق رابط رادیویی استفاده کند.

  هدف از فرآیند درخواست تغییر مسیر، برقراری یک اتصال سیگنالینگ مرتبط با UE با 5GC و، در صورت امکان، درخواست تغییر نقطه پایانی downlink حامل انتقال NG-U به یک نقطه پایانی جدید است. 3GPP فرآیندهای مربوطه 5G را در TS38.413 پس از فعال کردن IAB، برش، موقعیت‌یابی و فناوری‌های محدوده به شرح زیر تعریف می‌کند:   I. پردازش مجوز IAB   اگر پیام PATH SWITCH REQUEST ACKNOWLEDGE شامل IE مجوز IAB باشد، گره NG-RAN (در صورت پشتیبانی) باید اطلاعات مجوز IAB دریافت شده را در زمینه UE ذخیره کرده و همانطور که در TS 38.401 مشخص شده است، از آن استفاده کند.   اگر پیام PATH SWITCH REQUEST ACKNOWLEDGE شامل IE مجوز Mobile IAB باشد، گره NG-RAN (در صورت پشتیبانی) باید وضعیت مجوز Mobile IAB دریافت شده را در زمینه UE Mobile IAB-MT ذخیره کند. اگر IE مجوز Mobile IAB از Mobile IAB-MT روی "غیرمجاز" تنظیم شده باشد، گره NG-RAN (در صورت پشتیبانی) باید اطمینان حاصل کند که گره Mobile IAB به هیچ UE خدمات ارائه نمی‌دهد.   II. NSSAI و محدوده و موقعیت‌یابی   اگر IE "NSSAI مجاز جزئی" در پیام Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) گنجانده شده باشد، گره NG-RAN (در صورت پشتیبانی) باید برش شبکه مجاز جزئی را برای UE از آن استنباط کند، هر "NSSAI مجاز جزئی" قبلاً دریافت شده را ذخیره و جایگزین کند و همانطور که در TS 23.501 مشخص شده است، از آن استفاده کند.   اگر IE "اطلاعات سرویس موقعیت‌یابی و مسیر جانبی" در پیام Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) گنجانده شده باشد، گره NG-RAN (در صورت پشتیبانی) باید اطلاعات سرویس موقعیت‌یابی و مسیر جانبی UE را بر این اساس به‌روزرسانی کند. اگر IE "مجوز موقعیت‌یابی و مسیر جانبی" در IE اطلاعات سرویس موقعیت‌یابی و مسیر جانبی روی "غیرمجاز" تنظیم شده باشد، گره NG-RAN (در صورت پشتیبانی) باید اقداماتی را برای اطمینان از اینکه UE دیگر به خدمات موقعیت‌یابی و مسیر جانبی دسترسی ندارد، انجام دهد.   III. رویه گزارش انتقال غیرفعال RRC   اگر IE درخواست گزارش انتقال غیرفعال RRC در پیام Path Switch Request Acknowledgement گنجانده شده باشد و روی "گزارش وضعیت اتصال RRC واحد" تنظیم شده باشد و UE در حالت RRC_CONNECTED باشد، گره NG-RAN (در صورت پشتیبانی) باید یک پیام گزارش انتقال غیرفعال RRC را به AMF ارسال کند تا وضعیت RRC UE را گزارش دهد.   اگر IE درخواست گزارش انتقال غیرفعال RRC در پیام PATH SWITCH REQUEST ACKNOWLEDGE گنجانده شده باشد و روی "گزارش وضعیت اتصال RRC واحد" تنظیم شده باشد و UE در حالت RRC_INACTIVE باشد، گره NG-RAN باید (در صورت پشتیبانی) یک پیام گزارش انتقال غیرفعال RRC را به AMF ارسال کند و یک پیام گزارش انتقال غیرفعال RRC متعاقب آن پس از انتقال وضعیت RRC به RRC_CONNECTED.   اگر IE درخواست گزارش انتقال غیرفعال RRC در پیام PATH SWITCH REQUEST ACKNOWLEDGE گنجانده شده باشد و روی "گزارش انتقال وضعیت بعدی" تنظیم شده باشد، گره NG-RAN باید (در صورت پشتیبانی) یک پیام RRC INACTIVE TRANSITION REPORT را به AMF ارسال کند تا وضعیت RRC UE را گزارش دهد و یک پیام RRC INACTIVE TRANSITION REPORT متعاقب آن برای گزارش وضعیت RRC UE پس از ورود یا خروج UE از حالت RRC_INACTIVE.   IV. رویه اعلان منبع جلسه PDU   اگر IE انتقال Path Switch Request Acknowledge پیام PATH SWITCH REQUEST ACKNOWLEDGE شامل پارامترهای مرتبط با QoS (به عنوان مثال، IE بودجه تاخیر بسته CN Downlink یا IE بودجه تاخیر بسته CN Uplink) باشد، اما گره NG-RAN قادر به پذیرش موفقیت‌آمیز پارامترها نباشد، گره NG-RAN باید به استفاده از مقادیر قدیمی (در صورت وجود) دریافت شده از گره NG-RAN منبع ادامه دهد. در صورت پشتیبانی، گره NG-RAN باید با ارسال یک پیام PDU SESSION RESOURCE NOTIFY به AMF اطلاع دهد.    

  هدف از فرآیند درخواست مسیر انتقال، ایجاد اتصال سیگنالینگ مربوطه بین ترمینال (UE) و 5GC و، در صورت وجود، درخواست نقطه پایانی پایین‌رونده حامل انتقال NG-U برای انتقال به یک نقطه پایانی جدید است. برای انتقال سرویس‌های مرتبط با UE در رابط PC5 در Sildlink، 3GPP آن را در TS38.413 به شرح زیر تعریف می‌کند:   I. پردازش PC5 QoS درخواست مسیر در انتقال رابط PC5 در Sildlink به شرح زیر تعریف شده است:   اگر پیام Path Switch Request Acknowledge (تایید درخواست تغییر مسیر) شامل IE پارامتر PC5 QoS باشد، گره NG-RAN باید (در صورت پشتیبانی) از آن همانطور که در TS 23.287 تعریف شده است، استفاده کند. اگر پیام Path Switch Request Acknowledge (تایید درخواست تغییر مسیر) شامل IE پارامتر A2X PC5 QoS باشد، گره NG-RAN باید (در صورت پشتیبانی) از آن همانطور که در TS 23.256 تعریف شده است، استفاده کند. اگر پیام Path Switch Request Acknowledge شامل IE لیست مجموعه پارامتر QoS جایگزین باشد، گره NG-RAN باید (در صورت پشتیبانی) از آن همانطور که در TS 23.502 مشخص شده است، استفاده کند. II. درخواست مسیر در CE-mode-B و User Plane CIoT انتقال به شرح زیر تعریف شده است:   اگر پیام Path Switch Request Acknowledge شامل IE محدودیت CE-mode-B باشد، IE محدودیت پوشش پیشرفته روی "محدود شده" تنظیم نشده باشد و اطلاعات محدودیت پوشش پیشرفته ذخیره شده در زمینه UE روی "محدود شده" تنظیم نشده باشد، گره NG-RAN باید (در صورت پشتیبانی) این اطلاعات را در زمینه UE ذخیره کرده و از آن همانطور که در TS 23.501 تعریف شده است، استفاده کند. اگر پیام Path Switch Request Acknowledge شامل IE نشانگر پشتیبانی User Plane CIoT UE باشد، گره NG-RAN باید (در صورت پشتیبانی) این اطلاعات را در زمینه UE ذخیره کرده و فرض کند که UE از بهینه‌سازی User Plane CIoT 5GS همانطور که در TS 23.501 مشخص شده است، پشتیبانی می‌کند. اگر پیام Path Switch Request Acknowledge شامل IE شناسه قابلیت رادیویی UE باشد، گره NG-RAN باید (در صورت پشتیبانی) از آن همانطور که در TS 23.501 و TS 23.502 مشخص شده است، استفاده کند. III. فعالیت UE مورد انتظار PDU Session و درخواست مسیر در MDT انتقال به شرح زیر تعریف شده است: برای هر PDU Session، اگر پیام PATH SWITCH REQUEST ACKNOWLEDGE شامل IE "رفتار فعالیت UE مورد انتظار PDU Session" باشد، گره NG-RAN باید (در صورت پشتیبانی) این اطلاعات را همانطور که در TS 23.501 مشخص شده است، پردازش کند. اگر پیام PATH SWITCH REQUEST ACKNOWLEDGE شامل IE "لیست PLMN MDT مبتنی بر مدیریت" باشد، گره NG-RAN باید آن را در زمینه UE ذخیره کرده و، در صورت پشتیبانی، از این لیست برای اجازه انتخاب بعدی UE برای MDT مبتنی بر مدیریت همانطور که در TS 32.422 تعریف شده است، استفاده کند. اگر پیام PATH SWITCH REQUEST ACKNOWLEDGE شامل IE "لیست اصلاح PLMN MDT مبتنی بر مدیریت" باشد، گره NG-RAN (در صورت پشتیبانی) باید از این لیست برای بازنویسی هرگونه اطلاعات لیست PLMN MDT مبتنی بر مدیریت که قبلاً در زمینه UE ذخیره شده است، استفاده کند و از اطلاعات دریافتی برای اجازه انتخاب بعدی UE برای MDT مبتنی بر مدیریت همانطور که در TS 32.422 تعریف شده است، استفاده کند. اگر پیام PATH SWITCH REQUEST ACKNOWLEDGE شامل IE اطلاعات کمک همگام‌سازی زمان باشد، گره NG-RAN (در صورت پشتیبانی) باید این اطلاعات را در زمینه UE ذخیره کرده و از آن همانطور که در TS 23.501 تعریف شده است، استفاده کند. IV. درخواست مسیر در 5G ProSe انتقال به شرح زیر تعریف شده است: اگر پیام PATH SWITCH REQUEST ACKNOWLEDGE شامل IE مجاز 5G ProSe باشد، گره NG-RAN (در صورت پشتیبانی) باید اطلاعات مجوز ProSe خود را برای UE بر این اساس به‌روزرسانی کند. اگر اطلاعات مجوز 5G ProSe (IE مجاز 5G ProSe) شامل یک یا چند IE باشد که روی "غیرمجاز" تنظیم شده است، گره NG-RAN (در صورت پشتیبانی) باید اقداماتی را برای اطمینان از اینکه UE دیگر به سرویس‌های 5G ProSe مرتبط دسترسی ندارد، انجام دهد. اگر IE پارامترهای PC5 QoS 5G ProSe در پیام PATH SWITCH REQUEST ACKNOWLEDGE گنجانده شده باشد، گره NG-RAN (در صورت پشتیبانی) باید از آن همانطور که در TS 23.304 تعریف شده است، استفاده کند. اگر IE اطلاعات اشتراک UE هوایی در پیام PATH SWITCH REQUEST ACKNOWLEDGE گنجانده شده باشد، گره NG-RAN (در صورت پشتیبانی) باید این اطلاعات را ذخیره کند یا هرگونه اطلاعات ذخیره شده قبلی را در زمینه UE بازنویسی کرده و از آن همانطور که در TS 38.300 تعریف شده است، استفاده کند. اگر IE حداکثر نرخ بیت تجمعی PC5 UE 5G ProSe در پیام PATH SWITCH REQUEST ACKNOWLEDGE گنجانده شده باشد، گره NG-RAN باید (در صورت پشتیبانی) اقدامات زیر را انجام دهد: جایگزینی حداکثر نرخ بیت تجمعی PC5 UE 5G ProSe که قبلاً ارائه شده است (در صورت موجود بودن در زمینه UE) با مقدار دریافتی؛ استفاده از مقدار دریافتی برای ارتباطات sidelink برای UE مرتبط در حالت زمان‌بندی شبکه برای سرویس 5G ProSe.

  1. تکه کردن شبکه، یک شبکه را به موارد استفاده مستقل تقسیم می‌کند که هر کدام برای ارائه خدمات تخصصی طراحی شده‌اند. در عصر سنتی 4G (LTE)، APN (نام‌های نقطه دسترسی) اولین شکل تکه کردن شبکه در شبکه‌های تلفن همراه بودند که به اپراتورها اجازه می‌دادند شبکه‌های خود را بر اساس الزامات خدمات تقسیم‌بندی کنند.   2. تکه‌های شبکه 5G, تعریف شده توسط 3GPP، شامل نمونه‌های شبکه مستقل با پردازش مستقل صفحه کنترل و کاربر هستند. این تکه‌ها به پشتیبانی از هسته شبکه 5G (5GC) نیاز دارند که فقط در 5G با معماری مستقل (SA) استفاده می‌شود.   3. عناصر و شناسه های شبکه: استقرار تکه کردن در 5G شامل عملکردهای شبکه مانند تجهیزات کاربر (UE)، شبکه دسترسی رادیویی نسل بعدی (NG-RAN)، عملکردهای صفحه کنترل (به عنوان مثال، AMF، PCF، SMF) و عملکردهای صفحه کاربر (به عنوان مثال، UPF) است. هر تکه شبکه توسط یک S-NSSAI (نوع سرویس تکه) شناسایی می‌شود که شامل یک نوع سرویس تکه (SST) برای نشان دادن سرویسی است که تکه شبکه به آن اعمال می‌شود. اپراتورهای شبکه می‌توانند از مقادیر استاندارد SST مانند موارد زیر استفاده کنند: 1 برای پهنای باند موبایل پیشرفته, 2 برای ارتباطات با تأخیر کم و بسیار قابل اطمینان, 3 برای اینترنت اشیا انبوه, 4 برای وسایل نقلیه به همه چیز (V2X), 5 برای ارتباطات نوع ماشین با کارایی بالا. آنها همچنین می‌توانند از مقادیر SST غیر استاندارد و تعریف شده محلی استفاده کنند.   4. پشتیبانی از تکه کردن شبکه ترمینال: برای ترمینال‌های 5G (UE) مستقل (SA) که با USRP (خط‌مشی مسیریابی UE) پیکربندی شده‌اند، می‌توانند S-NSSAI را برای تکه کردن شبکه (سرویس‌ها) بر اساس برنامه مورد نظر (بسته به الزامات کیفیت خدمات برنامه) انتخاب کنند. به عنوان مثال، اولین Galaxy S24 Ultra سامسونگ مجهز به URSP، امکان انتخاب تکه و اجرای سرویس را در سیستم 5G فراهم می‌کند.   5. پشتیبانی از تکه کردن شبکه سیستم: ADC (تشخیص و کنترل) فعال است (یک عملکرد در عناصر هسته شبکه 5G PCF (عملکرد کنترل خط‌مشی) و SMF (عملکرد مدیریت جلسه)). ADC برای شناسایی برنامه‌ها یا ترافیک در سمت شبکه، اعمال خط‌مشی‌هایی مانند کیفیت خدمات، صورت‌حساب یا هدایت مجدد و پیاده‌سازی طبقه‌بندی و اولویت‌بندی ترافیک در زمان واقعی استفاده می‌شود.   6. نمونه‌هایی از استقرار تجاری تکه کردن شبکه: شرکت مخابرات سنگاپور (Singtel) Singtel 5G+ را راه‌اندازی کرده است، یک نوآوری پیشرفته «تکه کردن شبکه» که استانداردی جدید از اتصال و یک تجربه اولویت‌دار را از طریق سه ویژگی کلیدی ارائه می‌دهد: Singtel 5G+: تنها شبکه‌ای که از باند طیف 700 مگاهرتز استفاده می‌کند و پوشش بهینه در سراسر کشور، حتی در داخل ساختمان‌ها را ارائه می‌دهد. Singtel 5G+ پیشرفته: پوشش گسترده‌تر و سرعت‌های بالاتر، با سرعت‌های ثابت تا 2 برابر. Singtel 5G+ Priority: کانال‌های شبکه اولویت‌دار با سرعت‌های 4 برابر سریع‌تر، همیشه خدمات را اولویت‌بندی می‌کند و موارد نوظهور را شناسایی می‌کند.

3GPP موارد زیر را در TS 38.413 در مورد محدودیت پوشش افزایش یافته، زمان اتصال طولانی، مجوز خدمات V2X تعریف می کند،پردازش درخواست مسیر انتقال برای ترمینال های جمع آوری لینک جانبی در سیستم 5G:   I. محدود کردن پوشش بیشتر و افزایش زمان اتصال   اگر پیام تایید درخواست تغییر مسیر (PATH SWITCH REQUEST ACKNOWLEDGE) شاملمحدودیت پوشش افزایش یافته IE، گره NG-RAN باید (اگر پشتیبانی شود) این اطلاعات را در زمینه UE ذخیره کند و آن را همانطور که در TS 23 تعریف شده است استفاده کند.501.   اگر پیام تایید درخواست تغییر مسیر (PATH SWITCH REQUEST ACKNOWLEDGE) شاملزمان اتصال طولانی IE، گره NG-RAN باید (اگر پشتیبانی شود) آن را همانطور که در TS 23 تعریف شده است استفاده کند.501.   اگر پیام Path Switch Request Acknowledgment (PATH SWITCH REQUEST ACKNOWLEDGE) شامل یک UE Differentiation Information IE باشد، گره NG-RAN باید این اطلاعات را دراتحادیه اروپازمینه برای استفاده بیشتر مطابق با TS 23.501.   II. مجوز سرویس NR V2X   اگر پیام PATH SWITCH REQUEST ACKNOWLEDGE شامل IE مجوز سرویس NR V2X باشد،گره NG-RAN (اگر پشتیبانی می شود) باید اطلاعات مجوز سرویس NR V2X خود را برای UE به این ترتیب به روزرسانی کند.   اگر IE مجوز سرویس NR V2X شامل یک یا چند IE است که به "غیر مجاز" تنظیم شده است،" گره NG-RAN (اگر پشتیبانی شود) باید اقدامات لازم را انجام دهد تا اطمینان حاصل شود که UE دیگر به خدمات مرتبط دسترسی ندارد.   اگر پیام PATH SWITCH REQUEST ACKNOWLEDGE شامل IE مجوز سرویس LTE V2X باشد،گره NG-RAN (اگر پشتیبانی می شود) باید اطلاعات مجوز سرویس LTE V2X خود را برای UE به این ترتیب به روزرسانی کند..اگر IE مجوز سرویس LTE V2X حاوی یک یا چند IE با تنظیم "غیر مجاز" باشد" گره NG-RAN (اگر پشتیبانی می شود) باید اقدامات را انجام دهد تا اطمینان حاصل شود که UE دیگر به خدمات مرتبط دسترسی ندارد.   اگر مجوز سرویس NR A2X IE حاوی یک یا چند IE باشد که روی "غیر مجاز" تنظیم شده باشد،" گره NG-RAN (اگر پشتیبانی می شود) باید اقدامات را انجام دهد تا اطمینان حاصل شود که UE دیگر به خدمات مرتبط دسترسی ندارد.   اگر پیام تایید درخواست تغییر مسیر (PATH SWITCH REQUEST ACKNOWLEDGE) حاوی IE مجوز سرویس LTE A2X باشد،گره NG-RAN (اگر پشتیبانی می شود) باید اطلاعات مجوز سرویس LTE A2X خود را برای UE به این ترتیب به روزرسانی کند.   اگر IE مجوز سرویس LTE A2X حاوی یک یا چند IE است که به "غیر مجاز" تنظیم شده است،" گره NG-RAN (اگر پشتیبانی می شود) باید اقدامات را انجام دهد تا اطمینان حاصل شود که UE دیگر به خدمات مرتبط دسترسی ندارد.   III. پیوند جانبی و پردازش جمع بندی   اگر پیام PATH SWITCH REQUEST ACKNOWLEDGE حاوی NR UE Sidelink Aggregate Maximum Bit Rate IE باشد، گره NG-RAN (اگر پشتیبانی شود) باید عملیات زیر را انجام دهد: مقدار داده شده را با مقدار داده شده جایگزین کنید. استفاده از مقدار دریافت شده برای ارتباطات لینک جانبی با UE مرتبط در حالت برنامه ریزی شبکه NR V2X.   اگر پیام PATH SWITCH REQUEST ACKNOWLEDGE حاوی LTE UE Sidelink Aggregate Maximum Bit Rate IE باشد، گره NG-RAN (اگر پشتیبانی شود) باید عملیات زیر را انجام دهد: مقدار داده شده را با مقدار داده شده جایگزین کنید. استفاده از مقدار دریافت شده برای ارتباطات لینک جانبی با UE مرتبط در حالت برنامه ریزی شبکه LTE V2X. اگر پیامی PATH SWITCH REQUEST ACKNOWLEDGE شامل حداکثر بیت ریت مجموع NR A2X UE PC5 IE باشد، گره NG-RAN (اگر پشتیبانی شود) باید عملیات زیر را انجام دهد: در صورت وجود در زمینه UE، حداکثر نرخ بیت NR A2X UE PC5 که قبلاً ارائه شده است (اگر در دسترس باشد) با مقدار دریافت شده جایگزین شود. در حالت برنامه ریزی شبکه، از مقدار دریافت شده برای ارتباطات لینک جانبی سرویس NR A2X برای UE مرتبط استفاده کنید. اگر پیام PATH SWITCH REQUEST ACKNOWLEDGE شامل مجموع حداکثر بیت ریت LTE A2X UE PC5 IE باشد، گره NG-RAN (اگر پشتیبانی شود) باید عملیات زیر را انجام دهد: در صورت وجود در زمینه UE، حداکثر نرخ بیت LTE A2X UE PC5 را با مقدار دریافت شده جایگزین کنید. در حالت برنامه ریزی شبکه، از مقدار دریافت شده برای ارتباطات لینک جانبی سرویس LTE A2X برای UE مرتبط استفاده کنید.

  در یک سیستم 5G، یک انتقال (Handover) درخواست مسیر درخواستی است توسط یک ترمینال (UE) برای برقراری یک اتصال سیگنالینگ مرتبط با UE با 5GC و، در صورت وجود، درخواست اینکه نقطه پایانی پایین‌رونده حامل حمل و نقل NG-U به یک نقطه پایانی جدید تغییر یابد. از آنجایی که 5G از تعداد فزاینده‌ای از انواع سرویس‌ها پشتیبانی می‌کند، محتوای درخواست‌های مسیر در طول انتقال‌ها پیچیده‌تر خواهد شد. 3GPP این را در TS 38.413 به شرح زیر تعریف می‌کند.   I. بودجه تاخیر بسته   اگر IE بودجه تاخیر بسته CN پایین‌رونده در IE حمل و نقل تایید درخواست تغییر مسیر پیام تایید درخواست تغییر مسیر (PATH SWITCH REQUEST ACKNOWLEDGE) گنجانده شود، گره NG-RAN باید (در صورت پشتیبانی) بودجه تاخیر بسته CN پایین‌رونده ارائه شده قبلی (در صورت وجود) را جایگزین کرده و از آن به شرح مشخص شده در TS 23.502 استفاده کند.   اگر IE بودجه تاخیر بسته CN بالارونده در IE حمل و نقل تایید درخواست تغییر مسیر پیام تایید درخواست تغییر مسیر (PATH SWITCH REQUEST ACKNOWLEDGE) گنجانده شود، گره NG-RAN باید (در صورت پشتیبانی) بودجه تاخیر بسته CN بالارونده ارائه شده قبلی (در صورت وجود) را جایگزین کرده و از آن به شرح مشخص شده در TS 23.502 استفاده کند.   II. رسیدگی به داده‌های انفجاری   اگر IE زمان رسیدن انفجاری پایین‌رونده در IE حمل و نقل تایید درخواست تغییر مسیر پیام تایید درخواست تغییر مسیر گنجانده شود، گره NG-RAN باید (در صورت پشتیبانی) مقدار ارائه شده قبلی (در صورت وجود) را جایگزین کرده و از آن به شرح مشخص شده در TS 23.502 استفاده کند.   III. رسیدگی به اطلاعات کمکی RRC غیرفعال و شبکه هسته   اگر اطلاعات کمکی شبکه هسته از IE RRC غیرفعال در پیام تایید درخواست تغییر مسیر گنجانده شود، گره NG-RAN (در صورت پشتیبانی) باید این اطلاعات را در زمینه UE ذخیره کرده و از آن برای تصمیم‌گیری‌های حالت RRC_INACTIVE و پیکربندی RNA و صفحه‌بندی RAN UE (در صورت وجود)، همانطور که در TS 38.300 توضیح داده شده است، استفاده کند.   اگر اطلاعات کمکی شبکه هسته از IE RRC غیرفعال شامل IE MICO All PLMN باشد، گره NG-RAN (در صورت پشتیبانی) باید ناحیه ثبت نام UE را به عنوان PLMN کامل در نظر گرفته و لیست TAI از IE RRC غیرفعال را نادیده بگیرد.   اگر اطلاعات کمکی شبکه هسته از IE RRC غیرفعال شامل IE نشانگر علت صفحه‌بندی سرویس صوتی باشد، گره NG-RAN (در صورت پشتیبانی) باید آن را ذخیره کرده و همانطور که در TS 38.300 مشخص شده است، استفاده کند.   اگر اطلاعات کمکی شبکه هسته از IE RRC غیرفعال شامل IE اطلاعات کمکی PEIPS باشد، گره NG-RAN (در صورت پشتیبانی) باید آن را ذخیره کرده و از آن برای زیرگروه‌های صفحه‌بندی UEها در حالت RRC_INACTIVE، همانطور که در TS 38.300 توضیح داده شده است، استفاده کند.   اگر IE رسیدگی به ارتباطات CN MT در اطلاعات کمکی شبکه هسته (IE RRC غیرفعال) گنجانده شود، گره NG-RAN باید (در صورت پشتیبانی) این IE را ذخیره کند و ممکن است متعاقباً از CN درخواست کند تا رسیدگی به ارتباطات MT را انجام دهد، همانطور که در TS 23.502 توضیح داده شده است، بسته به پیاده‌سازی.   اگر IE تنظیم پارامتر RAN کمکی CN در پیام تایید درخواست تغییر مسیر (PATH SWITCH REQUEST ACKNOWLEDGE) گنجانده شود، گره NG-RAN ممکن است از این IE همانطور که در TS 23.501 توضیح داده شده است، استفاده کند.   اگر IE درخواست گزارش انتقال RRC غیرفعال در پیام تایید درخواست تغییر مسیر (PATH SWITCH REQUEST ACKNOWLEDGE) گنجانده شود، گره NG-RAN باید (در صورت پشتیبانی) این اطلاعات را در زمینه UE ذخیره کند.   V. پردازش EPS و SRVCC   اگر پیام تایید درخواست تغییر مسیر (PATH SWITCH REQUEST ACKNOWLEDGE) شامل IE بازگشت به EPS هدایت مجدد برای صدا باشد، گره NG-RAN باید (در صورت پشتیبانی) این IE را ذخیره کرده و در تصمیم‌گیری‌های بعدی بازگشت به EPS صوتی همانطور که در TS 23.502 مشخص شده است، استفاده کند.   اگر پیام تایید درخواست تغییر مسیر (PATH SWITCH REQUEST ACKNOWLEDGE) حاوی اطلاعات IE عملیات SRVCC ممکن باشد، گره NG-RAN باید (در صورت پشتیبانی) محتوای IE عملیات SRVCC ممکن دریافت شده را در زمینه UE ذخیره کرده و از آن به شرح تعریف شده در TS 23.216 استفاده کند.