بين جهاز UE متصل بالكامل وآخر في حالة خمول كامل، يقدّم الجيل الخامس حالة تبدو هادئة من جهة المستخدم، لكنها تظل ذات أهمية تقنية داخل NG-RAN. هذه الحالة هي RRC Inactive. وقد أُضيفت إلى إدارة الاتصالات في 5G لحل مشكلة عملية: تحتاج أجهزة كثيرة إلى العودة سريعاً إلى نقل البيانات، لكن إبقاء جميع الأجهزة في RRC Connected طوال الوقت سيهدر موارد الإشارات والموارد الراديوية وطاقة البطارية.

قد يتحقق الهاتف الذكي من الرسائل في الخلفية، وقد يرسل المستشعر دفعات قصيرة من البيانات، وقد يستيقظ تطبيق لفترة وجيزة بعد صمت طويل. لا تبرر أنماط الحركة هذه دائماً العودة الكاملة إلى حالة الخمول ثم تنفيذ إجراء كامل لإنشاء الاتصال. توفر RRC Inactive طبقة وسطى، إذ يستطيع UE خفض نشاطه والاحتفاظ بالسياق الأساسي واستئناف الاتصال بسرعة أكبر عند ظهور بيانات صاعدة أو هابطة.

النقطة المهمة هي أن RRC Inactive ليست هي RRC Idle. ففي RRC Idle يكون UE أيضاً في CM-IDLE من منظور الشبكة الأساسية. أما في RRC Inactive فيبقى UE في CM-CONNECTED، بينما تُعلّق طبقة RRC عن التشغيل النشط المتصل. يحتفظ gNodeB بسياق UE، ويحتفظ UE بسياق AS، ويمكن للشبكة إعادة UE إلى RRC Connected عبر إجراء استئناف بدلاً من البدء من الصفر.

لماذا يحتاج 5G إلى هذه الحالة

يجب على إدارة اتصالات 5G خدمة أنواع كثيرة من الحركة في الوقت نفسه. تحتاج بعض الخدمات إلى معدل نقل مرتفع واتصال مستمر، بينما لا تحتاج أخرى إلا إلى تبادل قصير ومتقطع للبيانات. وقد تظل بعض المحطات صامتة لفترات طويلة، لكنها يجب أن تستجيب بسرعة عندما تحتاج إليها الشبكة أو التطبيقات. إذا بقي كل UE في RRC Connected فستتحمل الشبكة عبئاً تحكمياً غير ضروري. وإذا نُقل كل UE غير نشط بالكامل إلى RRC Idle فقد تصبح استعادة الاتصال أبطأ وأكثر استهلاكاً للإشارات.

تقلل RRC Inactive هذه الفجوة. يستطيع UE إيقاف المعالجة النشطة للبيانات بالمعنى المرتبط بـRRC Connected، من دون التخلص من سياق طبقة النفاذ المهم. وهذا يسمح لإجراء استئناف لاحق باستعادة الاتصال بسرعة أكبر. من منظور تجربة المستخدم، يظل الجهاز سريع الاستجابة. ومن منظور الشبكة، يتجنب النظام الاحتفاظ بالموارد النشطة مدة أطول من الحاجة.

يفيد هذا التصميم بصورة خاصة التطبيقات التي تستيقظ كثيراً من دون الحفاظ على جلسات طويلة. ويمكن لخدمات المراسلة والمزامنة في الخلفية وتقارير المستشعرات المتقطعة ودفعات البيانات الصاعدة الصغيرة والإشعارات الهابطة القصيرة الاستفادة من حالة تدعم العودة الأسرع إلى التشغيل المتصل.

ومن منظور معمارية الشبكة، تفيد RRC Inactive أيضاً لأنها تنقل جزءاً من مسؤولية التنقل والنداء إلى NG-RAN. ولا يحتاج AMF إلى اعتبار كل حركة داخل منطقة إشعار RAN محلية حدث تنقل في الشبكة الأساسية. ويمكن لـgNodeB إدارة سياق UE وسلوك النداء المحلي بكفاءة أكبر.

كيف تُعرّف هذه الحالة

تتميز RRC Inactive بعدة خصائص أساسية. أولاً، يظل UE مصنفاً في CM-CONNECTED. وهذا فرق رئيسي عن RRC Idle، حيث يكون UE أيضاً في CM-IDLE. وتظل علاقة الاتصال مع نواة 5G قائمة، حتى وإن لم يكن اتصال RRC ينقل بصورة نشطة بيانات الوضع المتصل العادية.

ثانياً، تكون هذه الحالة شفافة إلى حد كبير للشبكة الأساسية. ففي التشغيل العادي لا يحتاج AMF إلى إدارة RRC Inactive مباشرة بالطريقة نفسها التي يديرها بها NG-RAN. ويحتفظ آخر gNodeB خدم UE بسياقه ويعرف RAN Notification Area التي ينتمي إليها. وهذا الاحتفاظ بالسياق هو ما يتيح الاستعادة السريعة.

