← نظرة عامة

دليل عمليات OmniSMF

OmniSMF هو وظيفة إدارة الجلسات (SMF) في النواة 5G. يمتلك دورة حياة كاملة لجلسات PDU: تخصيص العناوين، ربط السياسات، برمجة مستوى المستخدم والتفكيك. يغطي هذا الدليل دور 3GPP، وواجهات SBI و N4 التي يكشف عنها، والإجراءات الرئيسية التي يقودها، كل منها مع مخطط تسلسلي.

دور 3GPP ومراجع المواصفات

المواصفة	الصلة
TS 23.501	هندسة النظام: دور SMF، مفهوم جلسة PDU، نموذج QoS
TS 23.502	الإجراءات: إنشاء جلسة PDU (§4.3.2)، التعديل (§4.3.3)، الإنهاء (§4.3.4)، طلب الخدمة (§4.2.3)
TS 29.502	واجهة خدمة Nsmf_PDUSession API
TS 29.244	واجهة N4: بروتوكول PFCP بين SMF و UPF
TS 29.503	Nudm_SubscriberDataManagement (sm-data) و Nudm_UEContextManagement (smf-registrations)
TS 29.512	Npcf_SMPolicyControl: ربط سياسة SM والإشعار نحو PCF
TS 29.518	Namf_Communication: نقل رسالة N1N2 نحو AMF
TS 32.290 / TS 32.291	Nchf_ConvergedCharging (N40): الشحن المتقارب نحو CHF
TS 24.501	5GS NAS (5GSM): إنشاء/تعديل جلسة PDU، نوع الجلسة ومعالجة سبب 5GSM (§6.4.1.3)
TS 29.571	أنواع البيانات الشائعة: IpAddress, S-NSSAI

الواجهات

الواجهة	النظير	البروتوكول	الغرض
N11	AMF	Nsmf_PDUSession (SBI, HTTP/2)	إنشاء / استرجاع / تحديث / إنهاء سياق SM، نقل رسالة N1N2
N7	PCF	Npcf_SMPolicyControl (SBI)	إنشاء/حذف ربط سياسة SM + استدعاء سياسة الإشعار
N10	UDM	Nudm_SDM + Nudm_UECM (SBI)	بيانات اشتراك الجلسة، تسجيل SMF
N4	UPF	PFCP (UDP)	ربط PFCP + إنشاء/تعديل/حذف الجلسة
N40	CHF	Nchf_ConvergedCharging (SBI)	الشحن المتقارب: فتح/تحديث/إغلاق طلب بيانات الشحن خلال دورة حياة جلسة PDU (CHF يتم حله عبر اكتشاف NRF مع URI احتياطي ثابت؛ معطل بشكل افتراضي)
N26	PGW-C	العمل الداخلي	اعتماد / تبديل / بحث عن التنقل 4G/5G
n/a	NRF	Nnrf_NFManagement (SBI)	تسجيل NF + نبض القلب (لا اكتشاف خارجي)

نقاط نهاية SBI

تخدم جميع نقاط نهاية SBI تحت عنوان URL الأساسي {SBI_SCHEME}://{SBI_ADDR}:{SBI_PORT}.

الطريقة	المسار	الخدمة	الغرض	المواصفة
POST	/nsmf-pdusession/v1/sm-contexts	Nsmf_PDUSession	إنشاء سياق SM (إنشاء جلسة PDU)	TS 29.502
POST	/nsmf-pdusession/v1/sm-contexts/{smContextRef}/retrieve	Nsmf_PDUSession	استرجاع سياق SM (تستخدم المواصفة POST، وليس GET)	TS 29.502 §5.2.2.6
POST	/nsmf-pdusession/v1/sm-contexts/{smContextRef}/modify	Nsmf_PDUSession	تحديث سياق SM (معلومات N2، تغيير حالة UP، تسليم، تعديل تدفق QoS، علامة الإنهاء)	TS 29.502
POST	/nsmf-pdusession/v1/sm-contexts/{smContextRef}/release	Nsmf_PDUSession	إنهاء سياق SM (تفكيك الجلسة)	TS 29.502
POST	/nsmf-callback/sm-policy-notify/{smContextRef}	Npcf callback	تلقي تحديثات SmPolicyDecision من PCF (تدفقات QoS مخصصة)	TS 29.512 §4.2.4.3

