5G RedCap في أبريل 2026: من ينشر، وما الّذي يتغيّر في الاختبارات، وكيف تتحقّق من وحدة على شبكة تجاريّة

مدير منتج وحدات IoT في شركة OEM صناعيّة في الرياض في أبريل 2026 يحمل وحدة Quectel RG255C-EU جرى لحامها للتوّ على لوحة المرجعيّة لمستشعر مساريب الكاتيناري، ويسأل المُدمِج 5G: «GSA يقول إنّ 42 مُشغِّلًا ينشرون RedCap، لكنّ وحدتي تظلّ مُعسكرةً على LTE في تجربة جدّة. هل RedCap فعّال حقًّا على هذه الشبكة أم لا؟».

سؤال مشروع، ولا يُجاب عليه بالنظر إلى عمود الإشارة في هاتف أندرويد الاختبار، بل بفتح SIB1 الّذي تبثّه الخليّة، وقراءة UECapabilityInformation الّتي ترفعها الوحدة، ومقارنة ما تُعلنه الشبكة بما تطلبه الوحدة. يشرح هذا المقال، استنادًا إلى بيانات ميدانيّة من أبريل 2026، الشبكات الّتي تنشر RedCap حقًّا، وما الّذي تُقيّده Release 17، وكيف تُعامل الشبكة جهاز UE من نوع RedCap بشكل مختلف، والأخطاء الخمسة الّتي تظهر في الإنتاج، وبروتوكولًا تحقّقيًّا ميدانيًّا في 60 دقيقة لإصدار شهادة لوحدتك على شبكة تجاريّة.

لقطة RedCap في أبريل 2026: 42 مُشغِّلًا، 27 دولة، عمليّات نشر تجاريّة حقيقيّة

اللقطة الرسميّة تُوقِّعها GSA في تقريرها «5G RedCap April 2026 Industry Update» على موقع gsacom.com: 42 مُشغِّلًا فعّالًا في 27 دولة يستثمرون في RedCap، سواء في التخطيط أو التجارب أو النشر التجاريّ. ثلاث أسواق تتقدّم بوضوح.

T-Mobile US هو أوّل مُشغِّل في العالم يطلق جهاز RedCap تجاريًّا، في أكتوبر 2024 مع TCL Linkport، ويُكرِّر منذ ذلك الحين على شبكته الوطنيّة 5G SA. تَبِعَه Verizon و AT&T بنشر RedCap على 5G SA في النطاق C. في أوروبا، التجارب الظاهرة في المملكة المتّحدة وفنلندا وجمهوريّة التشيك. في آسيا، تمتلك كوريا الجنوبيّة حالة استخدام رمزيّة في مصنع Hyundai في Ulsan، أكبر منشأة تصنيع سيّارات في العالم في موقع واحد، حيث تُشغِّل Hyundai و Samsung تجربة RedCap على IoT في أرضيّة الإنتاج. والهند وإندونيسيا وماليزيا وتايلاند وتركيا تمتلك تجارب فعّالة. أمّا الشرق الأوسط فيُسهم بـ البحرين وعُمان والمملكة العربيّة السعوديّة.

تتبع منظومة الوحدات منظومة الشبكات. لدى Quectel و Fibocom و Telit Cinterion و Smawave و MeiG وحدات تجاريّة على شرائح Qualcomm و MediaTek و ASR و Sequans. أي أنّ السؤال لم يَعُد «هل RedCap موجود؟» بل «هل الخليّة الّتي سأنشر فيها أسطولي تُعامله بشكل صحيح؟».

ما الّذي تُقيّده 3GPP Release 17 RedCap فعلًا (وما لا تُقيّده)

RedCap ليس 5G مقصوصًا عشوائيًّا، بل هو ملفّ تعريف UE مُعرَّف معياريًّا في 3GPP Release 17، ومُحدَّد بدقّة في TS 38.300 (المعماريّة) و TS 38.331 (RRC) و TS 38.306 (القدرات). يجدر فهم القيود لأنّها تحكم كلّ قرار تصميم في المنتج.

عرض النطاق الأقصى لجهاز UE من نوع RedCap هو 20 MHz في FR1 و 100 MHz في FR2، مقابل 100 MHz / 400 MHz لجهاز eMBB. تُختزل هوائيّات الاستقبال إلى 1 أو 2، مقابل 4 المعتادة في eMBB. أمّا ظرف الإنتاجيّة العمليّ فيدور حول 150 Mbps في الاتّجاه الهابط و 50 Mbps في الاتّجاه الصاعد بإعدادات قياسيّة، وهي أرقام متوافقة مع تقارير اختبارات Keysight و Rohde & Schwarz و VIAVI لمحاكاة أجهزة RedCap. وضع half-duplex FDD (HD-FDD) اختياريّ ويُخفّض كلفة الواجهة الأماميّة. لا يوجد carrier aggregation، ولا dual connectivity، ولا MIMO 4x4.

