طلبات Zero-touch مع بقاء التحكم بيد الأشخاص: طلب واحد من الـ BSS، وتفعيلات عبر الشبكات المتنقلة والثابتة وشبكات التلفزيون

المشكلة

يبيع مشغّل متقارب الاتصالات المتنقلة والهاتف الثابت والإنترنت عبر GPON (Gigabit Passive Optical Network) والنحاس والتلفزيون الفضائي من BSS واحد. والطلب التجاري الواحد يعني عملًا على عدة عناصر في الشبكة: خط postpaid جديد يمس الـ HLR (Home Location Register) والـ PCRF (Policy and Charging Rules Function) والـ OCS ومنصة البريد الصوتي، ولكل منها بروتوكولها — MML (Man-Machine Language) over SSH و SOAP و CLI و HTTP.

وعندما يتعيّن على مدير الطلب التجاري أن يعرف كل ذلك، تصبح الباقة الجديدة تغييرًا في عدة أنظمة، ويترك العطل في عنصر واحد الطلب منجزًا جزئيًا دون أن يرى أحد أين توقف.

ما الذي يُطلب

• الاتصالات المتنقلة: خط جديد، وتغيير الرقم، وتغيير الـ SIM أو الـ IMEI (International Mobile Equipment Identity)، وباقات إضافية للبيانات والصوت، والتعليق وإعادة التفعيل في الاتجاهين، والإيقاف الإداري، وإلغاء الخط، وإدراج الأجهزة في القائمة السوداء.
• الهاتف الثابت والإنترنت: تفعيل الخط، والقطع وإعادة التوصيل، والبريد الصوتي، و caller ID و call forwarding، والإنترنت للعملاء الأفراد والشركات، وحسابات AAA (Authentication, Authorization and Accounting) وقفلها.
• التلفزيون: إعادة التفعيل بعد الدفع، والتعليق لعدم الدفع، وجهاز فك تشفير إضافي، وأوامر عمل التركيب والإزالة.

ما الذي يتغيّر

1. يرسل الـ BSS الـ product order عبر TM Forum Open API. ويفكّكه كتالوج المنتجات (product catalog) إلى بنود طلب (order items) وصولًا إلى الخدمات الموجّهة للعملاء والخدمات الموجّهة للموارد.
2. تتسلّم إدارةُ طلبات الخدمة الـ service order (TMF641 Service Order)، وتسجّل الخدمة في الـ service inventory، وتبني خطة orchestration من بنود الطلب والاعتماديات بينها.
3. لكل مورد يُفتح resource order: يأتي ملف التعريف من الـ resource profiles inventory، ويجري التفعيل (TMF640 Service Activation and Configuration) بوصفه قالب شبكة قابلًا للتنفيذ — عملية BPMN لكل نوع من العناصر عبر HTTP أو SSH أو Telnet.
4. عندما تؤكد العناصر، يُحدَّث الـ resource inventory والـ service inventory، ويتلقى الـ BSS حالة «completed» بوصفها event؛ وترى كل الفرق حالة كل بند طلب على طول الطريق.
5. تدخل التغييرات أثناء التنفيذ — الإضافة والتغيير والفصل والتعليق والاستئناف، ومراجعة طلب سبقت مراجعته — في الخطة نفسها بدلًا من طلب جديد.
6. حيث يتعطل عنصر أو تحتاج خطوة إلى شخص، تتحول الخطوة إلى مهمة provisioning يدوية أو إلى trouble ticket: يحرّر شخص الطلب وتتابع العملية. وتذهب أوامر عمل التركيب والإزالة إلى أنظمة الشركاء.

ما القيمة

• يرسل الـ BSS طلبًا واحدًا ويتلقى إجابة واحدة؛ وتبقى بروتوكولات الشبكة ومجموعات أوامرها في إدارة طلبات الخدمة، لذا فالباقة الجديدة تغيير في الكتالوج والقوالب، لا في الـ BSS.
• تخضع كل عملية للتدقيق، ويُراقَب الاتصال بكل منصة، مع تنبيهات على الشاشة وعبر البريد الإلكتروني.
• هدف التصميم: تتغير المهل والمستخدمون والأذونات وإعدادات الخدمات في شاشة إعداد مع أدوار، دون تغييرات في الكود.
• تمنع الأولويات والمعالجة المتوازية الطلبات الحرجة من الانتظار خلف طابور؛ وهدف التصميم 30 ثانية لكل عملية تفعيل أو إلغاء تفعيل أو تغيير خدمة.

نطاق الحل

السيناريو المستهدف: حل لمشغّل متقارب يغطي الاتصالات المتنقلة والثابتة والإنترنت والتلفزيون — البنية، وتفكيك الطلبات، والمحوّلات إلى عناصر الشبكة، والتوافر العالي على موقعين، بنمط active-active أو active-standby، على Kubernetes. ويُتفق على النطاق في المشروع، حسب خطوط الخدمة.

السيناريو المستهدف لإدارة طلبات الخدمة المعزّزة بالـ AI: قوالب شبكة على نماذج IETF YANG بالاقتران مع TMF641 Service Order و TMF640 Service Activation and Configuration، و Knowledge Graph الذي يربط الخدمات الموجّهة للعملاء بموارد الشبكة — تفكيك Customer Facing Service (CFS) و Resource Facing Service (RFS)، والـ inventory والطوبولوجيا على نماذج YANG. ويُبنى النموذج في المشروع على بيانات المشغّل.

ما الذي يقدّمه MEF.DEV

إدارة طلبات الخدمة على Enablement & Monetization Platform مع MEF.DEV BPMN Low-code: BPMN Flow Designer، ومحرّك الـ orchestration، وإعداد الكتالوج، ومحوّلات التكامل إلى عناصر الشبكة بوصفها backend plugins، مع تفعيل الخدمات وأنظمة الـ inventory من WideCoup Convergent BSS. ويحتفظ شريك الـ BSS والمشغّل بالطلب التجاري ومنطق الأعمال؛ ويبني MEF.DEV الـ backend والمحوّلات.