OmniRoam

OmniRoam es la solución integral de gestión de ingresos mayoristas para operadores de roaming de Omnitouch. Maneja el ciclo de vida completo de los CDRs de datos de roaming (Registros de Detalles de Llamadas), desde la ingestión hasta la calificación, la generación de archivos TAP3 y la elaboración de informes.

Tabla de Contenidos

• Descripción General
• Guía de Operaciones
  • Ejecutando Exportación TAP3
  • Monitoreo e Informes
  • Solución de Problemas
  • Soporte y Mantenimiento
• Arquitectura del Sistema
  • Descripción General de Alto Nivel
  • Proceso de Importación de CDR
  • Motor de Calificación OmniCharge
  • Generación de Archivos TAP3
• Guía de Configuración
  • Configuración del Socio
  • Configuración del Contador de Secuencia
  • Configuración de la Red
  • Configuración de InfluxDB
• Decisiones de Arquitectura

Descripción General

OmniRoam procesa los CDRs de roaming de los operadores de redes móviles, los califica utilizando el motor de calificación OmniCharge, genera archivos TAP3 compatibles con GSMA para la facturación y proporciona capacidades integrales de monitoreo e informes.

Proceso de Importación y Calificación de CDR

Proceso de Exportación TAP3

Guía de Operaciones

Ejecutando Exportación TAP3

# Exportar para socio específico
python3 export_TAP3.py VZW_Live

# Modo interactivo (solicita socio)
python3 export_TAP3.py

El proceso de exportación:

1. Consulta los CDRs de los últimos 30 días (requisito de GSMA)
2. Filtra los CDRs marcados como ya procesados
3. Excluye los CDRs con tiempo de finalización menor a 1 hora (previene sesiones incompletas)
4. Agrupa los CDRs por socio de roaming
5. Genera un archivo TAP3 por socio
6. Marca los CDRs como procesados en la base de datos
7. Incrementa el contador de secuencia
8. Envía métricas a InfluxDB

Monitoreo e Informes

OmniRoam envía métricas en tiempo real a InfluxDB para monitoreo y análisis.

Métricas Recopiladas

Métricas CDR Crudas Enviadas durante el proceso de importación y calificación de CDR:

• operator: Identificador del socio de roaming
• input_file: Nombre del archivo CSV de origen
• apn: Nombre del Punto de Acceso (identificador del servicio de datos)
• cellId: Identificador de la torre celular
• imsi: Identidad del suscriptor
• tac: Código de Área de Seguimiento
• sGWAddress: Dirección IP del Gateway de Servicio
• pGWAddress: Dirección IP del Gateway PDN
• chargeableUnits: Total de bytes de uso
• chargedUnits: Costo calculado

Métricas de Exportación TAP Enviadas durante el proceso de generación de archivos TAP3:

• operator: Identificador del socio de roaming
• filename: Nombre del archivo TAP3 generado
• totalcharge: Carga total en el archivo TAP3
• totalconsumed: Total de bytes en el archivo TAP3
• cdr_count: Número de CDRs en el archivo TAP3

Consultas del Dashboard

Ejemplo de consultas InfluxDB para monitoreo:

Ingresos por Operador

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

Uso de Datos por TAC

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

Volumen de CDR por Hora

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

Ingresos por APN

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

Integración con Grafana

Crea dashboards de Grafana utilizando estas métricas para:

• Monitoreo de ingresos en tiempo real
• Análisis de patrones de tráfico
• Seguimiento del rendimiento del socio
• Utilización de recursos de la red
• Detección de anomalías
• Conciliación de facturación

Solución de Problemas

Problemas de Importación de CDR

Verifique los registros en /tmp/import_CDR_Logger_Marben_*.log

Problemas comunes:

• Formato de IMSI inválido
• Campos requeridos faltantes
• Errores de conversión de zona horaria
• IDs de carga duplicados

Problemas de Exportación TAP3

Verifique los registros en /tmp/tap3_export_*.log

Problemas comunes:

• No hay CDRs en los últimos 30 días
• Falta configuración de TAC
• Número de secuencia inválido
• Errores de conexión a la base de datos

Errores de Calificación OmniCharge

Revise los registros de OmniCharge para:

• Planes de tarifas faltantes
• Cuenta no encontrada
• Valores de uso inválidos
• Errores de conversión de divisas

Problemas de Conexión a InfluxDB

Verifique:

• URL de InfluxDB accesible
• Token de autenticación válido
• El bucket existe
• Conectividad de red

Soporte y Mantenimiento

