← نظرة عامة

دليل عمليات 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	تلقي تحديثات 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	معلومات SM N2 من 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 عبر معلومات SM N2)
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 أولاً. رسالة SM N1 هي قبول إنشاء جلسة NAS ومعلومات SM N2 هي PDUSessionResourceSetupRequestTransfer NGAP، تحمل كجسم 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؛ يتم فشل تخصيص IP لـ DNN الموجود في UDM ولكن بدون إدخال مطابق في subnet_map وبدون مجموعة default مع :no_pool_for_dnn.

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

يتم تعيين عنوان IP (IPv4، IPv6، أو كليهما) لكل جلسة PDU قبل إنشاء جلسة 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 في السياسة (قاعدة الشحن HSS PCRF إلى 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 عبر معلومات SM N2.

إنهاء جلسة 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 على UPF N3 F-TEID
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 التداخل بين EPS (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 (S-GW S5/S8-U TEID/عنوان لـ EPS، gNB N3 TEID/عنوان لـ 5GS) مع الحفاظ على نفس عنوان IP لـ UE ونفس جلسة PFCP على UPF. يعيد التبديل عرض EPS (عنوان IP محفوظ لـ UE، DNN، AMBR للجلسة، معرف الناقل الافتراضي EPS، و F-TEID لـ PGW-U) الذي يستخدمه PGW-C للرد على SGW.
• بحث: يمكن قراءة جلسات PDU النشطة لـ UE كعرض اتصالات PDN EPS بواسطة SUPI/IMSI.

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