في الحالات الّتي تظلّ فيها 150 Mbps مكلفة جدًّا، تعمل 3GPP على eRedCap في Release 18، بهدف 5 MHz من عرض النطاق وملفّ تعريف موجَّه إلى IoT منخفض الفئة فعلًا. يُتوقَّع وصوله إلى الوحدات التجاريّة بين 2026 و 2027. يوجد تحليل مُفصَّل في مقال eRedCap: IoT أرخص في Release 18.

الاستنتاج العمليّ من الجدول قاسٍ: في FR1، يمتلك RedCap R17 و LTE Cat-4 سقف إنتاجيّة متشابهًا. ما يتغيّر هو مستوى التحكّم 5G SA، والقدرة على دعم slicing، والمسار التطوّريّ نحو Release 18. إذا كانت حالة الاستخدام «20 Mbps مستقرّة مع IMS اختياريّة»، يظلّ LTE Cat-4 خيارًا قابلًا للدفاع. أمّا إذا احتجتَ slicing أو URSP أو مسارًا نحو 5G-Advanced، فإنّ RedCap هو الخيار المعقول الوحيد. ولفهم كيفيّة إدارة أسطول IMEI لتلك الوحدات في الإنتاج، يفيد قراءة IMEI في IoT و M2M: إدارة الأجهزة على نطاق واسع.

كيف تُعامل شبكة تجاريّة جهاز UE من نوع RedCap بشكل مختلف (ولماذا يجب أن يتكيّف الاختبار)

شبكة 5G SA «جاهزة لـ RedCap» ليست هي نفسها شبكة 5G SA «جاهزة لهاتف ذكيّ». على gNB أن يُعلن عناصر معيّنة في RRC، وعلى AMF أن يقبل الملفّ المُختزَل في طبقة NAS. هناك خمس نقاط للتحقّق.

أوّلًا، يجب أن تحتوي UECapabilityInformation الّتي ترفعها الوحدة على الراية redcap-r17. بدون هذه الراية، تفترض الشبكة eMBB وستطلب من UE موارد لا يستطيع تحملها. تفاصيل بناء شجرة القدرات موجودة في دليل UE Capabilities و MR-DC وتركيبات CA في NR.

ثانيًا، يمكن للخليّة أن تُعلن RedCapInitialBWP مُخصَّصًا في SIB1، وفقًا لـ TS 38.331. إذا غاب هذا BWP، ستحاول وحدة RedCap استخدام BWP الابتدائيّ المشترك، وفي بعض تطبيقات الموزِّعين يؤدّي ذلك إلى رجوع مبكّر إلى LTE.

ثالثًا، يمكن للخليّة أن تحظر RedCap صراحة في SIB1 عبر الحقل cellBarred-redcap-r17. هذا شائع جدًّا في الشبكات الّتي يُفعَّل فيها RedCap على مستوى المُشغِّل لكن في مجموعة فرعيّة من الخلايا فقط: تظلّ الخلايا الأخرى تُعلن «barred» للملفّ. إذا ظلّت وحدتك على LTE في تجربة جدّة، فهذا الحقل هو أوّل مُشتبه به.

رابعًا، يمكن لإعداد PRACH أن يكون مُخصَّصًا لـ RedCap. قد تُخصّص الخليّة جذر Zadoff-Chu وصيغةً مختلفتَين عن ملفّ eMBB.

خامسًا، التنقّل. يعمل intra-RAT NR-NR بشكل طبيعيّ إذا كانت الخليّة الهدف تُعلن أيضًا دعم RedCap. أمّا inter-RAT الرجوع إلى LTE فحالة يجب التحقّق منها ميدانيًّا، لأنّ بعض إعدادات الشبكة تدفع UE من نوع RedCap إلى LTE فور رصدها جودة منخفضة، وأخرى تُبقيه على NR رغم رداءة SINR.

لالتقاط هذا التسلسل على هاتف أندرويد Qualcomm للاختبار، يُوثَّق التدفّق العمليّ في دليل decoder من HiCellTek.

خمسة أشياء تنحرف مع وحدة RedCap على شبكة تجاريّة (وكيفيّة رصدها في Layer 3)

بعد بضع حملات تحقّق فعليّة، تتكرّر أنماط الأعطال. إن أبقيتها حاضرة، توفّر ساعات من التصحيح.