إنشاء ��ياق SM

حقول الطلب الإلزامية: supi, sNssai, servingNetwork, dnn, smContextStatusUri, pduSessionId, anType, servingNfId. يعود 201 Created مع Location: {base}/nsmf-pdusession/v1/sm-contexts/{ref}. خريطة الأخطاء: 400 MANDATORY_IE_MISSING, 404 DNN_DENIED, 500 SYSTEM_FAILURE, 503 NF_DISCOVERY_FAILURE (UDM غير متاح).

استرجاع سياق SM

يقرأ AMF سياق SM الحالي عن طريق الإشارة إليه (TS 29.502 §5.2.2.6 تستخدم POST .../sm-contexts/{smContextRef}/retrieve، وليس GET). يعود SMF بـ 200 OK مع عرض سياق SM الحالي لمرجع معروف، أو 404 CONTEXT_NOT_FOUND لمرجع غير معروف.

تحديث سياق SM

يتولى معالج التعديل التوزيع على المفتاح المعترف به أولاً في الجسم:

مفتاح الجسم	السيناريو
n2SmInfo + n2SmInfoType	معلومات N2 SM من gNB (PDU_RES_SETUP_RSP ينشط النفق؛ PDU_RES_REL_RSP يعطله)
upCnxState: "DEACTIVATED"	إنهاء AN / دخول UE في حالة الخمول (FAR لأسفل إلى BUFFER)
upCnxState: "ACTIVATING"	طلب الخدمة؛ الاستجابة تحمل N2 PDU_RES_SETUP_REQ
hoState	انتقال حا��ة التسليم: PREPARING, PREPARED, COMPLETED (يعيد تنشيط النفق)، CANCELLED
qosFlows	إضافة/تعديل تدفق QoS بعد الإنشاء (يعود 204 No Content؛ التغييرات تنقل إلى gNB عبر معلومات N2 SM)
release: true	إنهاء بدأه AMF (يعود 204 No Content)
servingNfId	تغيير مثيل AMF أثناء التنقل (يعود 204 No Content)

إنهاء سياق SM

قد يتضمن الجسم ueLocation لتسجيل الموقع النهائي. يعود 204 No Content.

الإجراءات الرئيسية

إنشاء جلسة PDU (TS 23.502 §4.3.2)

يتم إرسال N1N2MessageTransfer بشكل غير متزامن بحيث يعود 201 Created إلى AMF أولاً. رسالة N1 SM هي قبول إنشاء جلسة PDU ورسالة N2 SM هي PDUSessionResourceSetupRequestTransfer، تحمل كجسم multipart/related (TS 29.518) مع الأجزاء الثنائية NAS/NGAP المشار إليها بواسطة contentId.

مصادر تكوين DNN

يتم تعريف سلوك DNN في مكانين، ويجب على المشغل تعيين كل��هما بشكل متسق لكي يظهر DNN بشكل صحيح:

سمة DNN	مصدرها	كيف يتم توفيرها	ملاحظات
S-NSSAI المسموح به	اشتراك AMF/UDM	يوفر AMF sNssai عند إنشاء سياق SM؛ يجب أن يوجد DNN تحت S-NSSAI مطابق في بيانات SM الخاصة بالمشترك في UDM	يبحث SMF عن DNN المطلوب عبر كل إدخال S-NSSAI المشترك في dnnConfigurations
AMBR للجلسة	UDM dnnConfiguration.sessionAmbr	يتم توفيره في HSS → UDM/UDR	يتم إرساله إلى PCF كـ subsSessAmbr و sessionAmbr (انظر AMBR للجلسة نحو PCF)
QoS الافتراضي (5QI + ARP)	UDM dnnConfiguration.5gQosProfile	يتم توفيره في HSS → UDM/UDR	الافتراضي هو 5QI 9، أولوية ARP 15 عند عدم وجوده؛ يصبح تدفق QoS الافتراضي (QFI 1)
نوع (أنواع) جلسة PDU	UDM dnnConfiguration.pduSessionTypes	defaultSessionType + allowedSessionTypes	يتم احترام طلب UE فقط إذا كان في المجموعة المسموح بها، وإلا يتم استخدام الافتراضي؛ الافتراضي هو IPV4
وضع SSC	UDM dnnConfiguration.sscModes	defaultSscMode + allowedSscModes (TS 23.501 §5.6.9.2)	يتم احترام طلب UE فقط إذا كان في المجموعة المسموح بها، وإلا يتم استخدام الافتراضي؛ الافتراضي هو SSC_MODE_1
IP ثابت لـ UE	UDM dnnConfiguration.staticIpAddress	يتم توفيره في HSS → UDM/UDR	انظر حقل IP الثابت والحجز
مجموعة IP لـ UE (ديناميكية)	SMF ue_ip_pool subnet_map	تكوين SMF	يتم تعيينها لكل DNN؛ انظر المجموعات التي تدرك DNN
DNS / MTU / P-CSCF (ePCO)	SMF dns / dns6 / mtu / :pco	تكوين SMF	تُعطى لـ UE في قبول الإنشاء ePCO؛ ليست لكل DNN، باستثناء أن P-CSCF يتم إرجاعه فقط عندما يبدأ DNN بـ ims

