خادم ACS إنتاجي لبروتوكولَي TR-069 و TR-369 — على نفس الرسم البياني الذي يحوي المشترك.
يأتي ACS من Netxol ضمن NMM. يدعم CWMP لأجهزة CPE القديمة، وUSP (TR-369) عبر MQTT وWebSocket للأجهزة الحديثة، ونموذج TR-181، واختبارات TR-143، والتفعيل التلقائي حسب ملف الخدمة، ومستودع للـFirmware مع إطلاق تدريجي وroll-back. ولأن الخادم يعيش على الرسم البياني المشترك، فإن تغيير CPE وتغيير خطة المشترك يصبحان نفس المحادثة.
مشغّلو FTTH وWISP الذين يقارنون ACS مستقلاً بواحد مدمج في المنصة — والذين ينتقلون من GenieACS أو Incognito أو HDM أو ACS مغلق من مورّد بعينه.
ظلّت صناعة مزوّدي الخدمة لسنوات تتعامل مع ACS كتطبيق منفصل — خادم بقاعدة بياناته الخاصة ومسار دخوله الخاص، يقف بجوار NMS وCRM وأداة الفوترة. هذا الفصل هو السبب في أن zero-touch لا يزال صعباً: يعرف الـACS جهاز الـCPE لكن لا يعرف مَن هو العميل، ولا الخطة التي اشتراها، ولا منفذ الـOLT الذي يتصل به.
ACS من Netxol جزء من الدرجة الأولى داخل NMM. يطبّق TR-069 (CWMP) وTR-369 (USP) بجودة إنتاجية، مع نقلَي MQTT وWebSocket بحيث تصبح تفاعلات USP قائمة على الأحداث بدلاً من الاستفتاء. يُحترم نموذج TR-181؛ وتُعالَج امتدادات المورّدين عبر إطار مُهيَّئات (Adapters)، فيصبح إضافة موديل CPE جديد إضافة Plugin لا إصداراً جديداً.
المكسب التجاري هو zero-touch كما ينبغي. جهاز يُشحَن للمشترك يتصل بالخادم، ويُوثَّق، ويكتشف ملف خدمته، ويحمّل تهيئته، ويصبح فعّالاً — عادةً في أقل من 15 دقيقة من الفتح — دون زيارة فنية. حملات الـFirmware تُطلَق canary → 1% → 100% مع roll-back آلي عند تدهور مؤشر الصحة.
ولأن CPE والمشترك والفاتورة ومنفذ OLT يشيرون جميعاً إلى الهوية نفسها على الرسم البياني المشترك، يصبح كل إجراء من ACS ذا سياق افتراضياً. حملة Firmware اكتشفت دفعة مُعطّلة تُسمّي العملاء المتأثرين تلقائياً. مشترك يتصل بخدمة العملاء يرى حالة CPE فوراً دون جسر تكامل.
أربع خطوات.
فعِّل TR-069 و TR-369
CWMP للأجهزة القديمة، وUSP (MQTT/WebSocket) للأجهزة الحديثة — كلاهما في خادم واحد.
اربط zero-touch بملفات الخدمة
يتوثّق الجهاز → تُقرأ خطة CRM → تُطبَّق التهيئة القالبية → يعمل الجهاز. دون خطوة يدوية.
أطلق حملات Firmware بأمان
إطلاق canary → 1% → 100% مع roll-back آلي عند تدهور الصحة. كل خطوة قابلة للتدقيق.
اجعل الرسم البياني مشتركاً بين الرعاية والفوترة
يعيش CPE على نفس سجل المشترك الذي يراه CRM وBilling — بلا جسر ولا تصدير ولا انحراف.
كل CPE، كل بروتوكول، كل مورّد.
ACS من Netxol ليس غلافاً رقيقاً فوق محرك مفتوح المصدر، بل وحدة من الدرجة الأولى داخل NMM بتنفيذ مشترك لـTR-069 و TR-369، ونمذجة TR-181، وتشخيصات TR-143، وإطار محوّلات لكل مورّد، ومستودع Firmware مع حملات مرحلية، ونموذج متعدّد المستأجرين يشغّل عدّة علامات مشغّل على الخادم نفسه. تفصّل الأقسام أدناه كل قطعة.
TR-069 (CWMP) — كل CPE قديم لديك
ينفّذ Netxol بروتوكول Broadband Forum TR-069 / CWMP (عميل / خادم)، بما فيه جميع RPCs المعيارية: Inform وGetParameterValues وSetParameterValues وGetParameterNames وGetParameterAttributes وSetParameterAttributes وAddObject وDeleteObject وDownload وUpload وReboot وFactoryReset وScheduleInform وChangeDUState وScheduleDownload وإشعارات Autonomous Transfer. يُعالج session pooling حركة إعادة الاتصال دون استنزاف عرض النطاق. تعمل الأجهزة التي تتحدث CWMP فقط من اليوم الأول بدون تعديل شفرة.
- كل RPCs الـCWMP المعيارية منفَّذة
- دعم تعديلات TR-069 من 1 إلى 6
- session pooling للأساطيل الضخمة
- نقل HTTPS مع TLS 1.3
- طلب اتّصال عبر TR-069 أو STUN
TR-369 (USP) — الخليفة الحديث، مدفوع بالحدث
TR-369 (User Services Platform) هو خليفة TR-069. ينفّذ Netxol نموذج USP Agent / Controller كاملاً مع نقلَي MQTT وWebSocket، فيستطيع CPE أن يدفع الأحداث (بنموذج اشتراك) بدلاً من أن يُستفتى — إشارة أفضل جوهرياً في أسطول كبير حيث الاستفتاء كل دقيقة غير عملي. Broker MQTT مضمَّن؛ ودعم WebSocket لـCPE خفيف. إشعارات USP تُغذّي الرسم البياني المشترك لحظياً.
- نموذج USP Agent + Controller كامل
- Broker MQTT مضمَّن (متوافق Mosquitto)
- نقل WebSocket لأجهزة CPE خفيفة
- مدفوع بالحدث — لا عواصف polling
- STOMP / CoAP في خارطة الطريق
نموذج بيانات TR-181 + محوّلات مورّدين
نموذج TR-181 (Device:2) هو المفردات القياسية — واجهات LAN وWAN وراديوهات Wi-Fi ومنافذ Ethernet وجداول IP forwarding وحلّالات DNS وخوادم DHCP وسياسات QoS وVoIP. ينفّذ Netxol الشجرة كاملة ويمدّها عبر إطار محوّلات مورّدين: امتدادات Huawei في إضافة Huawei، لا في نواة الـACS. إضافة موديل CPE يتحدّث شجرة مملوكة تصبح إسقاطاً لإضافة، لا رقعة شفرة.
- تنفيذ كامل لـTR-181 (Device:2)
- إطار إضافات محوّلات مورّدين
- يصحب محوّلات لكبار الموردين
- محوّلات مخصّصة تُكتب بـTypeScript
- سوق محوّلات في خارطة الطريق
تشخيص TR-143 — السرعة والكمون من الـCPE
تمنح RPCs التشخيصية في TR-143 قدرة NMM على تشغيل اختبار سرعة، وUDP echo، وthroughput TCP، وping من أي CPE، عند الطلب أو مجدولاً. مع قياسات OLT / edge التي يجمعها NMM، يغلق ذلك حلقة تشخيص تجربة المشترك: حين يتصل قائلاً "الإنترنت بطيء"، يعمل التشخيص من CPE نحو edge خاص بك — لا نحو خادم عام عشوائي.
- اختبارات throughput تحميل / رفع
- UDP echo وTCP throughput
- ping / IP ping / traceroute
- مجدول أو عند الطلب
- النتائج تهبط على سجل المشترك
التزويد بدون تدخّل — العائد التشغيلي
جهاز يُشحن للمشترك يتّصل بالـACS، ويوثّق نفسه على مخزون مسبق التسجيل (Serial + MAC + OUI)، ويقرأ ملف خدمته من CRM على الرسم البياني المشترك، ويحمّل تهيئته القالبية (SSIDs وPSKs وVLANs وQoS وبيانات VoIP وعناوين TR-069)، ويصبح فعّالاً — عادةً خلال 15 دقيقة من الفتح، دون زيارة فنية. في المشغّلين الناضجين يصبح zero-touch الطريق الافتراضي؛ والزيارات الفنية هي الاستثناء.
- تسجيل مسبق بـSerial + MAC + OUI
- ملف الخدمة يُقرأ من CRM
- تهيئة قالبية حسب الفئة
- توليد تلقائي لـSSID / PSK Wi-Fi
- بيانات VoIP تُهيّأ في نفس التدفّق
حملات Firmware — canary وrolling وrollback
كل مشغّل احترق مع إصدار firmware سيّئ. يتعامل Netxol مع التوزيع كحملة: اختر build مرشّح؛ ring 0 عشرة أجهزة اختبار في المختبر؛ ring 1 يمثّل 1% من الأسطول؛ ring 2 يمثّل 10%؛ ring 3 يمثّل 100%. بين المراحل تُراقب إشارة الصحة (عدّاد انهيار CPE، معدّل drop PON، churn الجلسة، تذاكر الشكاوى). أي تراجع يستدعي rollback آلي للمراحل المتبقّية. كل خطوة تخضع للتدقيق.
- إطلاق canary مبني على rings
- roll-back آلي عند تدهور الصحة
- أثر تدقيق كامل لكل جهاز
- مُجمَّع حسب الموديل / عائلة firmware
- roll-back لمشترك أو موديل أو الأسطول كلّه
كتالوج CPE مدعوم
يصحب ACS Netxol محوّلات مختبَرة لماركات CPE يستخدمها المشغّلون فعلاً: Huawei (سلسلة HG وEG وOptixstar)، ZTE (F600 وF660 وF670L وF680 وF6600)، FiberHome (HG6145 وHG6543 وAN5506)، Nokia (G-140W وG-1425G وG-2425G)، Genexis (Pulse وLive)، Tenda (HG9)، TP-Link (HX510 وXC220)، Zyxel (PMG5622)، Cambium (cnPilot وePMP)، Ubiquiti (UniFi UAP وEdgeRouter)، MikroTik (RouterOS مع عميل TR-069)، والتنفيذات المرجعية لـUSP-Agent. تُضاف موديلات جديدة باستمرار.
- Huawei HG / EG / Optixstar
- ZTE F600 / F660 / F670L / F680 / F6600
- FiberHome HG6145 / HG6543 / AN5506
- Nokia G-140W / G-1425G / G-2425G
- Genexis وTenda وTP-Link وZyxel
- Cambium وUbiquiti وMikroTik
- تنفيذات USP-Agent المرجعية
الهجرة من GenieACS أو Incognito أو HDM
يصل معظم المشغّلين إلى Netxol من أحد ثلاثة أسلاف: GenieACS (مفتوح المصدر، مجتمعي، بلا دعم تجاري)، وIncognito Broadband Command Center (ثقيل ومكلف ومتقادم)، وNokia HDM (مقيّد بـCPE من Nokia). يوفّر Netxol أدوات هجرة: استيراد جماعي لمخزون CPE (CSV وdump قاعدة بيانات GenieACS وexport HDM)، ومصالحة حالة عند أول جلسة ACS (Inform يُجاب بدمج لا factory reset)، ووضع dry-run يُظهر ما سيتغيّر قبل الالتزام.
- مستوردات CSV / قاعدة بيانات GenieACS / export HDM
- مصالحة الحالة عند أول Inform
- وضع dry-run بعرض التغيير
- استيراد حملات firmware تاريخية
- صفر انقطاع مرئي للمشترك
ACS متعدّد المستأجرين — MVNO وجملة وعلامات فرعية
يدعم ACS Netxol مستأجرين معزولين يتشاركون خادماً واحداً: والدة MVNO تعيد البيع لعلامات أبناء، ومشغّل جملة يبيع النقل لـISP أصغر، ومجموعة تشغّل علامات إقليمية لكل منها فريق رعايتها. كل CPE وكل ملف خدمة وكل حملة firmware يخضع لمستأجر. الاستعلامات العابرة للمستأجرين مسموحة فقط لهويّات group-admin. السياق التشغيلي في /solutions/national-carrier.
- عزل مستأجر على مستوى CPE / ملف / حملة
- دعم والدة MVNO + علامات أبناء
- مشغّل جملة يعيد بيع سعة Netxol
- SLA وحدود معدّل لكل مستأجر
- عرض عبر المستأجرين للمشغّلين group
الأمان والحجم والتدقيق
يتولّى الـACS العملية الحسّاسة أمنياً بدفع التهيئة إلى أجهزة العملاء — أي اختراق هنا يصبح اختراقاً لكل مشترك. ينفّذ Netxol TLS 1.3 مع certificate pinning، وmTLS على طلبات الاتّصال، وحمولات تزويد موقّعة HMAC، ودوران بيانات اعتماد لكل CPE بجدول، وسجل تدقيق كامل يسمّي كل تغيير معلمة وكل دفع firmware وكل إعادة إقلاع. حجمياً يعالج الـACS مئات آلاف الـCPE النشطة لكل عنقود؛ راجع /blog/tr-369-usp-adoption-2026.
- TLS 1.3 + certificate pinning
- mTLS على طلبات الاتّصال
- حمولات تزويد موقّعة HMAC
- دوران بيانات اعتماد لكل CPE
- سجل تدقيق كامل — كل معلمة
- مئات آلاف الـCPE النشطة لكل عنقود
كل ما تحصل عليه مع هذا الـ playbook.
نُقرن هذا الـ playbook عادةً مع Netxol Core X5.
الـ X5 هو المحطة التي يستقرّ عندها معظم المشغّلين بعد أوّل 10٬000 مشترك. ضِعف القدرة الحوسبية، وطاقة احتياطية مزدوجة، وهامش يكفي لدورة حياة المشترك الكاملة — من تفعيل وحدة ONT إلى إغلاق الشهر المحاسبي.
مشغّلون يشغّلون هذه اللعبة بالفعل.
الأسئلة التي تصلنا في المكالمة الأولى.
كم يستغرق الوقت لتصبح مباشرًا؟
عمليات النشر الصغيرة تكتمل في أقل من أسبوع من إخراج Core من الصندوق إلى أول مشترك يدفع؛ عمليات النشر الأكبر تُخطَّط بالأسابيع لا بالأشهر.
هل نحتاج إلى تغيير عتادنا الحالي؟
لا. يُشحن NOS مع مُهيّئات لكل OLT وراوتر رئيسي. تحتفظ بالمعدات التي تمتلكها؛ نستبدل نحن الأدوات فوقها.
ماذا يحدث لبياناتنا؟
كل شيء يبقى على جهاز Core لديك افتراضيًا. النسخ الاحتياطية تذهب إلى مخزن الكائنات الذي تختاره. لا تغادر بيانات المشتركين رفّك ما لم تُفعّل قناة تلمتري اختيارية.
هل يمكننا الترحيل من منصة أخرى؟
نعم — نُدير مشروع ترحيل محدّد النطاق مع تعيينات بيانات متطابقة ونوافذ تبديل. الإصدارات القياسية تشمل أول ترحيل.
قصص أخرى بهذا الشكل.
أرسل ONT إلى مشترك. حين يوصله بالكهرباء، يُزوّده NOS، ويربطه بسجلّه، ويُطلق خطته — دون أن يلمس فنّي أيّ ملف تهيئة.
اقرأالنتيجةHuawei وZTE وFiberHome وCDATA وV-SOL وHSGQ وBDCOM وNokia وغيرها — مُجرَّدة خلف واجهة موحّدة محايدة المورّد. تُراقَب البطاقات والمنافذ والبيئة باستمرار. تُكتشف ONT تلقائياً (بما فيها غير المصرّح بها)، وتُهيَّأ في ثوانٍ، وتُستَعاد بنظافة. عتبات الطاقة البصرية Tx/Rx تلتقط لَحمة متدهورة قبل أسابيع من ملاحظة المشترك.
اقرأالنتيجةمعظم ما يفعله NOC عند الثالثة صباحاً صغير ومملّ وقابل للتكرار. صُمّم NOS لملاحظة تلك الأنماط، والتصرّف حيالها بأمان، وإبقاء البشر في الحلقة لأي شيء ليس روتيناً.
اقرأ