Ubicaciones de Registros

• Importación de CDR: /tmp/import_CDR_Logger_Marben_*.log
• Exportación TAP: /tmp/tap3_export_*.log

Archivos de Configuración Clave

• config.yaml - Configuración principal (tarifas de socios, configuraciones de red, conexión a InfluxDB)
• counters.yaml - Contadores de secuencia de archivos TAP3

Tareas de Mantenimiento Regular

1. Monitorear contadores de secuencia - Asegurarse de que no excedan 99999
2. Archivar archivos TAP antiguos - Mover archivos más antiguos que el período de retención
3. Monitorear uso de disco de InfluxDB - Configurar políticas de retención
4. Revisar configuraciones de tarifas - Actualizar cuando cambien las tarifas de los socios
5. Respaldar archivos de configuración - config.yaml y counters.yaml
6. Monitorear el retraso de CDR - Asegurar un procesamiento oportuno

Arquitectura del Sistema

Arquitectura de Alto Nivel

Proceso de Importación de CDR

OmniRoam utiliza un proceso de importación en dos etapas con Caché como una capa de agregación temporal para ensamblar registros CDR parciales en CDRs completos y facturables.

Comprendiendo los CDRs Parciales

Los elementos de red móviles (S-GW/P-GW) no generan un solo CDR para una sesión de datos. En su lugar, producen múltiples registros CDR parciales a lo largo del ciclo de vida de la sesión:

• Registro de Inicio: Generado cuando comienza la sesión de datos
• Registros de Actualización: Generados periódicamente durante la sesión (por ejemplo, cada 15 minutos o cada 100 MB de uso de datos)
• Registro de Detención: Generado cuando finaliza la sesión

Cada registro parcial contiene datos de uso incrementales. Para una facturación precisa, OmniRoam debe:

1. Identificar qué registros parciales pertenecen a la misma sesión de datos
2. Agregar los datos de uso de todos los registros parciales
3. Calcular la duración total de la sesión
4. Ensamblar un CDR completo que represente toda la sesión

¿Por qué Caché para la Agregación de CDR?

Caché sirve como un área de almacenamiento temporal de alto rendimiento donde los CDRs parciales se acumulan hasta que la sesión se completa. Caché proporciona:

• Búsquedas rápidas de clave-valor - Encuentra instantáneamente los CDRs parciales existentes para una sesión
• Almacenamiento en memoria - Operaciones de lectura/escritura de alta velocidad para agregación en tiempo real
• Operaciones atómicas - Actualizaciones concurrentes seguras desde múltiples procesos de importación
• Persistencia - Los CDRs sobreviven a reinicios del sistema durante la ventana de agregación

Arquitectura de Importación en Dos Etapas

Etapa 1: Análisis CSV y Agregación de CDR Parciales

La primera etapa lee continuamente archivos CSV de los elementos de red S-GW y agrega CDRs parciales en Caché.

Cómo se Identifican y Coinciden los CDRs Parciales

OmniRoam debe determinar qué registros parciales pertenecen a la misma sesión de datos. Cada sesión se identifica de manera única mediante un ID de Sesión compuesto por:

• ID de Carga: Identificador único de sesión del elemento de red
• IMSI: Identidad del suscriptor (identificador del número móvil)
• Fecha: Fecha de la sesión en la zona horaria de la red de servicio
• Dirección IP de P-GW: Gateway que manejó la sesión
• TAC: Código de Área de Seguimiento (ubicación de la torre celular)
• QCI: Clase de Calidad de Servicio

Esta combinación asegura que todos los registros parciales de la misma sesión de datos se agrupen, incluso cuando múltiples archivos llegan fuera de orden.

Cómo se Agregan los CDRs Parciales

Cuando el analizador CSV procesa cada CDR parcial:

1. Generar ID de Sesión a partir de los campos del CDR
2. Verificar Caché para ver si esta sesión ya existe
3. Si la sesión existe en Caché:
   • Recuperar los datos acumulados del CDR
   • Verificar que este archivo no haya sido procesado antes (previene duplicados)
   • Agregar los nuevos datos de uso: bytes entrantes + bytes salientes
   • Actualizar la duración de la sesión utilizando las marcas de tiempo más tempranas y más recientes
   • Almacenar metadatos sobre este registro parcial para fines de auditoría
   • Guardar el CDR actualizado de nuevo en Caché
4. Si es una nueva sesión:
   • Crear una nueva entrada de CDR en Caché
   • Inicializar contadores de uso y metadatos de sesión
   • Registrar la marca de tiempo del primer registro parcial