قاعدة الإبهام: سياسة لكل مشترك ولكل DNN (S-NSSAI، AMBR، QoS الافتراضي، نوع الجلسة، وضع SSC، IP ثابت) تعيش في اشتراك UDM؛ الموارد الشبكية المقدمة لـ UE (مجموعة IP الديناميكية، DNS، MTU، P-CSCF) تعيش في تكوين SMF. يتم رفض DNN الموجود في subnet_map الخاص بـ SMF ولكنه غائب عن بيانات SM الخاصة بالمشترك في UDM مع 404 DNN_DENIED؛ DNN الموجود في UDM ولكن بدون إدخال subnet_map مطابق وبدون مجموعة default يفشل في تخصيص IP مع :no_pool_for_dnn.

تخصيص عنوان IP لـ UE

يتم تخصيص عنوان IP لكل جلسة PDU (IPv4، IPv6، أو كلاهما) قبل إنشاء جلسة PFCP مع UPF. تعكس مجموعة IP نموذج تخصيص PGW-C 4G. يتم تجربة المصادر بترتيب الأولوية:

1. عنوان متبنى من N26. لجلسة منشأة من 4G تنتقل إلى 5G عبر N26 (عنوان adoptedIpv4 في طلب الإنشاء)، يتم إعادة استخدام IP UE الذي تم تخصيصه بالفعل بواسطة PGW-C المستقل؛ ينتمي العنوان إلى مجموعة PGW-C، لذا يتم الحفاظ عليه عبر التسليم، وليس إعادة تخصيصه. لجلسة مزدوجة المكدس، يتم تخصيص الجزء IPv6 بعد ذلك بشكل ديناميكي.
2. IP ثابت (محدد للمشترك). عندما تحتوي بيانات اشتراك SM الخاصة بـ UDM على staticIpAddress لـ DNN المطلوب، يتم احترام هذا العنوان الثابت لكل جلسة على ذلك DNN. هذا يعكس سلوك IP الثابت في HSS/PGW-C 4G ويتم توفيره في النهاية في HSS ويظهر من خلال UDM/UDR. لجلسة مزدوجة المكدس، يتم تخصيص الجزء IPv6 بشكل ديناميكي.
3. مجموعة ديناميكية. بخلاف ذلك، يتم تخصيص عنوان من مجموعة DNN المكونة. تختار التخصيص عنوان مضيف مجاني عشوائي (باستثناء الشبكة/البث لـ IPv4)، تعيد المحاولة عند التصادم، ويتم إزالة التكرار عبر جميع الجلسات النشطة.

يتم إرجاع IP لـ UE إلى المجموعة عند أي خروج عامل (إصدار صريح، تعطل، أو إيقاف مشرف)، لذا لا يمكن لجهاز CPE عالق في حلقة إنشاء/إصدار/إعادة محاولة تسرب عناوين المجموعة ببطء.

المجموعات التي تدرك DNN (subnet_map)

يتم اختيار المجموعات لكل DNN عبر subnet_map. المفاتيح هي أسماء DNN الدقيقة، أو أنماط ^regex، أو :default؛ القيم هي قوائم من CIDRs IPv4 و/أو IPv6. أولوية المطابقة هي DNN الدقيق → regex → :default. لجلسة IPV4V6، يقوم SMF بالتخصيص من كل من نطاقات IPv4 وIPv6 للمجموعة المطابقة. انظر مجموعة IP لـ UE في مرجع التكوين.

