انتقل إلى المحتوى الرئيسي

OmniRoam

OmniRoam هي الحل الشامل لإدارة الإيرادات بالجملة لمشغلي التجوال من Omnitouch. تتعامل مع دورة حياة بيانات التجوال CDRs (سجلات تفاصيل المكالمات) بالكامل، من الاستيعاب إلى التصنيف إلى توليد ملفات TAP3 والتقارير.

جدول المحتويات​

نظرة عامة​

تقوم OmniRoam بمعالجة CDRs التجوال من مشغلي الشبكات المحمولة، وتصنيفها باستخدام محرك تصنيف OmniCharge، وتوليد ملفات TAP3 متوافقة مع GSMA للفوترة، وتوفير قدرات شاملة للمراقبة والتقارير.

OmniTAP Architecture 1

عملية استيراد وتصنيف CDR​

عملية تصدير TAP3​

دليل العمليات​

تشغيل تصدير TAP3​

# تصدير لشريك محدد
python3 export_TAP3.py VZW_Live

# وضع تفاعلي (يطلب الشريك)
python3 export_TAP3.py

تتضمن عملية التصدير:

  1. استعلام CDRs من آخر 30 يومًا (متطلبات GSMA)
  2. تصفية CDRs المعلّمة بأنها تمت معالجتها بالفعل
  3. استبعاد CDRs التي يكون وقت نهايتها أقل من ساعة مضت (يمنع الجلسات غير المكتملة)
  4. تجميع CDRs حسب الشريك في التجوال
  5. توليد ملف TAP3 لكل شريك
  6. تعليم CDRs بأنها تمت معالجتها في قاعدة البيانات
  7. زيادة عداد التسلسل
  8. دفع المقاييس إلى InfluxDB

المراقبة والتقارير​

تقوم OmniRoam بدفع المقاييس في الوقت الحقيقي إلى InfluxDB للمراقبة والتحليلات.

المقاييس ا��مجمعة​

مقاييس CDR الخام تم دفعها خلال عملية استيراد وتصنيف CDR:

  • operator: معرف شريك التجوال
  • input_file: اسم ملف CSV المصدر
  • apn: اسم نقطة الوصول (معرف خدمة البيانات)
  • cellId: معرف برج الخلية
  • imsi: هوية المشترك
  • tac: رمز منطقة التتبع
  • sGWAddress: عنوان IP للبوابة الخدمية
  • pGWAddress: عنوان IP لبوابة PDN
  • chargeableUnits: إجمالي بايت الاستخدام
  • chargedUnits: التكلفة المحسوبة

مقاييس تصدير TAP تم دفعها خلال عملية توليد ملف TAP3:

  • operator: معرف شريك التجوال
  • filename: اسم ملف TAP3 المولد
  • totalcharge: إجمالي التكلفة في ملف TAP3
  • totalconsumed: إجمالي البايتات في ملف TAP3
  • cdr_count: عدد CDRs في ملف TAP3

استعلامات لوحة المعلومات​

مثال على استعلامات InfluxDB للمراقبة:

الإيرادات حسب المشغل

SELECT sum("totalcharge")
FROM "tap_cdr"
WHERE time > now() - 30d
GROUP BY "operator"

استخدام البيانات حسب TAC

SELECT sum("chargeableUnits")
FROM "raw_cdr"
WHERE time > now() - 7d
GROUP BY "tac"

حجم CDR حسب الساعة

SELECT count("chargeableUnits")
FROM "raw_cdr"
WHERE time > now() - 24h
GROUP BY time(1h)

الإيرادات حسب APN

SELECT sum("chargedUnits")
FROM "raw_cdr"
WHERE time > now() - 7d
GROUP BY "apn"

تكامل Grafana​

إنشاء لوحات معلومات Grafana باستخدام هذه المقاييس من أجل:

  • مراقبة الإيرادات في الوقت الحقيقي
  • تحليل أنماط الحركة
  • تتبع أداء الشركاء
  • استخدام موارد الشبكة
  • اكتشاف الشذوذ
  • تسوية الفواتير

استكشاف الأخطاء وإصلاحها​

OmniTAP Architecture 3

مشاكل استيراد CDR​

تحقق من السجلات في /tmp/import_CDR_Logger_Marben_*.log

المشاكل الشائعة:

  • تنسيق IMSI غير صالح
  • الحقول المطلوبة مفقودة
  • أخطاء تحويل المنطقة الزمنية
  • معرفات ا��شحن المكررة

