RECMT: Sistema de Mediación para el procesamiento de Call

Detail Record (CDR)

Gustavo Iguiní Sergio Machuca Mario Pereyra

ANTEL ANTEL ANTEL.
Montevideo, Uruguay Montevideo, Uruguay Montevideo, Uruguay
Email guigini@antel.com.uy Email smachuca@antel.com.uy email beto@antel.com.uy
Marcel Oxandabaratz Paolo Galeotti Guillermo Freire
ANTEL. ANTEL. ANTEL.
Montevideo, Uruguay Montevideo, Uruguay Montevideo, Uruguay
email email pgaleotti@antel.com.uy email gfreire@antel.com.uy
moxandabaratz@antel.com.uy

Andrómaca Tasistro
ANTEL.
Montevideo, Uruguay
email atasistr@antel.com.uy

Resumen
Se describe la implementación del sistema de mediación
RECMT (Recepción, Envío y Control de Meters y Tolls)
para el procesamiento de CDR.
El proyecto implementa la recepción automática de CDR
(larga distancia, celulares, servicios especiales, de RI,
Valor Agregado, Telex e Internet) generados por centrales
telefónicas de diversos proveedores, y transportarlos a los
sistemas de Facturación y control de fraudes.
Palabras clave
CDR, Mediation System, MTP, FTAM, NRT Billing
1. INTRODUCIÓN
La Administración Nacional de Telecomunicaciones
(ANTEL) es la principal empresa de Telecomunicaciones
de Uruguay contando con oficinas y centrales telefónicas en
todo el país, sus sistemas de gestión residen en un
Mainframe localizado en Montevideo y sus negocios son
telefonía fija, larga distancia, telefonía celular y datos.
El sistema de Facturación tiene la característica que se
observa en los sistemas de empresas de telecomunicaciones
(gran cantidad de usuarios y gran volumen de información)
y la complejidad de tener que unificar la información a
partir de distintas fuentes de datos y distintas formas de
comunicación con éstas.
Hace varios años se desarrolló e implementó un sistema de
control y unificación de los tickets. Luego se empezó a
considerar nuevas alternativas para un Sistema de
Mediación cuando comenzaron a surgir nuevos
requerimientos tales como:
• Eliminación del tráfico de cintas de carrete abierto,
debido a que éstas eran caras, lentas, de poca
capacidad, transporte lento y actualmente difíciles de
conseguir en plaza. La información de llamadas era
generada en este tipo de cintas en las centrales y
transportadas al centro de cómputos para su
procesamiento por el sistema de Gestión de
Facturación.
• Reducir la tasa de errores (debido al procesamiento de
cintas).
• Evitar la manipulación y posible alteración de los
datos.
• Reducir el tiempo de recolección de la información.
• Acortar el período medio de pago.
• Obtener los datos para tarifar NRT (Near Real Time).
En particular, para la facturación del alquiler de
servicios celulares y provisorios es necesario contar
con la información en forma cuasi inmediata.
• Control de fraude de celulares. Necesidad de detectar
patrones de fraude en un corto lapso de tiempo para
tomar acciones correctivas.
Para satisfacer estos requerimientos se definió y utilizó una
infraestructura de hardware y software, la cual es utilizada
para el transporte de los datos generados. El proyecto se
inicia con el tráfico de celulares involucrando centrales
Ericsson y Nortel. Posteriormente se involucran centrales
Ericsson que concentran el tráfico interurbano en la capital,
el tráfico internacional y los servicios de Red Inteligente
(0800) y de Valor Agregado (0900). Recientemente se
incorporan las centrales Siemens, que cubren el interior del
país, tickets de acceso a Internet, de centrales de Telex, de
servicios especiales y CDPD (Cellular Digital Packet Data).
2. ARQUITECTURA LÓGICA DEL RECMT.
Los sistemas de mediación en general [4,5,6,9], proveen un
flujo de información de datos de registración de uso entre
los equipos de redes telefónicas y datos, y múltiples
aplicaciones operacionales. Estas aplicaciones comprenden
sistemas de tarifación, sistemas de administración de
fraudes, etc. La mediación usualmente implica recolectar y
dar formato a los registros de utilización.