حقل IP الثابت والحجز

يتبع حقل staticIpAddress TS 29.503 (DnnConfiguration) و TS 29.571 (IpAddress): مصفوفة من الكائنات، يحمل كل منها بشكل اختياري ipv4Addr (يتم قبول كائن واحد أيضًا). يتم حجز عنوان ثابت في المجموعة بحيث لا يتم تسليمه ديناميكيًا أبدًا:

• يتم احتساب عنوان ثابت داخل نطاق محدد ضد تلك المجموعة ويتم استبعاده من التخصيص الديناميكي.
• يتم تتبع عنوان ثابت خارج كل نطاق محدد للكشف عن التكرار فقط ولا يستهلك سعة المجموعة (يمكن أن تعيش IPs الثابتة على شبكتها الموجهة الخاصة).
• إذا كان العنوان الثابت مستخدمًا بالفعل بواسطة جلسة حية أخرى، يتم رفض الجلسة PDU الجديدة (:static_ip_in_use) بدلاً من إصدار تكرار، مما يتماشى مع PGW-C 4G. يجب أن يحدث هذا فقط إذا تم تكوين نفس IP الثابت بشكل خاطئ ضد مشتركين اثنين.

لتوفير IP ثابت، قم بتعيين staticIpAddress على تكوين DNN الخاص بالمشترك (عبر HSS → UDM/UDR)؛ لا يتطلب الأمر تغيير تكوين SMF.

تسوية نوع جلسة PDU (TS 24.501 §6.4.1.3)

عندما يتم طلب جلسة مزدوجة المكدس (IPV4V6) ولكن المجموعة المطابقة تنتج فقط عائلة عنوان واحدة، يقوم SMF بتسوية نوع الجلسة المعلنة إلى العائلة التي تم تخصيصها فعليًا قبل بناء قبول إنشاء N1 و PDUSessionResourceSetupRequestTransfer N2:

• تم تخصيص IPv4، لا IPv6 → الإشارة إلى IPV4 مع سبب 5GSM #50 (نوع جلسة PDU IPv4 فقط مسموح به).
• تم تخصيص IPv6، لا IPv4 → الإشارة إلى IPV6 مع سبب 5GSM #51 (نوع جلسة PDU IPv6 فقط مسموح به).
• كلا العائلتين موجودتين → الإشارة إلى IPV4V6 دون تغيير.

هذا مطلوب للتشغيل البيني: الإعلان عن IPV4V6 أثناء حمل عنوان IPv4 فقط يجعل RAN يرفض إعداد موارد N2. لذلك، سيشهد المشغلون الذين يقدمون اشتراكات مزدوجة المكدس من مجموعات IPv4 فقط أن تلك الجلسات تظهر كـ IPv4 مع السبب NAS المقابل، بدلاً من الفشل.

المراقبة

• GET /api/ip_pool: السعة الإجمالية لـ IPv4 بالإضافة إلى ملخص مجموعة لكل DNN.
• GET /api/ip_pool/detail: مجموعات لكل DNN مع CIDR لكل نطاق، الإجمالي/المخصص/المتاح، والقائمة الكاملة للعناوين المخصصة حاليًا (ديناميكية + ثابتة).

ملاحظة IPv6: يتم تخصيص عناوين IPv6، وحجزها، وإصدارها، والإبلاغ عنها بواسطة المجموعة.

اكتشاف P-CSCF والإعلان (VoNR / IMS)

لجلسة PDU IMS/VoNR، يجب على UE معرفة P-CSCF للتسجيل ضده. يعيده SMF في ePCO من قبول إنشاء جلسة PDU (حاوية P-CSCF IPv4 0x000C، حاوية IPv6 0x0001)، حاوية واحدة لكل عنوان، مماثلة لـ PGW-C 4G. يتم إرجاع P-CSCF فقط عندما يبدأ DNN بـ ims. ترتيب الاختيار:

1. اكتشاف DNS + فحص الصحة (مفضل). عندما يكون p_cscf_discovery_enabled، يقوم SMF بحل _sip._tcp.<fqdn> (SRV) إلى A/AAAA، ثم يتحقق من صحة كل مرشح باستخدام SIP OPTIONS (TCP ثم UDP). يتم الإعلان فقط عن الخوادم التي تجيب، ويتم ت��ديث المجموعة على دورة ثابتة مدتها 60 ثانية، لذا يتم إسقاط P-CSCF الذي يتوقف عن الرد على OPTIONS من المجموعة المعلنة في غضون دقيقة تقريبًا، ويتم إعادة إضافة P-CSCF الذي تم استرداده في الدورة التالية. تعمل التحديثات بشكل مستقل عن إنشاء الجلسة؛ تقرأ الجلسات الجديدة دائمًا المجموعة الصحية الأحدث.
2. احتياطي ثابت. إذا تم تعطيل الاكتشاف أو لم يعد شيئًا صحيًا، يتم استخدام p_cscf_ipv4_address_list / p_cscf_ipv6_address_list.

هذا يعكس PGW-C تمامًا، لذا يقوم تكوين نشر مختلط 4G/5G P-CSCF بنفس الطريقة على كلا العقدتين. انظر P-CSCF وخيارات تكوين البروتوكول.

تدفق QoS مخصص / حامل GBR (VoNR، 5QI-1)

تحتاج VoNR إلى تدفق QoS GBR مخصص (5QI 1) لوسائط الصوت، جنبًا إلى جنب مع التدفق غير GBR الافتراضي. يتم دعم كل من المسار الثابت (المزود) و الديناميكي (المعتمد على المكالمة).

ثابت: يتم توفير قاعدة GBR في السياسة (قاعدة الشحن PCRF في HSS إلى UDR sm-policy-data إلى قاعدة PCF PCC) ويتم إرجاعها في قرار sm-policies. يتم تخزينها وتثبيتها بمجرد وجود جلسة PFCP، لذا يقوم UPF بتمييز التدفق مع 5QI/GBR من لحظة بدء الجلسة.

ديناميكي (مدفوع بالمكالمة): يتم إضافة التدفق عندما يتم الرد على المكالمة وإزالته عند BYE، مدفوعًا باستدعاء سياسة PCF:

يتم تسليم الإشعار إلى /nsmf-callback/sm-policy-notify/{smContextRef} (يقرأ SMF smPolicyDecision من الجسم): قاعدة PCC غير الصفرية تثبت التدفق، وقاعدة ذات قيمة صفرية تزيله (TS 29.512، قاعدة PCC ذات قيمة صفرية هي قاعدة للإزالة). يتم إجراء مطابقة تطبيق AF مع SM-policy (حسب IP UE) على PCF.

تعديل جلسة PDU: تحديث تدفق QoS

يمكن أن يقود AMF أيضًا تعديل تدفق QoS مباشرة عبر نقطة النهاية للتعديل مع قائمة qosFlows، بدلاً من عبر PCF. كل إدخال إما يقوم بتحديث تدفق موجود (مطابق بواسطة qfi) أو يخصص QFI جديد. يتم إعادة برمجة UPF مع QoS المتغيرة، ونظرًا لأن SmContextUpdatedData لا تحدد أي عضو JSON qosFlows، فإن الاستجابة هي 204 No Content؛ يتم نقل تغيير QoS إلى gNB عبر معلومات N2 SM.

إنهاء جلسة PDU (TS 23.502 §4.3.4)

ترتيب التفكيك هو حذف سياسة PCF → حذف جلسة PFCP → إلغاء تسجيل UDM → إشعار حالة سياق SM (resourceStatus: RELEASED) إلى استدعاء AMF؛ ثم يقوم العامل بإرجاع IP UE إلى المجموعة ويتوقف. يتم تشغيل نفس التفكيك لجلسة release: true التي بدأها AMF.

UE Idle / طلب الخدمة: حالة الاتصال UP (TS 23.502 §4.2.3)

عند ACTIVATING، يقوم SMF بتحديث PTI من أحدث طلب إنشاء لـ UE ويرسل N1N2MessageTransfer إلى AMF لتحفيز PDUSessionResourceSetup على gNB؛ تحمل استجابة 200 upCnxState: ACTIVATING. يتم إعادة توجيه مستوى المستخدم إلى gNB فقط عندما يصل gNB F-TEID في PDU_RES_SETUP_RSP المتابعة.