الحالة A هي الأكثر شيوعًا في التجارب الأوروبيّة: يُعلن المُشغِّل أنّ RedCap فعّال في المنطقة، لكنّه يُفعّله في خلايا محدّدة فقط. الوحدة، عند رؤية cellBarred-redcap-r17 يساوي true، تختار خليّة LTE دون إبلاغ المستخدم بأيّ شيء.

الحالة B مشكلة في برنامج الوحدة الثابت أكثر منها في الشبكة. بعض الإصدارات القديمة لا تُعلن redcap-r17 رغم أنّ الشريحة تدعمها. الترقية تحلّ المسألة، والتتبّع يظهر مباشرة في UECapabilityInformation.

الحالة C عادةً نتيجة إيجابيّة كاذبة: يُقارن المُدمِج بـ Galaxy S24 ويستغرب. وهذا هو السلوك الطبيعيّ: 150 Mbps DL، و 50 Mbps UL، على 20 MHz، بـ 1 أو 2 RX. إنّه ليس شذوذًا بل هو الملفّ.

الحالة D أدقّ. يفترض تنقّل RedCap أن تُعلن الخليّة الهدف الدعم أيضًا. إذا فعّلت الشبكة RedCap في مجموعة فرعيّة فقط من الخلايا، فإنّ التنقّلات بين الخلايا المجاورة الّتي تدعم وتلك الّتي لا تدعم تُنتج سقوطًا إلى LTE.

الحالة E تؤثّر في الأعمال. يَعِد RedCap بتوفير الطاقة إذا أعدّ المُشغِّل DRX طويلًا، أو eDRX، أو حتّى Power Saving Mode (PSM) عند توفّره. إذا لم يُحضر RRCReconfiguration معه DRX طويلًا، فسيستهلك منتجك مثل هاتف ذكيّ. الأمر قابل للمراجعة، وكثيرًا ما يُصحّحه المُشغِّل بطلب مباشر.

بروتوكول تحقّق ميداني لوحدة RedCap في 60 دقيقة

الهدف بسيط: الخروج من الجلسة وأنت تعرف ما إذا كانت الخليّة التجاريّة تُعامل وحدتك فعلًا على أنّها RedCap، أم أنّها تُخفّض جودتها. الحدّ الأدنى من العتاد: وحدة RedCap (مثلًا Quectel RG255C-EU)، هاتف أندرويد Qualcomm للتحكّم مع DiagClient SDK، وساعة في الميدان.

الخطوة 1 تؤكّد أنّ الشبكة تقبل الوحدة: إذا وصل Registration Accept مع 5G-GUTI، مرتبطًا بشريحة URSP متّسقة، فإنّ مستوى التحكّم نظيف. الخطوة 2 هي الأكثر تشخيصيّةً: يجب رؤية UECapabilityInformation مفكّكة وقراءة حقل redcap-r17 بقيمة true حرفيًّا. إذا غاب، فلا معنى لباقي الاختبار. الخطوتان 3 و 4 وظيفيّتان. الخطوة 5 هي الأثقل في نموذج العمل لدى العميل النهائيّ، وتتطلّب دقائق عديدة من الالتقاط لأنّ دورات DRX الطويلة قد تبلغ 1.28 ثانية أو أكثر. الخطوة 6 تكشف الأعطال المتقطّعة الّتي لا تظهر إلّا في السلسلة.

التقرير الّذي يُسلَّم للعميل مباشر:

هذا الجدول، بعموده الخاصّ بالدليل، هو ما يُغلق الحوار مع المُشغِّل. ليس رأيًا، بل محتوى SIB1 و RRCReconfiguration الملتقَط في الميدان.

خلاصة القول

5G RedCap في أبريل 2026 حقيقة لا تسويق: 42 مُشغِّلًا في 27 دولة ينشرونه، و T-Mobile US يدخل عامه الثاني تجاريًّا، ومنظومة الوحدات على Qualcomm و MediaTek و ASR و Sequans ناضجة. لكنّ الفرق بين «المُشغِّل يدعم RedCap» و«هذه الخليّة تُعامل وحدتك على أنّها RedCap» يظهر في SIB1، وفي UECapabilityInformation، وفي RRCReconfiguration، لا في عمود الإشارة في هاتف أندرويد. بروتوكول من 60 دقيقة بوحدة RedCap وهاتف أندرويد Qualcomm للتحكّم ورؤية Layer 3 نظيفة كافٍ لإصدار شهادة بسلوك الميدان. حين ترى وحدة RedCap مُعسكرةً على LTE في منطقة يُفترض أنّها مُغطّاة، لا تَفترِض: افتح SIB1.

كم عدد الخلايا الّتي تُعلن فيها شبكتك دعم RedCap في SIB1 فعلًا اليوم؟