ثالثاً، يحتفظ UE وgNodeB بسياق طبقة AS. وبما أن سياق طبقة النفاذ محفوظ، فلا يحتاج UE إلى إعداد جديد كامل عند استئناف الخدمة. وبدلاً من ذلك يمكنه استخدام إجراء RRC Resume للعودة إلى RRC Connected.

يحدث الانتقال إلى RRC Inactive من خلال رسالة RRC Release تتضمن إعداد التعليق. ولهذا تُناقش هذه الحالة غالباً مع إجراءات التعليق والاستئناف. تحرر الشبكة اتصال RRC النشط، لكنها تطلب من UE تعليق سياقه بدلاً من التخلص منه بالكامل.

عندما يصبح النشاط مطلوباً من جديد، يستطيع UE الانتقال من RRC Inactive إلى RRC Connected. وقد يحدث ذلك عندما تكون لديه بيانات صاعدة لإرسالها أو عندما يتلقى نداء RAN بسبب بيانات هابطة. وإذا استمرت حالة عدم النشاط مدة طويلة، فقد يؤدي UE Inactivity Timer في gNodeB في النهاية إلى تحرير N2 ونقل UE نحو RRC Idle وCM-IDLE.

ما الذي يستطيع UE مواصلة تنفيذه

لا تعني RRC Inactive أن UE متوقف تماماً. تظل عدة إجراءات ممكنة حتى عندما لا يكون UE نشطاً في RRC Connected. يستطيع UE اختيار PLMN واستقبال بث معلومات النظام وإجراء إعادة اختيار الخلية والاستجابة للنداء الذي يبدأه RAN. وتساعد هذه الوظائف UE على البقاء قابلاً للوصول من دون الاحتفاظ باتصال RRC نشط بالكامل.

ويظل جانب الشبكة نشطاً بطرق محددة أيضاً. يدير NG-RAN منطقة RAN Notification Area، ويضبط DRX لنداء RAN، ويحتفظ بسياق AS الخاص بـUE. ويعرف gNodeB إلى أي RNA ينتمي UE، ولذلك يمكنه تحديد نطاق النداء المحلي عندما تتطلب البيانات أو الإشارات استئناف UE.

ومن النقاط المهمة أيضاً أن سياق اتصالي N2 وN3 يمكن أن يظل قائماً لـUE في نموذج التشغيل هذا. ويصبح ذلك مهماً عند وصول بيانات هابطة. فقد يظل UPF عارفاً بعنوان gNodeB ويرسل البيانات الهابطة إلى آخر gNodeB خدم UE. ثم يطلق gNodeB النداء داخل RNA المضبوطة بدلاً من فرض إجراء نداء للشبكة الأساسية من البداية.

توضح هذه العناصر المحتفظ بها سبب فائدة RRC Inactive، كما توضح أنها أكثر تعقيداً من سلوك الخمول البسيط. يجب أن تحتفظ الشبكة بسياق كافٍ للاستعادة السريعة، لكن من دون تخصيص موارد نشطة كثيرة تجعل الحالة مكافئة لـRRC Connected. وتكمن قيمة هذه الحالة في هذا التوازن التصميمي.

كيف تتحكم RNA في التنقل

تعني RNA عبارة RAN Notification Area. وهي منطقة إشعار على جانب RAN تُستخدم لأجهزة UE الموجودة في RRC Inactive. تتكون RNA من عدة خلايا، عادة ضمن Tracking Area واحدة. وعندما يتحرك UE داخل RNA المخصصة له، لا يحتاج إلى إبلاغ الشبكة في كل مرة يغير فيها الخلية، ما يمنع الإشارات غير الضرورية عند الحركة المحلية فقط.

تُعرّف RNA بواسطة RNA ID. ويتكون المعرّف من TAC وRAN Area Code، ويتراوح RAN Area Code من 0 إلى 255. وعملياً يمنح ذلك NG-RAN طريقة مدمجة لتعريف مناطق محلية يستطيع فيها UE غير النشط التحرك من دون تحديثات متكررة.

يخصص آخر gNodeB خدم UE معرّف RNA ID عبر إعداد التعليق في رسالة RRC Release. وهذه نقطة مهمة لأن gNodeB الذي خدم UE أخيراً يصبح مسؤولاً عن معرفة سياق RNA الخاص به. وإذا ظهرت لاحقاً بيانات هابطة، يستطيع ذلك gNodeB تحديد كيفية نداء UE داخل المنطقة المناسبة.

