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

أومني روم

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

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

نظرة عامة​

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

معمارية OmniTAP 1

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

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

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

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

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

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

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

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

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

يدفع أومني روم المقاييس في الوقت الحقيقي إلى 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: عدد سجلات CDR في ملف 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 3

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

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

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

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

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

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

ال��شكلات الشائعة:

  • لا توجد سجلات CDR في آخر 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​

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

فهم سجلات CDR الجزئية​

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

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

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

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

لماذا التخزين المؤقت لتجميع CDR؟​

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

كيفية اختيار CDR المكتملة من التخزين المؤقت​

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

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

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

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

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

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

التحقق من CDR والإثراء​

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

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

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

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

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

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

    • جمع جميع بايتات الوارد والصادر
    • تطبيق قواعد التقريب المحددة من الشريك (على سبيل المثال، التقريب لأعلى لأقرب 1 كيلوبايت)

  4. الإثراء ببيانات الموقع:

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

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

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

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

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

هيكل بيانات 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  # تقريب الاستخدام ل��قرب 1 كيلوبايت

يعمل النظام على:

  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​

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

معمارية OmniTAP 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​

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

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

عند تصنيف CDR، تق��م أومني روم:

  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​

بعد تصنيف سجلات CDR بواسطة OmniCharge، يقوم أومني روم بتوليد ملفات 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

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

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