Este sistema sistema fue denominado RECMT (Recepción,
Envío y Control de Meters y Tolls), logrando que toda la
registración de Antel sea manejada por el sistema de
mediación.
En la sección 2 se presenta la Arquitectura de la solución
implementada. En la 3 se comentan las características
particulares y estado actual del proyecto. Finalmente en la 4
se realiza una evaluación y se comentan las perspectivas de
futuro.
Más allá de asegurar la transferencia de datos entre los
elementos de redes y los sistemas operacionales, el sistema
de mediación actúa como un buffer valorizado,
desacoplando la infraestructura de swicheo desde el sistema
de soporte operacional y permitiendo a cada uno ser
configurado independientemente de los demás. Más aún,
realizar el preprocesamiento de los datos de utilización da
como resultado reducciones en los costos, reduciendo la
cantidad de procesamiento necesario por el sistema de
facturación, el cual esta usualmente ubicado en un
Mainframe.

Sistema de
Monitoreo

Centrales
Sistema de
telefónicas y
Acciones
Alarmas

Ar Facturación
Nodos n
ch
concentradores iv ació s)
(o os s o
rig ta ta sad
in sa s e
al ció ivo oc
) n rch -pr
A pre
(

Sistema de
Mediación
RECMT
A r re -
n
al ió

ch pr
(p
in ac

iv o o c
rig as
)

s t esa
(o os t

Archivos tasación

as do
iv

ac s)
ch

(original)

ió n
Ar

Sistema control Sistema de

de Fraude busqueda
de llamadas

Sistema de
Respaldo

Figura 1: Arquitectura lógica del sistema


Los sistemas de mediación normalmente implementan las
siguientes funciones genéricas:
1. Recepción de datos de CDRs desde las centrales.
2. Control en la recepción de archivos, secuencia de
generación, recepción de archivos duplicados, etc..
3. Planificación del procesamiento de archivos.
4. Conversión de los archivos con CDRs originales, en
archivos en el formato requerido por el sistema de
facturación. Esto implica validación y filtrado de ticket
de acuerdo a los escenarios de registración definidos
para facturar.
5. Creación de copias de respaldo de los archivos con
CDRs recibidos.
6. Envío de los archivos con CDRs a sistemas de
facturación, de análisis de fraude, de control de tráfico,
búsquedas, control de consumo telefónicos (CCT), etc.
7. Mantener logs auditables del conjunto de
transformaciones y procesos.
En el caso de ANTEL, la cuarta función (incluída dentro
del Sistema de Mediación en la figura 1) ya estaba
implementada. Se recibían las cintas de carrete abierto de
las distintas centrales, se validaba su contenido y se
unificaba su formato.
Con el objetivo de seguir utilizando lo que ya estaba
implementado, se definió la arquitectura lógica que se
muestra en la Figura 1.
El transporte de datos del proyecto se implementó en torno

Centrales Siemens

Centrales Nortel

Ericsson (AP, Xmate, CDPD)

Aguada Maldonado
FTP
FTAM / X.25
MTP / X.25

FTP
FTP
Servidor de Mediación

Control fraude
Mainframe
Figura 2: Arquitectura del transporte de datos
a un sistema UNIX conectado a las fuentes de datos
(centrales digitales y nodos concentradores), al sistema de
facturación, al sistema de control de fraude de celulares y al
sistema de búsquedas (ver Figura 1 y en forma más
detallada, Figura 2).
La conexión con las centrales telefónicas y nodos, desde el
Sistema de Mediación se realiza por medio de módulos que
resuelven las particularidades de comunicación con cada
tipo de central o nodo. Los módulos implementados
actualmente son los siguientes: MTP Ericsson, MTP Nortel;
FTAM (Siemens), FTP; de los cuales los dos primeros se
implementaron completamente.
Dependiendo del tipo de fuente de datos varía la forma en
que se reciben los archivos. En algunos casos (MTP y FTP)
la comunicación es iniciada por la central y en otros
(FTAM Siemmens) la misma se inicia desde el Sistema de
Mediación.
se sustituyó por herramientas estándares del entorno
TCP/IP (FTP, SCP, REXEC, etc.).
Se definió un log del sistema, en el que todos los procesos
indican los pasos realizados, este log se complementa con
logs particulares de cada uno de los procesos.
Resumiendo, [9] el sistema de mediación es un proceso en
donde los datos de utilización crudos son transformados a
datos formateados para facturación. Esta transformación
precisa una plataforma distinta que conecta los dos
componentes de un sistema de telecomunicaciones la red
switcheada y los sistemas de información del negocio,
mientras se asegura que estas funcionen independientes
unas de otras.
El sistema de mediación recolecta una gran cantidad de
datos de utilización en un tiempo determinado, en forma
segura y confiable desde varias tecnologías distintas.

Las centrales almacenan los tickets en archivos que luego

deben ser transferidos al Sistema de Mediación. En la
mayoría de los casos es posible definir la frecuencia de
transferencia definiendo una cota para el tamaño de los
archivos o una cota de tiempo, eventualmente se necesita
una transferencia manual.

El sistema cuenta con un módulo de control que se encarga

de procesar los archivos provenientes de las centrales,
chequear desfasajes en la recepción de archivos, controlar y
autorizar la recepción de reenvíos, generar alarmas.

Una vez recibidos los archivos de tasación originales se

planifica su procesamiento por los módulos de validación y
formateo de CDR´s, que ya estaban implementados, con el
objetivo de enviarlos al sistema de facturación de la
empresa.

Se definieron procedimiento de respaldo de los registros

originales, (aparte de los backups del sistema). Diariamente
se generan y envían a guardar en bóbeda cintas con los
datos originales recibidos de cada tecnología. Estas cintas
son guardadas durante 14 meses.

Los archivos son recibidos en el Sistema de Mediación

RECMT para luego derivarlos a los sistemas de
facturación, control de fraude, búsquedas y control de
consumo telefónico.

Al sistema de control de fraudes de celulares se envían los

CDR en formato original.(ver Figura 1).

La conexión con el Mainframe en un primer momento se

implementó utilizando herramientas específicas de
transferencia y ejecución remota de JOBS. En la actualidad

3. IMPLEMENTACIÓN.
ANTEL posee centrales Ericsson celulares, Nortel
Celulares, Ericsson convencional y Siemens convencional,
las cuales generan los mencionados CDR cada una en su
formato particular, además explota servicios especiales
(despertador, etc.), de conexión a Internet y Telex, que
también generan tickets.
El diseño interno de cada central es propietario y los
formatos de la información relacionada con las llamadas
que ellos reúnen está formateada de acuerdo a la central en
lugar de un estándar de la industria. Las centrales están
originalmente diseñadas para autoridades de
telecomunicaciones de países y nunca se imaginó que
deberían ser intercambiables o formar parte de una red
heterogénea. Muchas tienen protocolos de comunicación
propietario y sistemas operativos comparativamente
primitivos [9].
Los registros de utilización producidos por diferentes
centrales tienen diferentes formatos. Algunos registros
(también denominados mensajes) tienen largo fijo, mientras
que otros tienen largo variable. Bellcore [10] introdujo un
grado de estandarización con su formato AMA. Los
registros AMA tienen una estructura compleja la cual
incluye una parte de longitud fija y otra parte agregada de
largo variable.
La información relacionada con la utilización sólo puede
ser recolectada una vez. Por lo tanto debe ser validada y
asegurada.
Los registros de las llamadas son mantenidos en un buffer
en la misma central y ensamblados en archivos conteniendo
un número grande de registros antes que el archivo se
transmita.
3.1 Protocolos de Comunicación
Para cada tecnología de comunicaciones se implementó un
módulo específico que soporta los protocolos necesarios
para la comunicación con las centrales. A continuación se
analizarán separadamente cada uno de éstos.
3.1.1 MTP Ericsson - Comunicación con centrales
Ericsson.
El protocolo de comunicaciones utilizado por Ericsson es
el Message Transfer Protocol (MTP) el cual especifica el
acceso y transferencia de datos entre la central y un
Operational Maintenance Centre (OMC) remoto, por lo
tanto el sistema implementado en el equipo UNIX se
comporta como el sistema de un OMC [1].
El protocolo MTP maneja las capas de transporte, sesión y
presentación de acuerdo al modelo OSI, y utiliza los
servicios provistos por la capa de red del CCITT X.25,
permitiendo que los procesos del usuario tengan una
comunicación transparente a través de la línea..
Con cada llamada la central genera un ticket, el cual es
almacenado en disco. El sistema de almacenamiento
consiste en un conjunto de archivos (subarchivos)
manejados en forma circular. Los subarchivos se cierran al
cumplirse cierto tiempo desde que éste se encuentra abierto
o al llegar su tamaño a determinada cota (parámetros
configurables en el sistema operativo de la central -
IOG11), quedando pronto para su transmisión en forma
automática.
El IOG11 envía los subarchivos secuencialmente. Si
durante el envío hay algún problema que interrumpa la
transferencia, el sistema IOG11 continúa tratando de enviar
el mismo subarchivo hasta terminar satisfactoriamente,
recién entonces se pasa al subarchivo siguiente.
Este protocolo fue implementado sobre una línea x.25 de
128 K, con los parámetros definidos en [8].
En la actualidad este módulo fue sustituido por los AP
(Adjunt Processor) . Ver Figura 2, marcado con la letra (C).
3.1.2 MTP NORTEL. - Comunicación con centrales
Nortel celular.
NORTEL utiliza como protocolo de comunicaciones una
modificación del MTP[2], el cual agrega algunas
funcionalidades de retoma a nivel de bloques en la
transferencia de archivos.
En la implementación, ver Figura 2, marcado con la letra
(B), se reutilizaron las capas inferiores del MTP y se debió
implementar una variante del protocolo de transferencia de
archivos.
La implementación de NORTEL se comporta en forma
diferente, en este caso se transfieren los tickets a medida
que son generados. Cuando se cierra el archivo los tickets
ya fueron transferidos.
Una de las variantes que presenta este protocolo respecto
del de Ericsson, es que la señal de inicio de la conexión
incluye información que indica qué parte del archivo se
transferirá a continuación. Esta información es la que
permite la retoma en la última parte del archivo cuya
recepción fue confirmada, en el caso de un corte en la
conexión.
3.1.3 FTP- Comunicación con centrales Ericsson
convencional.
Para capturar los archivos generados por las centrales
Ericsson destinadas a telefonía convencional se ha resuelto
utilizar un sistema de gestión para centrales AXE XMATE
[11] basado en programas y scripts UNIX. Este sistema es
propietario de Ericsson y se encarga de recibir y luego
transferir los archivos al Sistema RECMT. La transferencia
desde las centrales digitales AXE al XMATE es realizada
mediante el protocolo MTP[1] sobre X.25. Del XMATE al
RECMT la transferencia se realiza mediante scripts que
utilizan el protocolo FTP (File Transfer Protocol).
Para los archivos CDPD de Ericsson se usa una solución
similar. Ver Figura 2, marcado con la letra (C).
En ambos caso la frecuencia de las transferencias es diaria.
3.1.4- FTP- Tickets de Telex
Existe una central telex que registra tickets con los cuales se
genera en forma manual un archivo, éste es enviado
incluido en un correo electronico a un PC. En dicho PC
existen aplicaciones que formatean el archivo y lo envian al
sistema de mediacion por ftp .
En este caso la frecuencia es definida por un cronograma.
3.1.5- FTP- Tickets de Servicios especiales
Dentro de esta categoría de servicios se distingue, servicio
de despertador diario y mensual, Telefonograma, Abonado
ausente, Servicio Costero.
Existen cuatro puntos de recolección de estos ticket, los
cuales son tratados en forma similar a la explicada en 3.1.4
En este caso la frecuencia es definida por un cronograma.
3.1.6- FTP- Tickets de Internet
ANTEL, proveedor de servicios de Internet (ISP) dispone
de sistemas AAA (Authentication, Authorization,
Accounting) que almacenan los tickets de conexiones a
Internet por parte de los usuarios suscritos. Esta
información recibe un procesamiento a través del cual se
genera un ticket en un formato estándar que es aceptado por
el Sistema de Facturación. No fueron incluidos e la Figura
2, por claridad del dibujo.
Estos tickets son transferidos en forma automática al
Sistema de Mediación.
Existe también otra modalidad de acceso a Internet que se
factura en forma similar a los servicios de Red Inteligente.
3.1.7 -FTAM- Protocolo de Comunicación con
centrales Siemens.
Las centrales Siemmens convencional utilizan como
protocolo de transferencia de archivos el protocolo ISO-
OSI 8571 FTAM (File Transfer, Access and Management),
ver Figura 2, marcado con la letra (A).
Para la implantación se utilizó una implementación de
dominio público de FTAM[3], a la cual se le hicieron
modificaciones para soportar la plataforma AIX.
La frecuencia de transferencias inicial es diaria (excepto
para las centrales de más tráfico en temporada, que tienen
una frecuencia mayor) y para ello se implementaron scripts
en las centrales que generan los archivos. El Sistema de
Mediación realiza un pooling a determinadas horas para
revisar si los archivos fueron generados. Para esto fue
necesario definir una convención de nombres que siguen
una secuencia en cada día.
Para la comunicación con estas centrales, se aprovechó que
ya existían enlaces desde la rs02 con routers en Aguada y
Maldonado. Se hizo un túnel de x25 sobre IP con el fin de
aprovecharlos. Estos enlaces son de 2M y tienen sus
correspondientes backups.
3.2 Control.
El módulo de control tiene por objetivo asegurar el
funcionamiento del sistema. Para ello se procesan los
archivos provenientes de las centrales, se chequea que no se
produzca discontinuidad en la secuencia para cada origen
y/o pérdida de archivos, se generan alarmas y se entregan
los archivos para su procesamiento a los sistemas de
facturación y control de fraudes.
3.2.1 Ericsson Convencional, Celular y CDPD.
En el caso de Ericsson, el control consiste en verificar que
ninguno de los subarchivos generados en la central falte
(estos vienen numerados secuencialmente desde el 0000 a
9999).
Este control se complementa en el Mainframe verificando
que el tiempo entre una llamada y otra dentro de un mismo
archivo y entre la última y la primera de dos archivos
consecutivos no supere determinada cota.
3.2.2 Nortel Celular y CDPD
En el caso de Nortel en el sistema UNIX no es posible
controlar la falta de archivos, dado que los nombres de los
archivos de estas centrales, si bien incluyen la fecha y hora
de creación, no incluyen un número de secuencia que
permita controlar la falta de un archivo, por eso en estos
casos sólo se chequea que los archivos arriben en orden
cronológico.
En el Mainframe se realiza el mismo chequeo que en 3.2.1.
Se realizan chequeos de frecuencia, de forma que si durante
mucho tiempo no llega ningún paquete, significa que existe
algún problema con la central o con la conexión X.25 entre
la central y el sistema UNIX. En este caso, como en todos
los errores detectados se emite la alarma correspondiente.
3.2.3 Siemens Convencional
En este caso el control que se hace es similar al de los
archivos que provienen de Nortel, dado que tampoco se
dispone de número de secuencia.
Excepto para las centrales de más tráfico, que envían al
menos 3 archivos diarios, las demás envían al menos un
archivo diario.
Durante cada interrogación a las centrales se verifica que se
hayan transferido todos los archivos generados. También se
genera en las centrales en forma semanal un listado de
todos los archivos generados esa semana.
3.2.4. Servicios especiales y télex.
En estos casos los archivos se transfieren por FTP. Dado
que la frecuencia es diaria y que sólo existe un archivo por
central se controla que todos los días se transfieran la
cantidad de archivos esperados. Además como los nombres
incluyen un número de secuencia, en el sistema UNIX se
hace un control como el mencionado el 3.2.1.
3.3 Transferencia de los tickets al Sistema de
Facturación y al Sistema de Control de Fraude.
Generalmente la validación y post-procesamiento de los
CDR, está incluido en la plataforma que contiene el sistema
de mediación como forma de minimizar el espacio utilizado
en el Mainframe, ya que los costos de almacenamiento en
uno y otro lugar son bastante significativos.
En el caso de la solución implementada en Antel, la parte
de post-procesamiento y transformación en un único
formato, independientemente del formato de origen, para
facturación, ya estaba desarrollada, con lo que se utilizó
este módulo. En la fig.2 está marcado con la letra (E)
Ya se poseía el desarrollo de los programas y los controles,
agregando la seguridad proporcionada por RACF( IBM -
Resource Access Control Facility).
Básicamente se reciben en el Mainframe los CDR reunidos
por el sistema de recoleción (implementado en Unix),
manteniendo su formato original. En el Mainframe se
valida el formato de las distintas formas de
registración[7,12,13,14]., se analizan los casos de
registración, aprobando, filtrando y descartando registros y
por último se hacen transformaciones para obtener la
unificación de los formatos.
El sistema de Control de Fraude en celulares exige los
CDRs en su formato original. Se decidió hacer la
transferencia de los datos a este sistema utilizando el
protocolo FTP. En la figura 2, está indicado con la letra
(D).
3.4 Sistema de Monitoreo
Se implementó un sistema de monitoreo que es utilizado
por los operadores durante las 24 hs. todos los días del año
pudiendo ver en forma inmediata las alertas que se generan,
como así también tomar algunas acciones correctivas que
no necesiten la intervención de los administradores.
Además este sistema envía e-mails a los administradores
adecuados según corresponda, informando la alerta.
El sistema de monitoreo genera alarmas de dos tipos: del
sistema operativo y de la aplicación.
Las situaciones que generan alarmas del sistema operativo
se detectan por medio de un monitoreo periódico de los
elementos del mismo (espacio en disco, uso de cpu,
conectividad de los enlaces x25, conectividad con el
Mainframe).
Existe también un monitoreo asincrónico, cuando las
situaciones que generan alarmas de la aplicación son
detectadas por los procesos que determinan que hay alguna
condición de error.
Los errores son indicados a los operadores por medio de
ventanitas emergentes, que indican el nivel de criticidad, y
además se envía un e-mail los usuarios de mantenimiento.
Algunos posibles errores detectados son: que fallen los
protocolos de comunicación por ej.el ftp, que el mtp detecte
que no se ha recibido nada desde una central durante
demasiado tiempo (este tiempo de espera es configurable,
se pasa como parámetro a cada mtp), que una central
Siemens no tenga generado el archivo correspondiente,
También se detectan errores en el secuenciamiento de los
archivos, detección de reenvíos no solicitados.
Se desarrolló para los operadores un menú que permite .
chequear la conectividad de las diferentes líneas y los
4-EVALUACIÓN Y PERSPECTIVAS DE FUTURO
distintos protocolos de comunicación usados. Además les
permite ejecutar acciones como verificar si están generados
Se desarrolló un sistema a medida integrado con el sistema
los archivos en las centrales Siemens, posibilidad de
de facturación que ya estaba funcionando en la empresa,
traerlos en forma manual. Por medio de este menú se
disminuyendo significativamente los costos de
realizan las copias de respaldo de los archivos de CDR’s
implementación respecto de los sistemas de mediación
originales recibidos y la posibilidad de su recuperación.
disponibles en el mercado.

También se logró la eliminación del tráfico de información

en cintas reduciendo la tasa de errores. Todo esto permite
reducir el tiempo de recolección de los datos de llamadas y
acortar el período medio de cobro por estos servicios, con
los beneficios económicos que esto acarrea.

Este sistema, al obtener los datos de las llamadas en un

corto período luego de que éstas se realizan, permite
transferir información al sistema de control de fraude de
celulares en tiempo y forma como para tomar acciones
correctivas.

También posibilitó implementar un sistema de consultas de

consumo telefónico (CCT) en inmuebles arrendados, para
ser utilizado por inmobiliarias sobre todo en el período de
mayor afluencia turística.

Este sistema se ha puesto en producción en forma gradual

desde 1999 a medida que fueron surgiendo los
requerimientos y desarrollados los módulos
correspondientes.

En la actualidad el sistema esta en funcionamiento en un

entorno de producción, transfiriendo alrededor de 1GB de
información diariamente.

Con respecto a los planes de futuro se prevé:

• Un significativo incremento en el volumen de

información manejada diariamente porque se planea la
recolección de tickets de llamadas locales de telefonía
fija.
• Conexión directa a las centrales Ericsson de telefonía
convencional.
• Generalizar y profundizar el NRT Billing.
• Mejora del sistema de monitoreo permitiendo el
relacionamiento de los eventos de forma que a los
operadores solamente se les presenten aquellas alertas
con real significación. Dando la posibilidad de definir
relaciones entre los eventos, de forma que si un error es
originado por otro que ya fue reportado, este

Como parte del sistema de base en que se soporta el

Sistema de Mediación RECMT se tiene previsto contar con
un sistema de contingencia, respaldando la alta
disponibilidad actualmente implementada.
5- BIBLIOGRAFÍA

[1] Descripción de MTP- Documentación interna de

Ericsson. Nro. 2/155 17 ANZ 216 01 Uen, 29/9/93
[2] Descripción de MTP – Documentación interna de
Nortel.
[3] The ISO Development Environment: User’s Manual.
Marshall T. Rose, Julian P. Onions, Colin J. Robbins.
1991.
[4] ”Network polling solution” preparado por CGI,
20/10/98
[5] CBOSSmd Mediation Devices System
http://www.cbossbilling.com/products/cbossmd.html
[6] Telecomm Billing Mediation
http://www.packetware.com/telemedia.html
[7] Formatos de Datos de Salida de Ericsson : XF/SD 83
196 “Output format for toll ticketing data, AXE-OPS
(with MTS).
[8] X.25 DATA LINK, Ericsson: Doc. Nro. LMC(U/T94-
017 Ref LZB BT 103 02.
[9] “The Strategic Importance of Service Provisioning
and Mediation”, Chooreylwood Publications
[10] Bellcore Automatic Message
Accounting Format (BAF), Knapp, Sara
732-758-5247
[11] XMATE COMMAND INTERFACE, 1/198 17 –
CNAP 102 15 Uen, 12/05/1997.
[12] Siemens EWSD “File Description inter Administrative
Revenue Accounting and Statistics (IARSTAT) V9 –
P30305-X0404-L212-1-7617
[13] Formatos de datos de Ericsson Convencional:
“Common Charging Output Isocode Result” Nro.
1/190 83-CNT 215 1288.
[14] Formatos de datos de Nortel Celular: “DMS-MTX
Billing Management Manual MTX09 Stadard” 411-
2131-204. Febrero 2001