Registro de Auditoría y Metadatos

Cada registro parcial que contribuye a un CDR se rastrea con metadatos completos:

• Nombre del archivo fuente: Qué archivo CSV contenía este registro parcial
• Marca de tiempo: Cuándo generó este registro el elemento de red
• Tiempo de procesamiento: Cuándo lo recibió y procesó OmniRoam
• Contribución de uso: Cuánto dato agregó este parcial (bytes entrantes/salientes)
• Tipo de evento: Si fue un registro de inicio, actualización o detención
• Zona horaria de la red de servicio: Para una conversión precisa de la marca de tiempo

Por qué los metadatos son críticos para la contabilidad:

Este registro de auditoría permite a OmniRoam rastrear un solo cargo de extremo a extremo a través de cada etapa de procesamiento, lo cual es esencial para:

• Resolución de disputas: Cuando los socios impugnan un cargo, los operadores pueden mostrar exactamente qué archivos fuente contribuyeron a él
• Conciliación de ingresos: Verificar que todo el uso facturable fue capturado y que no se perdió ni se duplicó nada
• Cumplimiento regulatorio: Demostrar el manejo adecuado de los registros de facturación para fines de auditoría
• Depuración: Identificar rápidamente problemas en el proceso de agregación de CDR rastreando el flujo de datos completo
• Precisión financiera: Asegurar que cada dólar cobrado pueda ser rastreado hasta eventos de red específicos

Cálculo de la Duración de la Sesión

La duración total de la sesión se calcula encontrando:

• Marca de tiempo más temprana entre todos los registros parciales (inicio de la sesión)
• Marca de tiempo más reciente entre todos los registros parciales (fin de la sesión)
• Duración = Más reciente - Más temprana

Para sesiones donde solo existen registros de actualización (falta de inicio/detención), la duración se establece por defecto en 24 horas.

Etapa 2: Ensamblaje y Calificación de CDR

La segunda etapa escanea periódicamente Caché en busca de sesiones completadas, ensambla los CDRs finales y los envía a OmniCharge para calificación.

Cómo se Seleccionan los CDRs Completos de Caché

El Proceso de Ensamblaje de CDR se ejecuta continuamente y examina todas las sesiones almacenadas en Caché:

1. Escanear Caché en busca de todas las sesiones de CDR acumuladas
2. Procesar en lotes de 1,000 sesiones a la vez
3. Para cada sesión:
   • Extraer la fecha de la sesión del ID de Sesión
   • Saltar si es demasiado antigua (> 30 días): Eliminar de Caché (previene acumulación de datos obsoletos)
   • Saltar si es demasiado reciente (< 24 horas): Dejar en Caché para que lleguen más registros parciales
   • Cargar el CDR completo con todos los datos acumulados

El Período de Espera de 24 Horas

¿Por qué OmniRoam espera 24 horas antes de calificar un CDR?

• Los registros parciales llegan fuera de orden: La congestión de la red puede retrasar la entrega de archivos CSV por horas
• Las sesiones abarcan la medianoche: Una sesión que comienza a las 11:50 PM genera archivos en dos fechas diferentes. El mismo ID de carga puede abarcar varios días, con registros parciales fechados de manera diferente
• Los registros de actualización están retrasados: Los registros de actualización periódicos pueden llegar mucho después de que finaliza la sesión
• Generación de archivos asíncrona: Diferentes elementos de red exportan archivos en diferentes horarios
• Sesiones de larga duración: Las sesiones de datos pueden durar horas o días, con registros de actualización llegando a lo largo de

El tiempo

Al esperar 24 horas, OmniRoam asegura que todos los registros parciales hayan llegado y que el CDR esté verdaderamente completo antes de la facturación.

Validación y Enriquecimiento de CDR

Antes de la calificación, cada CDR ensamblado pasa por validación y enriquecimiento:

1. Validar completitud:

   • Verificar si están presentes los registros de inicio/detención
   • Si solo existen registros de actualización, establecer la duración en 24 horas (por defecto)

2. Descartar CDRs inválidos:

   • Se eliminan las sesiones con uso cero (sin actividad facturable)

3. Calcular uso final:

   • Sumar todos los bytes entrantes y salientes
   • Aplicar reglas de redondeo específicas del socio (por ejemplo, redondear al KB más cercano)

4. Enriquecer con datos de ubicación:

   • Mapear TAC (Código de Área de Seguimiento) a la ubicación de la red de servicio
   • Agregar información de zona horaria para marcas de tiempo precisas
   • Agregar descripción de ubicación geográfica