مشاكل تصدير TAP3​

تحقق من السجلات في /tmp/tap3_export_*.log

المشاكل الشائعة:

  • لا توجد CDRs في آخر 30 يومًا
  • تكوين TAC مفقود
  • رقم تسلسل غير صالح
  • أخطاء في اتصال قاعدة البيانات

أخطاء تصنيف OmniCharge​

راجع سجلات OmniCharge من أجل:

  • خطط أسعار مفقودة
  • الحساب غير موجود
  • قيم استخدام غير صالحة
  • أخطاء تحويل العملات

مشاكل اتصال InfluxDB​

تحقق من:

  • إمكانية الوصول إلى عنوان URL لـ InfluxDB
  • رمز المصادقة صالح
  • وجود الدلو
  • الاتصال بالشبكة

الدعم والصيانة​

مواقع السجلات​

  • استيراد CDR: /tmp/import_CDR_Logger_Marben_*.log
  • تصدير TAP: /tmp/tap3_export_*.log

ملفات التكوين الرئيسية​

  • config.yaml - التكوين الرئيسي (أسعار الشركاء، إعدادات الشبكة، اتصال InfluxDB)
  • counters.yaml - عدادات تسلسل ملفات TAP3

مهام الصيانة الدورية​

  1. مراقبة عدادات التسلسل - التأكد من عدم تجاوزها 99999
  2. أرشفة ملفات TAP القديمة - نقل الملفات التي تزيد عن فترة الاحتفاظ
  3. مراقبة استخدام القرص InfluxDB - تكوين سياسات الاحتفاظ
  4. مراجعة تكوينات الأسعار - تحديثها عند تغيير أسعار الشركاء
  5. نسخ ملفات التكوين احتياطيًا - config.yaml و counters.yaml
  6. مراقبة تراكم CDR - التأكد من المعالجة في الوقت المناسب

معمارية النظام​

نظرة عامة على المعمارية​

عملية استيراد CDR​

تستخدم OmniRoam عملية استيراد من مرحلتين مع Cache كطبقة تجميع مؤقتة لتجميع سجلات CDR الجزئية إلى CDRs كاملة قابلة للفوترة.

فهم CDRs الجزئية​

لا تولد عناصر الشبكة المحمولة (S-GW/P-GW) CDR واحد لجلسة بيانات. بدلاً من ذلك، تنتج عدة سجلات CDR جزئية طوال دورة حياة الجلسة:

  • سجل البداية: يتم إنشاؤه عند بدء جلسة البيانات
  • سجلات التحديث: يتم إنشاؤها بشكل دوري خلال الجلسة (مثل كل 15 دقيقة أو كل 100 ميغابايت من استخدام البيانات)
  • سجل التوقف: يتم إنشاؤه عند انتهاء الجلسة

كل سجل جزئي يحتوي على بيانات استخدام متزايدة. من أجل فوترة دقيقة، يجب على OmniRoam:

  1. تحديد أي السجلات الجزئية تنتمي إلى نفس جلسة البيانات
  2. تجميع بيانات الاستخدام من جميع السجلات الجزئية
  3. حساب إجمالي مدة الجلسة
  4. تجميع CDR كاملة واحدة تمثل الجلسة بالكامل

لماذا Cache لتجميع CDR؟​

يعمل Cache كمنطقة احتفاظ مؤقتة عالية الأداء حيث تتجمع CDRs الجزئية حتى تكتمل الجلسة. يوفر Cache:

  • بحث سريع عن القيم الرئيسية - العثور على CDRs جزئية موجودة لجلسة على الفور
  • تخزين في الذاكرة - عمليات قراءة/كتابة عالية السرعة للتجميع في الوقت الحقيقي
  • عمليات ذرية - تحديثات متزامنة آمنة من عمليات الاستيراد المتعددة
  • استمرارية - تبقى CDRs على قيد الحياة خلال إعادة تشغيل النظام خلال نافذة التجميع

معمارية الاستيراد من مرحلتين​

المرحلة 1: تحليل CSV وتجميع CDR الجزئية​

تقوم المرحلة الأولى بقراءة ملفات CSV من عناصر الشبكة S-GW باستمرار وتجميع CDRs الجزئية في Cache.

كيفية تحديد السجلات الجزئية ومطابقتها​