انتقالات حالة التسليم

تقدم عملية تسليم يقودها AMF الجلسة عبر قيم hoState على نقطة النهاية للتعديل:

• PREPARING / PREPARED: يتم تسجيل الحالة؛ لا يتم تغ��ير مستوى المستخدم.
• COMPLETED: يتم إعادة تنشيط النفق (تعديل PFCP، FAR لأسفل إلى gNB المستهدف) ويتم مسح حالة التسليم.
• CANCELLED: يتم مسح حالة التسليم دون تغيير مستوى المستخدم.

هيكل جلسة PFCP N4

تقوم كل جلسة PDU بتثبيت عناصر PFCP التالية على UPF (TS 29.244):

IE	الاتجاه	الغرض
PDR (لأعلى)	الوصول → النواة	مطابقة حركة GTP-U من gNB على F-TEID N3 لـ UPF
PDR (لأسفل)	النواة → الوصول	مطابقة الحركة من N6 حسب عنوان IP لـ UE
FAR (لأعلى)	النواة	توجيه إلى N6 (بدون رأس خارجي)
FAR (لأسفل)	الوصول	في البداية BUFFER؛ يتم تحديثه إلى GTP-U FORWARD بعد PDU_RES_SETUP_RSP
QER	كلاهما	فرض AMBR للجلسة (MBR لأعلى ولأسفل)؛ يتم إضافة QER مخصص لكل تدفق GBR
URR	كلاهما	تقارير الاستخدام المستندة إلى الوقت (العتبة مستمدة من heartbeat_interval)

تستخدم URR الواحدة قياسًا مستندًا إلى المدة مع مشغل عتبة زمنية. يتم اشتقاق ��لعتبة من heartbeat_interval (ست مرات قيمته، مثل 60 ثانية عند نبض القلب الافتراضي 10 ثوانٍ)، لذا فهي غير قابلة للتعديل بشكل مستقل؛ رفع heartbeat_interval لزيادة تردد التقارير. يتم تسجيل تقارير الاستخدام التي ترسلها UPF وتظهر كـ omni_smf_n4_usage_reports_total و omni_smf_n4_usage_report_volume_bytes_total (انظر المقاييس)، وعندما يتم تمكين الشحن المتقارب N40، يتم توجيهها إلى CHF كطلبات بيانات شحن مؤقتة.

يتم إنشاء ارتباط PFCP مع UPF (مع نبضات القلب) قبل إرسال أي طلب جلسة. إذا فقد الارتباط، يمكن إعادة تحفيزه عبر واجهة الإدارة (POST /api/oam/pfcp/reassociate).

العمل الداخلي N26 (4G ↔ 5G)

يتشارك SMF و PGW-C المستقل UPF وينسقان عبر مسار عمل داخلي N26 بحيث يحتفظ UE بعنوان IP الخاص به عبر التسليم:

• اعتماد (4G → 5G): يتم اعتماد جلسة EPS منشأة من 4G إلى 5GS، مع إعادة استخدام IP UE المخصص بالفعل من PGW-C. إعادة اعتماد جلسة موجودة ��عيد الجلسة 5G الحالية بدلاً من إنشاء تكرار.
• تبديل: يتم تبديل جانب الوصول لجلسة موجودة إلى :eps (5G → 4G) أو :fivegs (4G → 5G) عن طريق تحديث النفق الوصول عبر تعديل PFCP (TEID/عنوان S-GW S5/S8-U لـ EPS، TEID/عنوان gNB N3 لـ 5GS) مع الحفاظ على نفس IP UE ونفس جلسة PFCP على UPF. يعود التبديل برؤية EPS (IP UE المحفوظ، DNN، AMBR للجلسة، معرف الحامل الافتراضي EPS، و F-TEID PGW-U) الذي يستخدمه PGW-C للإجابة على SGW.
• بحث: يمكن قراءة جلسات PDU النشطة لـ UE كوجهات نظر PDN-connection EPS بواسطة SUPI/IMSI.

تظهر واجهة الإدارة POST /api/eps_handover لدفع العمل الداخلي. يتم الإعلان عن عنوان S5/S8-C لـ PGW-C المقترن عبر مفتاح التكوين pgw_c_addr (انظر مرجع التكوين).