ومع ذلك يجب على UE تحديث الشبكة في ظروف معينة. فإذا انتهى مؤقت التحديث الدوري لـRNA أو غادر UE منطقة RNA المضبوطة، فعليه بدء إجراء تحديث RNA. ويمنع ذلك NG-RAN من فقد المعرفة العملية بالمنطقة المحلية لـUE، مع تجنب الإشارات المفرطة أثناء الحركة العادية داخل RNA.

يؤثر تصميم RNA في كفاءة النداء. فقد تسبب RNA صغيرة جداً تحديثات متكررة عند تحرك UE، بينما قد تزيد RNA كبيرة جداً عبء النداء لأن عدداً أكبر من الخلايا قد يحتاج إلى النداء عند وصول بيانات هابطة. لذلك يعتمد التخطيط الجيد على أنماط حركة المستخدمين وتوزيع الخلايا وحدود gNodeB وسلوك الخدمة المتوقع.

كيف تُسلّم البيانات الهابطة

تُعد معالجة البيانات الهابطة من أوضح الأمثلة على سبب وجود RRC Inactive. فعندما تصل بيانات هابطة من UPF بينما يكون UE في RRC Inactive، يمكن إرسالها إلى آخر gNodeB خدم UE. ثم يبدأ gNodeB النداء داخل RNA لأنه يعرف أن UE غير نشط لكنه قابل للوصول محلياً عبر النداء على مستوى RAN.

إذا كانت جميع خلايا RNA تابعة لآخر gNodeB خدم UE، تكون العملية مباشرة نسبياً. ينادي gNodeB جهاز UE في الخلايا المعنية. ويتلقى UE رسالة RAN Paging ويبدأ إجراء RRC Resume ويعود إلى RRC Connected. وبعد الاستئناف يستطيع UE استقبال البيانات الهابطة.

إذا تضمنت RNA خلايا تخدمها gNodeB مجاورة، فقد يستخدم آخر gNodeB خدم UE إشارات Xn. ويمكنه إرسال رسالة XnAP RAN Paging إلى gNodeB المجاور كي يحدث النداء في تلك الخلايا أيضاً. وبهذا يتبع نطاق النداء RNA بدلاً من اقتصاره على خلايا آخر gNodeB وحده.

تنطبق الفكرة العامة نفسها عندما تصل من AMF إشارات هابطة مرتبطة بـUE، باستثناء حالات مثل UE Context Release Command التي تُعالج عبر مسار مختلف. والنقطة الأساسية هي أن NG-RAN يستطيع إدارة نداء UE غير النشط من دون التعامل معه فوراً كحالة نداء كاملة للشبكة الأساسية في وضع الخمول.

من منظور الخدمة، تعتمد تجربة المستخدم على سرعة تلقي UE للنداء وإتمام الاستئناف. ومن منظور الشبكة، يستفيد النظام من إعادة استخدام السياق وجعل الإشارات أكثر محلية.

كيف تعمل انتقالات الاستئناف

يمكن أن تعود RRC Inactive إلى RRC Connected من جانب UE أو من جانب الشبكة. يحدث الانتقال الذي يبدأه UE عندما تكون لديه بيانات صاعدة أو حاجة إلى الإشارات. يرسل UE طلب RRC Resume Request إلى gNodeB. وإذا لم يكن gNodeB الحالي هو آخر gNodeB خدم UE، فقد يحتاج إلى استرجاع سياق UE من ذلك gNodeB قبل إكمال الاستئناف.

قد تتضمن العملية النموذجية التي يبدأها UE رسائل RRC Resume Request وRetrieve UE Context Request وRetrieve UE Context Response وRRC Resume وRRC Resume Complete. وإذا تغير gNodeB الخادم، فقد تلزم إجراءات إضافية مثل Xn-U Address Indication وPath Switch Request باتجاه AMF. وبعد معالجة تبديل المسار يمكن تحرير السياق القديم عند الحاجة.

يبدأ الانتقال الذي تطلقه الشبكة بطريقة مختلفة. يتلقى آخر gNodeB خدم UE بيانات هابطة أو إشارات ذات صلة، ثم يطلق RAN Paging. ويُنادَى UE داخل RNA. وبعد تلقي النداء يستأنف UE من RRC Inactive ويعود إلى RRC Connected لمعالجة البيانات أو الإشارات المعلقة.

صُممت هذه الانتقالات لتكون أخف من إنشاء اتصال كامل انطلاقاً من وضع الخمول، لكنها ليست إجراءات بسيطة. يعتمد السلوك الصحيح على السياق المخزن وتنسيق gNodeB وتبديل المسار في AMF عند الحاجة والتحرير المنظم للسياق بعد إنشاء مسار الخدمة الجديد.

