OmniRoam

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

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

• نظرة عامة
• دليل العمليات
  • تشغيل تصدير TAP3
  • المراقبة والتقارير
  • استكشاف الأخطاء وإصلاحها
  • الدعم والصيانة
• معمارية النظام
  • نظرة عامة على المستوى العالي
  • عملية استيراد CDR
  • محرك تصنيف OmniCharge
  • توليد ملف TAP3
• دليل التكوين
  • مرجع تكوين YAML
  • تكوين الشريك
  • تكوين عداد التسلسل
  • تكوين الشبكة
  • تكوين InfluxDB
• قرارات المعمارية

نظرة عامة

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

عملية استيراد 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 باستخدام هذه المقاييس لـ:

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

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

مشاكل استيراد 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 عملية استيراد من مرحلتين مع ذاكرة التخزين المؤقت كطبقة تجميع مؤقتة لتجميع سجلات CDR الجزئية إلى CDRs كاملة قابلة للفوترة.

فهم CDRs الجزئية

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

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

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

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

لماذا تستخدم الذاكرة للتجميع CDR؟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. مسح الذاكرة لجميع جلسات CDR المتراكمة
2. المعالجة في دفعات من 1,000 جلسة في كل مرة
3. لكل جلسة:
   • استخراج تاريخ الجلسة من معرف الجلسة
   • تخطي إذا كانت قديمة جدًا (> 30 يومًا): حذف من الذاكرة (يمنع تراكم البيانات القديمة)
   • تخطي إذا كانت حديثة جدًا (< 24 ساعة): تركها في الذاكرة لوصول المزيد من السجلات الجزئية
   • تحميل 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 المعالجة من الذاكرة

هيكل بيانات 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

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

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

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

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

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.