عند استكشاف أخطاء الواجهات القائمة على الخدمات في نواة 5G، يواجه كثير من المهندسين المشكلة نفسها. فقد يحتوي جسم الطلب المرسل من AMF إلى SMF على حقول مألوفة مثل SUPI وDNN وS-NSSAI وTAI وPDU Session ID و5QI، ومع ذلك قد يظل من الصعب تحديد ما إذا كانت الرسالة صحيحة فعليًا. هل يجب ترميز الحقل كسلسلة نصية أم كعدد صحيح؟ وهل له نطاق قيم محدد؟ وهل يمكن استخدام أي قيمة، أم يجب أن تأتي من تعداد محدد مسبقًا؟ وهل يمكن أن يحتوي الكائن على معلمات أخرى متداخلة؟
تحدد أنواع البيانات المشتركة في SBI الإجابات عن هذه الأسئلة. تمتد الواجهات القائمة على الخدمات عبر وظائف شبكة مثل AMF وSMF وUDM وPCF وNRF، لكن كثيرًا من المعلمات الأساسية لا يخص وظيفة شبكة واحدة بعينها. ولو عرّفت كل خدمة هذه القيم بصورة مستقلة، لاحتوت المواصفات على تكرار غير ضروري، ولأمكن تمثيل معرّف المشترك نفسه أو معلمة QoS نفسها بطرق مختلفة بين واجهات API. لذلك لا يكفي عند تحليل حركة SBI فحص أساليب HTTP ومعرّفات URI للموارد فقط. يحدد HTTP/2 كيفية نقل الطلبات، ويحدد JSON كيفية تمثيل البيانات، بينما تجيب أنواع البيانات المشتركة عن سؤال أكثر أساسية: ما التنسيق وقواعد التحقق التي يجب أن تتبعها كل معلمة JSON.
ما المشكلات التي تحلها أنواع البيانات المشتركة؟
يمكن النظر إليها على أنها «مفردات بيانات» مشتركة لبيئة واجهات API القائمة على الخدمات في 5GC بأكملها. فقد يظهر نوع بيانات في طلب من AMF ويُشار إليه كذلك من SMF أو UDM أو PCF. وهو لا ينتمي إلى واجهة واحدة، بل يقدم تعريفًا موحدًا يمكن إعادة استخدامه عبر خدمات متعددة.
لنأخذ عنوان IPv4 مثالًا. لا ينبغي لكل NF أن تضع طريقتها الخاصة لتمثيل العنوان كسلسلة نصية. وينطبق الأمر نفسه على معلومات PLMN، حيث لـMCC وMNC أطوال وتنسيقات محددة، وعلى معرّفات المشترك والمعدات مثل SUPI وGPSI وPEI التي تتبع قواعد ترميز خاصة بها. وتسمح التعريفات المتسقة لواجهات RESTful API بين وظائف الشبكة المختلفة بتبادل المعلومات بصورة موثوقة.
ويجب أيضًا التمييز بين أنواع البيانات المشتركة والأنواع الخاصة بوظيفة شبكة محددة. فالأنواع المشتركة تغطي الكائنات التي تتكرر عبر عدة واجهات، بينما تُعرّف كائنات الأعمال الفريدة لوظيفة شبكة معينة في مواصفات السلسلة 29 ذات الصلة. وعمليًا، كثيرًا ما تشير واجهة SBI API واحدة إلى كلا النوعين من البيانات.
ويتجاوز نطاقها عناوين الشبكة بكثير. إذ تغطي التعريفات المشتركة المعلمات العامة، ومعلومات الاشتراك والهوية، وبيانات شبكة 5G، وQoS، والفوترة، ومعلومات التتبع، وغيرها من الكائنات القابلة لإعادة الاستخدام. وتشكل مجتمعة نموذج بيانات أساسيًا لمعلمات رسائل SBI.
ما الفرق بين هياكل البيانات الأساسية الثلاثة؟
من المنظور الهيكلي، يمكن تصنيف معلمات SBI عمومًا إلى ثلاث فئات: أنواع بيانات بسيطة، وتعدادات، وأنواع بيانات مهيكلة. وفهم هذه الفئات الثلاث أكثر فائدة من حفظ أسماء المعلمات منفردة، لأن معظم الحقول التي تظهر في لقطات Wireshark ووثائق API وتعريفات OpenAPI تندرج ضمن هذا النموذج.
أنواع البيانات البسيطة هي اللبنات الأساسية في أدنى مستوى. وتشمل السلسلة النصية، والعدد الصحيح، والعدد، والتاريخ، والتاريخ والوقت، والقيمة المنطقية. وفي 5GC، تُقرن هذه الأنواع الأساسية عادة بقيود إضافية مثل نطاقات القيم أو تنسيقات الترميز أو أنماط التعبيرات النمطية.
فعلى سبيل المثال، يُمثَّل عنوان IPv4 تقنيًا كسلسلة نصية، لكن ليست كل سلسلة عشوائية صالحة. بل يجب أن تتبع تنسيق IPv4 المطلوب. كما أن لعناوين IPv6 وبادئات IPv6 وعناوين MAC متطلبات تنسيق خاصة بكل منها. وتحدد Uint16 وUint32 وUint64 نطاقات الأعداد الصحيحة غير الموقعة. ويجب أن يتبع URI قواعد تنسيق URI، بينما يجب أن تستخدم قيم DateTime تنسيق التاريخ والوقت المحدد.
كما تعرّف المواصفات كثيرًا أنواعًا تحمل اللاحقة Rm مثل Ipv4AddrRm وDateTimeRm وUint32Rm. وتستخدم هذه الأنواع التنسيق الأساسي نفسه للأنواع المقابلة لها، لكنها تتضمن خاصية nullable في OpenAPI، ما يسمح للحقل بحمل القيمة null.
تعمل أنواع التعداد مثل حقول الاختيار من قائمة: يجب اختيار القيمة من مجموعة محددة مسبقًا. فمثلًا يميز AccessType بين 3GPP_ACCESS وNON_3GPP_ACCESS. ويمكن أن يأخذ PduSessionType قيمًا مثل IPV4 أو IPV6 أو IPV4V6 أو UNSTRUCTURED أو ETHERNET. ويمكن لـCoreNetworkType أن يشير إلى 5GC أو EPC.
والغرض من التعداد هو إزالة الغموض. فلا يمكن للجهة المستهلكة اختراع سلسلة أخرى تحمل المعنى نفسه تقريبًا، بل يجب استخدام إحدى القيم التي حددتها المواصفة صراحة. وهذه حالة شائعة في استكشاف الأخطاء: يكون اسم الحقل صحيحًا، لكن قيمة التعداد غير صالحة، فتستمر واجهة API في رفض الطلب أو تفسيره بشكل خاطئ.
تجمع أنواع البيانات المهيكلة عدة خصائص في كائن كامل. وقد تشير هذه الخصائص بدورها إلى أنواع بسيطة أو تعدادات أو كائنات مهيكلة أخرى، وبذلك يتكون نموذج هرمي.
يُعد ProblemDetails مثالًا نموذجيًا، إذ يمكن أن يتضمن حقولًا مثل type وtitle وstatus وdetail وinstance وcause وinvalidParams. ويُعد TAI مثالًا آخر، حيث يجمع PLMN ID مع TAC. أما GUAMI فيذهب إلى مستوى أعلى بدمج PLMN ID مع AMF ID. وعند هذا المستوى، لا يمكن أن يقتصر تحليل SBI على الحقول الفردية؛ فالعلاقات بين الخصائص داخل الكائن مهمة أيضًا.
كيف تُبنى معلمات الهوية والشبكة؟
في لقطات الحزم الحقيقية، تُعد بيانات الاشتراك والهوية والبيانات المتعلقة بشبكة 5G من أكثر معلمات SBI شيوعًا. يعرّف SUPI المشترك، ويمثل GPSI هوية خارجية للمشترك، ويمثل PEI معرّفًا دائمًا للمعدات، ويحدد DNN شبكة بيانات، بينما يحدد NF Instance ID مثيل NF بصورة فريدة.
قد تبدو معظم هذه الحقول مجرد سلاسل نصية بسيطة، لكن المهم هو قاعدة الترميز داخل السلسلة. فقد يحتوي SUPI على تمثيل IMSI أو NAI، بينما قد يحتوي GPSI على MSISDN أو External Identifier. وبعبارة أخرى، تعريف الحقل كسلسلة نصية لا يعني أن أي سلسلة تكون صالحة.
تعتمد الأنواع المتعلقة بشبكة 5G على هذه المعرّفات الأساسية لتمثيل معلومات الجلسة والموقع. يحدد PduSessionId جلسة PDU Session. ويشكل MCC وMNC جزءًا من هوية PLMN. ويحدد TAC رمز منطقة التتبع (Tracking Area Code)، بينما يحدد NrCellId وEutraCellId خلايا NR وE-UTRA على التوالي.
ثم تجمع الكائنات المهيكلة هذه المعلمات الأساسية في نماذج بيانات أعلى مستوى. يستخدم S-NSSAI قيمة SST وSD اختيارية لتمثيل شريحة شبكة. ويجمع TAI بين PLMN ID وTAC. ويجمع NCGI بين PLMN ID وNR Cell ID لتحديد خلية NR، بينما يؤدي ECGI دورًا مشابهًا في E-UTRA.
يمثل UserLocation مستوى أعلى من التجريد. وبحسب نوع الوصول، يمكن أن يحمل NR Location أو E-UTRA Location أو Non-3GPP Access Location. ويمكن لـNR Location نفسها أن تحتوي على TAI وNCGI وطابع زمني للموقع ومعلومات جغرافية.
يوضح ذلك التصميم المعياري لنماذج بيانات SBI. إذ تُوحّد العناصر الأساسية مثل MCC وMNC وTAC وCell ID أولًا، ثم تُجمع في كائنات أعلى مستوى مثل PLMN ID وTAI وNCGI وUserLocation. ويمكن لواجهات API إعادة استخدام هذه الكائنات مباشرة بدل إعادة تعريف مجموعة كاملة من معلمات الموقع لكل خدمة.
لماذا يجب توحيد بيانات QoS والفوترة والتتبع أيضًا؟
تحمل حركة SBI أكثر بكثير من هويات المشتركين ومواقع الشبكة. فسياسات QoS ومعلومات الاستخدام وبيانات تتبع الشبكة تنتقل أيضًا بين عدة وظائف NF، ولذلك تحتاج هذه القيم كذلك إلى تعريفات بيانات متسقة.
من بين معلمات QoS، يحدد QFI تدفق جودة الخدمة (QoS Flow)، ويمثل 5QI معرّف جودة الخدمة في 5G (5G QoS Identifier)، ويمثل BitRate معدلًا باستخدام قيمة ووحدة، ويعبّر Packet Delay Budget عن ميزانية التأخير، بينما يصف Packet Error Rate وPacket Loss Rate جودة النقل.
وتستخدم سياسات QoS كذلك أنواع تعداد عديدة. يوضح PreemptionCapability ما إذا كان بإمكان خدمة ما انتزاع موارد مخصصة في موضع آخر. ويبين PreemptionVulnerability ما إذا كان يمكن سحب موارد قائمة لصالح خدمة أعلى أولوية. ويميز QosResourceType بين قيم مثل NON_GBR وNON_CRITICAL_GBR وCRITICAL_GBR.
ثم تُجمع هذه الحقول الأساسية في كائنات مهيكلة مثل ARP وAMBR وDynamic 5QI وNon-Dynamic 5QI. وهذا يسمح لـSMF وPCF ووظائف الشبكة الأخرى ذات الصلة باستخدام التمثيل نفسه عند تبادل مفاهيم مثل الأولوية ومعدل البت والتأخير وسلوك الاستباق.
تتبع بيانات الفوترة المبدأ التصميمي نفسه. وتُعد ChargingId وRatingGroup وServiceId أنواع بيانات بسيطة نسبيًا، بينما يمكن أن يتضمن QoSFlowUsageReport قيمة QFI وطوابع زمنية لبداية ونهاية الجمع وأحجام حركة الوصلة الصاعدة والهابطة. ويمكن لـVolumeTimedReport تمثيل استخدام PDU Session خلال فترة زمنية محددة.
وتوحد الأنواع المتعلقة بالتتبع معلومات تتبع الشبكة. يستخدم TraceDepth قيم تعداد لوصف مستويات مختلفة من التتبع، بينما يجمع TraceData معلمات مثل Trace Reference وTrace Depth وNE Type. وهذا يمنع كل NF من تعريف مجموعة غير متوافقة خاصة بها من حقول التتبع.
توضح هذه الأمثلة أن أنواع البيانات المشتركة لا تقتصر على توحيد «بضعة حقول JSON»، بل توحّد كيفية فهم خدمات النواة المختلفة للمفاهيم نفسها على مستوى الأعمال والشبكة. فإذا كان لا بد من نقل QoS أو الموقع أو معلومات الفوترة أو معرّفات المشترك بين عدة وظائف NF، فإنها تحتاج أولًا إلى نموذج بيانات متسق.
كيف يمكن استخدام أنواع البيانات في استكشاف الأخطاء عمليًا؟
من أكثر الأخطاء الهندسية شيوعًا فحص رسالة JSON فقط لمعرفة ما إذا كان الحقل موجودًا، من دون التحقق من نوع البيانات والقيود المرتبطة به. والطريقة الأكثر فاعلية هي فحص طبقة HTTP ونموذج البيانات معًا.
ابدأ بتحديد الخدمة التي يجري استدعاؤها وURI المورد. ثم حدد الحقل المستهدف في جسم الطلب أو الاستجابة. وبعد العثور عليه، لا تتوقف عند قيمته فقط. تحقق من نوع البيانات الذي يشير إليه، وما إذا كان إلزاميًا أو اختياريًا، وقيمة Cardinality الخاصة به، وهل هو تعداد، وهل توجد قيود Format أو Pattern.
قد يبدو حقل IPv4 للعين كأنه عنوان IP، لكنه يظل إدخالًا غير صالح إذا لم يطابق التنسيق المحدد. وبالمثل، قد تكون قيمة PduSessionType مفهومة لغويًا، لكنها إذا لم تكن واحدة من قيم التعداد المحددة فلن تتوافق مع تعريف API.
يجب توسيع البيانات المهيكلة بصورة تكرارية. فعند ظهور UserLocation، حدد ما إذا كان الكائن يحتوي على معلومات موقع NR أو E-UTRA أو Non-3GPP. وعند ظهور TAI، افحص PLMN ID وTAC. وعند ظهور S-NSSAI، افحص SST وSD الاختيارية. ولا يمكن للمهندس تحديد مدى مطابقة كائن JSON لنموذج API إلا باتباع مراجع الأنواع طبقة بعد طبقة.
عندما يرفض الخادم طلبًا، يجدر كذلك فحص ProblemDetails بعناية. فإلى جانب رمز حالة HTTP، يمكن أن يقدم معلومات detail وcause وinvalidParams. وعند وجود هذه الحقول، يمكن بدء الاستكشاف من المعلمة المحددة التي خالفت متطلبات API بدل التوقف عند استجابة HTTP 4xx عامة.
لماذا يعد التفكير بنموذج البيانات أكثر فائدة من حفظ جداول المعلمات؟
عدد أنواع البيانات المشتركة في SBI لنواة 5GC كبير إلى درجة تجعل حفظ كل حقل وتعبير نمطي ونطاق قيم أمرًا غير فعال بسرعة. والأفضل هو تبني طريقة تفكير قائمة على نموذج البيانات: فالأنواع البسيطة تحدد أصغر وحدات البيانات، والتعدادات تقيد الحالات المسموح بها، والأنواع المهيكلة تجمع تلك الوحدات في كائنات يمكن لخدمات 5GC استخدامها مباشرة.
ضمن هذا الإطار، لا تعود SUPI وMCC وTAC وQFI معلمات منفصلة، بل تصبح لبنات لبناء نماذج المشترك والموقع والجلسة وQoS والفوترة والتتبع. وأحد أسباب قدرة وظائف NF المختلفة على استدعاء الخدمات باتساق عبر SBI هو أن هذه الأنواع المشتركة توفر دلالات بيانات مستقرة وقابلة لإعادة الاستخدام.
لذلك، عند قراءة API غير مألوفة في 5GC، لا يكون السؤال الأول الأكثر فائدة «كم عدد الحقول في هذه الرسالة؟»، بل يجب تحديد الأنواع التي تشير إليها هذه الحقول، وكيف تتداخل الكائنات، وما القيود التي تحدد صلاحية JSON الناتج. وبعد إتقان هذه الطريقة، يمكن تحليل حتى خدمة SBI لم تُشاهد من قبل باتباع تعريفات OpenAPI وأنواع البيانات طبقة بعد طبقة بدل حفظ جدول معلمات جديد بالكامل.
الأسئلة الشائعة
أي مواصفة من 3GPP تعرّف أنواع البيانات المشتركة في SBI؟
تُعرّف أساسًا في TS 29.571، 5G System; Common Data Types for Service Based Interfaces. وتحدد هذه المواصفة هياكل بيانات قابلة لإعادة الاستخدام ومشتركة بين خدمات SBI. أما الخدمات وأنواع البيانات الخاصة بوظيفة NF معينة فتُعرّف في مواصفات 29.5xx المقابلة، مثل TS 29.502 لخدمات SMF وTS 29.503 لخدمات UDM.
كيف تظهر خاصية nullable في OpenAPI داخل رسالة JSON فعلية؟
يمكن للحقل المعرّف على أنه nullable، عادة من خلال نوع ذي لاحقة Rm، أن يحمل صراحة القيمة null في جسم JSON للإشارة إلى عدم وجود قيمة صالحة مسندة حاليًا. وهذا يختلف عن غياب الحقل تمامًا. فقد يعني غياب الحقل أن المعلمة غير قابلة للتطبيق أو لم تُرسل، بينما يمكن أن تحمل null الصريحة معنى دلاليًا محددًا، مثل مسح قيمة كانت مهيأة سابقًا.
هل يمكن أن تختلف أنواع البيانات المشتركة في SBI بين الشركات المصنّعة؟
التعريفات موحدة على مستوى المواصفة، لكن قد تظهر فروق تنفيذية في المنتجات الفعلية. فقد تطبق بعض الشركات مجموعة فرعية فقط من الحقول الاختيارية، وقد تتضمن بعض واجهات API امتدادات خاصة بالمورّد، كما قد تختلف صرامة التحقق من قيم التعداد. وهذه الفروق من النقاط الشائعة التي تُفحص أثناء اختبارات التشغيل البيني.
كيف يمكن معرفة ما إذا كان الحقل يستخدم نوعًا مشتركًا أم نوعًا خاصًا بوظيفة NF؟
الطريقة الأكثر مباشرة هي فحص مسار $ref في تعريف OpenAPI. فإذا أشارت المرجعية إلى مخطط مشترك معرّف في TS 29.571، فهي عادة نوع بيانات SBI مشترك. وإذا أشارت إلى مخطط معرف داخل مواصفة الخدمة الحالية، فهي عمومًا نوع خاص بوظيفة NF. كما تساعد معرفة الأنواع كثيرة الاستخدام مثل SUPI وTAI وS-NSSAI وProblemDetails على تمييزها بسهولة أثناء تحليل الحزم.
ما الفرق بين نوع Rm والنوع العادي في لقطة حزم؟
عندما لا تكون القيمة null، يكون تمثيل JSON متماثلًا عمليًا لأن النوعين يستخدمان التنسيق الأساسي نفسه. ويظهر الاختلاف على مستوى نموذج OpenAPI: فنوع Rm يسمح للحقل بأن يحتوي null. وإذا كان الحقل الملتقط يحمل صراحة القيمة null، فلا بد أنه يستخدم تعريفًا nullable. أما إذا احتوى قيمة طبيعية صالحة، فلا تكفي القيمة وحدها لمعرفة ما إذا كان المخطط يشير إلى النوع العادي أو نوع Rm المقابل.