5. Enviar a OmniCharge:

   • Enviar el CDR completo y enriquecido para calificación
   • Recibir de vuelta la carga calculada

6. Almacenar y limpiar:

   • Guardar el CDR calificado en la base de datos
   • Enviar métricas a InfluxDB para informes
   • Eliminar el CDR procesado de Caché

Estructura de Datos de CDR

Cada CDR agregado contiene:

• Información del Suscriptor: IMSI, MSISDN, IMEI
• Información de la Red: Gateway de Servicio (S-GW), Gateway PDN (P-GW), ID de Celda, TAC (Código de Área de Seguimiento)
• Detalles de la Sesión: Marcas de tiempo de Inicio/Fin, Duración, APN (Nombre del Punto de Acceso)
• Datos de Uso: Volumen de Datos Entrantes/Saliendo, Unidades Totalmente Cargables
• Información de Ubicación: BID de Servicio (ID de Red), Ubicación Geográfica
• Información de QoS: QCI (Identificador de Clase de QoS)

Reglas de Procesamiento de Datos

Redondeo de Uso

Los CDRs se redondean según la configuración específica del socio en config.yaml:

partners:
  Example_Live:
    round_up_to: 1024  # Redondear uso al KB más cercano

El sistema:

1. Calcula el uso total: dataVolumeIncoming + dataVolumeOutgoing
2. Redondea al valor configurado (por ejemplo, 1024 bytes)
3. Preserva los valores originales para auditoría

Localización Basada en TAC

El sistema determina la ubicación de la red de servicio en función del TAC (Código de Área de Seguimiento):

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

Esto permite:

• Conversión adecuada de zona horaria para marcas de tiempo
• Asignación de ubicación geográfica
• Identificación de la red de servicio

Motor de Calificación OmniCharge

OmniRoam envía CDRs a OmniCharge, el potente motor de calificación que calcula los cargos en función de planes de tarifas configurables.

Proceso de Calificación

Configuración de Tarifas

Las tarifas se configuran por socio de roaming en el archivo de configuración:

partners:
  Example_Live:
    imsi_prefixes:
      - 99901
    rates:
      unit_price: 0.000476800  # Precio por unidad
      unit_bytes: 1024          # Tamaño de unidad en bytes
    batch_info:
      sender: AUSIE
      recipient: AAA00
      accountingInfo:
        localCurrency: 'USD'
        tapCurrency: 'USD'
        roundingAction: 'Simple'
        tapDecimalPlaces: 5

Coincidencia de Prefijos IMSI

OmniRoam coincide los CDRs con socios de roaming utilizando coincidencia de prefijos IMSI con lógica de coincidencia más larga primero. Esto permite a los operadores crear configuraciones específicas para SIMs de prueba mientras mantienen configuraciones generales para el tráfico de producción.

Cómo Funciona la Coincidencia de Prefijos

Al calificar un CDR, OmniRoam:

1. Extrae el IMSI del CDR (por ejemplo, 310410123456789)
2. Evalúa todas las configuraciones de socios en orden
3. Encuentra el prefijo coincidente más largo
4. Aplica las tarifas y configuraciones de ese socio

Ejemplo: Configuración de SIM de Prueba

Esta característica es particularmente útil para pruebas TADIG/IREG donde las SIMs de prueba necesitan un manejo diferente:

partners:
  Demo_Test:
    imsi_prefixes:
      - 0010112345123  # Rango de SIM de prueba (prefijo de 9 dígitos)
    rates:
      unit_price: 0.0  # Sin cargo por tráfico de prueba
    batch_info:
      sender: AUSIE
      recipient: AAA00TEST

  Demo_Production:
    imsi_prefixes:
      - 001011  # Rango de producción (prefijo de 6 dígitos)
    rates:
      unit_price: 0.000476800
    batch_info:
      sender: AUSIE
      recipient: AAA00

Comportamiento de coincidencia:

• IMSI 00101123451234 → Coincide con Demo_Test (el prefijo de 9 dígitos es más largo)
• IMSI 00101023456789 → Coincide con Demo_Production (el prefijo de 6 dígitos)

Esto asegura que el tráfico de prueba vaya a archivos TAP de prueba con códigos TADIG de prueba, mientras que el tráfico de producción se factura normalmente con códigos TADIG de producción.

Cálculo de Calificación

Para cada CDR:

1. Coincidir Socio: Identificar al socio de roaming por prefijo IMSI
2. Calcular Unidades: totalBytes / unit_bytes
3. Aplicar Tarifa: units × unit_price = charge
4. Aplicar Redondeo: Redondear según roundingAction (Arriba/Abajo/Simple)
5. Convertir a Unidades TAP: Multiplicar por 1000 para formato TAP3

Ejemplo:

Uso: 52,428,800 bytes (50 MB)
Tamaño de Unidad: 1024 bytes
Unidades: 51,200
Tarifa: $0.000476800 por 1KB
Carga: 51,200 × $0.000476800 = $24.41
Unidades TAP: 24,410 (24.41 × 1000)

Asignación de Tipo de Llamada Basada en QCI

Las Clases de Calidad de Servicio (QCI) se mapean a Niveles de Tipo de Llamada TAP3:

call_type_level:
  qci_1: 20  # Conversacional (Voz)
  qci_2: 22  # Conversacional (Video)
  qci_3: 23  # Juegos en Tiempo Real
  qci_4: 24  # Streaming en Buffer
  qci_5: 20  # Señalización IMS
  qci_6: 26  # Interactivo (Navegación)
  qci_7: 27  # Interactivo (Juegos)
  qci_8: 28  # Fondo
  qci_9: 29  # Fondo (Baja Prioridad)
  default: 20

Generación de Archivos TAP3

Después de que los CDRs son calificados por OmniCharge, OmniRoam genera archivos TAP3 estándar de GSMA para facturación mayorista.

Flujo de Exportación TAP3

Estructura del Archivo TAP3

Convención de Nombres de Archivos

Los archivos TAP3 siguen los estándares de nomenclatura de GSMA:

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

Ejemplos:
CDAUSIEAAA0000001  - Archivo de Datos Comercial de AUSIE a AAA00, secuencia 1
TDAUSIEAAA0000001  - Archivo de Datos de Prueba de AUSIE a AAA00, secuencia 1

Donde:

• FileType: CD (Comercial) o TD (Prueba)
• Sender: código TADIG de 5 caracteres
• Recipient: código TADIG de 5 caracteres
• SequenceNumber: secuencia de 5 dígitos (de counters.yaml)

Guía de Configuración

Configuración del Socio

Agregue socios de roaming en config.yaml:

partners:
  ONS_Live:
    imsi_prefixes:              # Lista de prefijos IMSI para este socio
      - 505057
    accessPointNameOI: mnc057.mcc505.gprs
    rates:
      unit_price: 0.000476800   # Precio por unidad en dólares
      unit_bytes: 1024          # Número de bytes por unidad
    batch_info:
      sender: AUSIE             # Su código TADIG
      recipient: AAA00          # Código TADIG del socio
      specificationVersionNumber: 3
      releaseVersionNumber: 12
      accountingInfo:
        localCurrency: 'USD'
        tapCurrency: 'USD'
        roundingAction: 'Simple'  # Arriba/Abajo/Simple
        tapDecimalPlaces: 5
    round_up_to: 1024           # Redondear uso al más cercano N bytes
    call_type_level:            # Mapeo de QCI a Nivel de Tipo de Llamada
      qci_1: 20
      qci_2: 22
      default: 20

Configuración del Contador de Secuencia

Inicialice los contadores de secuencia en counters.yaml:

AAA00:
  CD: 1     # Secuencia de Datos Comerciales
  TD: 1     # Secuencia de Datos de Prueba
AAA01:
  CD: 1
  TD: 1

Las secuencias se incrementan automáticamente con cada archivo TAP generado.

Configuración de la Red

Configure los mapeos TAC-a-ubicación:

config:
  tac_config:
    LocationName:
      tac_list: ['1101', '10000']
      servingBid: 72473
      servingLocationDescription: 'Ubicación de la Red'
      timezone: 'America/New_York'

Configuración de InfluxDB

Configure la conexión a InfluxDB en config.yaml:

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

Rutas de Salida

Configure las ubicaciones de salida de archivos:

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

Decisiones de Arquitectura

¿Por qué OmniCharge?

OmniCharge proporciona:

• Potente motor de calificación con planes de tarifas flexibles
• Capacidades de calificación en tiempo real
• Deducción de CDR
• Registros de auditoría integrales
• Integración basada en API

¿Por qué InfluxDB?

Ventajas:

• Optimizado para series temporales de métricas CDR
• Alto rendimiento de escritura
• Almacenamiento eficiente con compresión
• Muestreo incorporado
• Integración nativa con Grafana

Resumen del Flujo de Trabajo

---

OmniRoam - Gestión profesional de ingresos por roaming de Omnitouch.