يجب على OmniRoam تحديد أي السجلات الجزئية تنتمي إلى نفس جلسة البيانات. يتم تحديد كل جلسة بشكل فريد بواسطة معرف الجلسة المركب الذي يتكون من:

  • معرف الشحن: معرف الجلسة الفريد من عنصر الشبكة
  • IMSI: هوية المشترك (معرف رقم الهاتف المحمول)
  • التاريخ: تاريخ الجلسة في المنطقة الزمنية للشبكة الخدمية
  • عنوان IP للبوابة P-GW: البوابة التي تعاملت مع الجلسة
  • TAC: رمز منطقة التتبع (موقع برج الخلية)
  • QCI: فئة جودة الخدمة

يضمن هذا المزيج أن جميع السجلات الجزئية من نفس جلسة البيانات يتم تجميعها معًا، حتى عندما تصل ملفات متعددة بترتيب غير صحيح.

كيفية تجميع CDRs الجزئية​

عندما يقوم محلل CSV بمعالجة كل CDR جزئي:

  1. توليد معرف الجلسة من حقول CDR
  2. التحقق من Cache لمعرفة ما إذا كانت هذه الجلسة موجودة بالفعل
  3. إذا كانت الجلسة موجودة في Cache:
    • استرجاع بيانات CDR المجمعة
    • التحقق من أن هذا الملف لم تتم معالجته من قبل (يمنع التكرار)
    • إضافة بيانات الاستخدام الجديدة: بايتات واردة + بايتات صادرة
    • تحديث مدة الجلسة باستخدام أقدم وأحدث الطوابع الزمنية
    • حفظ البيانات الوصفية حول هذا السجل الجزئي لأغراض التدقيق
    • حفظ CDR المحدث مرة أخرى في Cache
  4. إذا كانت جلسة جديدة:
    • إنشاء إدخال CDR جديد في Cache
    • تهيئة عدادات الاستخدام وبيانات الجلسة
    • تسجيل الطابع الزمني للسجل الجزئي الأول

مسار التدقيق والبيانات الوصفية​

يتم تتبع كل سجل جزئي يساهم في CDR مع بيانات وصفية شاملة:

  • اسم الملف المصدر: أي ملف CSV يحتوي على هذا السجل ال��زئي
  • الطابع الزمني: متى أنشأ عنصر الشبكة هذا السجل
  • وقت المعالجة: متى استلمت OmniRoam وعالجته
  • مساهمة الاستخدام: مقدار البيانات التي أضافها هذا الجزء (بايتات واردة/صادرة)
  • نوع الحدث: سواء كان هذا سجل بداية أو تحديث أو توقف
  • المنطقة الزمنية للشبكة الخدمية: من أجل تحويل الطوابع الزمنية بدقة

لماذا تعتبر البيانات الوصفية حاسمة للمحاسبة:

يسمح مسار التدقيق هذا لـ OmniRoam بتتبع شحنة واحدة من البداية إلى النهاية عبر كل مرحلة معالجة، وهو أمر ضروري لـ:

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

حساب مدة الجلسة​

يتم حساب إجمالي مدة الجلسة من خلال العثور على:

  • أقدم طابع زمني عبر جميع السجلات الجزئية (بداية الجلسة)
  • أحدث طابع زمني عبر جميع السجلات الجزئية (نهاية الجلسة)
  • المدة = الأحدث - الأقدم

بالنسبة للجلسات التي توجد فيها سجلات تحديث فقط (مفقودة بداية/توقف)، تكون المدة الافتراضية 24 ساعة.

المرحلة 2: تجميع CDR والتصنيف​

تقوم المرحلة الثانية بفحص Cache دوريًا للبحث عن الجلسات المكتملة، وتجميع CDRs النهائية، وتقديمها إلى OmniCharge للتصنيف.

كيفية اختيار CDRs الكاملة من Cache​

تعمل عملية تجميع CDR بشكل مستمر وتفحص جميع الجلسات المخزنة في Cache:

  1. فحص Cache لجميع جلسات CDR المجمعة
  2. ا��معالجة في دفعات من 1000 جلسة في كل مرة
  3. لكل جلسة:
    • استخراج تاريخ الجلسة من معرف الجلسة
    • تخطي إذا كانت قديمة جدًا (> 30 يومًا): حذف من Cache (يمنع تراكم البيانات القديمة)
    • تخطي إذا كانت حديثة جدًا (< 24 ساعة): تركها في Cache لوصول المزيد من السجلات الجزئية
    • تحميل CDR الكاملة مع جميع البيانات المجمعة