ومسار المؤقت مهم أيضاً. فإذا ظل UE غير نشط مدة تتجاوز سياسة UE Inactivity Timer في gNodeB، يمكن للشبكة نقله إلى RRC Idle. ويتضمن ذلك عادة تحرير N2 وتغيير حالة الشبكة الأساسية إلى CM-IDLE. وعند هذه النقطة لا تعود مزايا الاستئناف السريع لـRRC Inactive سارية.

كيف يتلقى AMF تقارير الحالة

غالباً ما توصف RRC Inactive بأنها شفافة للشبكة الأساسية، لكن هذا الوصف يحتاج إلى تفسير دقيق. فعموماً لا يتحكم AMF مباشرة في حالة RRC الخاصة بـUE بالطريقة نفسها التي يفعلها NG-RAN. ومع ذلك يستطيع AMF طلب تقارير انتقالات حالة RRC عبر إشارات NGAP.

يمكن لـAMF تضمين معامل RRC Inactive Transition Report Request في رسائل مثل Initial Context Setup Request أو UE Context Modification Request. وعندما يُضبط الطلب لتقرير انتقالات الحالة اللاحقة، يجب على gNodeB الإبلاغ عند دخول UE إلى RRC Inactive أو خروجه منها.

عند حدوث تغير في الحالة، يرسل gNodeB تقرير RRC Inactive Transition Report إلى AMF. ويتضمن التقرير قيمة RRC State مثل Inactive أو Connected. وتمنح هذه الآلية AMF رؤية الحالة عندما يطلبها، من دون تغيير الحقيقة الأساسية بأن NG-RAN هو الذي يدير سلوك RRC Inactive.

تفيد قدرة الإبلاغ هذه في تنسيق الشبكة والوعي بالسياسات والمراقبة التشغيلية. كما توضح لماذا لا ينبغي وصف RRC Inactive ببساطة بأنها غير مرئية تماماً للشبكة الأساسية. والأدق أنها حالة يديرها RAN أساساً، بينما يستطيع AMF الحصول على معلومات انتقال الحالة في ظروف محددة.

هذا التمييز مهم في التحليل الهندسي. فإذا فشل إجراء ما، فقد يتطلب استكشاف الأعطال مراجعة سلوك RAN وسلوك تقارير NGAP معاً. ويمكن لحالة UE وسياق gNodeB وإعداد RNA وRAN Paging وطلب تقرير AMF ومعالجة تبديل المسار أن تؤثر جميعاً في النتيجة النهائية.

الأسئلة الشائعة

لماذا لا تساوي RRC Inactive حالة RRC Idle؟

تحافظ RRC Inactive على UE في CM-Connected وتحتفظ بسياق طبقة النفاذ، بينما تمثل RRC Idle علاقة خمول مع الشبكة الأساسية تتطلب فيها استعادة الاتصال إجراء أثقل.

ما الذي يطلق استئناف UE من RRC Inactive؟

قد يبدأ الاستئناف بسبب بيانات صاعدة من UE، أو حاجة UE إلى الإشارات، أو RAN Paging ناتج عن بيانات هابطة أو إشارات هابطة مدعومة.

لماذا تقلل RNA الإشارات؟

تسمح RNA لـUE بالتحرك داخل منطقة إشعار RAN محددة من دون إبلاغ الشبكة بكل تغير في الخلية، ما يقلل إشارات التنقل المحلية غير الضرورية.

ماذا يحدث إذا غادر UE منطقة RNA الخاصة به؟

ينبغي على UE بدء إجراء تحديث RNA كي يستطيع NG-RAN تحديث معلومات المنطقة المستخدمة للنداء المحلي وإمكانية الوصول في الحالة غير النشطة.

لماذا قد تشارك gNodeB المجاورة في النداء؟

إذا تضمنت RNA خلايا تخدمها gNodeB مجاورة، فقد يرسل آخر gNodeB خدم UE رسالة XnAP RAN Paging كي تتمكن تلك الخلايا المجاورة أيضاً من نداء UE.

متى يعرف AMF بتغيرات حالة RRC؟

يمكن لـAMF تلقي تقارير انتقال الحالة عندما يطلبها عبر معامل RRC Inactive Transition Report Request في إجراءات NGAP المدعومة.

تُعد RRC Inactive من أكثر تحسينات إدارة الاتصالات في 5G فائدة عملية. فهي تحتفظ بسياق كافٍ للاستئناف السريع، وتقلل الاستخدام غير الضروري لموارد الاتصال النشط، وتدعم الحركة المحلية عبر RNA، وتتيح لـNG-RAN إدارة النداء بكفاءة أكبر. وتأتي قيمتها من التوازن: أسرع من العودة من الخمول الكامل، وأخف من البقاء متصلاً بالكامل، ومرنة بما يكفي لدعم أنماط الحركة الحديثة للبيانات المتنقلة.