فترة الانتظار لمدة 24 ساعة​

لماذا تنتظر OmniRoam 24 ساعة قبل تصنيف CDR؟

  • تصل السجلات الجزئية بترتيب غير صحيح: يمكن أن تؤدي الازدحامات في الشبكة إلى تأخير تسليم ملفات CSV لساعات
  • تغطي الجلسات منتصف الليل: تولد جلسة تبدأ في الساعة 11:50 مساءً ملفات بتاريخين مختلفين. يمكن أن يمتد نفس معرف الشحن عبر عدة أيام، مع سجلات جزئية مؤرخة بشكل مختلف
  • تتأخر سجلات التحديث: قد تصل سجلات التحديث الدورية بعد انتهاء الجلسة بفترة طويلة
  • توليد الملفات بشكل غير متزامن: تصدر عناصر الشبكة المختلفة الملفات في جداول زمنية مختلفة
  • الجلسات الطويلة: يمكن أن تستمر جلسات البيانات لساعات أو أيام، مع وصول سجلات التحديث طوال الوقت

من خلال الانتظار لمدة 24 ساعة، تضمن OmniRoam وصول جميع السجلات الجزئية وأن CDR مكتمل حقًا قبل الفوترة.

التحقق من CDR والتعزيز​

قبل التصنيف، تمر كل CDR مجمعة بعملية التحقق والتعزيز:

  1. التحقق من الاكتمال:

    • التحقق مما إذا كانت سجلات البداية/التوقف موجودة
    • إذا كانت موجودة سجلات تحديث فقط، يتم تعيين المدة إلى 24 ساعة (افتراضي)

  2. التخلص من CDRs غير الصالحة:

    • يتم حذف الجلسات التي لا تحتوي على استخدام (لا توجد نشاطات قابلة للفوترة)

  3. حساب الاستخدام النهائي:

    • جمع جميع بايتات الواردة والصادرة
    • تطبيق قواعد التقريب الخاصة بالشركاء (مثل تقريب إلى أقرب 1 كيلوبايت)

  4. تعزيز البيانات ب��علومات الموقع:

    • ربط TAC (رمز منطقة التتبع) بموقع الشبكة الخدمية
    • إضافة معلومات المنطقة الزمنية لتحويل الطوابع الزمنية بدقة
    • إضافة وصف الموقع الجغرافي

  5. تقديم إلى OmniCharge:

    • إرسال CDR الكاملة والمعززة للتصنيف
    • استلام التكلفة المحسوبة

  6. التخزين والتنظيف:

    • حفظ CDR المصنفة في قاعدة البيانات
    • دفع المقاييس إلى InfluxDB للتقارير
    • حذف CDR المعالجة من Cache

هيكل بيانات CDR​

تحتوي كل CDR مجمعة على:

  • معلومات المشترك: IMSI، MSISDN، IMEI
  • معلومات الشبكة: بوابة الخدمة (S-GW)، بوابة PDN (P-GW)، معرف البرج، TAC (رمز منطقة التتبع)
  • تفاصيل الجلسة: الطوابع الزمنية للبداية/النهاية، المدة، APN (اسم نقطة الوصول)
  • بيانات الاستخدام: حجم البيانات الواردة/الصادرة، إجمالي الوحدات القابلة للفوترة
  • معلومات الموقع: BID الخدمي (معرف الشبكة)، الموقع الجغرافي
  • معل��مات QoS: QCI (معرف فئة جودة الخدمة)

قواعد معالجة البيانات​

تقريب الاستخدام​

تتم تقريب CDRs بناءً على تكوين محدد للشريك في config.yaml:

partners:
  Example_Live:
    round_up_to: 1024  # تقريب الاستخدام إلى أقرب 1KB

يقوم النظام:

  1. بحساب إجمالي الاستخدام: dataVolumeIncoming + dataVolumeOutgoing
  2. بالتقريب إلى الوحدة المكونة (مثل 1024 بايت)
  3. بالحفاظ على القيم الأصلية لأغراض التدقيق

تحديد الموقع بناءً على TAC​

يحدد النظام موقع الشبكة الخدمية بناءً على TAC (رمز منطقة التتبع):

config:
  tac_config:
    Global:
      tac_list: ['1101', '10000', '10100']
      servingBid: 72473
      servingLocationDescription: 'Smallville USA'
      timezone: 'America/Smallville'

هذا يمكّن من:

  • تحويل الطوابع الزمنية بشكل صحيح
  • تعيين الموقع الجغرافي
  • تحديد الشبكة الخدمية

محرك تصنيف OmniCharge​

ترسل OmniRoam CDRs إلى OmniCharge، المحرك القوي للتصنيف الذي يحسب الرسوم بناءً على خطط الأسعار القابلة للتكوين.

OmniTAP Architecture 2

عملية التصنيف​

تكوين الأسعار​

يتم تكوين الأسعار لكل شريك تجوال في ملف التكوين:

partners:
  Example_Live:
    imsi_prefixes:
      - 99901
    rates:
      unit_price: 0.000476800  # السعر لكل وحدة
      unit_bytes: 1024          # حجم الوحدة بالبايت
    batch_info:
      sender: AUSIE
      recipient: AAA00
      accountingInfo:
        localCurrency: 'USD'
        tapCurrency: 'USD'
        roundingAction: 'Simple'
        tapDecimalPlaces: 5

مطابقة بادئات IMSI​

تقوم OmniRoam بمطابقة CDRs مع شركاء التجوال باستخدام مطابقة بادئات IMSI مع منطق المطابقة الأطول أولاً. يسمح ذلك للمشغلين بإنشاء تكوينات محددة لبطاقات SIM الاختبارية مع الحفاظ على التكوينات العامة لحركة المرور الإنتاجية.

كيفية عمل مطابقة البادئات​

عند تصنيف CDR، تقوم OmniRoam:

  1. باستخراج IMSI من CDR (مثل 310410123456789)
  2. تقييم جميع تكوينات الشركاء بالترتيب
  3. العثور على أطول بادئة مطابقة
  4. تطبيق أسعار وتكوينات ذلك الشريك

مثال: تكوين SIM الاختباري​

تعتبر هذه الميزة مفيدة بشكل خاص لاختبار TADIG/IREG حيث تحتاج بطاقات SIM الاختبارية إلى معالجة مختلفة:

partners:
  Demo_Test:
    imsi_prefixes:
      - 0010112345123  # نطاق SIM الاختباري (بادئة 9 أرقام)
    rates:
      unit_price: 0.0  # لا توجد رسوم لحركة المرور الاختبارية
    batch_info:
      sender: AUSIE
      recipient: AAA00TEST

  Demo_Production:
    imsi_prefixes:
      - 001011  # نطاق الإنتاج (بادئة 6 أرقام)
    rates:
      unit_price: 0.000476800
    batch_info:
      sender: AUSIE
      recipient: AAA00

سلوك المطا��قة:

  • IMSI 00101123451234 → تطابق Demo_Test (بادئة 9 أرقام أطول)
  • IMSI 00101023456789 → تطابق Demo_Production (بادئة 6 أرقام)

هذا يضمن أن حركة المرور الاختبارية تذهب إلى ملفات TAP الاختبارية مع رموز TADIG الاختبارية، بينما يتم فوترة حركة المرور الإنتاجية بشكل طبيعي مع رموز TADIG الإنتاجية.

حساب الرسوم​

لكل CDR:

  1. مطابقة الشريك: تحديد شريك التجوال بواسطة بادئة IMSI
  2. حساب الوحدات: totalBytes / unit_bytes
  3. تطبيق السعر: units × unit_price = charge
  4. تطبيق التقريب: تقريب بناءً على roundingAction (أعلى/أسفل/بسيط)
  5. التحويل إلى وحدات TAP: الضرب في 1000 لصيغة TAP3

مثال:

الاستخدام: 52,428,800 بايت (50 ميغابايت)
حجم الوحدة: 1024 بايت
الوحدات: 51,200
السعر: $0.000476800 لكل 1 كيلوبايت
الرسوم: 51,200 × $0.000476800 = $24.41
وحدات TAP: 24,410 (24.41 × 1000)

تعيين نوع المكالمة بناءً على QCI​

تُربط فئات جودة الخدمة (QCI) بمستويات نوع المكالمة في TAP3:

call_type_level:
  qci_1: 20  # محادثة (صوت)
  qci_2: 22  # محادثة (فيديو)
  qci_3: 23  # ألعاب في الوقت الحقيقي
  qci_4: 24  # بث مؤجل
  qci_5: 20  # إشارة IMS
  qci_6: 26  # تفاعلي (تصفح)
  qci_7: 27  # تفاعلي (ألعاب)
  qci_8: 28  # خلفية
  qci_9: 29  # خلفية (أولوية منخفضة)
  default: 20

توليد ملفات TAP3​

بعد تصنيف CDRs بواسطة OmniCharge، تقوم OmniRoam بتوليد ملفات TAP3 القياسية من GSMA للفوترة بالجملة.

تدفق تصدير TAP3​

هيكل ملف TAP3​

قاعدة تسمية الملفات​

تتبع ملفات TAP3 معايير التسمية من GSMA:

<FileType><Sender><Recipient><SequenceNumber>

أمثلة:
CDAUSIEAAA0000001  - ملف بيانات تجاري من AUSIE إلى AAA00، التسلسل 1
TDAUSIEAAA0000001  - ملف بيانات اختبار من AUSIE إلى AAA00، التسلسل 1

حيث:

  • FileType: CD (تجاري) أو TD (اختبار)
  • Sender: رمز TADIG مكون من 5 أحرف
  • Recipient: رمز TADIG مكون من 5 أحرف
  • SequenceNumber: تسلسل مكون من 5 أرقام (من counters.yaml)

دليل التكوين​

تكوين الشريك​

إضافة الشركاء في التجوال في config.yaml:

partners:
  ONS_Live:
    imsi_prefixes:              # قائمة بادئات IMSI لهذا الشريك
      - 505057
    accessPointNameOI: mnc057.mcc505.gprs
    rates:
      unit_price: 0.000476800   # السعر لكل وحدة بالدولار
      unit_bytes: 1024          # عدد البايتات لكل وحدة
    batch_info:
      sender: AUSIE             # رمز TADIG الخاص بك
      recipient: AAA00          # رمز TADIG للشريك
      specificationVersionNumber: 3
      releaseVersionNumber: 12
      accountingInfo:
        localCurrency: 'USD'
        tapCurrency: 'USD'
        roundingAction: 'Simple'  # أعلى/أسفل/بسيط
        tapDecimalPlaces: 5
    round_up_to: 1024           # تقريب الاستخدام إلى أقرب N بايت
    call_type_level:            # ربط QCI بمستوى نوع المكالمة
      qci_1: 20
      qci_2: 22
      default: 20

تكوين عداد التسلسل​

تهيئة عدادات التسلسل في counters.yaml:

AAA00:
  CD: 1     # تسلسل بيانات تجارية
  TD: 1     # تسلسل بيانات اختبار
AAA01:
  CD: 1
  TD: 1

تزداد التسلسلات تلقائيًا مع كل ملف TAP يتم إنشاؤه.

تكوين الشبكة​

تكوين روابط TAC إلى المواقع:

config:
  tac_config:
    LocationName:
      tac_list: ['1101', '10000']
      servingBid: 72473
      servingLocationDescription: 'موقع الشبكة'
      timezone: 'America/New_York'

تكوين InfluxDB​

تكوين اتصال InfluxDB في config.yaml:

config:
  influx_db:
    influxDbUrl: 'http://10.3.0.135:8086'
    influxDbOrg: 'omnitouch'
    influxDbBucket: 'Omnicharge_TAP3'
    influxDbToken: 'your-token-here'

مسارات الإخراج​

تكوين مواقع إخراج الملفات:

config:
  tap_output_path: '/etc/pytap3/OutputFiles'
  tap_human_readable_output_path: '/etc/pytap3/OutputFiles_Human'
  tap_in_path: '/home/user/TAP_In/'

قرارات المعمارية​

لماذا OmniCharge؟​

يوفر OmniCharge:

  • محرك تصنيف قوي مع خطط أسعار مرنة
  • قدرات تصنيف في الوقت الحقيقي
  • إزالة التكرار من CDR
  • مسارات تدقيق شاملة
  • تكامل قائم على API

لماذا InfluxDB؟​

المزايا:

  • محسّن للبيانات الزمنية لمقاييس CDR
  • معدل كتابة مرتفع
  • تخزين فعال مع ضغط
  • تقليل مدمج
  • تكامل أصلي مع Grafana

ملخص سير العمل​

OmniRoam - إدارة إيرادات التجوال الاحترافية من Omnitouch.

آخر تحديث في