OURNAL. monografía iplantech. IINDICE 1- Topología de la red física. 2- Distribución, acceso y servicios. 3- Argumentos Económicos.

Transcripción

1 monografía iplantech Journal Monografías es una publicación de iplan que contiene información técnica y confidencial de la empresa. Se distribuye a un circuito limitado de lectores a fin de mantenerlos informados sobre el estado y la evolución de la tecnología y el negocio de la Telecomunicaciones, principalmente en las redes IP y la Telefonía-IP. Se ruega a los lectores a mantener el principio de Confidencialidad sobre la información aquí contenida. No está autorizada su reproducción o distribución por cualquier medio sin antes consultar con la empresa. IModelo exitoso para Pymes. El modelo de red de transporte IP-Gigabit con distribución mediante Nodos de Manzana y acometida mediante cobre, se ha demostrado exitoso para ofrecer servicios a SOHO y Pymes. IINDICE 1- Topología de la red física. 2- Distribución, acceso y servicios. 3- Argumentos Económicos. IABSTRACT Se presenta una descripción de la topología de ductos y cables, que permiten desarrollar una red urbana de fibras ópticas FO para el transporte y de cables de cobre para la última milla de acceso. Se analiza la topología de la electrónica necesaria para ofrecer servicios integrados mediante una red IP con transporte Gigabit-Ethernet (1000 Mbps). Los servicios posibles permiten atacar a un mercado normalmente descuidado por otros operadores: los clientes SOHO y las Pymes. El producto estrella es el denominado Pack-N, que consiste en N líneas analógicas de telefonía y un acceso a Internet dedicado de 1 Mbps. Finalmente, se analizan los argumentos económicos ligados al modelo de Nodos de Manzana NdM que permiten sostener una política de crecimiento constante en un momento donde las inversiones son particularmente escasas. 1

2 Monografías 1 (2003) Modelo Exitoso para Pymes 1- TOPOLOGÍA DE LA RED FISICA 1.1- Base de Datos y Red de Ductos. El primer paso en el diseño de la Topología de la Red Física de transporte es la creación de una Base de Datos de potenciales clientes. Esta actividad fue realizada en iplan en el segundo semestre de 1999 (año en que fue creada la empresa) y se utilizaron diversas fuentes: -Guía de la Industria, -Guía de la revista Mercado, -una base de datos de Bancos y -la Base de Datos del Indec. Esta última era la más extensa en cantidad y calidad de datos, pero su antigüedad (databa de 1994) la hacía menos confiable. La geocodificación (proceso por el cual se indica en un plano la posición de cada punto de la base de datos) se realizó mediante el software Agemap. Un año después, para realizar el Business Plan de ocho ciudades de Brasil, se usaría el software Mapinfo, que disponía de varias funcionalidades adicionales. La depuración de las distintas Bases de Datos llevó un par de meses, debido que los errores debían ser corregidos uno a uno. Con esta operación se pudo lograr una tasa de efectividad en la geocodificación superior al 90%. El 10% restante se trataba de errores sistemáticos o inconsistencias que no pudieron ser eliminados manualmente. Así quedó representada la Base de Datos de 4 ciudades. Una nube de puntos de empresas inundaba Buenos Aires y el GBA (conocido como el Área Múltiple Buenos Aires, AMBA). En la Figura 1 se muestra el mapa de Buenos Aires con cerca de empresas, de las cuales 3500 (el 16%) se encontraba en el microcentro. Cerca del 40% de las empresas de Buenos Aires se encuentran en la zona de cobertura de la Figura 10. Adicionalmente, el procesamiento de las Bases de Datos permitió realizar varias segmentaciones: -una segmentación se realizó en 4 actividades (servicios, comercio, bancos e industria), -otra se realizó en 4 niveles de cantidad de empleados (hasta 6, de 6 a 15, etc), -otra por ciudad (Buenos Aires, La Plata, Rosario, Córdoba, Mendoza), y -en algunos casos pudo trabajarse con la segmentación por facturación. Dos objetivos serían cumplidos a fines de 1999: -por un lado fundamentar cuantitativamente un Business Plan orientado a las Pymes (basado en empresas con más de 6 empleados), -y por otro, el diseño de la red de ductos que permitiera cubrir las zonas de mayor densidad de probables clientes. Figura 1. Base de Datos de empresas del Indec (Ciudad de Buenos Aires), geo-codificada para determinar la distribución geográfica. Fue utilizada para preparar el Business Plan (cantidad y distribución del Adressable Market) y el diseño de la red. 2

3 Monografías 1 (2003) Modelo Exitoso para Pymes Figura 2. La red de ductos fue diseñada para obtener un cuadriculado que permite el fácil acceso a clientes dentro de la zona de cobertura. El cuadriculado es mucho más denso en el microcentro de la ciudad. Con el diagrama de la Base de Datos geo-codificada se inició un proceso de inspección visual. Se recorrieron las calles para preparar un diagrama del recorrido de ductos. El ajuste final se realizó con el contratista de obra para verificar que lo diseñado no pasara por lugares vedados por la Municipalidad. El objetivo del diagrama de ductos contemplaba que cada manzana del microcentro de Buenos Aires fuera tocada en al menos una de las 4 caras por nuestra red y en lo posible en la mejor de ellas. Para el macrocentro en cambio, se adoptó un criterio de construir por las avenidas y principales calles de la ciudad. Un trabajo similar se realizó para las ciudades de La Plata, Rosario y Córdoba. Figura 3. Fotografías históricas del 6 de febrero de 2000 cuando se iniciaron las obras de construcción en Buenos Aires. La constructora inicial fue Miavasa, siendo completadas las obras por Sade-Skanska. 3

4 Monografías 1 (2003) Modelo Exitoso para Pymes La red fue construida en diferentes etapas. La empresa constructora fue inicialmente Miavasa y posteriormente Sade-Skanska (Figura 3). Miavasa inició las obras en Buenos Aires el 9 de febrero del Se decidió construir una red paralela que eventualmente podía ser comercializada como ductos. El sobreprecio calculado para construir dos redes simultáneamente era del orden del 15% (esta red se la conoce como NSS-II). Debido a la elevada ocupación del subsuelo de las ciudades, la red se construyó mediante capas de tritubos. Un tritubo resulta de 3 tubos de 40 mm de diámetro exterior que se encuentran unidos horizontalmente. La cantidad de capas de tritubos instalados ha sido desde 3 a 5. Lo que entrega un total de 9 a 15 ductos. No es posible instalar caños de PVC de 100 mm de diámetro (como era costumbre en la época de Entel) debido al escaso espacio en el subsuelo. Esto determina entonces una topología de red restrictiva: los cables serán de fibras ópticas FO y solo se utilizarán cables de cobre para distribución de corto alcance. Los cables de cobre más gruesos posibles, factibles de instalarse en estos ductos, son de 100 pares (mas no sin esfuerzos, debido al diámetro y al radio de curvatura) Topología de cables ópticos. La red de ductos es una malla reticulada que en las zonas más densas (microcentro) llega a tener paralelas por todas las calles y hacia el exterior se propaga por las avenidas (Rivadavia, Corrientes, Córdoba, Santa Fe, etc) y por las principales calles. Los clientes están en ambas veredas, razón por lo cual muchas veces se pueden ver sobre la misma calle ductos de ambos lados. La red de cables puede separarse en tres niveles (los dos primeros son cables de FO y el tercero es de cobre): -la red troncal (lleva cables ópticos que recorren distancias largas entre Hubs), -la red de distribución (para el acceso hasta los Nodos de Distribución en las Manzanas) y -la red de acceso (mediante cables de cobre que llegan hasta el usuario). En la ciudad de Buenos Aires se dispone del centro de operaciones NOC (Network Operation Center) y varios Hubs. Como veremos luego, estos puntos contienen switch IP que trabajan a velocidad de ports Gigabit (1000 Mbps). Hoy día, se tienen Hubs en los barrios de San Telmo, Once, Congreso y en la ciudad de La Plata. Desde estos Hubs (una sala de equipos de 15 mts cuadrados aproximadamente) dependen los Nodos de Manzana (un rack con equipos dedicados para abastecer a una o varias manzanas). En teoría, los Hubs están unidos entre sí en topología malla y los Nodos en topología de anillo. El acceso al cliente desde el Nodo tiene una topología en estrella (sin redundancia), normalmente mediante pares de cobre. Se seleccionaron Fibras Opticas Standard para los cables. Los años siguientes demostraron lo acertado de la decisión. Parecería ser que por una vez en la tecnología, uno de los primeros desarrollos, (en este caso la FO monomodo conocida como estándar y definida en la norma ITU-T G.652 que data del principio de los años 80) no ha podido ser reemplazada luego de 3 intentos de nuevos desarrollos en 20 años. Un caso excepcional en la tecnología. La segunda capa de la topología de cables es la que corresponde a la distribución. Así desde un Hub se tienen anillos de cables para la cobertura de pequeñas zonas de la ciudad. El anillado permite acceder a un Nodo de Manzana desde dos direcciones distintas y generar cierta protección de caminos redundantes. Normalmente, un mismo Hub tiene dependientes varios cables en anillo a su alrededor. Figura 4. Diagrama simplificado de la red de ductos Troncal de Buenos Aires (línea de delgada), la ubicación de Hubs (puntos amarillos) y cables Inter-Hubs (líneas gruesas). Los cables de 144FO que los unen tienen topología mala. 4

5 Monografías 1 (2003) Modelo Exitoso para Pymes Figura 5. Topología de cables de FO en anillo para la Distribución desde los Hubs hacia los Nodos de Manzana. Un Hub (en la figura se muestra el NOC de iplan en Reconquista 865 en amarillo) tiene varios cables para cubrir la zona de influencia. Figura 6. La Interconexión entre las redes urbanas de Buenos Aires y La Plata se realiza mediante un enlace Interurbano por la red de ferrocarril Metropolitano. Otro nivel de interconexión es el interurbano. En el caso de iplan se dispone de un enlace propio entre Buenos Aires y La Plata, que ocupa un ducto instalado por el ferrocarril Metropolitano. Este enlace de FO permite, además de la conexión entre extremos, ofrecer servicios en varias ciudades intermedias (Lomas de Zamora, Quilmes, etc). Los enlaces entre las ciudades de Buenos Aires, Rosario y Córdoba, se efectúa mediante enlaces redundantes y duplicados por distintos carriers (empresas orientadas al transporte de ancho de banda interurbano). 5

6 Monografías 1 (2003) Modelo Exitoso para Pymes 1.3- Management de Recursos Físicos. Para la gestión de los recursos físicos (ductos, cables, empalmes, Nodos, etc) se utiliza un sistema GIS (Geographic Information System). El proveedor del software ha sido LAT45. El GIS sirve para documentar y administrar todos los Recursos de nuestra Red en forma gráfica y alfanumérica. Esto significa que en planos y en su posición geográfica exacta, podemos documentar: -La red de ductos y las cámaras en la vía pública. -Los cables de FO y de cobre. -Las cajas de empalme para ambos tipos de cables. -Los Hubs y Nodos de Manzana. -Los Nodos Virtuales de acceso de cobre. -El equipamiento distribuido en cada Nodo. -Los clientes y sus servicios asociados. En la Figura 7 se muestran algunos nodos de manzana que son simbolizados por rombos azules, los nodos de edificio son simbolizados por rombos rojos, los edificios conectados y tendidos de cobre intra-manzana son simbolizados por líneas verdes. De fondo, la cartografía provista por la empresa Aeromapa tiene una precisión submétrica y fue realizada a partir de fotografías aéreas tomadas especialmente para esta cartografía. La misma se encuentra geoposicionada, esto significa que sus coordenadas coinciden con las que tomaría un GPS (Global Position System), ubicado en cualquier punto de la misma. Esta información gráfica, que se relaciona con bases de datos, permite administrar recursos tales como: -La disponibilidad en ductos libres en la red. -La disponibilidad en cables, ya sea de FO o de cobre. -La ubicación de los empalmes. -La disponibilidad de espacio en los Racks. -La cantidad de equipos y disponibilidad de puertos libres. -Los servicios asociados a un determinado cable. El GIS consta de 4 módulos. El módulo de Network Design and Service Planning y el de Service Modeling están relacionados con la carga de información; mientras que los módulos de Desition Support y Web Access, lo están para la consulta de la información cargada (uno en forma local y otro a través de la web). Las capacidades mencionadas anteriormente, son quizá las más importantes, pero las posibilidades de consulta aumentan a medida que se dispone de mayor cantidad de información en el sistema. Figuras 7. Se pueden observar parte de la red de ductos del microcentro de Buenos Aires mediante el GIS. 6

7 Monografías 1 (2003) Modelo Exitoso para Pymes Finalmente, se ha dejado de utilizar las planillas Excell, planos CAD, Power Point, etc. Se trata de suprimir información duplicada. La migración se ha realizado teniendo en cuenta que muchos usuarios utilizaban planillas llamadas Hojas de Corte con una información muy confiable y amigable. La migración a GIS ha tenido ciertas dificultades pero ha confiabilizado la información. Lo bueno de un sistema GIS es que la base de datos es única para las distintas informaciones y los distintos usuarios. Los inconvenientes para la implementación fueron: la costumbre de los usuarios a las amigables hojas de Excell y a que la información se presenta en forma conceptualmente diferente, lo que requiere cambios en los hábitos. 2- DISTRIBUCIÓN, ACCESO Y SERVICIOS 2.1- Red Gigabit y Nodos de Manzana. El diagrama a bloques genérico de la red de iplan incluye una red de distribución Gigabit-Ethernet. Esta red funciona mediante equipos Cisco-6509 distribuidos en los NOC (uno por ciudad) y en los Hubs. La interconexión se realiza mediante FO a 1000 Mbps (protocolo Gigabit). Una red también de FO permite llegar desde el Hub hasta el Nodo de Manzana para la distribución de los servicios. Figura 8. Diagrama general a bloques de la red de iplan. Se muestra la interconexión de telefonía mediante un switch class-5 y gateways IP-E1. La Telefonía-IP tiene varios componentes como Gatekeepers y Softswitch. Los switch de Core permiten la conexión de la Telefonía-IP con el Data Center IDC y la conexiones a Internet con los NAP. Abajo a la derecha se muestra la distribución y acceso hacia los clientes finales (ver figura siguiente para más detalle). También, se muestra una foto panorámica del NOC de iplan en Reconquista 865, Buenos Aires. 7

8 Monografías 1 (2003) Modelo Exitoso para Pymes Otra red de acceso, pero en este caso de cables de cobre, conforma la última milla hasta el cliente. La red de Iplan ha sido construida para cables de FO debido a la congestión del subsuelo en los centros de las ciudades. La red se ha realizado con tritubos que permiten el pasaje de un cable de FO o de cobre hasta 100 pares. El objetivo fue llegar a cada manzana con 6 FO (2 para Gigabit, 2 para SDH, y 2 de reserva) y distribuir dentro de la manzana mediante cables de cobre. Un primer modelo de distribución fue utilizado hasta julio Consistía en Nodos de Edificio NdE al cual se llegaba mediante FO. Este modelo estaba de moda en los países centrales donde se esperaba colocar un Nodo en los grandes edificios y lograr una gran penetración de clientes en el mismo. Por diversas razones, este modelo se demostró antieconómico para nuestro caso y se paso rápidamente al modelo de Nodos de Manzana NdM, en conjunto con una red de acceso de baja-densidad mediante pares de cobre. Figura 9. Modelo de distribución mediante Nodos de Manzana. Desde el Core de la red y mediante el Backbone de FO se llega a los Hubs. La red de Distribución de FO conecta los Nodos de Manzana con los Hubs. La red de Acceso de cobre conecta al Nodo NdM con los Clientes. 8

9 Monografías 1 (2003) Modelo Exitoso para Pymes Un NdE contiene equipos para los clientes dentro de un mismo edificio, mientras que el NdM contiene equipos para los clientes de toda la manzana (incluso manzanas cercanas pueden ser alcanzadas en zonas de menor densidad de clientes). Los NdE distribuyen servicios mediante cables UTP, mientras que desde el NdM se utilizan pares telefónicos comunes. iplan ha construido su propia red de cobre para esta función, dentro de las manzanas. Los NdM contienen: -Un rack en un espacio común de un edificio huésped y una UPS para mantener la alimentación de energía durante los cortes de suministro. La alimentación es de 220 V. -Regletas para conectores de FO (para los cables que provienen desde los Hubs) y de cobre (hacia los cables de cobre que se dirigen al cliente). -El equipo Cisco-3524/3550 para recibir Gigabit (1000 Mbps) desde la red y entregar 10 Mbps hacia el lado cliente. Otro equipo, el Cisco-2924/2950 permite extender los 10 Mbps mediante pares de cobre hasta más de 1000 mts. Se lo conoce como tecnología LRE (LongReach Ethernet). -Otro equipo es el Gateway de telefonía. Se tienen diversas versiones que han permitido sucesivamente reducir costos. La primer versión fue el equipo Cisco-1750/2600 (gateway E1) junto con Edgelink (multiplexor de 30 líneas analógicas). Una segunda versión fue el Cisco-VG248 para entregar 48 líneas de telefonía (Call Manager). Una tercera versión se está introduciendo en el segundo semestre Adicionalmente se pueden encontrar equipos SDH o conversores para FO en el caso de necesitar llegar a clientes por este medio. La distribución mediante cobre permite acceder varias manzanas desde el mismo NdM. Esto se logra mediante los denominados Nodos Virtuales que consisten en cajas de distribución de cobre en una manzana abastecida desde el NdM cercano. Hacia julio-2003, hay un promedio de 2,5 manzanas que son abastecidas desde cada NdM. Sin embargo, la distribución mediante cables de cobre agota el recurso escaso de ductos disponibles. Los cables de cobre son más gruesos y de menor capacidad de clientes que los de FO (no se pueden instalar cables de más de 100 pares por cada ducto entre manzanas). Por ello, los ductos son un recurso muy escaso y agotable a mediano plazo, en especial en las áreas centrales de la red. El resultado a mediano plazo será que las áreas densamente pobladas de clientes tendrán un NdM por manzana, mientras que hacia la periferia de la red un NdM abastecerá varias manzanas aledañas. El modelo de NdM permite una cobertura de clientes muy homogénea. De esta forma es posible determinar zonas de cobertura de servicios mediante mapas de manzanas (Figura 10). El modelo de NdE aplicados por otras empresas proveedoras de servicios de Telecomunicaciones tiene niveles de inversión prohibitivos para ofrecer servicios a empresas Pymes. Veremos esto con más detalle. Figura 10. Manzanas acometidas con distribución mediante cobre en el año La red tiene una expansión constante en la medida que la ganancia de clientes permite aumentar la cobertura. 9

10 Monografías 1 (2003) Modelo Exitoso para Pymes 2.2- Productos para las Pymes. La red de iplan ha sido diseñada para ofrecer servicios a Pymes desde muy baja cantidad de empleados. Los Productos han seguido la misma línea. En septiembre-2002 se festejó haber llegado a una cantidad de 50 productos (cada uno con una buena cantidad de variantes internas). A inicios del 2001 el producto más pequeño de iplan era el Pack-4 (en aquella época llamado Bundle-1 y ofrecido con CPE Cisco-1750/2611). Desde fines del 2001 se ofrece el Pack-2 y Pack-3, reduciendo la granularidad de líneas analógicas para llegar a más clientes. Desde fines del 2002 el producto estrella es el Pack-1 para el mercado SOHO (unipersonal) o domiciliario. Los productos se dividen entre el mercado minorista (Retail o Pymes) y mayorista (Wholesale para operadores y prestadores de servicios). En el mercado Retail, que representa el 75% de la facturación de iplan, encontramos productos relacionados con la telefonía, Internet, transmisión de datos, servicios de Data Center, etc. Varios productos de valor agregado han sido desarrollados para ser ofrecidos mediante redes de terceros. El desarrollo de productos está básicamente orientado a cubrir nuevos e innovadores servicios que serían de difícil concreción sobre una red que no sea IP. En el mercado Wholesale, se destaca el producto de Calling Card llave-enmano, desarrollado gracias una Plataforma propia y los Locutorios de iplan. El producto de mayor éxito para las Pymes ha sido el Pack de telefonía e Internet. El Pack-N, donde N indica la cantidad de líneas analógicas, se acompaña con otros servicios básicos ligados a Internet. Para ofrecer este servicio, se extiende desde el NdM tantos pares de cobre como líneas analógicas requiera el cliente, y un par adicional para Internet. El servicio de Internet se extiende mediante los equipos LRE (Cisco-2924/2950 y el modem de usuario 575). El ancho de banda básico ofrecido es de 1 Mbps (ampliable hasta 10 Mbps). Figura 11. Distribución de cantidad de Packs en funcionamiento en función del número de líneas que lo componen. 10

11 Monografías 1 (2003) Modelo Exitoso para Pymes El Pack-1 es la puerta de entrada en los servicios de Profesionales y Residenciales. Consiste en una línea telefónica más un acceso a Internet de banda ancha. La comercialización de Pack-1 se inició a fines del 2002, de forma que en diciembre fue el primer mes con clientes en este producto. La tecnología utilizada hasta el presente es mediante los equipos gateways en los NdM (EdgeLink de 30 líneas o VG248 de 48 líneas). Durante el 2003 se ha analizado la posibilidad de ingresar nuevos equipos a la red de un costo inferior (manteniendo las prestaciones) para acceder sucesivamente a clientes de menor porte. Repasemos algunos números para observar primero como se comporta el mercado para este tipo de productos. A mediados de mayo-2003 iplan tenía cerca de 3000 clientes donde 2000 de ellos tenía un Pack como producto. De estos, el 80% son Pack-1 a Pack-4 (SOHO y Pymes). El Pack-1, que había ingresado recientemente a la venta, llevaba acumulado 200 productos (el 10%), mientras que el Pack-2 era el que más clientes tenía con 800 unidades (el 40%). El gráfico de la Figura 11 muestra la distribución de cantidades de clientes en función de la cantidad de líneas N. Podemos observar algunos datos de interés: -De los 2000 Packs, un 77% corresponden a Buenos Aires, 13,% a Rosario y 10% a Córdoba. Esta distribución guarda correlación con las ciudades. Sin embargo, una diferencia entre Rosario y Córdoba, es que Rosario es más propensa a solicitar productos Pack con líneas analógicas, mientras que Córdoba tiene más predisposición para solicitar tramas E1 (para medianas y grandes empresas). -La distribución de Packs en Rosario y Córdoba es aproximadamente la misma: cerca del 70% corresponden a Pack-2. Son mercados obviamente de empresas más pequeñas que Buenos Aires. -En Buenos Aires, el más vendido es Pack-4 (30%) y Pack-2 (29%). Se observa en los dos picos del gráfico. El valor promedio de líneas por Pack para todas las ciudades es de 3,6. -El Pack-1 tenía en mayo-2003 una vida corta aún con menos de 6 meses, pero ya acumulaba un 7% de los clientes Pack; con un 11% en Rosario y un 4,5% en Buenos Aires. -Si se analiza las Ventas (el diagrama muestra la cantidad de clientes activos) de los primeros meses del 2003, se encuentra una concentración muy alta en Packs pequeños. En clientes acumulados, el 80% se encuentran entre Pack-1 a Pack-4, pero en ventas el 70% es entre Pack-1 y Pack-2. Se trata del 25% en Pack-1 y 43% en Pack-2. Figura 12. Evolución de las líneas analógicas a la izquierda y las tramas E1 desde el inicio de las operaciones de la telefonía en enero La pendiente promedio de los 27 meses indicados es de mas de 400 líneas analógicas y 15 tramas E1. 11

12 Monografías 1 (2003) Modelo Exitoso para Pymes El mensaje es claro, el mercado requiere productos como Pack-1 y Pack-2, lo cual es natural ya que se encuentra en la base de la pirámide de empresas y profesionales (debajo se encuentra un mercado residencial con un requerimiento similar en el producto Pack-1, pero con un consumo ubicado en la mitad que el profesional). El ingreso en el mercado residencial no es una decisión de tecnología, sino de marketing. Se trata de bajar en la pirámide de clientes pasoa-paso. La causa del éxito que tiene iplan en este segmento del mercado, se debe a la tecnología utilizada. Difícilmente otros competidores puedan llegar a igualar esta ventaja, siendo casi imposible con tecnologías SDH, ATM o wireless LMDS. Gracias a la tecnología IP, iplan ha podido mantener un crecimiento constante en la cantidad de ventas de líneas analógicas (dentro de Packs y locutorios) y de tramas E1 (como sumatoria del mercado Retail y Wholesale). Para comprobarlo, véase la Figura 12. En el caso de las líneas analógicas FXS, la evolución puede ser representada mediante dos aproximaciones. El año 2001 se muestra como una exponencial de crecimiento (1), aumentando el ritmo en la medida que la cobertura de red mediante Nodos de Manzana facilita las ventas. Entre diciembre-2001 y marzo-2002 se produce una distorsión y cambio de tendencia (asociado a los acontecimiento macroeconómicos en Argentina). Desde allí nos encontramos con un 2002 representado mediante una recta (2). Para el 2003 se puede esperar un crecimiento de menor pendiente en el primer semestre (mientras se hacen ajustes en los equipos utilizados para reducir costos) y para el segundo semestre una recuperación basados en la introducción de nuevas tecnologías de las cuales se ocupan otros números de nuestro Journal. En el caso de las tramas E1, la aproximación es mediante una recta (3). La pendiente parece ser una sola con leves variaciones al inicio del 2001, donde se tiene un arranque muy alto en enero-2001 y un crecimiento más suave después, y a finales del 2002, donde la velocidad de crecimiento se incrementa. 3- ARGUMENTOS ECONÓMICOS 3.1- Componentes de la Red. Los costos asociados a una red con tecnología IP como la descripta en la Figura 13 (basado en las Figuras 8 y 9) tiene en cuenta los componentes necesarios para ofrecer un servicio del tipo Pack: 1- Interconexión ITX: Se indica con (1) el costo de los puertos E1 de Interconexión en las Telco (red pública de telefonía PSTN) y el costo derivado de la coubicación (paulatinamente se hace insignificante en la medida que aumenta la cantidad de E1). Para el cálculo se considera la multiplexación por cada E1 promedio. En (2) se considera el transporte de las E1 hasta la coubicación, basado en los equipos SDH. Estos costos han sufrido pocas modificaciones a lo largo del tiempo. 2- Core de la red. La central de conmutación Switch class-4 tiene dos lados. El lado Interconexión (3) tiene un grado de multiplexación mayor que el lado de la red IP (4). El ítem (5) toma en cuenta el gateway E1 a IP, que en la actualidad es el equipo Cisco-5300/5350. En (6) tenemos el softswitch, donde se pueden apreciar diferentes versiones: iplan inició las operaciones con el OCMC de HP durante el 2001, el Call Manager de Cisco en el 2002 y hacia fines del 2003, se pone en marcha en forma operativa el Softswitch SI diseñado en iplan. La reducción de costos es sustancial en cada uno de los pasos. La red de transporte IP-Gigabit con equipos Cisco-6509 se indica como (7). Se encuentran estos equipos tanto en el Core como en los Hubs. 3- Nodo de Manzana. Para la distribución se consideran varios componentes. En (8) se incluyen los costos para la implementación de un Nodo de Manzana, con la construcción de la acometida de FO y los materiales básicos. En (9) se indica el switch 3524/3550 para la conversión desde el nivel Gigabit por FO a Ethernet por UTP (10/100 Mbps). Por (10) se entiende el equipo para extender el servicio de Internet mediante cobre; se trata del equipo Cisco-2924/2950 que trabaja en conjunto con el modem de usuario Cisco-575. Figura 13. Componentes a tener en cuenta en la valuación de costos en una red IP para ofrecer Pack-N. 12

13 Monografías 1 (2003) Modelo Exitoso para Pymes Figura 14. Evolución a lo largo del tiempo de los costos en dólares asociados a la oferta de Packs. En el gateway de telefonía (11), se detectan diversas alternativas. Inicialmente en el 2001 se realizaba mediante el Gateway-E1 Cisco-2600 acompañado con multiplexores Edgelink. En el 2002 se introdujo el Call Manager que trabaja con Gateway-FXS, el Cisco-VG248. A fines del 2003 está planeado la introducción de nuevos gateways de menor costo para reducir aun más las inversiones por cada línea analógica. 4- Cliente. El cableado de cobre (última milla) desde el NdM hasta el cliente, está contenido en el ítem (12). Muchas veces se dispone de un punto intermedio (conocido como Nodo Virtual). Este sólo dispone de una distribución de pares de cobre, intermedio entre el NdM y el cliente. En (13) se indica las inversiones en equipos en el cliente. En el inicio de las operaciones (primer semestre del 2001) se utilizaron equipos Cisco-1750/2611 como CPE de cliente para ofrecer el Pack-4. Actualmente, el único equipo en el cliente es el Cisco-575 que actúa de corresponsal del Cisco- 2924/ Evolución de las inversiones En la Figura 14 se muestra la evolución de las inversiones de los 4 ítem mencionados en el punto anterior, a lo largo de los últimos años. Se observa claramente que la tecnología IP ha tenido una reducción de costos sostenida, lo que permite mantener el crecimiento en épocas donde las inversiones son difíciles de conseguir. Veamos con más detalle cada ítem: 1- Interconexión ITX. Este rubro no sufre cambios significativos a lo largo del tiempo. Se trata de equipos SDH de precios muy estables. 2- Core de la red. La evolución temporal muestra cambios importantes debido a la introducción de Softswitch y Gateway-E1 de costos inferiores. La reducción de costos se lleva desde 240 u$s/línea a 70 u$s/línea, en 3 años. 3- Nodo de Manzana. Incluye los componentes básicos del Nodo de Manzana en los cuales no han existido cambios sustanciales. Sin embargo es posible observar una fuerte reducción desde 500 u$s/línea a 180 u$s/línea, impulsado por el cambio de gateways de telefonía. Estos valores incluyen el proporcional para ofrecer el servicio de Internet asociado a las líneas telefónicas en los Packs. 4- Cliente. Incluye fundamentalmente la instalación, razón por la cual no se pueden observar variaciones a lo largo del tiempo. El valor señalado aquí es cercano a 130 u$s. Todo sumado, nos encuentra con una reducción de inversiones necesarias por cada línea telefónica (incluyendo el proporcional para ofrecer la Internet asociada en el Pack) desde un valor de unos 880 u$s/línea en el 2001, a 580 u$s/línea en el 2002 y a 390 u$s/línea a fines del Eficiencia del Modelo de NdM. Este modelo exitoso de NdM requiere un trabajo de reingeniería permanente, que permita seguir la evolución de facturación de cada nodo para mejorar la recuperación de las inversiones. Veamos algunos datos de referencia. 13

14 Monografías 1 (2003) Modelo Exitoso para Pymes Figura 15. Diagrama de constelación de la facturación de los NdM a fines del Hacia fines del 2002 se disponían de más de 100 NdM habilitados con otras 160 manzanas con Nodos Virtuales con solo distribución de cobre. Analizando unos 90 NdM en la ciudad de Buenos Aires se obtiene el gráfico de la Figura 15. -Considerando una inversión promedio de u$s por cada NdM y una facturación promedio en julio-2002 de $/NdM (un año después de iniciarse el modelo de distribución mediante NdM), se puede obtener el cociente entre la facturación y la inversión. Este valor varía desde 0,02 a 1,75 (en la Figura se muestra hasta 0,90 para no distorsionar la imagen). -El valor promedio era en aquel momento de 0,32 $/us$ (32 centavos de peso de facturación por cada dólar de inversión). Se puede observar también que unos 15 NdM (de los 90 analizados) tienen equipamiento mínimo y la facturación es baja (promedio 4800 $/mes). Se trata de la zona (1) en la Figura. La zona (3) en cambio incluye aquellos nodos que reportan un elevado valor de facturación vs. inversión. -Es de notar que los valores de inversiones indicados, solo toman en cuenta los NdM (ítem 3- en los puntos anteriores). Pero en realidad, si se realiza un up-grade de los NdM existentes (situación corriente en el caso que la red que se encuentra ya desplegada) las inversiones son mucho menores. En este caso es típico obtener valores de 1 $/u$s. El gráfico muestra el cociente (facturación en pesos dividido por la inversión en dólares) de los 90 NdM. Los NdM ubicados en la zona (1) se tratan de nodos de baja eficiencia en cuanto a facturación de acuerdo con las inversiones realizadas. También se encuentran en esta zona los NdM nuevos que inician las operaciones. La zona (2) es el promedio de los NdM. En la zona (3) se encuentran los NdM de alta eficiencia, normalmente se trata de aquellos que además de brindar telefonía, tienen servicios de TLS e Internet (productos con mayor rentabilidad de acuerdo al Capex). Con el transcurso del tiempo esta curva se mueve hacia arriba en la medida que se mejora la rentabilidad de cada nodo. Un nodo en particular se moverá hacia la derecha incrementando la facturación por cada dólar invertido Oportunidades por ventajas tecnológicas. El modelo de NdM implementado por iplan, se ha demostrado exitoso en términos del crecimiento sostenido de ventas. Por otro lado, la selección tecnológica ha mostrado paulatinamente que era la variante apropiada en cuanto hace a ofrecer servicios a pequeñas empresas, debido a la reducción de costos y a la granularidad de la oferta. Esto, comparado con las tecnologías en competencia (SDH o ATM). Desde ya que el modelo de las Telco tradicionales (Telefónica y Telecom) es inaplicable hoy día por una empresa que entra en el mercado. Aclaremos esto un poco más. Las Telco continúan el modelo de red de Entel. Se trata de una gran central de conmutación (switch class-5), con gruesos cables de pares de cobre (centenar o miles de pares) que se instalan por ductos de 10 cm de diámetro y que se van desgranando hasta llegar al usuario (a centenares o miles de metros de distancia). Una empresa nueva en el mercado debe construir una red subterránea mucho más modesta (con tritubos de 3,5 cm de diámetro interior) y que solo permite instalar cables de FO o hasta 100 pares de cobre (con mucho esfuerzo). Resultado: el único modelo posible es llegar con cables de FO hasta un 14

15 Monografías 1 (2003) Modelo Exitoso para Pymes punto de distribución (el Nodo de Manzana) y allí cambiar a cables de cobre, de corto recorrido por ductos (no más de algunos centenares de metros), debido a que los ductos son un bien escaso en la red. Es posible crear NdM con diferentes tecnologías: SDH, ATM o IP-Gigabit (y quizás wireless LMDS). Durante el primer trimestre de 1999 se realizó una profunda evaluación de tecnologías en iplan. Los resultados en aquel momento indicaban que era conveniente el modelo de distribución IP- Gigabit frente al SDH o ATM por razones económicas. Además, por razones de ancho de banda el modelo wireless era básicamente desaconsejable. En particular, la tecnología ATM tiene algunas ventajas de Interés. Dispone de accesos E1 con emulación de circuitos. Es muy efectiva para la gestión del ancho de banda asignado del cliente (granularidad Nx64 kbps). Sin embargo, tiene algunas desventajas. No dispone de clientes 100 Mbps y el número de ports de cliente es limitado (escalabilidad de cliente más costosa). Gigabit tiene algunas ventajas de Interés particular: Toda la red de acceso es 1000 Mbps (ancho de banda diferenciador) y la operación es ampliamente conocida. Se utiliza la misma tecnología del cliente en toda la red. La desventaja de Gigabit es el mito que no dispone de calidad de servicio, un mito que se contrarresta con fuerza bruta, ya que se utiliza 1000 Mbps de transporte hasta cada manzana a un costo bajísimo. El paso del tiempo ha demostrado lo correcto de la elección. Hoy día la tecnología IP-Gigabit mantiene una tendencia decreciente de costos y permite continuar con un crecimiento sostenido en el tiempo. Siguiendo esta línea de razonamiento, se puede observar que varias empresas entrantes en el mercado se han visto obligadas a enfocar su negocio hacia el mercado mayorista o grandes cuentas (obligadas por la reducción de las nuevas inversiones y por los costos de tecnología). En el extremo opuesto se encuentra iplan, que con una red de distribución de cobre y transporte IP-Gigabit ha logrado enfocarse sobre un mercado abandonado: las medianas, pequeñas empresas y profesionales (Pym es y SOHO). La Figura 16 intenta reflejar este concepto. Un caso particular son las Telco. Ellas tienen una orientación a todos los mercados por tener una posición dominante, pero se refugian en los grandes clientes debido a la imposibilidad o falta de vocación en el cuidado del pequeño cliente. Figura 16. Cambios de orientación estratégica de las empresas de telecomunicaciones. Mientras la mayoría de las empresas entrantes se concentran en grandes clientes, la ventaja tecnológica ayuda a iplan a trabajar sobre un mercado desatendido. 15

16 MONOGRAFIAS DE J: Journal monografías número 1. Edición julio Diseño gráfico original de Marianela V. Ricardo 16

17 monografía iplantech Journal Monografías es una publicación de iplan que contiene información técnica y confidencial de la empresa. Se distribuye a un circuito limitado de lectores a fin de mantenerlos informados sobre el estado y la evolución de la tecnología y el negocio de la Telecomunicaciones, principalmente en las redes IP y la Telefonía-IP. Se ruega a los lectores a mantener el principio de Confidencialidad sobre la información aquí contenida. No está autorizada su reproducción o distribución por cualquier medio sin antes consultar con la empresa. ILa Tecnología COSO COSO (Competitive Open Service Operator) es un desarrollo de iplan que permite resolver desafíos de tecnología y productos. IINDICE 1 Historia de COSO. 2 Componentes y Funcionamiento. 3 Funcionalidades del Release Funcionalidades del Release Solución Tecnológica: Transporte de SS7 sobre IP. 6 Solución Tecnológica: Manejo de STP. 7 El futuro de COSO. IABSTRACT COSO es una tecnología desarrollada en iplan para generar servicios de red inteligente sobre las centrales de conmutación, soportado en señalización SS7. Originalmente fue desarrollado para ofrecer servicios 0800 y resolver algunos servicios obligatorios de la CNC. Luego pasó a entregar novedosos servicios de valor agregado para clientes sin conexión física con iplan Networks. Paralelamente, entregó diversas soluciones tecnológicas para una red pionera de Telefonía-IP (transporte de SS7 sobre IP y la funcionalidad STP). Esta monografía presenta un detalle del funcionamiento, funcionalidades y soluciones tecnológicas de COSO. Además informa brevemente de los próximos pasos de la tecnología. IAUTORES Esta monografía está basada en documentos originales de Eduardo Moreira, Claudio Degraf, Sebastián Navarro y Ariel Barmat. 1

18 Monografías Tecnología COSO 2 (2003) iplan es una empresa fundada en 1999, cuya orientación es el servicio de Telecomunicaciones a las Pymes. Desde su origen se presentó como una solución a pequeñas empresas y toda su red y tecnología fue pensada y desarrollollada en este sentido. Desde el punto de vista de la tecnología se seleccionó una red de transporte Gigabit-Ethernet (1000 Mbps) sobre fibras ópticas metropolitanas y con protocolo IP. Sobre esta red se ofrecen servicios de telefonía analógica, transmisión de datos, acceso a Internet y una variedad de servicios de valor agregado. También dispone de una red de transporte de E1 mediante la tecnología SDH para grandes clientes. iplan ha mantenido un crecimiento constante desde el inicio de las operaciones comerciales a mediados del año Para dar cabida a nuevos e innovadores servicios, se dispone de un grupo multidisciplinario para el Desarrollo de Software y Hardware. En este número de Journal se presenta una de las tecnologías más ricas en resultados. La tecnología COSO se independiza de la marca de la central de conmutación; el requisito es trabajar con señalización SS7. 1- HISTORIA DE COSO La red de Telefonía en iplan fue desplegada entre el año 2000 y Consiste en centrales de conmutación de tránsito (switch class-4 marca NEC) que se instalaron en las ciudades de Buenos Aires, Rosario y Córdoba. Paralelamente se dispone de una red de Telefonía-IP que permite ofrecer todos los servicios de telefonía analógica (líneas FXS). La primer plataforma de Telefonía-IP se desarrolló sobre el softswitch OCMC (Open Call) de HP. Ante la evidencia de las dificultades que poseía HP para mantener operativo el OCMC, se requirió a Cisco una solución alternativa que se implementó mediante Gatekeeper Cisco-7400 en abril Paralelamente se iniciaba el startup de una plataforma de Telefonía-IP denominada Call Manager de Cisco. Mas tarde, durante el 2003, se implementaría el softswitch de iplan en conjunto con gateway Cisco-IAD2430 y Audiocodes-MP124. Las necesidades urgentes a resolver a mediados del 2002 eran: -la traducción numérica para servicios 0800 (hasta aquel momento, se realizaba mediante Índices de Traducción Numérica en la central de conmutación), -liberar los prefijos en los Gatekeepers Cisco-7400 y -solucionar los problemas existentes de la numeración 0800 con las empresas celulares Unifón y Personal. Para la función de traducción numérica se estaba utilizando una funcionalidad de la central de conmutación NEC, la cual no está preparada para esta tarea por ser una central class- 4 (de tránsito). La central posee una función que permite ciertas modificaciones de dígitos en las llamadas luego de decidir el enrutamiento y básicamente está pensada para enrutamientos por Carrier. Esta función trabaja en base a parámetros conocidos como Indices de Edición, y permite convertir un número de entrada en otro de salida. Se utilizó para traducir el servicio Sin embargo, la central solo dispone de 64 índices y todos ellos estaban siendo utilizados a medidos del Una de las alternativas posibles era la modificación del software en la central para ampliar el número de índices disponibles. Esta solución resultaba cara y limitada (llevaría a 128 el número de índices), y solo alcanzaba para cubrir la coyuntura. Otra alternativa para solucionar esta deficiencia, era usar el software NAM de Cisco. El NAM permite proveer una variedad de servicios de enrutamiento inteligente de las llamadas. Sin embargo, no todos los requerimientos necesarios para la red de iplan estaban cubiertos por este software. NEC propuso otra solución adicional con la Plataforma Naina, un software a ser desarrollado en Argentina. Era una solución definitiva al problema, que solo podía ser considerada en el marco de un Budget de inversiones distinto al disponible. Por otro lado, existían algunas soluciones de software transportables en PC para interfaz ISDN-PRI. El freno era este tipo de alternativa es que no se disponía de tramas E1 con interfaz PRI en las centrales. Además, se requería un análisis y test más profundos de estas soluciones. Se analizó entonces una plataforma de manipulación de dígitos sobre IP con el Gatekeeper-Master (denominación interna de iplan), el cual más tarde daría lugar al Softswitch SI. El softswitch es motivo de otra monografía de la serie Journal. Esta solución solo sería útil para una parte del problema, dado que estaría sobre la Telefonía-IP y no sobre toda la red de telefonía. La propuesta no resolvería los 0800 para modem y no traduciría o restringiría por la categoría de llamada desde teléfono público. Se trataba de una solución limitada. Otra solución descartada de inmediato fue el uso de loops entre equipos Cisco-5300 con señalización SS7. Se podrían realizar traducciones de números mediante una técnica llamada translation-rules Hair-Pinning. La desventaja es que la calidad de servicio sería impresentable (inferior al 40%). Con todas estas alternativas rechazadas, quedaba una que daría una solución definitiva y se demostraría la tecnología más prolifera durante el siguiente año: COSO. Esta plataforma de Red Inteligente entró en servicio de pruebas en enero-2003 y en servicio operativo desde marzo Así se contaba en septiembre-2002 el nacimiento de este software: Luego de sacar de servicio el softswitch OCMC de HP en abril-2002, si bien la red de Telefonía-IP continuó trabajando con gatekeeper de Cisco, el cambio de equipamiento trajo aparejados otros inconvenientes, entre ellos los aspectos de tasación, provisioning y traducción de números para llamadas Estuvimos evaluando softswitch alternativos que ofrecían buenas performances y cantidad de features, pero cualquier instalación requería inversiones importante. Entre las opciones evaluadas también hubo una propuesta de NEC, con una solución para servicios de red inteligente 2

19 Monografías 2 (2003) Tecnología COSO (como el del 0800), que "habla" señalización SS7 con la central y emula una comunicación ida y vuelta con central adyacente utilizando loops de E1s. Independiente de lo anterior, estábamos analizando equipos que nos permitieran transportar señalización SS7 sobre IP en modo seguro, de manera de llevar los enlaces de Telecom hasta Rosario y Córdoba. A partir de ahí pusimos manos a la obra para conseguir precios de placas o servidores para hacerlo nosotros, a sabiendas que la tarea nos podría demandar mucho tiempo y esfuerzo. Una mañana se escuchó "..y si usamos los SLT de Cisco?" (SLT son los terminales de señalización SS7 que ya estaban en uso en nuestra red), "...si con una máquina logramos hablar con los SLT usando el protocolo Cisco, no solo podemos transportar los enlaces, sino que... también podemos llegar a solución definitiva". Vinimos una madrugada y, muñidos de los correspondientes equipos para monitorear y emular protocolos de red, estudiamos el "lenguaje" de los SLT. En menos de dos semanas ya estaba la demo funcionando y permitía tanto la traducción de un número 0800, como también sacar llamadas en modo privado (sin presentación del número en el display del teléfono). El prototipo del COSO (porque así se llama ahora) fue puesto a prueba por la gente de iplan a mediados del Acerca del nombre. Durante una presentación, se escuchó la pregunta: "este coso puede hacer... (tal o cual función)?" y así es que, recordando ese momento, COSO se transformó en el acrónimo de "Competitive Open Services Operator". Unos meses después COSO tenía su propia identidad, con el logotipo e isotipo correspondiente Componentes del Sistema El diagrama a bloques de COSO se fundamenta en dos conceptos: un ISUP-Loopback y el procesamiento de señalización SS7 usando el equipo SLT de Cisco con protocolo RUDP (propietario de Cisco). Los componentes pueden verse en la Figura ISUP-Loopback. El protocolo ISUP (Integrated Services Digital Network User Part) es el protocolo de señalización SS7 que se utiliza para comunicar las centrales de telefonía de iplan con el resto de los operadores (ver más adelante para una detallada explicación). Mediante el ISUP-loopback se establecen lazos de señal vocal en cada central de conmutación mediante tramas E1. El ISUP-loopback permite al SHP (Signaling Handler Platform) tener el control de los mensajes de señalización en las diferentes etapas de la llamada (mensajes IAM, ANM, ANS, REL, RLC, etc). De este modo, el SHP puede ahora controlar todo el establecimiento (call-setup) de la llamada, y además enviar triggers al SDBP (Service Data Base Platform) mediante la API (una pieza de software) para ejecutar las operaciones de servicios de Red Inteligente. Así, en vez del alto costo de modificación o reemplazo del equipo de conmutación, el ISUP-loopback puede proveer lo mismo, a mucho menor costo. 2- Cisco SLT y RUDP Protocol. EL equipo SLT (Signaling Link Terminal Cisco-2611) transporta los protocolos SS7 mediante la red IP hacia un nodo servidor. Utiliza el protocolo RUDP propietario de Cisco para encapsular y transportar el protocolo ISUP de la señalización SS7. El UDP es un protocolo simple diseñado para el transporte y basado en paquetes orientados a la conexión. RUDP permite establecer una conexión confiable entre un cliente y un servidor, proveyendo control de flujo y congestión. En cada extremo, la conexión se realiza usando la dirección IP y un puerto específico de protocolo UDP (User Datagram Protocol). 3- Las centrales NEAX-61. Son sistemas de conmutación digital que se utilizan en iplan para establecer la interconexión contra la PSTN (todos los operadores de telefonía) en Buenos Aires, La Plata, Rosario y Córdoba. Además permiten la conexión de clientes E1 de alto tráfico sin pasar por la red IP (Gigabit Ethernet). Figura 1. Logotipo e isotipo de COSO. 2- COMPONENTES Y FUNCIONAMIENTO COSO es uno de los desarrollos de software de iplan. Tiene el objetivo de completar las funcionalidades de la red de Telefonía-IP y ofrecer servicios novedosos y a la medida del cliente. Inicialmente el servicio de telefonía estaba basado en equipos que no poseían las funcionalidades de red inteligente IN (Inteligent Network) y existía la necesidad de una tecnología alternativa para brindar este tipo de servicios. La solución COSO como tecnología alternativa se conoce como Red Inteligente Virtual (VIN). 4- Servidores de plataforma COSO. Los siguientes son las funcionalidades de software de la plataforma COSO: -Signaling Handler Platform (SHP). El SHP lleva a cabo la comunicación con el SLT hablando señalización SS7 sobre IP a través del protocolo RUDP. El SHP provee las API para enviar y recibir parámetros ISUP desde y hacia el SDBP. -Service Data Base Platform (SDBP). El servidor SDBP ejecuta todas aplicaciones de red inteligente avanzada tomando la información recibida desde el SHP. De este modo, el SHP y el SDBP juntos, pueden controlar el callsetup y ejecutar las más diversas operaciones de servicio. 3

20 Monografías 2 (2003) Tecnología COSO Figura 2. Diagrama a bloques y componentes de COSO. -Service Provisionig Platform (SPP). El SPP permite el provisioning para todas las aplicaciones del sistema, desde la configuración básica de señalización hasta los perfiles de cliente, otorgando una interfaz la cual puede ser accedida a través de perfiles de usuario y password Funcionalidades del Sistema El servicio general que provee COSO es la traducción numérica. Consiste en que la central de conmutación enviará a la plataforma un mensaje del Sistema de Señalización SS7 con el número del abonado llamado B y asociado a un circuito vocal (CIC) específico. La plataforma COSO re-envía el mensaje SS7 hacia la central, pero con un CIC diferente y un número de abonado llamado B traducido. En un servicio de Calling Card por ejemplo, la llamada entrante tiene generalmente un destino 0800 y se cambia por el destino final deseado por el usuario. Entonces, la central procesará el mensaje recibido en modo corriente como una nueva llamada. Un número monográfico de Journal se ocupa de tratar el funcionamiento de la plataforma de Calling Card junto con COSO. La tramas están conectadas de tal manera que los canales vocales tomados en cada mensaje forman un lazo (loop E1 en la figura), aunque la central creerá que está hablando con una central IN Remota (Inteligent Network). Con esta solución, el COSO puede controlar todo el proceso de establecimiento de la llamada (call-setup) y ejecutar las operaciones de servicios IN. COSO ofrece servicios a usuarios y soluciones tecnológicas. Entre los servicios a usuarios se encuentran el 0800, Calling Card y algunos servicios obligatorios del ente regulador (la CNC). Entre las soluciones tecnológicas se encuentra el transporte de señalización SS7 en la red IP y la funcionalidad STP, ambas son analizadas más adelante en este mismo trabajo. A mediados del 2002 se disponía de una versión demo, la que permitía establecer una llamada ISUP completa y la emulación de una llamada de servicio Free-Phone (0800). Se adicionaron las facilidades mínimas de mantenimiento MTP3 de SS7 para permitir la disponibilidad del circuito y la liberación y reset. Esta versión demo corría sobre una plataforma Windows-NT, y la aplicación fue desarrollada en MicroSoft Visual Basic. En la versión demo el SDBP fue reemplazado por un programa simple de MSVB que responde a las solicitudes (queries) sin disponer de una base de datos. El SPP aún no se había implementado. El billing se hacía en el modo corriente con los CDR de la central de conmutación. Para una llamada común se hacían dos CDR y no se hacían registros de llamada para conciliar ambos CDR. En enero-2003 se disponía ya de la primera versión precomercial de COSO, la cual estuvo a prueba durante el verano de este año. En marzo se volcaron los primeros clientes en un funcionamiento comercial a pleno. 3- FUNCIONALIDADES DEL RELEASE El Servicio de 0800 En el primer Release de COSO, conocido como versión v1.02, se implementaron las funcionalidades del servicio 0800 (llamadas gratuitas). Se configuraron las siguientes restricciones, que se configuran para cada cliente con 0800: -Restricción por Área de Origen o Prefijo (conocido como Lista Blanca-Negra). Esta funcionalidad restringe las llamadas de acuerdo al prefijo de origen recibido en el mensaje de señalización. El operador tiene la capacidad de personalizar y agregar todos los prefijos que desee y la restricción se hará de acuerdo con listas negras y blancas. -Restricción por Categoría de Telefonía Pública. Es posible restringir las llamadas originadas en teléfonos públicos. -Restricción por Fecha y Hora. Se restringe las llamadas los días feriados a requerimiento del cliente. Para el caso de 4

21 Monografías 2 (2003) Tecnología COSO Hora y Día se contemplan los días de la semana y las bandas horarias por hora completa. Es decir, se puede determinar la restricción o no, según cada hora de cada día. Sin embargo, existían entonces en el Release 1.02 diversos inconvenientes y limitaciones. Por ejemplo, se puede mencionar: -Enrutamientos por Área de Origen. Los clientes no podían solicitar enrutamientos de llamadas provenientes de diferentes áreas de origen. Una vez superados los niveles de restricción en el proceso de llamada, ésta era traducida sin tener en cuenta el origen. -Llamadas a 0800 Local en Córdoba y Rosario no originadas en Telecom. Las llamadas a números 0800 Local ubicados en Córdoba y Rosario y originadas en otro proveedor distinto de Telecom (por ejemplo, Telefónica, Impsat, etc) eran entregadas todas en Buenos Aires y eran bloqueadas por la central de conmutación. -Caso 0800 ciudades-iplan. Se había vendido a algunos clientes esta facilidad (las ciudades-iplan son Buenos Aires, La Plata, Rosario y Córdoba), pero el problema radicaba en la facturación, dado que en aquel momento todas las llamadas que se originaban y terminaban en Telefonía-IP no se facturaban. -Interconexión con Celulares. No era posible asegurar la interconexión con todas las prestadoras celulares del mercado local. En el caso de Personal y Unifón, ambas insertan un código de tres cifras a continuación del prefijo 345 (es el identificador PQR que tiene iplan como carrier interurbano) para indicar el origen cuando el celular hace roaming, lo que provocaba colisiones de numeración. -También se tenía la imposibilidad de brindar servicios de Valor Agregado. Por enrutamiento se entiende la traducción de un número 0800 a un número geográfico y la posterior terminación de la llamada. En el caso de un enrutamiento en redes de terceros, la plataforma COSO versión 1.02 permitía traducir el número del usuario llamante poniendo un ANI de plataforma asociado a cada 0800 en particular. Este ANI puede ser tanto un Número Geográfico como No- Geográfico. Los tipos de enrutamiento soportados para 0800 en esta versión de COSO, son los siguientes: -Standard (se realiza una traducción a un número geográfico de aquellas llamadas sin restricciones). -Por Fecha, a requerimiento del cliente. Es posible ofrecer algunos Servicios Avanzados en este Release. Se trata de las siguientes posibles restricciones: -Límite de Cantidad de Llamadas Simultáneas. Este feature es útil para clientes que disponen de cierta cantidad de líneas y desean dejar algunas libres para uso privado. -Límite del Tiempo de Duración de Llamadas (sin el anuncio asociado). Se ingresa el valor en segundos del límite de duración de llamadas. Cuando el valor llega al del tiempo límite establecido, la plataforma corta la llamada hacia ambos lados. En esta Release, no se conecta la locución alertando al usuario que dispone de un tiempo limitado de comunicación. -Distribución de Llamadas (sin detección de ocupado). La plataforma puede hacer una Distribución Equitativa (round robin) de llamadas entre varios números. La cantidad máxima de números de distribución posibles es 4. Si el número al que se traduce por efecto de la distribución se encontrara ocupado, la plataforma no lo vuelve a traducir sobre otro de la lista de distribución, ya que no detecta esta condición de abonado ocupado. Se han implementado algunos Anuncios de Catálogo en esta Release. Para la conexión a Anuncios, el número es traducido a un código predeterminado de manera que la llamada sea conectada a un servidor de anuncios externo. Los posibles anuncios son: -por Número Inexistente ( El número gratuito marcado no corresponde a un cliente en servicio ); -por Área de Acceso ( El destino solicitado ha decidido no recibir llamadas desde el área donde usted llama ); -por Categoría del Usuario de Origen ( El destino ha solicitado no recibir llamadas originadas en telefonía pública ); -por Fecha, Hora y Tipo de Día ( El destino ha solicitado no recibir llamadas en este momento ); -por Límite de Cantidad de Llamadas Simultáneas ( El destino no tiene operadores de atención disponibles, por favor intente mas tarde ). 4- Funcionalidades del Release 2.01 Los servicios de la Plataforma COSO se iniciaron en marzo con la versión Desde mayo-2003 se dispuso de la versión 2.01, con nuevos servicios. COSO, visto como una plataforma de servicios, es tan flexible que permite crear casi cualquier funcionalidad en tiempos muy breves de desarrollo. El Release 2.01 se implementó con la función de Servicio de Operadora Nacional e Internacional y Servicio de Red Privada Virtual (VPN). Por otra parte, soporta la implementación de SHP en múltiples sitios, lo que permite instalar plataformas SHP sobre cada central telefónica manteniendo una única plataforma SDBP centralizada El Servicio de 0800 Al servicio 0800 se le implementaron nuevos Features adicionales en el Release Desde este Release es posible la Resolución de Inserto AMM. El AMM (Área Múltiple Móvil) es un código insertado por las compañías de celulares Personal, Unifón y Nextel sobre el número del usuario B en llamadas 0800 para identificar el área de origen. El inconveniente que trae aparejado este código es que produce colisiones de numeración sobre las centrales públicas. El formato de un número 0800 recibido desde un teléfono fijo es 800-PQR-MCDU y el recibido desde un teléfono móvil 800-PQR-AMM-MCDU (el PQR de iplan es 345). Se puede observar que este código AMM colisiona fácilmente con los dígitos MCD de un número 0800 normal. 5

22 Monografías 2 (2003) Tecnología COSO Figura 3.Se muestra las pantallas de COSO para configuración en el Release Debajo el Formulario de requerimientos que se llena con el usuario para configurar el servicio. Mediante la funcionalidad introducida, la plataforma determina la longitud del número recibido, luego normaliza el 0800 extrayendo el código AMM. Por último, se procede a realizar las restricciones y enrutamientos que son necesarios. En esta Release, la plataforma no realiza restricciones ni enrutamientos de acuerdo al código AMM presente en llamadas desde teléfonos móviles. El prefijo de origen siempre se extrae desde el ANI de la llamada, estando previsto implementar esta facilidad en futuras versiones. A los enrutamientos ya soportados, se agregan los relacionados con el Área de Acceso. Permite diferentes enrutamientos según el origen, y se ha establecido en 4 el número de traducciones diferentes. El enrutamiento personalizado por prefijo es combinable con el enrutamiento por fecha y hora. Es decir, la traducción puede depender del prefijo de origen y además variar de acuerdo al día y la hora. El enrutamiento se realizará solamente a partir del ANI. A su vez, la plataforma permite traducir a diferentes números de acuerdo a la categoría del usuario de origen. En caso de combinarse con la facilidad de enrutamiento por prefijo de origen, el prefijo de origen tendrá prioridad, es decir primero se determina el origen y luego la categoría. 6

23 Monografías 2 (2003) Tecnología COSO A los anuncios de catálogo ya soportados por el Release anterior se agrega el Límite de Tiempo de Duración de Llamadas ( Usted dispone de XX minutos de comunicación gratuita hacia este destino ). Además, se agregó la funcionalidad que en caso de producirse enrutamientos a redes de terceros, la plataforma indicará este evento como un nuevo tipo de servicio en el ticket de AMA correspondiente Servicio de Operadora En el Release 2.01 se implementó el Servicio de Operadora. Todas llamadas cuyo destino sea el 19 (operadora nacional) o 000 (operadora internacional) se resuelve en dos instancias. En la primer instancia se comunica al usuario llamante con la posición de operadora correspondiente y luego, una vez que la operadora resuelve el número de destino, corta el segmento de llamada conectado a la posición y genera una nueva llamada hacia el destino. El usuario llamante no percibe este corte. La operadora tendrá dos ventanas en su interfaz gráfica: -Aplicación para la búsqueda de Números en la base E.164, -Aplicación COSO para establecer la comunicación (proceso de transferencia entre la operadora y el destino solicitado). La aplicación COSO indicará la condición de Abonado de telefonía pública (como origen de llamada). Cuando el origen de la llamada es un Teléfono Público, la interfaz de operadora no habilita la opción de transferencia. El servicio Operadora Internacional (000) no tiene un interés comercial particular, pero es requerido regulatoriamente por la CNC en Argentina. El problema que se presentaba se relaciona con la facturación del servicio. El servicio implementado en COSO utiliza una característica conocida como click-to-dial. Cuando la operadora completa los datos del destino, al dar ok en su aplicación, envía estos datos a COSO, quien primero libera el canal de audio a la operadora y, sobre ese mismo canal, genera una nueva llamada al destino solicitado. La ventaja de la solución es que facilita el trabajo de la operadora. Tanto en la plataforma como en la central habrá dos CDR, uno con destino a la operadora y otro con el destino solicitado, pero ambos con el mismo origen (el número A del cliente). Al igual que en el servicio 0800, la plataforma COSO estará preparada para generar un único CDR para las dos instancias de llamada (call legs) que genera. Este único CDR contiene toda la información referida a la llamada internacional vía operadora. En cuanto a la ruta, COSO podría indicar un nombre de ruta especial de operadora, aunque la llamada salga por un canal del mismo loopback de Servicio de Red Privada Virtual (VPN) Con este servicio se pueden integrar todos los servicios de voz en un plan de numeración privado. Así, marcando pocos dígitos, un cliente puede comunicar todas sus sucursales, oficinas y edificios entre sí como si fueran internos. El sistema le asigna un número a cada terminal de la VPN conformando un Plan de Numeración Privado. El número a recibir por la plataforma tendrá la siguiente estructura: 876-CLI-XYZ-MCDU y NADI Nacional, donde 876 es el Prefijo indicativo de VPN, CLI es el Código de cliente de 3 dígitos, XYZ es el Código de sucursal y MCDU es el Número de interno. Esta estructura del número a recibir por la plataforma COSO para resolver el servicio de VPN, será formada por manipulación de dígitos en los terminales o por equipos del cliente pertenecientes a la VPN, es decir la PABX o líneas analógicas desde PSTN Gateways. De este modo el usuario marcará pocos dígitos (eventualmente el número de interno o el código de sucursal mas el número de interno). Luego, ya sea la propia PABX o las reglas de traducción vinculadas a las líneas analógicas, se encargan de agregar el código de VPN. En caso de que el cliente posea una PABX conectada a la central, la PABX envía los dígitos correspondientes y la central de conmutación de iplan le agrega el prefijo 0876 al recibirlos. El prefijo 0876 se ha predeterminado para el servicio VPN y es transparente para el usuario que llama. En el caso que el servicio sea prestado mediante la plataforma Call Manager de Cisco o mediante otros Gateways H.323, el prefijo se agrega por la función de Translation Rules. El paso siguiente es enviar un mensaje Setup con la numeración 0876-XX-Interno hacia el equipo Gateway-E1 Cisco-5300, que interconecta la red de Telefonía-IP con las centrales de conmutación. Todas las llamadas terminan en la central que envía hacia el COSO un mensaje de señalización SS7 con la información del número de B (876- XX-Interno) y el número de A (el ANI). El paso final es la traslación de numeración en COSO que cambia el mensaje y lo envía con la información del número de B (número Geográfico) y el número de A (ANI). El enlace vocal se completa a través del loopback E1 de la central de conmutación. Esta información contiene: -el Número Llamante, -el Número Internacional de Destino, -el Número de Operadora, -la hora en que atendió la operadora, -la hora de comienzo de llamada, l -a duración, etc. 7

24 Monografías 2 (2003) Tecnología COSO 5- SOLUCIÓN TECNOLÓGICA: TRANSPORTE DE SS7 SOBRE IP COSO no solo permite desarrollar servicios de valor agregado, sino que además ha generado varias soluciones tecnológicas. En este ítem se trata el transporte de señalización SS7 en una red IP. En el ítem siguiente se trata la funcionalidad STP para una red de telefonía pública. Como background de señalización SS7, se entrega a continuación, un resumen simplificado de los protocolos Sistemas de Señalización Por señalización en telefonía se entiende el conjunto de informaciones que son intercambiadas entre distintos puntos de la red de telefonía (entre el usuario-a-central o entre central-a-central). La señalización permite: -la Supervisión (detección de condición o cambio de estado), -el Direccionamiento (establecimiento de la llamada), -la Explotación (gestión y mantenimiento de la red). En iplan se utilizan 3 sistemas de señalización (...por el momento): -el MFCR2 para conectar algunas PABX de clientes con las centrales de conmutación mediante enlaces SDH, -la señalización SS7 para la denominada interconexión ITX hacia la red pública de telefonía PSTN y -la suite de protocolos H.323 para la red de Telefonía-IP. A continuación, hacemos una breve introducción a cado uno de estas suite de protocolos. MFCR2. En los sistemas de señalización se distingue entre los procedimientos de código de impulsos y los de señales obligadas (en este último caso, el MFCR2). En el primer caso, la señal tiene un período de duración fijo y determinado; mientras que en el segundo, a cada paso de mensaje se espera la respuesta de confirmación por el canal de retorno para cortar la señal de ida. Esto implica que la señalización por secuencia obligada requiere de mayor tiempo y de una duración no determinada. En MFCR2 la señal vocal y la señalización viajan por la misma vía (la trama E1), pero en distinto intervalo de tiempo. Por ello, no se interfieren y se puede efectuar el proceso de cómputo o tarifación del tiempo de comunicación mediante señales "hacia atrás". En el sistema de multiplexación mediante tramas E1 de 30 canales de telefonía, la señal E1 de 2048 kbps se divide en 8000 tramas por segundo de 32 intervalos de tiempo TS cada una. El Intervalo de Tiempo 16 se usa exclusivamente para información de señalización de los 30 canales vocales. SS7. En MFCR2 se tiene una correspondencia entre cada canal vocal y el de señalización correspondiente. A este método de lo llama Señalización por Canal Asociado, con sigla en ingles CAS. Otro tipo es la denominada Señalización por Canal Común CCS, donde el más usado es el SS7. Las principales características que identifican a la señalización CCS frente a CAS son: -Tiempo de conexión menor; -Número de mensajes prácticamente ilimitados; -Flexibilidad para nuevos servicios; -Encaminamiento alternativo y -Corrección de errores mediante retransmisión de tramas. La capacidad de un canal de señalización SS7 llega a más de 1500 llamadas telefónicas simultáneas. El SS7 se elaboró a partir de 1973 y sufrió modificaciones en los años 80 para manejar los servicios de la fallida Red Digital de Servicios Integrados ISDN. Surgen gracias a la evolución de los centros de conmutación con programa almacenado SPC (Stored Program Control) para circuitos digitales. H.323. Se trata de una familia de protocolos desarrollados durante los años 90 para ofrecer voz y video (señales en tiempo real) sobre redes de paquetes IP. H.323. Es una suite o stack de protocolos, entre los que se encuentran: -el protocolo H.225 que se utiliza para mensajes de control de señalización de llamada y que permiten establecer la conexión y desconexión; -el Q.931 que se utiliza para señalización de llamada en la red IP desde el gateway GW hacia el terminal; Figura 4. Los protocolos utilizados en la red de iplan son: SS7 para la interconexión con la red de telefonía PSTN, el MFCR2 para los clientes con PABX en tramas E1 (transporte SDH) y H.323 dentro de la red de Telefonía-IP. 8

25 Monografías 2 (2003) Tecnología COSO -el RAS utilizado para la comunicación entre el terminal y gatekeeper GK. Sirve para la registración, el control de admisión, el control de ancho de banda, el estado y la desconexión; -el H.245 es utilizado para comandos generales, para indicaciones, el control de flujo, la gestión de canales lógicos, etc y -el protocolo H.235 es utilizado para el agregado de servicios de seguridad, como ser la autentificación y la privacidad Protocolos asociados a SS7. El SS7 es una familia de protocolos. Los protocolos forman una sopa de letras, muchas veces difíciles de recordar. Vemos a continuación los protocolos más importantes relacionados con SS7. Un paquete de SS7 puede describirse con los siguientes protocolos fundamentales. MTP-1 (Parte de Transferencia de Mensaje). No es un protocolo propiamente dicho (no incluye software). Define las funciones de conexión física entre módulos a interconectar. Se trata de un trayecto de transmisión bidireccional compuesto de dos canales de datos para la transmisión dúplex. La velocidad de transmisión típica es de 64 kbps. En MTP-1 se definen las características físicas, eléctricas y funcionales del enlace. En un sistema basado en tramas E1, el canal de señalización es un canal de datos que ocupa algún intervalo de tiempo de los 31 disponibles (típicamente el TS16) en la trama. Como un solo canal de 64 kbps puede llevar el diálogo de señalización de cerca de 1500 canales telefónicos, solo algunas tramas E1 de la Interconexión tienen enlaces de señalización (conocidos como link de señalización SS7) y el resto tendrán disponible el TS16 para un canal vocal adicional. Mas adelante, encontraremos una cara distinta al MTP-1 cuando nos adentremos en una solución ad-hoc para la red de transporte IP. MTP-2. Este sí es un protocolo de comunicación. Ocupa un total de 7 Bytes (de 8 bits cada uno), con 4 Bytes al inicio del paquete y 3 Bytes al final del mismo (un total 64 bits). -Dos de los 7 Bytes se utilizan para reconocer el alineamiento del paquete. Se utiliza un Byte fijo en la secuencia (denominado Flag) y colocado al inicio y final del paquete. -Un Byte indica la longitud total del mensaje transmitido (ya que el paquete tiene una longitud variable, de acuerdo con el mensaje del protocolo ISUP). -Dos Bytes se utilizan para la detección de errores (conocido como Chequeo de Redundancia Cíclica CRC-16) en la recepción. -Un Byte corresponde al proceso de numeración secuencial de los mensajes transmitidos. Se utilizan 7 bits y permite una numeración cíclica desde 0 a Un Byte se usa indicar la confirmación o rechazo del mensaje recibido. Para ello, se toma como referencia la secuencia de chequeo de errores CRC-16. De esta forma es posible la retransmisión automática de mensajes cuando estos se reciben con errores. Se disponen de dos métodos de retransmisión: -mediante el acuse de recibo de un mensaje errado y -la retransmisión cíclica preventiva. En este último caso, cuando no existen nuevos campos de información ISUP a transmitir, se procede a retransmitir toda la cola de mensajes en memoria que aún no han sido confirmados. MTP-3. Este protocolo utiliza 5 Bytes. Un Byte se usa como dirección SIO que permite identificar al protocolo de mensajes (en el caso de Argentina es ISUP). En la red PSTN se disponen de direcciones que identifican a la central de conmutación de origen de la llamada (OPC) y a la central de destino de la llamada DPC. Estas direcciones se identifican con un número decimal resultante de 14 bits de dirección. Por otro lado, las centrales de conmutación se conectan mediante enlaces de señalización (Links de SS7), pudiendo existir varios links (cada uno de 64 kbps). El MTP-3 utiliza 4 bits para identificar el Link-SS7. Con esto se obtienen 5 Bytes (40 bits) definidos en MTP-3. Con la información DPC y OPC se realiza la función de Routing dentro de la red de señalización SS7 (esta función enruta el mensaje de señalización entre las centrales de los extremos de la comunicación telefónica). ISUP (Parte de Usuario ISDN). Este protocolo tiene una longitud de Bytes variable y corresponde al mensaje de señalización propiamente dicho. Se disponen de 3 tipos de unidades de datos: -Unidad de datos de relleno (cuando no existen mensajes para transmitir), -Unidad de datos de estado (para la supervisión del enlace SS7) y -Unidad de señalización ISUP (con un mensaje de señalización útil). El Mensaje de Señalización ISUP consiste en una etiqueta normalizada de 4 Bytes, que lleva información para el enrutamiento, seguido del mensaje del usuario. Algunos tipos de mensajes de usuario son: -IAM, que contiene la información inicial de llamada para el encaminamiento (se trata de los primeros dígitos discados, los cuales son suficientes para interpretar hacia donde va la llamada). -SAM, que transporta las cifras no enviadas en el mensaje IAM. -ACM, que indica que se ha obtenido el acceso al destino (retorno de llamada). -ANM, que indica que el usuario llamado ha respondido (inicio de la comunicación verbal). -BLO, que permite el bloqueo del canal útil. -UBL, que permite el desbloqueo del canal. -REL, que permite iniciar la liberación del canal. -RLC, que informa que la liberación ha sido completada. Normalmente, las redes de transporte para telefonía multiplexan las tramas E1 en equipos SDH. En este caso, el 9

26 Monografías 2 (2003) Tecnología COSO transporte del Link-SS7 (los 64 kbps entre centrales de conmutación) se realiza de acuerdo con MTP-1. Sin embargo, en la redes IP de próxima generación (como la implementada por iplan) no existe un transporte de tramas E1 entre las centrales de conmutación instaladas en Buenos Aires, Rosario y Córdoba. Esto obliga a transportar el Link-SS7 entre las centrales dentro del protocolo IP. En la Figura 5 puede observarse la forma de transportar el Link-SS7 (protocolos MTP-2, MTP-3 y ISUP) en la parte de la red con E1 (con MTP-1) y en una red IP (con el protocolo TCCS). En la Figura 6 se muestra la configuración usada hasta diciembre-2002 (a la izquierda). Se utiliza una funcionalidad de Cisco denominada TCCS sobre equipos En estos, se transporta el conjunto de Bytes del Link SS7, incluyendo las banderas de separación de tramas, los rellenos y la información útil. Este método utiliza aproximadamente 80 Kbps permanentemente para transportar el Link SS7 (64 Kbps del Link más un encabezado del protocolo TCCS) Solución tecnológica ss7fwd Los problemas derivados de la metodología descripta más arriba son -el Delay (retardo fijo en la transmisión) y -el Jitter (retardo variable debido a que los paquetes del TCCS compiten con los otros paquetes de datos). Una ínfima variación del retardo produce el desenganche del canal TCCS y la caída del Link-SS7 con pérdida de las llamadas en vías de establecimiento. El mantenimiento de los equipos involucrados también producen el desenganche y caída del Link-SS7. Durante las horas pico de utilización de los enlaces interurbanos, los Links-SS7 pueden sufrir inconvenientes regulares, aún cuando el ancho de banda disponible sea mucho mayor al requerido. Para corregir los problemas derivados del transporte del Link-SS7 en la red IP mediante TCCS, se planeó la solución de la derecha en la Figura 6. Se utiliza el conjunto de protocolos RUDP, Session Manager y BackHaul Signaling (propietarios de Cisco para el SC2200), conocidos como SLT y disponibles en los equipos Cisco El SC2200 son servers que manejan la señalización SS7 y H.323. Esto permite transportar por IP sólo la información útil del Link de señalización SS7. Estos protocolos son insensibles al Delay y Jitter, utilizando sólo el ancho de banda necesario para el transporte de la información de señalización de llamada. Figura 5. El transporte de los mensajes de señalización ISUP se realiza mediante el protocolo MTP-1 (el Time Slot 16 de la trama E1). En la red de Telefonía-IP de iplan se utilizó inicialmente la solución con protocolo TCCS. Algunas ventajas: -Es insensible al Delay y Jitter. -El ancho de banda es utilizado cuando se debe mandar señalización de llamada extremo a extremo. -Se utilizan protocolos desarrollados específicamente para la aplicación, siendo una de sus características principales la robustez. -Por no transportar la bandera de MTP-2 ni mensajes de relleno, el ancho de banda requerido es mucho menor y por demanda, de acuerdo con la información útil. Figura 6. La versión de transporte hasta el año 2002 fue mediante el protocolo TCCS. La solución diseñada mediante la tecnología ss7fwd recurre al protocolo RUDP 10

27 Monografías 2 (2003) Tecnología COSO El SLT corre sobre equipos Cisco-2600 y tiene requerimientos de hardware menores que en la solución TCCS. El SLT se encuentra funcionando en la implementación de SC2200 de iplan desde fines del año 2000, demostrando gran solidez y estabilidad de funcionamiento. Una desventaja es que a diferencia del protocolo TCCS, de implementación peer-to-peer (entre pares), los protocolos RUDP, Session Manager y BackHaul Signaling son protocolos del tipo Cliente-Servidor, desarrollados por Cisco específicamente para la solución SC2200. Requieren entonces un servidor que inicie el diálogo. El Servidor debe soportar los protocolos de modo de levantar los Links IP entre el Servidor y el SLT Local y entre el Servidor y el SLT Remoto. Esto implica la introducción de un nuevo equipo en la red. La implementación práctica se realiza mediante routers Cisco-2600 con SLT y un Servidor. El Servidor es una aplicación que levanta los Links IP entre el Servidor y los SLT, y reenvía los mensajes de señalización ISUP de llamada de un SLT a otro, en forma transparente. La aplicación del Servidor, denominada ss7fwd y desarrollada por iplan, está escrita en lenguaje C corriendo sobre un servidor Intel con Sistema Operativo Linux Red Hat. En una versión Demo la aplicación fue desarrollada en VisualBasic corriendo sobre Sistema Operativo Windows Los requerimientos del servidor Intel son mínimos, ya que la aplicación carga muy poco a la CPU. Por el bajo costo del servidor, sumado a una aplicación desarrollada in-house corriendo sobre un Sistema Operativo free, la redundancia se obtiene duplicando el sistema. Los costos más importantes en la redundancia son las necesidades de duplicación del SLT. La aplicación ss7fwd está basada en tecnología ss7coso, representando una solución optimizada para el transporte de links de señalización SS7 sobre una red IP. Da robustez y seguridad a la señalización, con costos menores a la solución anterior, la cual era problemática, poco confiable e ineficiente. El desarrollo in-house redujo los costos de implementación y de ownership y amplía la base de conocimientos interna. Permite inmediatas intervenciones en caso de fallos o problemas de software y desarrollos futuros en el caso de que Cisco porte sus aplicaciones a protocolos abiertos standard (conjunto de protocolos Sigtran del IETF). 6- SOLUCIÓN TECNOLÓGICA: EL MANEJO DE STP 6.1- Delimitación del problema Se entiende por STP al Punto de Transferencia de Señalización entre dos redes de telefonía. Cuando se dispone de la funcionalidad STP, un solo punto (o dos por razones de redundancia) puede llegar a administrar toda la señalización SS7 de Interconexión ITX con otros operadores. Cuando iplan desplegó la red de telefonía, colocó centrales NEC que no disponían de la funcionalidad STP. Entonces, cada nueva ITX con un operador que involucre más de un centro de conmutación, debe realizarse con nuevos enlaces de señalización Link-SS7. Tal es el caso de los operadores Telefónica y Telecom. Gestionar nuevos Links-SS7 con estos operadores genera desconfianza y costos adicionales. Comprar un STP comercial, implica un costo elevado, en una coyuntura donde las inversiones se orientan basadas en estrictas consideraciones económicas de repago. Un STP comercial proporciona además, muchas funcionalidades superfluas y una capacidad de procesamiento de llamadas innecesaria para la topología de red de iplan. Figura 7. Sin las funcionalidades STP en la red de iplan, cada central de conmutación (Buenos Aires, Rosario y Córdoba), así como el procesador de señalización SC2200 para la red de Telefonía-IP, requieren de conexiones directas con los STP de Telefónica y Telecom (en forma duplicada). 11

28 Monografías 2 (2003) Tecnología COSO Figura 8. Con la funcionalidad IP-STP los Links de señalización mirarán a las Telco desde servidores duplicados. Estos distribuirán la señalización en el interior de iplan mediante enlaces IP con tecnología ss7fwd. Por otro lado, se requiere el transporte de los links de señalización a las centrales del interior sobre la red IP interurbana, y la integración con el procesador de señalización SC2200 para la red de Telefonía-IP. Ningún STP comercial brinda estas funcionalidades que son obligatorias para la topología de una red de Telefonía-IP. Desde el startup de la red de iplan en el año 2000, la interconexión ITX con los operadores se realizó mediante enlaces de señalización ss7-isup. Esto para dar cumplimiento a los preceptos del Plan Fundamental de Señalización de la CNC. Siendo SS7 el medio de ITX óptimo para asegurar calidad en las comunicaciones. Cada nueva ITX requiere de al menos un link de señalización para las ITX denominadas estrechas (como AT&T, TechTel, Comsat, CTI, Impsat, etc.) y de dos links para las ITX denominadas amplias (como Telefónica, Telecom) Este último caso también se aplica a la red interna de Telefonía-IP, conocida como VoIP (Voice-over- IP). Estos links se materializan con placas de hardware en la central de conmutación y con equipos SLT en el equipo Cisco-SC2200. Posteriormente, la ITX en otras ciudades requieren links de señalización en las centrales del interior. Con la nueva topología IP-STP, es posible conectarse a Telefónica y Telecom mirando desde Servidores duplicados (Figura 8 y 9). La red interna de iplan se encarga de las interconexiones con las centrales de conmutación y el SC2200. Gracias a la red IP redundante de iplan de bajo Retardo y mínimo Jitter, el conexionado de links en el interior, puede ser transportado al IP-STP por la red IP sin consumo de enlaces TDM (tramas E1) y con mínimo requerimiento de ancho de banda (típicamente 3 Kbps por link). De esta forma solo dos servidores se mostrarán como frente de señalización para los distintos operadores de telefonía Hardware y protocolos utilizados La implementación del IP-STP se realiza sobre servidores Intel con Sistema Operativo Linux Red Hat. La aplicación es escrita en lenguaje C. La redundancia se obtiene duplicando la plataforma, funcionando en modo Activo- Activo. La topología es compatible con la red de SS7 de las Telco. Los requerimientos del SLT son menores que en la topología actual, donde tenemos SLTs para los links transportados por el ss7fwd, y links para el SC2200. Los SLTs que traen los Links de señalización desde la PSTN son equipos Cisco-2651 para asegurar la performance bajo carga. Los SLTs de bajada de los Links a las centrales pueden ser de menor escala (equipos Cisco- 2611). El SC2200 señaliza a las centrales de iplan vía el IP- STP, con lo que los requerimientos de cantidad de SLTs son menores que los configurados en la versión de red anterior. Este IP-STP deberá funcionar en dos formas, una similar al ss7fwd donde el mensaje es extractado por un SLT y bajado en la locación remota por otro SLT, y otra, simulando al SLT para el SC2200. Mediante la utilización del conjunto de protocolos RUDP, Session Manager y BackHaul Signaling (propietarios de Cisco para el SC2200), y disponibles en el IOS de los equipos SLT de Cisco, se transporta por IP solo la información útil del link de señalización. Estos protocolos ya están siendo utilizados por las aplicaciones desarrolladas por iplan conocidas como ss7coso y ss7fwd. El desarrollo IP-STP, implementa las funcionalidades de STP sin abrir el contenido del mensaje ISUP. El ruteo de mensajes SS7 al switch de destino se basa en el Código de Punto de Destino DPC que está contenido en el Routing Label del mensaje SS7 y en la dirección IP de destino del SLT, que baja el link a la central correspondiente. Cada IP- STP debe tener un punto de señalización donde terminan los mensajes de MTP2 y MTP3 de mantenimiento. 12

29 Monografías 2 (2003) Tecnología COSO Figura 9. Esquema general de interconexión con Telecom. Desde las tramas E1 que interconectan la central de Buenos Aires con la Central de Telecom en Belgrano CTU, se extrae el link de señalización mediante equipos SLT redundantes. Detrás de la CTU de Telecom se encuentran los STP de Telecom en Belgrano y Munro. Los servers IP-STP redundantes interactuarán con el SC2200 para la red de Telefonía-IP y con las tres centrales de conmutación. Hacia las ciudades de Rosario y Córdoba el transporte se realiza mediante ss7fwd Funcionamiento El link de señalización es extractado de la trama E1 que interconectan la central de Buenos Aires con la PSTN y es enviado al IP-STP. El IP-STP reenvía el mensaje de señalización en función de la dirección DPC, que viene en el mensaje (identificando a la central), al SLT correspondiente a la entrada de la central de conmutación. El SLT de destino del mensaje sube éste al link TDM y lo entrega a la central. Para el caso de comunicarse con el SC2200, el IP-STP debe ser visto por el SC2200 como si fueran los SLTs que actualmente tiene conectados. Esto implica que el stack de protocolos RUDP, Session Manager y BackHaul Signaling en el IP-STP debe ser simulado completamente tal como en una configuración redundante de SC2200. Por el IP-STP pasarán todas las llamadas cuya ITX pase por el STP, pudiendo éste ser una fuente de CDR adicional. Como el desarrollo es in-house, los CDR podrán volcar toda la información de la llamada y ser customizables a los requerimientos del área de Sistemas. Igualmente, tal como el ss7coso y ss7fwd, se integraría naturalmente a la plataforma de monitoreo mediante traps SNMP. El IP-STP recibirá los links de señalización desde la PSTN. Esto implica que este equipo va a estar directamente interconectado a ellas. A fin de ser introducido a la red de señalización nacional, el IP-STP debe ser homologado por la CNC y por las Telco (Telefónica y Telecom, principalmente). Los procedimientos de homologación en las Telco implican la instalación del equipo en sus Maquetas y la prosecución de un conjunto de pruebas que certifiquen el funcionamiento adecuado como para ser introducido en la red de ellos. Luego de obtenida la homologación, la interconexión sería inmediata. La interconexión del IP-STP sólo sería necesaria inicialmente con Telecom, con quien iplan tiene ITX directa al SC2200. Luego de estar en servicio, se debe homologar con Telefónica para la puesta en servicio posterior con esta Telco. 7- EL FUTURO DE COSO COSO ha sido una de las tecnologías desarrollada en iplan que más productos y soluciones tecnológicas ha dado a inicios del Un caso similar ha sido la plataforma de Calling Card a mediados del La plataforma COSO tiene varios desafíos a futuro El servicio de Calling Card iplan dispone de una plataforma de Servicios Prepago (la versión más conocida es la Calling Card). La evolución de la misma se muestra en la Figura 10. Una monografía de Journal se ocupa de las plataformas de servicios prepagos. 13

30 Monografías 2 (2003) Tecnología COSO Figura 10. Se muestran los tres estadios de la Plataforma de Calling Card. El primero fue el utilizado a inicios del 2002 mediante un Contrato de Revenue Sharing con el propietario de la Plataforma. Se trataban de tramas E1 conectadas al servidor. Desde mediados del 2002 se puso en servicio la plataforma de Calling Card diseñada en iplan. Utiliza equipos Cisco-5300 para la funcionalidad de IVR. Con la integración de la plataforma de Calling Card a COSO se obtienen variadas ventajas, la misma debe encontrarse operativa hacia fines del La integración del servicio prepago en COSO tiene alguna ventaja adicional. COSO hace la primera validación por origen (black list, categoría, horario, etc). Se mantiene la utilización del IVR de los Cisco-5300 (como en la versión de la plataforma en la red IP), de forma que la llamada primero es enrutada al 5300, quien se encarga de colectar los PIN y solicitar la validación al servidor Radius. Una vez realizada las validaciones, el IVR libera la llamada y COSO se encarga de re-discar al destino. El canal vocal del 5300 se libera quedando disponible para otra llamada. COSO se encarga de controlar el tiempo de llamada disponible y de generar el CDR respectivo. Este sistema podría permitir la integración entre la base de datos de la Calling Card, y la aplicación para un mejor procesamiento y capacidad sin gastos adicionales. Se utiliza el IVR del Cisco AS-5300 para pre-atender al usuario y recolectar los datos en el mismo modo que lo hace en la versión intermedia. Pero se optimiza el uso del 5300 ya que una vez validados el PIN y el número de destino, el canal vocal hacia el 5300 se libera quedando disponible para una nueva llamada. Se integrarán los datos de señalización y aquellos ingresados por el usuario (podrán integrarse parámetros y otras características tales como categoría del origen y Black/White Lists, no disponible hoy en la plataforma de Calling Card). Todas las instancias de llamada podrán generar los dos CDR que se utilizan para facturar este tipo de servicio. Estos CDR contiene la información referida a las dos instancias de llamada de Calling Card. En cuanto a la ruta, COSO podría indicar un nombre de ruta especial por cada cliente Calling Card, aunque la llamada salga por un canal del mismo loopback que utilizan el resto de los servicios Restricción CLIR-REC La restricción de presentación de Número por Llamada (CLIR-REQ) es un servicio que normalmente carece de interés comercial. Sin embargo, es requerido regulatoriamente por la CNC. Mediante esta facilidad, el usuario antecede un código (31) al número marcado y el usuario de destino recibe la indicación privado en su caller ID. La provisión de este servicio será posible mediante una nueva funcionalidad de COSO. Con COSO, todas las llamadas cuyo número de destino comience con 31 serán enrutadas a la plataforma, la que además de re-enrutar la llamada eliminando este código, modificará el valor del parámetro de presentación en el mensaje ISUP (IAM). La plataforma generará un único CDR eliminando el código 31 en el campo número llamado Centro de atención al cliente: el itac El iplantac es el Servicio de Asistencia Técnica que ha implementado la Gerencia de Desarrollo de Tecnología de iplan. Esta Gerencia ha sido creada en marzo del 2003 para centralizar los desarrollos, que con anterioridad se realizaban en diferentes áreas. Este servicio funciona tanto para los clientes internos (NOC, Sistemas e Ingeniería) como para clientes externos. Los servicios que se ofrecen son: -Soporte para diagnóstico de fallas complejas, -Registración y solución de Bugs, -Solicitud de información y -Servicios Profesionales. El funcionamiento es 7x24, de forma que el ingreso de un Caso en el itac genera un y llamadas a los celulares del personal de guardia. 14

31 Monografías 2 (2003) Tecnología COSO Figura 11. Se muestra la pantalla típica del itac para el ingreso de Casos. El mail anexo reporta el ingreso del primer caso con un bug el 26 de marzo de En el Release 1 (operativo desde marzo-2003) se pueden efectuar las siguientes acciones: -Apertura de casos, -Verificar el histórico de casos, -Ver el Esquema de Guardias por tecnología, -Seguir la Reasignación y Reapertura de casos y -Hacer el manejo de perfiles de usuarios. Con el Release 2 se puede: -Acceder a la información de Bugs y asociación a Casos, -Verificar la medición de tiempos de respuesta, -Hacer Up-load de Archivos y -Obtener reportes estadísticos. Los Casos se abren con 4 tipos de prioridades: -Prioridad 4: Información o ayuda de capacidades, instalación, o la configuración de productos desarrollados por iplan; se trabaja sin compromiso de tiempo de respuesta. Genera mensajes a celulares solo de 9 a 18 hs. -Prioridad 3: Red o servicio degradado. Los recursos son durante horas de oficina normales con mensajes a celulares en el momento de la apertura y notificaciones de 9 a 18 hs. -Prioridad 2: Red o servicio degradado seriamente. Con recursos a tiempo completo se generan mensajes a celulares en el momento de la apertura y los updates son del tipo 7x24. -Prioridad 1: Red o servicio crítico caído. Utiliza todos los recursos necesarios las 24hs del día. Se generan mensajes a celulares en el momento de la apertura y los updates son 7x COSO en otras empresas iplan mantiene una política de colaboración abierta con otras empresas y con nuevos emprendimientos. Mantiene, por otro lado, lazos activos con Universidades para el estudio de temas relacionados con las tecnologías IP. Esto hace que las tecnologías de iplan se estén utilizando en otras empresas como plataformas de servicios y tecnología. Mucha de esta información permanece Confidencial y podrán ser conocidas de acuerdo con las condiciones contractuales. Figura 12. Folleto de campaña de ventas del servicio 0800 para clientes de iplan en julio-2003, soportado en COSO. 15

32 MONOGRAFIAS DE J: Journal monografías número 2. Edición julio Diseño gráfico original de Marianela V. Ricardo 16

33 monografía iplantech Journal Monografías es una publicación de iplan que contiene información técnica y confidencial de la empresa. Se distribuye a un circuito limitado de lectores a fin de mantenerlos informados sobre el estado y la evolución de la tecnología y el negocio de la Telecomunicaciones, principalmente en las redes IP y la Telefonía-IP. Se ruega a los lectores a mantener el principio de Confidencialidad sobre la información aquí contenida. No está autorizada su reproducción o distribución por cualquier medio sin antes consultar con la empresa. ISoftphone: Tecnología y Productos Un desarrollo que solo es posible después de varios años de aprendizaje en la disciplina de la Telefonía-IP. IINDICE 1- Antecedentes 2- Funcionamiento 3- Interfaz de Usuario 4- El producto Arraiga 5- Locutorios IP (IPGol) 6- Hipótesis sobre el futuro IABSTRACT La tecnología Softphone ha sido desarrollada en iplan, en colaboración con bit2net. Ella, es una fuente de ideas y ha originado distintas soluciones tecnológicas y productos. Los límites de esta tecnología aun no están definidos y parecen ser ciertamente indeterminados. En la línea de máxima, puede pensarse que en el futuro el protocolo IP podrá abastecer los Servicios Integrados (telefonía y datos). Esta hipótesis ya había sido ensayada a inicios de los años 80 con la red ISDN (hoy claramente malograda). En este número de Journal nos ocupamos del funcionamiento técnico y del producto Arraiga, así como de sus variantes. Otras aplicaciones, como ser la Telefonía Pública para Locutorios y Cyber, solo es introducida ya que será tratada en una monografía próxima. IAUTORES El presente trabajo ha sido redactado sobre documentos originales de Mariano Tomalino y Diego Frick (bit2net). Otra documentación se basa en la generada por las áreas de Ventas, Sistemas y Marketing por los aportes al producto Arraiga y al área de Sistemas en el diseño de la plataforma de E-commerce. 1

34 Monografías 3 (2003) Softphone: Tecnología y Productos 1- ANTECEDENTES El softphone es una Tecnología desarrollada en conjunto por iplan y bit2net y que ha dado lugar a una larga serie de productos y servicios. El inicio de este proyecto se remonta a septiembre-2002, cuando se encaró el primer desarrollo de un Gateway denominado Pack-1. Se trataba de un proyecto semestral para obtener un hardware que permitiera ofrecer servicios de Telefonía-IP e Internet desde un mismo CPE. Con posterioridad este proyecto se suspendió por razones de economía de escala y de capacidad de procesamiento del chip seleccionado (no permitía el uso de codificación G.729 necesario para utilizar el CPE en la Internet). Sin embargo, el emprendimiento conjunto entregó como resultado varios subproductos, algunos de los cuales son tratados en este trabajo. El Softphone es solo uno de ellos. Se entiende por Softphone a un gateway software que corre sobre una PC y que con codec G.729 que permite el funcionamiento desde la Internet. En enero-2003 ya existían usuarios beta-test que utilizaban el Softphone en varios países del mundo. El ídolo de Rugby, número 10 de Los Pumas, Contepomi, conversaba con sus amigos en Buenos Aires utilizando un la versión Beta del Softphone. El primer producto comercialmente disponible se llevó hasta julio-2003, debido a la complejidad de resolución de la plataforma de E-commerce y las negociaciones con las Tarjetas de Crédito. El softphone es solo uno de los desarrollos tecnológicos encarados en iplan y que son tratados en varias de las monografías de Journal. Los componentes involucrados en esta tecnología se muestran en la Figura 1. (1) Una Granja de servidores para los servicios de Radius, Web y Base de Datos. (2) Un gatekeeper GK para la registración de los softphone. (3)-(4) Los usuarios, como ser los Locutorios-IP (comercialmente IPGol) y los clientes particulares de Softphone ubicados en la Internet. (5) Un gateway IP-IP que actúa de interfaz entre la red IP de iplan y la Internet. (6)-(7) Eventualmente se requerirá la intervención del softswitch y de COSO para ofrecer otros servicios de valor agregado no soportados en Softphone. Como se observa en la Figura 1, los Usuarios de la tecnología Softphone se encuentran en la Internet. Su ubicación es desconocida en principio y la forma de acceso a Internet es responsabilidad del Usuario. Podría utilizar ADSL, cablemodem, wireless o dial-up. Siendo que el Softphone en su primera versión trabaja en protocolo H.323 se requiere una dirección IP pública (no requiere que sea fija) y por ello se tienen diferentes inconvenientes para trabajar detrás de un Firewall. Si se encuentra detrás del Firewall, éste debe ser configurado para que permita el paso de los paquetes H.323. El Softphone puede funcionar en cualquier lugar de la Internet ya que en el proceso de conexión inicial envía su dirección IP (pública) y a partir de ese momento se registra en la base de datos. El mecanismo de seguridad para el acceso al servicio es mediante un nombre de Usuario y Password. El Softphone ha generado diferentes alternativas de productos, entre otros encontramos: -Arraiga: El softphone vendido mediante E-commerce. -Softphone Revendedor: Una plataforma para vender en forma mayorista este servicio. -Línea softphone: líneas analógicas post-pago con acceso mediante Internet. -Locutorios-IP (comercialmente IPGol). Son locutorios conectados mediante un acceso de Internet y que terminan en la red pública PSTN en iplan. -VPN entre distintas localizaciones del mismo cliente. Figura 1. Diagrama a bloques general de los componentes en la tecnología Softphone. 2

35 Monografías 3 (2003) Softphone: Tecnología y Productos 2- FUNCIONAMIENTO 2.1- Componentes del Sistema. Para proveer los servicios de Softphone se estructuran dos etapas de topología (representadas en la Figura 2). En una primer etapa se dedica un Gateway-E1 (Cisco-2600) hacia el mundo PSTN. En la segunda etapa se introducirá un Gateway IP-IP (la descripción se encuentra en un número de Journal futuro). En este caso el gateway hacia la PSTN es una granja de Cisco Los componentes son -Software en la PC del usuario (Gateway soft en Internet), -Gatekeeper, -Gateway-E1 (Cisco-2600 o 5300) y -Plataforma de Softphone (granja de Servers) El Software en la PC del usuario. Es una pieza de software que corre en la PC del usuario. Para comenzar a utilizarlo es necesario previamente instalarlo, para lo cual se provee del instalador que genera todas las carpetas y archivos que permiten la ejecución del software Softphone propiamente dicho. En los ítem 3.1 y 3.2 de este Journal se indican las generalidades de la instalación y uso de la versión de software disponible a mediados del Referido a los Requerimientos Mínimos de Hardware en la PC del cliente se recomienda un procesador Pentium de 300 MHz o superior. Una Memoria RAM igual o mayor a 64 MBytes (esto depende de las demás aplicaciones que utilice el usuario). Un disco rígido con al menos 10 MBytes de espacio disponible. La PC debe contar con sistema Multimedia (parlantes o auriculares y micrófono) y con puerto USB, en caso que el usuario opte por utilizar el adaptador telefónico desde USB a RJ11. Este último adaptador es un semi-standard en el mercado, existiendo de diferentes tipos y formas. El Softphone se encuentra disponible para ser usado sobre el Sistema Operativo Windows 98, Windows 2000 Profesional, Windows 2000 Server y Windows XP. Se espera trabajar en el futuro sobre Linux El Gatekeeper GK. Tiene la funcionalidad de dar servicios de registración de todos los softphones y el ruteo de llamadas utilizando el protocolo H.323. El modo de este Gatekeeper es no ruteado El Gateway GW. Este componente conecta la nube IP con la PSTN (en iplan es a través de la central de conmutación NEC). Trabaja inicialmente con E1 en señalización MFCR2. Figura 2. Diagrama a bloques general de los componentes para Softphone. 3

36 Monografías 3 (2003) Softphone: Tecnología y Productos Granja de Servers. La granja de Servers que componen la Plataforma de Softphone son los siguientes: 1- Web Server (server https): realiza las funciones de Login y Logout de usuarios (validación mediante nombre de usuario y password encriptadas) y las funciones de plataforma de administración de clientes y usuarios. Permite el ABM de usuarios (Altas, Bajas y Modificaciones). Sirve para monitoria y control; consulta de llamadas y conexiones; traducción numérica y servicios de valor agregado (por ejemplo VPN entre localizaciones del mismo cliente). 2- Server de Radius (Billing): permite dar servicios de Autenticación, Autorización y Registración de todas las llamadas realizadas por los softphone hacia la Red de Telefonía Pública PSTN. Permite la validación de llamadas, límite de crédito y generación de CDRs. Trabaja con el Server de Base de Datos para la memorización de la información. Mediante Radius se comunica con los Gateway- E1 quienes hacen la temporización de la llamada. 3- Server de Base de Datos: contiene toda la información relevante de cada usuario. Son Servers redundantes en la granja. 4-Un equipo ArrowPoint permite el balanceo de carga y varios Firewall segurizan el área de Servers Funcionamiento. El funcionamiento será explicado mediante la Figura 3. Se observa el procedimiento de Login-Registración cuando se activa el programa de software en la PC. También se muestra el procedimiento de cierre del programa, mediante el Logout-Desregistración. Entre ambos grupos de comandos el Softphone se encuentra activo para generar y recibir llamadas. Se indica el procedimiento para iniciar y cerrar una llamada y la forma en que se contabiliza el tiempo de llamada. Entre ambos procesos, el canal se encuentra con una llamada en curso. Durante este proceso se generan los tickets denominados CDRs y se descuenta el valor de la llamada de la cuenta del Usuario (en el caso de los servicios pre-pagos) Mensaje de Login (1). El mensaje Login es el primer bloque de paquetes. Cuando el Softphone se ejecuta (haciendo doble clic en el ícono correspondiente), se carga el nombre de Usuario y Password. Se genera entonces un mensaje utilizando el protocolo https. Este programa de comunicación está escrito en PHP. Este mensaje inicia una consulta en la Base de Datos utilizando los siguientes parámetros: -Username (por ejemplo, usuariofeliz ), -Password (por ejemplo, muyfeliz ), -Versión (por ejemplo, 1,0,0,1 ) y -Estado (por ejemplo, on ). Las tareas que se realizan con este paquete son dos (una vez recibidos dichos parámetros): -La consulta a la Base de Datos para asegurar la existencia del Usuario que requiere comenzar a utilizar el servicio y -La respuesta hacia el Softphone dependiendo que el Usuario y Password sean correctos y el servicio esté habilitado. La Respuesta al Softphone contiene las siguientes informaciones: -e_164: El parámetro e_164 indica cual es la numeración telefónica que debe registrar el softphone en el GK. (por ejemplo, ). -h323_id: Con este parámetro se le indica al Softphone cual es la identificación h323_id que debe utilizar para registrase en el GK (por ejemplo, iplan_ ). -Mensaje: Este parámetro es un texto que se presenta en pantalla antes de que el Softphone se registre en el GK. -Clave: Es un valor aleatorio y único en el tiempo que se genera en cada Login y que se utiliza en cada llamada. -Versión: Es el número de versión de software de usuario que esta en uso. -IP_GK: Es la dirección IP del GK en el cual se debe registrar el softphone (por ejemplo, ). -Port_GK: Es el puerto de RAS del GK, el cual se debe utilizar en la registración (por ejemplo, 1719 ). -Nombre_GK: Es el nombre del GK en el cual se debe registrar (por ejemplo, 3640GK ). -Translate: Este parámetro le indica al softphone la tabla de translación de numeración. Del lado derecho de la coma se ubica el prefijo discado por el usuario y del lado izquierdo cual es el reemplazo de dicho prefijo. Si del lado derecho de la coma existe la palabra reject significa que el usuario no podrá hacer llamadas a numeración que comience con el prefijo de esa translación. En los casos que corresponda se genera un mensaje de Usuario y Password incorrectos o de servicio deshabilitado, el cual se reporta en la pantalla del Softphone como mensaje de error Mensaje de Registración (2). El Softphone pide la solicitud de Registro en el GK utilizando el protocolo H.323 usando el mensaje Registration Request (RRQ). El GK devuelve una respuesta de aceptación Registration Confirm (RCF) o negación de la registración con Registration Reject (RRJ). Estos pasos se realizan periódicamente, por defecto es cada 60 segundos. Este período puede ser modificado desde el GK. Esta registración periódica permite mantener el contacto entre el GK y el Softphone actualizado. Algo así como una indicación periódica de vida del softphone, para el caso que el Usuario no cierre el programa correctamente o exista un corte del enlace. Para la registración del softphone en el GK se requieren algunos de los parámetros siguientes: -e_164: El formato de este valor es el mismo que se utilizan en la red actual de voz sobre IP en iplan. Siempre comienza con el numero 0 y sigue con la numeración nacional (por ejemplo, ). -h323_id. Este valor es un string que representa el nombre del Softphone dentro del dominio al cual pertenece. Este valor es único dentro del dominio y si algún otro Softphone pretende registrarse con el mismo h323_id, el mensaje de respuesta del GK será un ARJ. El formato de este parámetro es cliente_e164 (por ejemplo, iplan_ ). 4

37 Monografías 3 (2003) Softphone: Tecnología y Productos Figura 3. Intercambio de mensajes entre el cliente Softphone y los Server centrales. 5

38 Monografías 3 (2003) Softphone: Tecnología y Productos Mensaje de Logout (11). Al cerrar la aplicación GW.exe, en la PC del usuario, se genera un mensaje HTTPS hacia el servidor Web. Los parámetros son todos los mismos que en el mensaje de Login, excepto Estado que se encuentra en la condición de off. En este caso se puede recibir dos tipos de mensajes: El cliente ya se encontraba desconectado o el Usuario se desconecta correctamente Desregistración (12). El Softphone se desregistra en el GK utilizando el protocolo H.323 con el mensajes Unregistration Request (URQ). En tanto que el GK devuelve el Unregistration Confirm (UCF) o Unregistration Reject (URJ), según corresponda. Estos pasos se realizan una única vez luego de que el usuario haya decidido cerrar el programa. Para ello, se utilizan los mismos parámetros que para la Registración Comunicación y Valorización (3...10). Veamos ahora el procedimiento para abrir y cerrar una comunicación. Mediante el intercambio de mensajes (3) se procede al pedido de admisión del terminal al GK. El mensaje ARQ (Admissions Request) se responde con la confirmación ACF (Admissions Confirm). Luego, en (4) se pasa al intercambio de mensajes con el Gateway-E1 de interconexión hacia la PSTN. Se trata del Setup y ARQ del este Gateway. A continuación, en (5), el Gateway-E1 procede a dialogar con el Radius para señalar solicitar el permiso correspondiente. Radius consulta con la Base de Datos para conocer el crédito del cliente y responden al Gateway-E1 para que este contabilice el tiempo y corte la llamada cuando se termina el crédito. Cuando el Softphone se utiliza en un ambiente prepago (como el caso del servicio Arraiga descrito más adelante), se calcula el tiempo que el cliente tiene disponible para la comunicación. Esta operación se realiza sobre la base de la información disponible en el server de Data Base. La operación es similar a la utilizada en la Plataforma de Servicios Prepagos como en las Calling Card. Para calcular el tiempo máximo de duración de una llamada originada en un Softphone se definen los siguientes valores: -Saldo: Cantidad de dinero disponible en la cuenta del usuario. -Precio: Valor de la llamada por unidad de medición (en segundos). -Unidad de medición: Cantidad en segundos. -Tiempo Máximo: Cantidad en segundos máximo que podría ser consumido en la comunicación. -Tiempo Máximo efectivo: Es el tiempo máximo en segundos de duración de la llamada (es el valor entero de tiempo inferior al tiempo máximo). En (6) el Gateway-E1 informa que el usuario llamado se encuentra en estado de alerta (tono de llamada para el softphone). Luego, cuando el usuario responde, envía el mensaje Connect al softphone y realiza la apertura del ticket de llamada iniciada en el Radius y la Base de Datos, mediante (7). La llamada continua mediante paquetes en protocolo RTP, transparente a la Plataforma de Softphone y el gatekeeper. Cuando la llamada termina, se disparan los procesos (8) y (9) para el cierre de la llamada. En (10), el Gateway-E1 pide el cierre del ticket de llamada en curso y abre el ticket de llamada completada. Se genera entonces un CDR correspondiente a la llamada con el tiempo total de la misma Configuraciones Gatekeeper. Básicamente el Gatekeeper debe mapear las direcciones IP públicas de los Softphones con la numeración asignada al usuario. Por otro lado, es necesario que todas las llamadas originadas en los Softphones con destino a la PSTN sean ruteadas al Gateway de interconexión. Inicialmente en iplan se colocó un Cisco para esta operación. La configuración de la numeración de las líneas Softphone no es continua. Pueden convivir diferentes servicios en el mismo grupo de numeración. Por ejemplo, los que pertenecen al servicio IPGol junto con Arraiga. Cuando se configura el nombre del gatekeeper GK se utiliza un forma como 3640GK, bajo el dominio iplan.com.ar. Se configura también, la dirección IP privada que identifica al GK detrás de un Firewall PIX. Por otro lado, se indica al GK que cualquier llamada que tenga como destino un numero de abonado B (el llamado) con el prefijo 54, será ruteada al Gateway de Interconexión hacia la PSTN. Además, por default se asigna un valor de time-out de registración de 60 segundos. Esto quiere decir que si no ha llegado un mensaje H.323 RRQ dentro de los 60 segundos, el terminal Softphone se considera Desregistrado. El GK se sincroniza con el server NTP Gateway. La función del Gateway es la de hacer de traductor entre el mundo E1 en la PSTN y la red IP. Además se le ha agregado la tarea de realizar la valorización y el control de la duración de la llamada. En él se configura el servicio AAA para realizar la valorización (aaa accounting) de la llamada y el control de su duración (aaa authorization). En la configuración, se le indica al Gateway que se realice el Accounting en las llamadas de voz sobre IP (gw-accounting aaa), pero que la fuente del accounting sea solo las legs de pots (suppress voip). Se configura además el servicio de RADIUS Servidor WEB-HTTPS. Este servidor es utilizado para los siguientes servicios: -El servicio httpsd es el proceso encargado al servidor Web, por lo que es indispensable que se encuentre en ejecución en todo momento en el servidor para el correcto funcionamiento del Softphone. -El servicio de Página de Administración y Acceso a la Base de Datos contiene los archivos de las páginas PHP del Softphone, así como también las funciones que hacen de interfaz con la base de datos de la aplicación Servidor Radius. El servicio radiusd es el proceso encargado del servidor RADIUS, por lo que es indispensable que se encuentre en ejecución en todo momento. 6

39 Monografías 3 (2003) Softphone: Tecnología y Productos Otras aplicaciones. -La aplicación sp_on_off_test es la encargada de mantener actualizada en memoria la tabla de usuarios registrados, para lo cual realiza una conexión al router. Esta tabla es utilizada posteriormente para actualizar la Base de Datos de la aplicación. Este proceso también se debe encontrar en ejecución permanente para asegurar el correcto funcionamiento de la plataforma. -La aplicación Check-soft-phone es la encargada de verificar el estado de las aplicaciones que componen los servicios para el Softphone y se la puede encontrar en el directorio /usr/local/bin Alarmas. Si alguna de estas aplicaciones se encuentra fuera de las condiciones normales de operación, como por ejemplo alguno de los servicios no esta funcionando o el espacio en disco disponible es menor al 25%, un script se encarga del envío de alarmas mediante Traps SNMP al NMS (El sistema de Management de la red). Estas alarmas se enviarán únicamente ante el cambio de estado (de valores normales a valores anormales y viceversa) de alguno de los servicios mencionados anteriormente y por única vez. Por ejemplo, si se detecta una caída en el servidor https y luego se verifica que el mismo vuelve a levantar, aparecerán en total dos alarmas (una por cada cambio de estado) en el NSM. Es importante destacar que las alarmas aparecerán bajo la solapa con la descripción SPHONE. Esta aplicación se encontrará en funcionamiento continuo, dado que esta configurada para ejecutarse cada 5 minutos en el servidor. -CDR infructuosos. Cuando el Gateway envía algo distinto como causa del Stop de la llamada, los CDRs que estaban en la tabla cdrs_en_curso se acumulan en la tabla cdrs_infructuosos. -CDR de tráfico. Esta tabla guarda los CDRs que se cerraron exitosamente. Entre los datos que contiene, se encuentran los siguientes elementos: -el número de identificación de la llamada generado por el gateway, -la dirección IP del gateway, -los números de abonados A y B (el que llama y el llamado), -los prefijos urbano, interurbano y nacional, -la fecha y hora, -el tiempo de duración de la llamada, -el costo para el usuario final o para el revendedor. 3- INTERFAZ DE USUARIO 3.1- Instalación del software. El Usuario, luego de realizar todos los pasos necesarios para registrarse como cliente del servicio (por ejemplo, en la página accederá a una página web que le permitirá bajar el software Softphone a su PC. Una vez ubicado en la PC, el Usuario debe hacer doble click sobre el archivo de instalación Instalador Teléfono IP Iplanbit2NET.exe utilizando el Explorer de Windows. Un procedimiento simple de auto-instalación guiará al Usuario por una decena de pasos. Las alarmas que la aplicación envía, según los distintos escenarios, son las siguientes: -Alarmas de estado Normal: Estas alarmas se enviarán, y estarán en vigencia cuando el estado de los servicios que componen el Softphone se encuentren dentro de los valores aceptables de operación. Esto es, cuando los servicios de HTTPs, RADIUS y sp_on_off_test se encuentren en funcionamiento y los niveles de ocupación de disco y ocupación del CPU del equipo estén por debajo del 75%. -Alarmas de estado Crítico: Estas alarmas, a diferencia de las anteriores, se enviarán y estarán vigentes cuando se detecte que el estado de los servicios mencionados no sean los normales o aceptados CDR (Call Detail Record). Se ha decido generar 4 tipos de CDR diferentes, para la facturación y seguimiento de las comunicaciones. -CDR de llamada en curso. Se genera en el momento de establecimiento de la llamada en el sentido Softphone a la PSTN. Cuando se corta la comunicación, el Gateway envía un Stop con la causa, del mismo, a la base de datos. De acuerdo al tipo de finalización de llamada que se recibe, se cierran los CDRs guardándolos en diferentes tablas. Los CDRs que quedan abiertos por más de un periodo de tiempo a definir, serán cerrados, borrados y no facturados. -CDR de errores. Se generan cuando se encuentran errores antes de establecer la comunicación. Estos ticket de error permiten obtener estadísticas de llamadas concretadas. En todas las páginas se puede seleccionar: -seguir con la instalación mediante Siguiente, -ir al paso anterior presionando Anterior o -terminar con la instalación mediante Terminar. En una pantalla se le da al Usuario la posibilidad de copiar en una carpeta en el disco rígido los drivers del periférico USB para instalar un teléfono externo a la PC. Una vez terminada la instalación se le indica que se instalará un certificado de autenticación en su PC, y que al finalizar con esta operación se reiniciara la PC, luego de presionar Finalizar. Al presionar instalar certificado se habrán generado los archivos necesarios para ejecutar el Softphone. El adaptador USB permite convertir la interfaz de USB de la PC a una interfaz RJ11 para colocar un teléfono convencional. El software Softphone es el mismo y se puede 7

40 Monografías 3 (2003) Softphone: Tecnología y Productos utilizar en forma indistinta la versión soft en la pantalla o la versión hard con el adaptador. Cuando se instale el adaptador USB, la ubicación de los archivos se localiza en C://Archivos de programas/teléfono IP Iplan-bit2NET/Adaptador Telefónico USB (la ubicación de los archivos puede variar respecto de la versión de Windows). Antes de usar el Hardphone, deberá configurar el Dispositivo de Sonido y Audio y establecer su placa de sonido como predeterminada. En caso que se desee modificar el volumen del Hardphone se accede a grabación de Sonido y se selecciona el dispositivo USB para corregir el volumen. Haciendo doble clic sobre el símbolo en reposo, se desplegará la pantalla de Usuario (indicado como (2) en la Figura 4). Se ingresa luego la clave de Usuario y la contraseña suministrado por su proveedor del servicio. Se podrá optar por la registración automática del Softphone marcando Iniciar Automáticamente. Luego de completar la pantalla de Iniciación del servicio, se está en condiciones de presionar el botón Comenzar. Eventualmente podrían aparecer diferentes mensajes de error (registración fallida, error en el password, usuario ya conectado, problemas en el servicio, etc) Uso del software. Luego de instalar el software de Softphone, en el escritorio y en el menú Inicio, aparecerá un ícono. Es un teléfono en estado de reposo, que se activa cuando se recibe una llamada entrante y cambia de color cuando se está hablando. Se trata de la indicación (1) en la Figura 4. Figura 4. Pantalla de la PC con los elementos básico de Softphone. 8

41 Monografías 3 (2003) Softphone: Tecnología y Productos Desde la pantalla general del Softphone en (2), es posible acceder a otras pantallas desplegables. Una de ellas, permite el discado mediante un teclado. También puede escribirse el número en la pantalla. Otra pantalla permite el acceso a las llamadas recientemente recibidas: Con otra pantalla se accede a una lista de llamadas frecuentes: -Agregar Página: Luego de haber cargado todos los datos del nuevo contacto, presionando este botón se guardará la información del mismo (en caso de que no complete los datos necesarios, le aparecerá un mensaje de error). -Actualizar: Se lo utiliza para actualizar la información de un contacto. Primero debe marcar ese contacto desde el campo de búsqueda para que los datos del mismo le aparezcan en la pantalla. -Eliminar: Elimina un contacto de su agenda. -Discar el teléfono: Desde la agenda se puede realizar una llamada al número telefónico que ingresó en el campo teléfono. Primero debe buscar el contacto al cual desea llamar y luego presionar este botón. -Discar el teléfono laboral: Desde la agenda se puede realizar una llamada al número telefónico que ingresó en el campo teléfono Laboral. -Discar el teléfono celular: Desde la agenda se puede realizar una llamada al número telefónico que ingresó en el campo teléfono celular. -Más Opciones: Se puede especificar la carpeta donde quiere ubicar la base de contactos que crea el Softphone. -Cerrar: Este botón cierra la agenda. En caso de que haya hecho cambios y no los haya guardado, aparecerá un mensaje para confirmar que desea salir sin guardar los cambios. -Observaciones: Cada vez que se desee guardar un número telefónico se debe presionar el signo +. En caso de que se desee borrarlo se presiona el -. Este paso debe realizarse antes de Agregar la página, sino el número telefónico no será guardado. Por último se dispone de una pantalla de Opciones: Por otro lado, es posible acceder a una agenda, indicada como (3) en la Figura 4. Aquí se encuentran los siguientes campos: -Campo de Búsqueda: Se podrá optar por buscar por Nombre, Apellido o Empresa. Los contactos aparecerán ordenados por orden alfabético (en forma de árbol). También tiene la posibilidad de buscar una palabra o varias palabras, donde se podrá aclarar que distinga entre mayúsculas y minúsculas y/o definir que la palabra escrita esta completa o parcialmente escrita. -Vaciar Página: Si quiere agregar un nuevo contacto, con este botón se pone en blanco la página que ocupará este nuevo contacto. -Sonidos PC: Seleccionando esta opción, no se escucharán los sonidos propios del Softphone a través de los parlantes de la PC. -Últimos teléfonos discados: Si desea que se auto complete el número de teléfono, marque la casilla Autocompletar discado. También puede personalizar la cantidad de teléfonos más discados que desea ver al presionar el símbolo numeral (#) junto al display. -Selección IP: Se puede seleccionar la IP con la que desea utilizar el servicio. -Log-In: Se puede modificar el usuario y la contraseña. Esta modificación tendrá efecto cuando reinicie la aplicación. Seleccionando la casilla Recordar usuario y contraseña, el Softphone guarda estos datos. Iniciar automáticamente, hace que el Softphone se registre directamente sin hacer el paso de Log-In. -Versión: Muestra el número de versión del software. 9

42 Monografías 3 (2003) Softphone: Tecnología y Productos Figura 5. El Home del sitio en julio-2003 (lanzamiento del servicio). 4- EL PRODUCTO ARRAIGA 4.1- Modelo minorista por E-commerce. En el mes de julio-2003 se inició la operación comercial de Arraiga. Muchos usuarios hacían uso del softphone en forma de beta testers desde enero Arraiga es solo una de las variantes de comercialización de la tecnología Softphone. La importancia de este servicio es que fue el primer paso de iplan en un mercado masivo. Las dificultades estuvieron relacionadas con la difícil predicción del tráfico generado por el servicio y con ello la dificultad de seleccionar los Servers para la granja. Por otro lado, como el servicio se diseñó para ser vendido mediante E-commerce, se requería crear desde cero una plataforma completa, incluyendo los acuerdos con las tarjetas de crédito. Las características generales del producto Arraiga son: -Venta solo mediante E-commerce mediante el sitio en la web (Figura 5). No existe un equipo de ventas directo. Sin embargo, está previsto que existan agentes de ventas externos que trabajan por comisión de ventas. -Servicio prepago mediante tarjeta de crédito. -Contrato de servicio básico telefónico con numeración, inicialmente de Buenos Aires y posteriormente de otras ciudades iplan. -Tarifas locales y de LDN/LDI iguales a los clientes de iplan en Pack. -Posibilidad de efectuar llamadas entrantes y salientes a la red PSTN. -Posibilidad de acceso mediante Internet desde cualquier punto con banda ancha. Algunos beta-test han probado el servicio en enlaces dial-up. -Dificultades de acceso cuando el Softphone se encuentra detrás de un Firewall (en una LAN, por ejemplo). Arraiga es un servicio orientado a clientes domiciliarios. Para el caso de clientes corporativos, donde generalmente las PC se encuentran detrás de un Firewall, requieren una configuración en los mismos para dejar pasar los paquetes H.323. Para evitar esta limitación en el servicio, se debe trabajar con protocolo SIP o pasar a un formato http (donde la telefonía viaja como una paquete similar a una web) Modelo Revendedor mayorista. Como complemento, para el mercado corporativo se generó el producto Softphone Revendedor. Este producto está orientado a empresas revendedoras a las cuales iplan le entrega el producto llave-en-mano. La ventaja en este caso es que el Revendedor puede dar un soporte técnico personalizado al cliente, cosa que iplan no hace con Arraiga. La plataforma de Management de este producto incluye diferentes pantallas de configuración y reportes: 10

43 Monografías 3 (2003) Softphone: Tecnología y Productos Figura 6. Pantallas de Management y de Reportes para el Modelo Revendedor de Softphone. -La primera está disponible solo para iplan, se trata de Provisioning Administrator en la Figura 6. Esta pantalla permite a iplan gestionar al cliente mayorista asignándole un número de líneas Softphone determinado. Se le asigna un crédito global para todas las líneas (normalmente se reduce el riesgo crediticio mediante Cuenta Corriente o Servicio Prepago). El servicio puede ser pre-pago o post-pago, pero siempre tiene el formato de límite de crédito. -Una segunda pantalla de Management le permite al Revendedor gestionar uno a uno las líneas (sus Usuarios finales). Puede verificar su crédito total y asignar a cada Usuario un crédito individual. En la Figura 7 es el Provisioning Cliente. El Revendedor dispone de también de Reportes con el detalle de llamadas, saldos y CDRs de las llamadas. Esto le facilita la facturación final. -Además, se dispone de una pantalla de Reportes a la cual puede acceder el Usuario final, en la que encontrará un reporte de tráfico y el crédito remanente. -Otras pantallas de Reportes permite hacer el seguimiento a las áreas de Marketing e Ingeniería de iplan. Se puede seguir las altas y bajas de clientes, el tráfico cursado, el crédito total del producto, la carga de los Servers, alarmas, disponibilidad, etc. Este modelo permite manejar dos tablas de tarifas diferentes. Por un lado, la tarifa que iplan vende al Revendedor y por otro, las que utiliza el Revendedor con respecto a sus Usuarios. Esto es requerido debido a que el crédito total se maneja con la primer tarifa, mientras que los descuentos por cliente se maneja con la segunda tarifa Argumentos comerciales. El Softphone en el formato Arraiga o Revendedor tiene varias ventajas: -Número telefónico de la localidad deseada (inicialmente se tomó solo el AMBA, pero puede correponder a otras ciudades con numeración de iplan). No se requiere indicar prefijos ni códigos de áreas tanto para el que recibe como para el que hace llamadas. -Llamadas entrantes desde el área local adquirida a tarifa local (friendly). Otros productos competidores hacen pagar la llamadas entrantes al cliente receptor. -Paga solo por las llamadas salientes, con destino Argentina o cualquier parte del mundo. -Excelente relación Precio/Calidad de servicio. -Excelente percepción del cliente, por cuanto no sólo puede reducir su gasto telefónico, sino que además se siente más cerca de sus amistades y negocios, al acceder diariamente a ellos, y ellos a él. -Acceso a tarifas en pesos para el cliente residencial en larga distancia nacional e internacional. Sin embargo, tiene algunas desventajas -Requiere un acceso de Banda Ancha permanente, con abonos más elevados que los de Argentina. -Requiere la PC encendida para realización y recepción de llamados. -Es una forma no convencional de realización de llamados para determinados usuarios (mediante la PC). 11

44 Monografías 3 (2003) Softphone: Tecnología y Productos -Utilización de 2 sistemas de comunicaciones telefónicas En la misma Área Geográfica. Cuando un cliente se encuentra en la misma área geográfica que la numeración de Softphone, se pueden identificar los siguientes argumentos comerciales: - Aproveche su Banda Ancha y tenga una segunda línea de teléfono. - Disfrute las funciones de avanzada : Identificación de llamadas; Histórico de llamados; Tipo de Ring según quien llama; Interface con agendas; Registro de llamadas recibidas y perdidas. - Su línea de teléfono se mueve con usted, o Portabilidad de su línea a cualquier conexión de banda ancha. - Control de gastos : Cargue su línea solo con lo que desea gastar (para el servicio prepago). - Ahorre con tarifas muy competitivas : Tarifación por minuto y el menor costo en LDN y LDI Para usuarios remotos Nacional e internacional. Si el cliente se encuentra dentro o fuera de Argentina, puede encontrar otras ventajas adicionales en el Softphone. Por ejemplo: - Su línea directa con Buenos Aires o Argentina. - El menor costo de mercado para sus llamadas nacionales o Nadie va a dejar de llamarlo desde Buenos Aires o Argentina. - Quien lo llame lo estará haciendo a un número telefónico de Buenos Aires al costo de una llamada local. - Su línea de teléfono se mueve con usted o Portabilidad de su línea a cualquier conexión de banda ancha. - Control de gastos : Cargue su línea solo con lo que desea gastar. - Otros destinos a tarifas muy competitivas - Disfrute de las funciones de avanzada Argumentos económicos. Cualquier argumento económico nace envejecido. La realidad puede superar rápidamente a los Modelos de Cálculo, si no se está en continuo movimiento. Solo para identificar ciertas semejanzas se realizaron dos tipos de análisis. Uno desde la óptica del cliente argentino con residencia en exterior que habla hacia Argentina y el otro para un cliente en un nacional que utiliza la larga distancia en forma permanente. Para el caso del cliente en el exterior se comparó las tarifas de iplan a diferentes destinos (incluida la Argentina) con las de las principales operadoras de España, Reino Unido, México, Brasil y USA. Para el análisis se utilizaron las tarifas actuales de Telefónica de España, British Telecom, Embratel, Telmex, ATT&T y algunas tarifas de Calling Cards que operan actualmente en los respectivos países (por ejemplo, Telecard y Ladatel en México). Pero se hizo hincapié a la hora de comparar, en las mejores tarifas ofrecidas actualmente. Figura 7. Cuando es conveniente para un Usuario el Softphone. 12

45 Monografías 3 (2003) Softphone: Tecnología y Productos Los resultados se vuelcan en la Figura 7. Para el caso de un usuario en España por ejemplo, se requieren 90 minutos mensuales de comunicación a Buenos Aires para igualar los costos de Arraiga. Esto no toma en cuenta los argumentos comerciales en cuanto hace a las ventajas (disponer de un número para llamadas entrantes) o desventajas (necesidad de utilizar la PC para la conexión telefónica). Por otro lado, se analizó el producto Arraiga con el servicio ofrecido por la competencia Hola Argentina en formato Call Trough (empresa del grupo IRSA), por considerarlo un servicio sustituto del ofrecido por Arraiga. Se comprobó que para consumos mayores a 250 minutos desde USA, Arraiga comienza a ser más competitivo (a precios de junio-2003 en ambos productos). Softphone requiere a ERM para obtener la información del cliente (Alta, Baja, Modifiación); Información de la tarjeta de crédito y datos respecto del producto y price plan seleccionado. -Interfaces con Tarjetas de Crédito. Esta interfaz permite el cobro mediante la carga del número de tarjeta de crédito. (Visa, American Express, Master Card). Inicialmente, la validación se realiza mediante servicios de Decidir. Softphone requiere a Decidir para obtener la información de la tarjeta y monto en tiempo real. A la inversa, Decidir responde al pedido de autorización de descuento en tiempo real. El segundo análisis se realizó desde el punto de vista del cliente (con target en el segmento ABC1) que habla desde diferentes claves al AMBA. Se analizó la conveniencia de adquirir el servicio ofrecido por Arraiga en comparación a los servicios actualmente ofrecidos por la competencia. Para el análisis se utilizaron las tarifas a junio-2003 de TASA, TECO y AT&T, éste último en el formato de presuscripción. Pero se hizo hincapié a la hora de comparar cada clave en las tarifas que ofrece hoy TASA en el plan para hogares Super País. Este es el operador de mayor cobertura en el país y el porcentaje de presuscripción en hogares es muchísimo inferior que en el nivel corporativo. En la misma Figura 7 se muestra que para el caso de un cliente en clave 2 bastan con 300 minutos mensuales hacia Buenos Aires, para encontrar el punto de cruce (es decir solo 10 minutos al día) La Plataforma de E-commerce. Iplan ha desarrollado una plataforma sobre web para la gestión completa del servicio E-commerce, que inicialmente ha sido utilizada para el producto Arraiga. Desde el punto de vista técnico la opción fue realizar el desarrollo sobre php y MySQL como base de datos, para ser implementado sobre un servidor Linux (herramientas que no son licenciadas). Los componentes de la plataforma son los siguientes: -Plataforma de Pre-pago: este módulo (estudiado en la Figura 2) permite dar de alta al cliente, manejar la precompra, el saldo disponible y los detalles de llamadas (dispone del Data Base con la información sobre el cliente). La Base de Datos propiamente dicha dispone de los datos sobre tarifas, clientes, moneda, etc. El Softphone requiere de la plataforma de Prepago para la actualización del saldo por precompra y la consulta de detalle de llamadas en tiempo real. -Plataforma de Web-Care: este módulo permite la atención del cliente mediante y chat. Para clientes particulares de Arraiga no se dispondrá de un servicio de Customer Care personalizado. Si se dispondrá del mismo para los clientes Revendedores. -Plataforma ERM: Esta plataforma ERM tiene interfaz con el Softphone para la replicación de los productos y price plans y la facturación y débitos por abono mensual. A la inversa, el El conjunto, de cara al cliente, contempla las siguientes funcionalidades: -Selección del país y lenguaje cuando se ingresa por primera vez. -La página principal tendrá información general acerca de los productos y servicios ofrecidos como también permitirá el acceso (usuario y password) a los usuarios registrados. -Permite realizar el download del software. -En caso de que una persona quisiera registrarse por primera vez debe indicar el producto que desea adquirir. Se le informa el importe correspondiente al Abono Mensual correspondiente al servicio. Debe cargar sus datos: Apellido, Nombre, País de Residencia, Ciudad de Residencia, Domicilio de Residencia, Código Postal, Número de Teléfono, dirección de mail, etc. -Indica la tarjeta de crédito a ser utilizada. Se valida que la tarjeta no esté siendo utilizada por otro cliente, de estarlo se rechaza la transacción (el objetivo de esto es evitar el fraude y permitir que sólo se utilice una tarjeta por línea). -De estar OK se valida la transacción, para lo se dispara una transacción contra Decidir u otro proveedor. -De estar OK, se debe dar de alta el cliente para lo cual se dispara un proceso que gestiona la misma en ERM en tiempo real. Entonces, se le brinda el número de Cliente el cual será su usuario para acceder a Softphone. El cliente deberá cargar su Password. -Se muestra las condiciones del servicio (símil contrato), el cual deberá aceptar. Los clientes cuentan con una casilla de mensajes donde les podrá ser brindada información de 13

46 Monografías 3 (2003) Softphone: Tecnología y Productos utilidad. Como resultado de esta, se genera una Orden de Servicio interna por mail indicando los datos del cliente y demás información. -Una vez provisionado el servicio, se le informa al cliente la línea asignada como usuario y password del softphone. -Se cuenta con una tabla de conversión de moneda (inicialmente Pesos, USD y Euros). -Puede consultar su saldo disponible y el detalle de las últimas llamadas realizadas; realizar precompra adicional y realizar reclamos y consultas (vía ). 5- LOCUTORIOS-IP (IPGOL) iplan es una de las empresas de mayor éxito en el producto Locutorios. Sin duda, es el de mayor éxito en la zona de cobertura con red propia. Al cumplir los dos años de ofrecer el servicio ha logrado tener mas de 300 locales en 4 ciudades. Hasta mediados del 2003 solo instalaba Locutorios con líneas analógicas en tecnología IP. Como si esto fuera poca innovación tecnológica (ninguna otra empresa en el mercado o hace y ninguna puede entregar poca cantidad de líneas), desde esta fecha se inició la instalación con tecnología IP nativa. Es decir, el gateway se encuentra en la misma instalación del Locutorio (el tarifador). Este desarrollo es una variante de la tecnología Softphone. El desarrollo estuvo a cargo de bit2net, si bien la participación de iplan fue determinante en la definición de las Especificaciones Técnicas y el los Test de prueba y puesta en marcha. Desde el punto de vista comercial el producto se denomina IPGol. En la Figura 8 se observa el diagrama a bloques de la plataforma IPGol. En las instalaciones del Locutorios se encuentra una PC con el sistema operativo Linux. Esta PC realiza las funciones de tarifador y de gateway. Posee como periféricos una impresora fiscal (para emitir los ticket por cuenta y orden de iplan) y un switch desde el cual se conectan las distintas cabinas. En cada cabina se dispone de un lector con display que hace las funciones de traductor desde codificación G.711 a RJ11 para colocar un teléfono convencional (1). Hacia el exterior (2), la PC se comunica en G.711 en caso de encontrarse dentro de la red de iplan o mediante G.729 para el caso de una conexión vía Internet. Este es el caso de las cabinas telefónicas colocadas en los Cybercafé. En iplan, se pueden detectar los siguientes componentes: un gatekeeper, el gateway IP-IP y el gateway E1. Estos son componentes standard y similares al caso del softphone. Solo que ahora el servicio no pasa por una plataforma de pre-pago. Solo a manera de ejemplo, en la misma Figura 8, se puede observar el formato de la pantalla de gestión del locutorio. Se indican diferentes datos para cada cabina en forma individual. Sobre la evolución del producto y las tecnologías involucradas, Journal dedicará un número monográfico. Figura 8. Diagrama a bloques de componentes para IPGol y pantalla de administración del Locutorio. 14

47 Monografías 3 (2003) Softphone: Tecnología y Productos 6- HIPÓTESIS SOBRE EL FUTURO Para empezar debemos diferenciar claramente la Telefoníasobre-IP de la Telefonía-sobre-Internet. En el primer caso la telefonía se ofrece sobre una red IP de calidad garantizada. En el caso de iplan, se realiza mediante el transporte Gigabit (1000 Mbps), por lo que la calidad se garantiza por Fuerza Bruta (un ancho de banda tan elevado que el retardo y el Jitter es insignificante). En el Journal No 1 se ha analizado la solución adoptada en iplan. En el segundo caso, con una red de transporte donde la calidad no está garantizada (la Internet) se recurre a métodos de compresión vocal (codec G.729 o G.723) y supresión de silencios (codec VAD) que permiten reducir al mínimo la longitud de los paquetes. El segundo elemento inicial, es dejar en claro que el objetivo final es ofrecer servicios de telefonía, datos e Internet integrados. Esto nos lleva a productos exitosos como los Pack en iplan (ver nuevamente el Journal No 1 a tal efecto). Históricamente se ha vivido ya una situación similar cuando en los años 80. Las esperanzas de disponer de una red de servicios integrados ISDN (Integrated Service Digital Network) se construía sobre la idea de una banda angosta. Consistía en dos canales de 64 kbps cada uno, más 16 kbps de señalización (144 kbps en total). Aquella experiencia solo se desarrolló en forma inicial en Europa, mientras que USA permanecía indiferente. Desde inicio de los años 90, con la introducción del protocolo http y las páginas web, todo cambió. Ya la ilusión de la red de servicios integrados no pasaba por ISDN (o ATM, la versión para banda ancha), sino que se desplazaba al protocolo IP. En este segmento, la empresa líder era Cisco (quién sostendría el proyecto de iplan desde el año 2000). Siempre resulta difícil extender una línea de tendencia en forma recta. Si este fuera el caso, el protocolo IP está llamado a ser la base de la red digital de servicios integrados del futuro cercano. iplan es la empresa ejemplo de esta tendencia. La pendiente de la línea de tendencia es más difícil de predecir, ya que la telefonía tradicional seguirá subsistiendo en tanto las inversiones en telecomunicaciones estén acotadas. Sin embargo, cada nuevo emprendimiento que se genere, inevitablemente será con tecnología IP por lo próximos años. Sin duda, la Telefonía-IP es la mejor (quizás única) apuesta para una nueva empresa que ingresa en el mercado. Hacer una predicción sobre la Telefonía sobre Internet es mucho más difícil. Un modelo de tecnología como el Softphone tiene un futuro indeterminado y de alguna manera impredecible. Mas allá de las ventajas (transportabilidad, ubicuidad, integrabilidad), se deberá vencer durante un tiempo las costumbres del usuario (el requerir la PC y la conexión a Internet limita la generalización del servicio). Sin embargo, basta pensar que hace 10 años casi nadie tenía una conexión a Internet y hoy sigue el camino de considerarse una necesidad básica. Si el despliegue de las diferentes variantes de productos relacionados con la tecnología softphone tiene éxito, se podrán ver varias líneas de negocios: -por un lado, el uso del softphone de cualquier PC, en cualquier lugar con acceso a Internet y sin límites de protocolos. Para ello bastaría con usar protocolos de comunicación que pasen los Firewall y obtener el programa de comunicación desde la web (no se requiere tener el software instalado, se instala durante el tiempo de la conexión sobre la PC disponible). -por otro lado, será posible generar grupos de numeración de usuarios en localizaciones de la misma empresa (ámbito corporativo). Esto simulará VPN entre distintas localizaciones. Este servicio está hoy disponible con diferentes tecnologías. -se podrá lograr la integración de las LAN con la telefonía (teléfonos IP de bajo costo) local y global. Los avances en la telefonía celular IP también permitirá una sola red global. De todas formas es casi imposible predecir el futuro cuando las posibilidades de desarrollo y expansión son tan elevadas. Es más lógico limitarse a enumerar las virtudes y las limitaciones a vencer. 15

48 Monografías 3 (2003) Softphone: Tecnología y Productos MONOGRAFIAS DE J: Journal monografías número 3. Edición agosto Diseño gráfico original de Marianela V. Ricardo 16

49 monografía iplantech Journal Monografías es una publicación de iplan que contiene información técnica y confidencial de la empresa. Se distribuye a un circuito limitado de lectores a fin de mantenerlos informados sobre el estado y la evolución de la tecnología y el negocio de la Telecomunicaciones, principalmente en las redes IP y la Telefonía-IP. Se ruega a los lectores a mantener el principio de Confidencialidad sobre la información aquí contenida. No está autorizada su reproducción o distribución por cualquier medio sin antes consultar con la empresa. ISI: El softswitch iplan Luego de instalar el softswitch OCMC y de haber probado otras tres marcas de equipos, a mediados del 2002 se decidió encarar el desarrollo interno del softswitch de iplan. Hoy es una realidad. IINDICE 1- Evolución histórica 2- Introducción a H Arquitectura del Sistema SI 4- Funcionamiento básico 5- Servicios de aplicación 6- Secuencia de mensajes 7- Futuro del softswitch IABSTRACT El softswitch de iplan (conocido como SI) es un desarrollo interno. Obligados por las circunstancias y motivados por el desafío, se encaró la tarea de diseñar y programar un softswitch a medida. Inicialmente opera en protocolo H.323 (quizás en el futuro se programe para el protocolo SIP, sí los estudios en marcha así lo determinan). Su principal función es tomar el control del Dominio de gateway Cisco-VG200 y Cisco-2600 que corresponden a la primer generación y de Cisco-IAD2430 y Audiocodes-MP124 que corresponden a la tercer generación. Como segundo objetivo se tiene generar una serie de servicios de valor agregado para clientes en la red de Telefonía-IP. IAUTORES Esta monografía ha sido redactada sobre la base de diferentes documentos originales de Eduardo Moreira, Claudio Degraf, Mariano Tomalino y Diego Frick de bit2net, entre otros. 1

50 Monografías 4 (2003) SI: El softswitch -iplan 1- EVOLUCION HISTORICA El Softswitch es un software que permite ofrecer servicios de valor agregado a la telefonía. El primer softswitch instalado en iplan fue el OCMC de HP. El OCMC fue puesto en servicio a mediados de Octubre del Desde el inicio, el equipo presentaba fallas de estabilidad y falta de flexibilidad. Además, los servicios estaban en pleno desarrollo y nunca contó con una versión definitiva. A pesar de esto, durante ese tiempo, la versión de software para servicios Starvox sufrió varios upgrades y updates de parches. Las fallas sistemáticas reconocidas no podían ser reparadas ya que los desarrollistas se encontraban abocados a la codificación de la versión definitiva. Para mediados de mayo 2001 (en tanto se anunciaba el press release entre HP y Starvox), se contaba con una versión de software que presentaba un cierto grado de estabilidad. Estaba muy relacionado con al escaso tráfico que en ese momento se estaba cursando. A medida que esto sucedía, el tráfico se incrementaba y obstaculizaba al OCMC, si bien los valores de llamadas concurrentes y CPS (Calls Per Second) estaban aún muy lejos de lo especificado. HP había provisto equipos muletos iguales a los de servicio para realizar upgrades. Estos equipos muletos oficiaban la mayoría de las veces como maqueta, por lo que se usaban para probar la posibilidad de implementar un gatekeeper Cisco. Con el tráfico de cada día acumulándose más y más, la carga de las CPU del OCMC llegaba a valores donde el comportamiento se tornaba errático. Ya, para fin del año 2001, el tráfico y la configuración cargada hacía inmanejable la interfase de aprovisionamiento. HP pide la intervención del desarrollista del stack H.323, la empresa israelí RadVission. El técnico de RadVission viene a sitio y encuentra el origen del problema en el código del stack. A los pocos días viene el parche de software correspondiente. El día definido (el 4 de abril del 2002) se realiza el cambio acordado. A los pocos minutos el equipo se cae definitivamente y no levanta más. Se decide migrar todos los gateways registrados en el OCMC a gatekeepers de Cisco (7400ASR1). La causa de los crack fue que se dejó activado un trazado que se corrió una noche y al realizar un submit de la nueva configuración, el trazado arrancaba y todo terminaba. En tanto el OCMC producía dolores de cabeza, se analizaron dos softswitch: el NetCentrex y el Alcatel. Al primero se le hicieron pruebas remotas en el segundo semestre del 2001 (el equipo estaba en USA y se utilizó una conexión remota vía Internet), los resultados eran buenos. Por un tiempo fue el Plan B si el OCMC fallaba. Durante febrero-2002 se realizó una prueba básica de funcionalidad del softswitch de Alcatel en el Laboratorio del NOC de iplan. Pasaría a ser el Plan B, sino fuera porque... sino fuera porque nadie quería ensayar otra vez. En este caso la tesis era: si vamos a volver a ensayar hagámoslo con nuestro propio desarrollo. 2

51 Monografías 4 (2003) SI: El softswitch -iplan Hacia fines del 2002, Cisco presentaba el softswitch BTS, un equipo que por largo tiempo nos fue esquivo. Cisco disponía de este desarrollo pero no lo liberaba para la venta en Sudamérica. La introducción del BTS tenía objeciones desde el punto de vista técnico. Implicaba una migración de plataforma riesgosa para una red en servicio y con muchos clientes operativos. El BTS, con su carga de beneficios, había llegado indudablemente, tarde. A mediados del 2002 ensayamos con versiones libres de softswitch sobre Linux lo cual nos llevaba a la convicción que era posible hacer nuestro propio softswitch. Con esto y las experiencias anteriores diseñamos la arquitectura del softswitch. La fecha objetivo se fijó en el 4 de abril 2003 (un año después de la salida del OCMC). Figura 1. Diagrama general de la red de Telefonía-IP en iplan. Para este desarrollo se utilizaron recursos internos el plan para determinar la topología de funcionamiento. Se contrato a bit2net para trabajar en conjunto con iplan en el desarrollo del software y los features del softswitch. Para darle identidad al proyecto se generó un nombre (SI derivado de Softswitch iplan) y un símbolo (el símbolo de iplan que explota de alegría formando la sigla SI). El 4 de abril del 2003 se realizó la primer llamada en iplan utilizando el softswitch SI. Involucró varios componentes, líneas fijas y celulares, pero fundamentalmente el softphone y el Pack-1 (dos desarrollos de iplan). Un año después la historia cambiaba sustancialmente. La Figura 1 muestra la evolución y los componentes de la red de Telefonía-IP en iplan. Un próximo número de Journal se dedica a este tema por lo que no se extienden mas detalles en esta edición. 3

52 Monografías 4 (2003) SI: El softswitch -iplan 2- INTRODUCCIÓN A H Protocolos de Señalización. La voz sobre redes IP (también conocido como VoIP-Voice over IP) se implementó inicialmente para reducir el ancho de banda (velocidad de transmisión) mediante el uso de mecanismos de compresión vocal, de forma de disminuir los precios en el transporte internacional. Luego se migró lentamente a una red de servicios integrados con la denominación de Telefonía-IP, modelo que actualmente se utiliza en iplan. Existen varias características que hacen de la Telefonía-IP un problema de alta complejidad. Primero la interoperatividad con las redes telefónicas actuales y los servicios de valor agregado que generalmente se brindan en las redes soportadas con el Sistema de Señalización SS7. Por otro lado, en Telefonía-IP se debe aplicar el concepto de carrier-class, que debe incluir varios aspectos, como la redundancia de equipamiento para lograr disponibilidad elevada, excelente calidad vocal (mensurable en errores, retardo, jitter, eco, etc), la conectividad con todos los otros operadores, etc. Cuando se habla de Telefonía-IP se refiere a la aplicación pública, donde el principal problema es la interoperatividad (conexión entre distintos operadores y con distinta tecnología). Una parte de la historia empieza hace más de 20 años, cuando en 1981 en el modelo de capas para el protocolo IP tenía prevista la voz sobre protocolos RTP/IP (Real Time Protocol-Internet Protocol). Hoy día, la señal vocal (mediante Codec G.711 o G.729) se trabaja con los protocolos RTP- UDP-IP; mientras que la señalización trabaja sobre UDP o TCP, dependiendo del protocolo de señalización. El protocolo H.323 es una norma de la Unión Internacional de Telecomunicaciones ITU-T que data de 1996 y ha sido generado para sistemas de comunicación multimediales basado en paquetes (redes que no pueden garantizar correctamente la calidad de servicio QoS). Esta tecnología permite la transmisión en tiempo real de vídeo y audio por una red de paquetes. En la versión 1 del protocolo H.323v1 del año 1996 se disponía de un servicio con calidad de servicio (QoS) nogarantizada para trabajar sobre redes LAN. En la versión 2 del año 1998 se definió la aplicación VoIP independiente de la multimedia. Una versión 3 incluye el servicio de fax sobre IP (FoIP) y conexiones rápidas, entre otros features. La versión H.323v2 introduce una serie de mejoras sobre la H.323v1. Algunas de ellas son: -permite la conexión rápida (elimina parte de tiempo de solicitud de conexión); -mediante el protocolo H.235 introduce funciones de seguridad (autentificación, integridad, privacidad); -mediante el protocolo H.450 introduce los servicios suplementarios; -soporta direcciones del tipo RFC-822 (para ) y del formato URL; -permite el control de llamadas multi-punto en conferencia; -permite la redundancia de gatekeeper para la registración en la red; -soporta la codificación de vídeo en formato H.263; -admite el mensaje RIP (Request in Progress) para informar que la llamada no puede ser procesada por el momento; -provee la facilidad que el gateway informe al gatekeeper sobre las disponibilidad de enlaces para mejorar el enrutamiento de llamadas. Figura 2. Componentes y modelo de capas para el protocolo H

53 Monografías 4 (2003) SI: El softswitch -iplan 2.2- H.323 y otros software Las funciones que se deben cumplir en la Telefonía-IP son las de tráfico vocal, de señalización, de calidad de servicio y de direccionamiento. A continuación se hace un resumen de dicha funciones La señal vocal. La señal vocal se transporta en los protocolos RTP-UDP sobre IP. La Codificación de audio puede realizarse mediante G.711 a velocidad de 64 Kbps o G.729 en 8 Kbps. En tanto el ITU-T ratificó en 1995 al codificador G.729, el VoIP-Forum en 1997 (liderado por Intel y Microsoft) seleccionó a G con velocidad de 6,3 Kbps para la aplicación VoIP. La codificación de vídeo está de acuerdo con H.263. Ambos servicios se soportan en el protocolo de tiempo real RTP. En iplan se ha seleccionado el código G.711 para aplicación dentro de la red IP propia y el G.729 para aplicaciones en Internet. En el primer caso tenemos los conocidos Pack y en el segundo el Softphone. La Figura 2 muestra el conjunto de protocolos que se encuentran involucrados en H.323. El protocolo SIP es otra variante, más simple que H.323 y que probablemente será utilizada en el futuro en iplan La Señalización H.323. H.323 se soporta sobre protocolos TCP o UDP sobre IP. Los protocolos de señalización son varios: -H.225. Son los mensajes de control de señalización de llamada que permiten establecer la conexión y desconexión. Este protocolo describe como funciona el protocolo RAS y Q.931. H.225 define como identificar cada tipo de codificador y discute algunos conflictos y redundancias entre RTCP y H Q.931. Este protocolo es definido originalmente para señalización en accesos ISDN básico BRI (Basic Rate Interface). Se utiliza para señalización de llamada en la red IP entre Gateway GW. Es equivalente al ISUP utilizado desde el Gateway hacia la red telefónica pública PSTN (en señalización SS7). -RAS (Registration, Admission and Status). Utiliza mensajes H.225 para la comunicación entre terminal y el gatekeeper GK. Sirve para registración, control de admisión, control de ancho de banda, control de estado y desconexión. -H.245. Este protocolo de señalización transporta la información no-telefónica durante la conexión. Es utilizado para comandos generales, indicaciones, control de flujo, gestión de canales lógicos, etc. El H.245 es una librería de mensajes con sintaxis del tipo ASN.1. Además codifica los dígitos DTMF (Dual-Tone MultiFrequency) en el mensaje UserInputIndication. -H.235. Provee una mejora sobre H.323 mediante el agregado de servicios de seguridad como autentificación y privacidad (criptografía). H.235 trabaja soportado en H.245 como capa de transporte. Todos los mensajes son con sintaxis ASN Calidad de servicio. Soportado sobre el protocolo UDP sobre IP. -RTP (Real-Time Transport Protocol). Este protocolo es usado con UDP sobre IP para identificación de carga útil, numeración secuencial, monitoreo, etc. Trabaja junto con RTCP (RT Control Protocol), quien entrega un feedback sobre la calidad de la transmisión de datos. El encabezado de RTP puede ser comprimido para reducir el tamaño de archivos en la red. -Protocolo de reservación de ancho de banda RSVP es usado para reservar el ancho de banda especificado dentro de la red IP. RSVP trabaja sobre PPP (o similar a HDLC) pero no trabaja bien sobre una LAN multi-acceso. -Protocolo PPP-Interleaving se utiliza para enlaces inferiores a 2 Mbps para fraccionar los paquetes de gran longitud y permitir el intercalado con paquetes de servicios en tiempo-real Direcciones. Se tienen los siguientes tipos de direcciones: -Dirección de red (IP Address). Se trata normalmente de direcciones privadas que identifican a cada componente en la red IP. La asignación de direcciones puede ser fija o asignada en forma dinámica (protocolo DHCP). -Dirección TSAP. Corresponde al port TCP/UDP. Permite la multiplexación de canales con la misma dirección de red IP. Algunos componentes, como el gatekeeper GK y el protocolo RAS, tienen una dirección de port fija. En otros, como los terminales, se asignan en forma dinámica. -Dirección de Alias. Se trata de alguna identificación como el número telefónico, dirección de , nombre de usuario, etc. La resolución de direcciones alias se realiza en el gatekeeper GK Protocolo SIP. El IETF (que regula las Norma de Internet) ha generado un set de protocolos que simplifican al H.323 de la ITU-T. SIP es más simple que H.323 y está basado en HTTP. En H.323 se utiliza el Gatekeeper, mientras que en SIP se usa el SIP Server, el cual tiene mejores aspectos de escalabilidad para grandes redes. En H.323 para grandes redes se recurre a definir zonas de influencia y colocar varios GK. Para la interoperabilidad de protocolos se requiere un Gateway de borde que realice la conversión. SIP está basado en texto y el mensaje basado en http (RFC para la semántica y sintaxis). La dirección usada en SIP se basa en un localizador URL (Uniform Resource Locater) con formato del tipo sip:roberto@ (o mediante el dominio Domain: teleinfo.com.ar), de forma que SIP integra su servicio a la Internet. En este modelo se recurre a un server de resolución de dominio DNS (Domain Name Server). SIP incorpora también funciones de seguridad y autentificación, así como la descripción del medio mediante SDP. Para el proceso de facturación Billing se puede recurrir a RADIUS y RSVP. 5

54 Monografías 4 (2003) SI: El softswitch -iplan Figura 3. Arquitectura del Software del Softswitch SI. 3- ARQUITECTURA DEL SISTEMA SI 3.1- Arquitectura Lógica Las redes denominadas de próxima generación (conocidas con la sigla en ingles NGN) contienen tres partes básicas: el softswitch, los gateways o terminales y una red de transporte basada en paquetes. El softswitch provee el requerimiento de inteligencia centralizada para el control del flujo de tráfico manipulado por la red de transporte. El softswitch de iplan es una plataforma escalable, con características Carrier Class que ofrecerá una amplia gama de características de servicios para la Telefonía-IP. En la Figura 3 se muestra un diagrama con la arquitectura lógica de la plataforma Softswitch de iplan. Los módulos componentes de dicha arquitectura son los siguientes: GKMPU (Gatekeeper Master Proxy Unit). Esta unidad es la que se presenta hacia el lado de la red. De acuerdo al tipo de mensaje recibido (tipo de protocolo) y del puerto correspondiente, deriva los mensajes a las unidades de procesamiento correspondientes MCCU (Master Call Control Unit). Esta unidad lógica tiene toda la capacidad de ruteo de las llamadas y datos de aplicación de servicios. Se compone de las siguientes subunidades: -RAS: Esta unidad ejecuta todas las registraciones de los gateway GW y las transacciones de admisión de llamadas. -CSMU (Call Setup Master Unit): Esta unidad ejecuta el call setup a través de los mensajes Q.931. Las aplicaciones que corren dentro de la unidad son dos a saber:.su (Switching Unit). La Switching Unit se encarga de realizar todo el proceso de enrutamiento de la llamada de acuerdo a la información contenida tanto en el mensaje de setup, como la información contenida en la base de datos propia y la información de registraciones de CPEs..MSADB (Master Services Application Database). Esta base de datos de aplicación de servicios almacena todos los servicios y sus features vinculados a cada CPE o línea de GW registrado. Esta información se propaga entre todos los servers físicos que componen la unidad de call setup BMU (Billing Master Unit). BMU recibe la información desde MCCU y almacena los CDRs correspondientes luego de cada llamada completada. Los CDRs almacenados corresponden tanto a llamadas fructuosas como a las infructuosas WPU (Web Provisioning Unit). Esta unidad se requiere para tareas de aprovisionamiento y administración, pero podrían no ser parte de los componentes del sistema. 6

55 Monografías 4 (2003) SI: El softswitch -iplan Figura 4. Arquitectura de Hardware del Softswitch SI Arquitectura Física. En el diagrama de la Figura 4 se muestra la arquitectura física de la plataforma Softswitch de iplan. Los componentes en este caso son servers, cada uno de los cuales ejecuta una determinada función de acuerdo al módulo lógico al que pertenece. Cada módulo lógico puede estar formado por mas de un server, de manera de asegurar la escalabilidad y alta disponibilidad del sistema. En una etapa inicial (por ejemplo durante la puesta en marcha), solo se requerirá un servidor por cada uno de los módulos componentes. Serán suficientes cuatro servidores para completar la dotación: -Unidad Proxy, -Unidad RAS, -Unidad de Control de Llamada y -Unidad de Billing. En las etapas posteriores, se sumarán servidores de manera de crecer tanto en cantidad de gateways GW registrados, en cantidad de llamadas concurrentes, como así también en confiabilidad y disponibilidad del sistema. En el caso de las unidades CSMU, cada una de ellas está pensada para que pueda manipular hasta 500 llamadas simultáneas. Una vez superado este límite se considera que se debe agregar una nueva unidad CSMU. En el caso de fallo de una unidad CSMU, la carga de tráfico se reparte entre las restantes unidades mientras que las llamadas establecidas controladas por esta unidad no se cortan. En el caso de las unidades RAS, cada una de ellas está pensada para que pueda manipular y registrar hasta 100 gateways. Una vez superado este límite se considera que se debe agregar una nueva unidad RAS. En el caso de fallo de una unidad RAS, la carga de registración de gateways se reparte entre las restantes unidades Requerimientos de Hardware. Características de los Server. El sistema Softswitch de iplan está compuesto básicamente por cuatro tipos de servidores diferentes de acuerdo al módulo funcional al que dicho módulo se asigne. De acuerdo a esto, la Tabla superior de la Figura 5 resume los requerimientos de hardware para cada uno de los servidores de acuerdo a la tecnología disponible al presente. Número de Server. La Tabla inferior de la misma Figura 5 muestra los requerimientos en número de servidores de acuerdo a la etapa de implementación y a la cantidad de llamadas simultáneas que se pretenden manejar y asumiendo que cada servidor de control de llamadas (CSMU) podrá manipular hasta 500 llamadas simultaneas. 7

56 Monografías 4 (2003) SI: El softswitch -iplan Requerimientos Proxy RAS Control CSMU Billing BMU GKMPU Procesador Intel Xeon 2.4 GHz X X Procesador Intel Xeon 1.8 GHz perfil bajo X X Motherboard Intel SE7500WV2 X X X X 2 X 512Mb DDR Kingston ECC 266MHZ X X X X 1 Disco IDE 30 Gb Western Digital X X X 1 Disco SCSI 36 Gb 10K Seagate X 3 interfaces de Red Ethernet 10/100 X Gabinete rackeable 19" con 2 fuentes - 2U INTEL SR2300 X X Gabinete rackeable 19" con 1 fuentes - 1U INTEL SR1300 X X Backplane IDE X X CDROM 56X X X X X Disquetera de 3 ½ X X X X Teclado, mouse X X X X Fase de Implementación Nombre de Unidad Cantidad Total Desarrollo GKMPU 1 Etapa de Producción 1 (500 llamadas simultáneas) Etapa Final de Producción (5000 llamadas simultáneas) RAS Serv. 1 CSMU 1 BMU 1 WPU 0 GKMPU 2 RAS Serv. 2 CSMU 2 BMU 1 WPU 0 GKMPU 2 RAS Serv. 4 CSMU 11 BMU 2 WPU 1 Figura 5. Tipo y cantidad de Servers necesarios para el Hardware FUNCIONAMIENTO BÁSICO Secuencia de Mensajes En la Figura 6 se describe la interacción entre los server durante una llamada entre GWs registrados en diferentes unidades RAS. En el capítulo 6 se analiza con más detalle este procedimiento. El proceso es el siguiente: -El GW1 envía un pedido de registración (RAS RRQ) al softswitch. -El Proxy enviará este mensaje al módulo RAS1 y este enviará la información a la base MySQL de cada servidor CSMU. -El GW2 envía un pedido de registración (RAS RRQ) al softswitch. -El Proxy enviará este mensaje al módulo RAS2. -Cuando el GW1 quiere llamar al GW2, enviará un mensaje ARQ. -El Proxy le enviará el ARQ al RAS1, ya que éste tiene registrado al GW1. -Como el RAS1 no tiene registrado al GW2, le envía un LRQ al RAS2 quien le contesta con LCF. -El RAS1 envía ACF al GW1 a través del Proxy. -El GW1 envía el mensaje Setup (Q.931), el cual a su vez es dirigido por el Proxy a cualquiera de los servidores CSMU ya que tienen la información de todos los GW en su MySQL Procedimiento para Registración El softswitch deberá tener la capacidad de registrar los PSTN-GW y los CPEs a través de los parámetros siguientes: la dirección IP, el identificador H.323-ID y el Número E.164. Los PSTN-GW que poseen tramas de interconexión no registran los números E.164. Debido esto, y para mantener homogeneidad en la administración de equipos registrados, el modo de registro se realiza a través del H.323-ID y de la dirección IP del equipo. 8

57 Monografías 4 (2003) SI: El softswitch -iplan Figura 6. Intercambio de Mensajes entre los módulos de Hardware. Durante el aprovisionamiento de equipos, el personal encargado configurará el H.323-ID asignado al equipo en cuestión y los prefijos relacionados que manejará el equipo. El procedimiento en el equipo para establecer esta correspondencia será el siguiente: -El operador ingresa en la interfaz de administración el H323- ID del GW y los prefijos relacionados. -El GW se registrará con su H.323-ID y la dirección IP. -Al recibir una llamada hacia un número determinado (E.164), la plataforma compara este E.164 con los prefijos que tiene asignados. -La mejor correspondencia (Best Match) entre número y prefijo es la que determina el H.323-ID del GW para ese número marcado. -El softswitch termina enrutando la llamada de acuerdo a dicho criterio. -Si un terminal o GW, por alguna razón registrara su E.164, la plataforma hará la correspondencia en forma directa Requerimientos al Softswitch Se ha seleccionado el modo de llamada en el formato Modo Ruteado (Routed Model) bajo protocolo H323v2/v3 de la ITU- T, en fast y/o slow start Capacidad de Server de control de llamada. El sistema tendrá una capacidad inicial mínima de 6 CPS (Calls Per Second) (21600 BHCA) en configuración simple, y este valor será escalable hasta 60 CPS (200 KBHCA) en configuración de granja. Esto corresponde a la primer etapa y diseño final de la Figura Capacidad de llamadas concurrentes. El sistema tendrá una capacidad inicial mínima de 500 llamadas concurrentes con 100 gateways registrados que serán escalables hasta 5000 llamadas en configuración de granja. Para ambos ítem, se asumieron los siguientes valores: -MHT (Mean Holding Time): 120 segundos y -ASR (Answer to Seizure Ratio): 70 % Gateways soportados. Los gateways de abonado soportados deberían ser aquellos que actualmente están desplegados en la red desde el año Por ejemplo: Cisco-1750, Cisco-26xx, Cisco-36xx, Cisco-VG200. Así como aquellos que se integrarán desde el 2003: Cisco- IAD2430 o Audiocodes. Los PSTN-GW son aquellos que interconectan la red IP con la PSTN. Se deben considerar: Cisco-AS5300, Cisco- AS5350, Cisco-AS5400 y en el futuro otros Gateway-E1. Todos los PSTN-GW mencionados soportan los siguientes protocolos TDM: MFCR2 (stand-alone), ISDN PRI (standalone), ISUP (stand-alone o bajo configuración del Cisco SC2200 Media Gateway Controller) Gatekeepers soportados. Los Gatekeeper GK soportados deben ser la línea de Cisco Infraestructure Gatekeeper (26xx, 36xx, 72xx, 74xx, etc.). 5- SERVICIOS DE APLICACION Servicios y features Los siguientes son algunos de los servicios y features previstos de ser soportados por el Softswitch iplan SI. Referido a las Características de ruteo de llamadas se ofrecen los siguientes servicios: -Control de flujo y volumen de tráfico; -Ruteo por prefijos alternativos; -Ruteo por número de abonado llamante; -Ruteo por distribución entre prefijos; -Disposición de llamadas (Anuncios): -Servicios de emergencia obligatorios (por regulaciones); -Ruteo hacia prefijos de GK de infraestructura; -Diferenciación entre GW no registrados y no creados. 9

58 Monografías 4 (2003) SI: El softswitch -iplan Con referencia a los reportes y estadísticas que entrega el sistema, se tienen: -Generación de CDRs y -Mediciones de Tráfico. Relacionado a las características que se ofrecen al abonado, pueden enumerarse las siguientes: -Listas de bloqueo (Screening lists); -Listas Blanca y negra (black&white lists); -Manipulación de dígitos fija y en base a fecha y hora; -Características de identificación de línea llamante (CLIR, CLIRREQ, IGNORE); -Línea con crédito controlado y -control de tiempo de conversación; -Grupos de búsqueda sobre un conjunto de GWs; -Redes Privadas Virtuales (VPNs); -IP Centres; -Número Universal (One Number). Algunos servicios adicionales al abonado son: -Desvío de Llamadas (Incondicional, Ocupado, No Contesta y simultáneos para Voice Mail); -Llamada en espera; -Presubscripción de Carrier; -Selección de Carrier. En lo referente a requerimientos de monitoreo on-line para los servidores del Softswitch, se puede mencionar: -Carga de CPU de cada elemento; -Cantidad total de gateways registrados; -ASR de las últimas 100 llamadas; -MHT de las últimas 100 llamadas (solo de la porción de las fructíferas); -Cantidad de CPS (Calls Per Second) en promedio del último minuto; Referido a alarmas, se requiere la generación de SNMPtraps cuando: -en caso de superarse los umbrales predefinidos en los puntos anteriores; -si la carga de CPU de un servidor supera el umbral; -si la cantidad de gateways registrados cae debajo del umbral; -si el ASR cae debajo del umbral; -si el MHT cae debajo del umbral; -si el CPS sobrepasa el umbral; -cuando el valor actual supera el umbral y pasa nuevamente a la zona segura Registros de tasación CDRs Los CDRs estarán contenidos en un archivo de texto plano en formato CSV (coma separated values) y cada nueva llamada se agrega al archivo existente (append). En caso de que el archivo no exista, el sistema crea uno nuevo. Periódicamente la aplicación cierra el archivo existente a ciertas horas predefinidas y luego vuelve a abrir un nuevo archivo. Este archivo residirá en un directorio a ser definido y el contenido del mismo es estricto en orden y contenido. La plataforma conserva cada archivo durante 15 días, transcurridos los cuales el archivo es borrado. Al directorio de archivos de tasación se podrá acceder vía FTP. Tipo de servicio Número de A Campo Número de A Traducido Número de B Marcado NADI de B Marcado Número de B Traducido NADI de B Traducido Dirección IP de Origen Significado Indica el servicio relacionado con la llamada (vacío en caso de una llamada ordinaria). Número del usuario llamante (ANI) Traducción del número del usuario llamante (ANI), si es requerida. Si no hay traducción, este campo queda vacío Número marcado por el usuario llamante, en caso de No. Nacional ó Internacional sin los ceros adelante (los números no geográficos 0800 son números nacionales). Nature of Address Indication, para discernir si el número discado es: 1= local (subscriber); 3= No. Nacional; 4= No. Internacional Número de destino final si es requerida alguna traducción. En caso de No. Nacional ó Internacional, sin los ceros adelante. Nature of Address Indication, para discernir si el número traducido es local (subscriber), No. Nacional ó No. Internacional Indica la dirección IP del CPE/PSTN Gateway de origen, es decir el que inicia la llamada H.323 ID de Origen Indica la identificación H.323 del CPE/PSTN Gateway de origen, es decir el que inicia la llamada Dirección IP de Destino H.323 ID de Destino Fecha de Setup Hora de Setup Fecha de Connect Hora de Connect Fecha de Disconnect Hora de Disconnect Origen de Disconnect Release Cause Value Indica la dirección IP del CPE/PSTN Gateway de destino, es decir en donde termina la llamada Indica la identificación H.323 del CPE/PSTN Gateway de destino, es decir en donde termina la llamada Fecha del mensaje Setup de Q.931 (formato AAAAMMDD) Hora del mensaje Setup de Q.931 (formato hhmmss) Fecha del mensaje de conexión (CON) (formato AAAAMMDD) Hora del mensaje de conexión (CON) (formato hhmmss) Fecha del mensaje de desconexión (RLC) (formato AAAAMMDD) Hora del mensaje de desconexión (RLC) (formato hhmmss) Indica cual fue el usuario que cortó la comunicación. 0: Cortó el origen; 1: Cortó el destino; 2: Cortó el sistema liberando hacia el origen y hacia el destino Razón de desconexión de la llamada, según ITU-T Q.850 (en valor decimal) Figura 7. Formato de los CDRs. 10

59 Monografías 4 (2003) SI: El softswitch -iplan El contenido de cada CDR se muestra en la Tabla de la Figura 7. El campo Tipo de Servicio indicará a cual servicio estará vinculado el ticket. Estos servicios son los que se desarrollarán en un futuro. En el caso de llamadas infructuosas (B no contesta, ocupado, etc.) el mensaje CON está ausente, y esto se denota al encontrarse vacíos los campos FECHA y HORA de la respuesta. 6- SECUENCIA DE MENSAJES En este ítem se estudiará la secuencia de mensajes y la interacción entre los distintos módulos de Software y Hardware para establecer una comunicación. En la primera parte se hace una descripción de diferentes fases de la llamada, muchas de las cuales no están indicadas en las Figuras. En la segunda parte se trabaja con un diagrama de tiempos para casos de llamadas completadas y fallidas Tipos de Mensajes. En H.323 la notación para cada tipo de mensaje es diferente, y de esta forma puede distinguirse de un protocolo a otro. En las Figuras siguientes se puede seguir esta diferencia. Los mensajes de H.245 se describen en forma de texto concatenado en letras tipo bold: maximumdelayjitter. En cambio para el protocolo RAS se utiliza una representación mediante 3 letras (por ejemplo: ARQ) y es usado para señalización entre el terminal y Gatekeeper. En los protocolos H.225/Q.931 se utiliza una representación mediante una o dos palabras con la primer letra en mayúsculas (ejemplo: Call Proceeding). El H.225/Q.931 es usado para encapsular los mensajes H.245 de señalización entre terminales y originalmente fue diseñado como protocolo DSS1 en capa 3/7 para los accesos ISDN. El proceso de comunicación tiene distintas fases. A continuación se mencionan algunas de ellas Discovery. Discovery es el proceso por el cual el terminal H.323 (gateway GW-FXS en las Figuras anexas) determina cual es el gatekeeper GK que atiende a la red en ese momento. El mensaje desde el terminal es del tipo multicast (dirigido a todos los GK) y se denomina GRQ (Gatekeeper Request). El GK disponible responde con el mensaje de aceptación GCF (GK Confirmation) o de rechazo GRJ (GK Reject) a la solicitud. También el GK puede indicar un GK alternativo mediante un mensaje alternategatekeeper. Si no se está en condiciones de procesar el request GRQ se puede enviar un mensaje RIP (Request in Progress) para indicar que se está procesando el request. Esto permite el reset el timeout de la conexión (tiempo después del cual se considera que la conexión es imposible). El procedimiento de Discovery no está representado en las Figuras anexas por tratarse de una operación de inicialización Registration. Mediante este proceso el terminal de usuario GW-FXS informa y registra sus direcciones de transporte y el alias. Utiliza el mensaje RRQ (Registration Request) y el GK responde con RCF (Registration Confirmation) o RRJ (Registration Reject), para confirmar o rechazar el pedido de registración. El RRQ se emite en forma periódica. Este intercambio de mensajes está puesto en evidencia al inicio de la Figura 8 y se evita en el resto de las Figuras siguientes. En esta Figura se muestra la secuencia de Mensajes para el caso de una llamada completada correctamente. En esta operación intervienen el Gateway, el Gatekeeper y el RAS. La registración tiene un tiempo de duración (expresado en segundos) para lo cual se utiliza el mensaje timetolive. El terminal GW o el GK puede cancelar la registración mediante el mensaje URQ (Unregister Request) al cual le corresponde la confirmación URF (Unregister Confirmation). Esta operación no está reflejada en ninguna de las Figuras anexas, debido a que no corresponde a una función durante el intento de establecer una llamada Location. Un terminal o GK que tiene un alias para un terminal GW y que quiere determinar su información de contacto puede emitir el mensaje de requerimiento de localización LRQ (Location Request). Al cual le corresponde el mensaje de confirmación LCF (Location Confirmation) con la información requerida. La dirección puede ser del tipo E.164 si se trata de un GK fuera de la red. Tampoco esta función esta representada en las Figuras Admission. El pedido de admisión del terminal al GK es ARQ (Admissions Request) y contiene un requerimiento Call Bandwidth (en formato Q.931). El GK puede reducir las características de la solicitud en el mensaje de confirmación ACF (Admissions Confirm). En el mismo mensaje ARQ se dispone de la funcionalidad TransportQOS para habilitar la funcionalidad de reservación de ancho de banda RSVP, para servicios unidireccionales (orientado-al-receptor). Este intercambio de mensajes es la primer etapa propiamente dicha para establecer una llamada. Se muestra como encabezado de intercambio de mensajes en las distintas Figuras Bandwidth. Durante una conexión el terminal GW o el GK pueden requerir el cambio de ancho de banda del canal mediante el mensaje BCR (Bandwidth Change Request). No está mostrado en las Figuras Status. Se trata de un mensaje periódico (con período mayor a 10 segundos) que emite el GK al terminal GW para determinar el estado y requerir un diagnóstico. Son los mensajes IRQ (Information Request) y IRR (Information Response). La habilitación se realiza mediante willrespondtoirr enviado en el mensaje RCF o ACF. Como en los otros casos no se muestra en la Figuras anexas Mensajes de establecimiento de Comunicación. Los diferentes tipos de mensajes son tratados en el siguiente ítem y pueden ser seguidos con la ayuda de las Figuras 8 en adelante. 11

60 Monografías 4 (2003) SI: El softswitch -iplan Figura 8. Intercambio de mensajes para el caso de Llamada Completada Correctamente Secuencia de Mensajes de Comunicación. A continuación se describe la secuencia de mensajes de señalización para una llamada básica y algunos de los servicios soportados Llamada completada exitosamente (Figura 8). Se inicia con las funciones de Registración y Admisión (ítem anterior). Luego se pasa a la etapa de Setup de la llamada. Desde el GW1 se envía la información necesaria e interviene el server CSMU para ejecutar el call setup a través de los mensajes Q.931. La subunidad SU se encarga del proceso de enrutamiento de la llamada de acuerdo a la información contenida tanto en el mensaje de setup, como la información contenida en la base de datos propia y la información de registraciones de CPEs. Cuando el usuario B llamado tiene tono de llamada, se envía el mensaje de Alerting que permite ofrecer el tono de llamada al usuario A llamante. Cuando el usuario B responde a la llamada se envía el mensaje Connect. A partir de este momento la llamada está establecida. La señal vocal se intercambia en protocolo RTP. La negociación del codec utilizado (G.711 a 64 Kbps o G.729 a 8 kbps) se realiza entre los GW extremos. Si la llamada se dirige desde un usuario de Telefonía-IP hacia la PSTN, el GW2 será un Gateway-E1 de Interconexión. Cuando la comunicación se termina, el mensaje Rel_comp. Realiza las funciones necesarias para la tarifación Billing de la llamada. El cierre de la conexión se realiza mediante un intercambio de mensajes de pedido DRQ y confirmación DCF. El paso siguiente es enviar dicha información de Setup hacia el GW2 de destino, el cual solicita la admisión (mediante ARQ) y se confirma dicha operación. 12

61 Monografías 4 (2003) SI: El softswitch -iplan Figura 9. Llamada no completada. Arriba el usuario B está ocupado y debajo el usuario B no contesta Llamada no completada (Figura 9). En esta Figura se presentan dos casos. La secuencia indicada como (1) es idéntica a la de la Figura 8 (se ha evitado la parte correspondiente al RAS Server por simplicidad). En la secuencia indicada con (2) se muestra la interrupción de la llamada debido a que el usuario B está ocupado. Mientras que en (3), la causa de interrupción es que el usuario B no contesta la llamada. En el primer caso no llega a completarse la fase de Alerting (durante la cual que indica que el usuario B está llamando) y se pasa directamente a la fase de desconexión. En el segundo caso la fase de Alerting es interrumpido por el tiempo máximo Timeout, pasándose de inmediato a la desconexión. En ambas situaciones se genera el correspondiente ticket de Billing con la descripción de la interrupción (llamada infructuosa) Llamada rechazada (Figura 10). Podría darse la situación donde una llamada es rechazada porque el cliente se encuentra en una Lista Negra. En tal caso, nos encontramos con un intercambio reducido de mensajes. Interviene la Base de Datos del CSMU quien se encarga de rechazar la llamada en el mensaje de respuesta al setup. Esto inicia el proceso de desconexión de la llamada. Siempre, como en todos los casos, se genera un ticket de Billing que pasa a la lista de errores Desvío por no contesta y Desvío por ocupado (Figura 11). El desvío de llamada es un servicio de valor agregado ofrecido al cliente. En esta Figura se presentan dos casos. En el primero el usuario no contesta, razón por la cual luego de un Timeout se pasa a generar una llamada nueva hacia el GW3. Lo mismo se tiene previsto en caso que el usuario de ocupado. En este caso el mensaje DRQ da por terminado el intento sobre el GW2 e inicia el segundo intento sobre el GW3. 13

62 Monografías 4 (2003) SI: El softswitch -iplan Figura 10. Llamada rechazada por black list/screening. 7- FUTURO DEL SOFTSWITCH El softswitch es un desarrollo de largo aliento por la importancia estratégica de disponer de software que puedan ser manipulado en toda su extensión. Algunos temas para el futuro del softswitch son: -Admitir otros protocolos además de H Escalabilidad y crecimiento máximo por cada granja de servers. -Integración con sistemas de Billing para la venta a terceras empresas. -Generación e implementación de servicios a medida del cliente. Inicialmente, SI trabaja en protocolo H.323 ya que la primer generación de equipos implementados en iplan operaban en H.323. En la segunda generación se instaló el Call Manager que utiliza un protocolo propietario SCCP (o Skiny) y que hacia el exterior utiliza también H.323. En la tercer generación de equipos se utiliza el IAD-2430 de Cisco, también en H.323. Un próximo paso para el Softswitch es introducir otros protocolos de comunicación, como el SIP. iplan se encuentra en fase de estudio a largo plazo, referido a la conveniencia y consecuencias de introducir el protocolo SIP en la red. El softswitch SI tiene una estructura escalable. Sucesivamente incorpora Servers en la granja para incrementar la capacidad de procesamiento de las llamadas. La cantidad de llamadas simultáneas en la red de Telefonía- IP de iplan es cercana a 2500 hacia mediados del año La cantidad de líneas habilitadas es del orden de , lo que entrega 0,2 Erlang como carga de tráfico por línea en la hora pico. La escalabilidad y los límites de esta granja, así como la conveniencia de generar pequeñas granjas interconectadas, serán materia de estudio a mediano plazo. La posibilidad de venta del softswitch a otros operadores obliga a integrar el softswitch con sistemas de Billing. Esta tarea tiene un plazo de ejecución indeterminado. Una tarea de aplicación inmediata, es la generación de servicios a clientes. La generación de nuevos y novedosos servicios es la base de un Softswitch y es encarada en forma paralela a los demás ítem tecnológicos. El softswitch SI tiene el año 2003 como el de implementación básica y el 2004 como año de expansión de servicios. 14

63 Monografías 4 (2003) SI: El softswitch -iplan Figura 11. Desvío de llamada. Arriba debido a que el usuario B no contesta y debajo porque está ocupado. 15

64 Monografías 4 (2003) SI: El softswitch -iplan MONOGRAFIAS DE J: Journal monografías número 4. Editado agosto Diseño editorial a cargo de Marianela V. Ricardo 16

65 monografía iplantech Journal Monografías es una publicación de iplan que contiene información técnica y confidencial de la empresa. Se distribuye a un circuito limitado de lectores a fin de mantenerlos informados sobre el estado y la evolución de la tecnología y el negocio de la Telecomunicaciones, principalmente en las redes IP y la Telefonía-IP. Se ruega a los lectores a mantener el principio de Confidencialidad sobre la información aquí contenida. No está autorizada su reproducción o distribución por cualquier medio sin antes consultar con la empresa. ITelefonía iplan: el balance óptimo. La telefonía en iplan es el balance óptimo entre una red de Telefonía-IP para servicios de líneas analógicas y transporte SDH para las tramas E1. IINDICE 1- La generación del start-up ( ). 2- El switch clase-5 y transporte SDH. 3- Solución coyuntural ( ). 4- La generación definitiva ( ). 5- El tráfico telefónico. IABSTRACT El Balance Optimo se logra con la Telefonía-IP para aplicaciones de líneas analógicas y el transporte SDH para clientes E1. Se dispone de un switch class-5 para asegurar la interconexión ITX con la PSTN. Las ventajas derivadas de la Telefonía-IP en la red de distribución de líneas analógicas se han visto en nuestro Journal No 1. En esta edición nos concentramos en la evolución de los componentes centrales de la red de telefonía. Se analizan 3 generaciones de equipos aplicados a la red. La generación definitiva implementada desde el año 2003 incluye diferentes desarrollos de iplan a medida de las necesidades. Varios componentes básicos han sido analizados en números anteriores de Journal. Entre ellos nos encontramos con la tecnología COSO, la tecnología Softphone y el Softswitch. Algunos otros componentes serán materia de próximos Journal, como el gateway IP-IP. 1

66 Monografías 5 (2003) Telefonía: El balance óptimo 1- LA GENERACIÓN DEL STARTUP ( ) 1.1- Telefonía-IP sobre GbE o ATM?. Los primeros documentos de iplan a inicios de 1999 (en aquella época se denominaban NIT -Normas Internas Técnicas-), contenían referencias al transporte SDH y a la conmutación de circuitos, superpuesta a la red IP para datos e Internet. Sin embargo, la ilusión era realizar una red absolutamente IP, que integrara la telefonía (conmutación de paquetes) y los datos. Hacia mediados de 1999, los análisis realizados con posibles proveedores indicaban la alta factibilidad de desarrollar una red de transporte Gigabit en lugar de SDH o ATM y la integración de la telefonía sobre IP. La red final, como se sabe, quedó formada por un transporte IP-Gigabit para los servicios de datos y para las líneas analógicas de telefonía y otra red SDH para tramas E1 de alto tráfico. Esta monografía se ocupa de como evolucionó la historia hasta tener una red con lo mejor de cada modelo. Una de las preguntas primogénitas se relacionaba con el transporte del protocolo IP, mediante ATM o Gigabit?. Una visión personal indicaba que ATM había tenido la oportunidad durante todos los años 90 para conquistar el mercado y no lo había logrado. En cambio, los protocolos IP y Ethernet estaban decididamente a la ofensiva. El corazón indicaba una orientación determinada, se necesitaba convencer al cerebro (...y al bolsillo). Para convencer al cerebro, se preparó una comparativa técnica entre ambos modelos. El modelo ATM consideraba un Backbone de 622 Mbps, con Hubs de 622 Mbps y Nodos de Acceso de 155 Mbps. Los clientes debían disponer de una conexión Ethernet para ofrecer servicios IP y telefonía mediante tramas E1. Si se requerían líneas analógicas se necesitaba un multiplexor apropiado, que no se incluyó en el análisis. Esta ausencia, el de no incluir las líneas analógicas en el análisis de ATM, habría sido un error fatal en caso de seleccionar ATM. Otras empresas adoptaron este modelo y un par de años después se arrepentirían. El modelo ATM se demostraría insaciable en costos para ofrecer líneas analógicas. Para convencer al bolsillo, se planteó un Modelo de Evaluación de 3 niveles en la red. El nivel superior es ocupado por el Backbone o Core de la red; por ejemplo 4 sitios (2 en Buenos Aires incluido el NOC, Rosario y Córdoba). El segundo es ocupado por los Hubs de la red (para concentración y distribución por zonas). El tercero es el acceso que corresponde a un edificio en particular. La evaluación tomaba en cuenta en forma preferencial el costo del primer port (el primer cliente en el edificio) y el crecimiento de los costos en forma de escalera para los clientes sucesivos. Se trataba del Modelo de Distribución mediante un Nodo de Edificio (aún no estaba la idea del Nodo de Manzana). Los resultados fueron concluyentes. En todos los casos ATM era más caro que Gigabit, esta diferencia se hacía mucho más notoria en los equipos de acceso. La diferencia entre tecnologías era más evidente en la medida que se incrementa el número de ports en el Nodo. Por ejemplo, para el primer port Ethernet la diferencia de precio era del orden del 40% (ATM con 146 Ku$s y Gigabit con 105 Ku$s). Cuando la red llegaba a unos 500 ports Ethernet, la diferencia aumentaba al 100%. La cantidad de ports Ethernet que poseía iplan a medidos del 2003 es cercana a los 3000 ports en Buenos Aires. Por ello, el costo inicial de ATM era mayor a Gigabit y la escalabilidad menor. Es decir, existía una importante diferencia en costo inicial y la misma se incrementaba con el número de ports Ethernet de clientes. Este cálculo comparativo fue realizado tomando en cuenta el esquema de Nodo de Edificio, pero dos años más tarde, con el esquema de Nodo de Manzana, la comparativa sería mejor aún para Gigabit. Que la decisión de seleccionar Gigabit (junto con la Telefonía-IP) fue buena, se puso en evidencia claramente durante el 2002, cuando ninguna otra empresa podía competir con iplan en los productos de líneas analógicas (el producto Pack representa un tercio de los ingresos de la empresa). En la decisión final de la tecnología coincidieron el corazón, el cerebro y el bolsillo. Lo mismo ocurriría con el proveedor de los equipos: Cisco Los componentes de la telefonía. Con el nombre Proyecto 811, haciendo referencia a la fecha en que el Estado había fijado el fin del monopolio en la telefonía (8 de noviembre del 2000), se designó el proceso de puesta en marcha del sistema durante el año El Proyecto 811 fue una provocación para retar a la capacidad de creación e iniciar el startup con clientes amigables el mismo día de la apertura del mercado. Luego veríamos que los clientes no serían tan amigables en los malos momentos y que el período de prueba no sería tan corto, extendiéndose más allá de lo deseado. Los componentes de la red de telefonía, desde fines del 2000 hasta principios del 2002, fueron los siguientes (indicados en la Figura 1): 1- La central de conmutación NEC. La decisión de colocar una central de conmutación convencional (switch Class-5) como interconexión hacia la red pública PSTN se tomó como precaución ante la posibilidad de fallas durante el startup de la Telefonía-IP. En esta primer etapa solo se colocó una central en Buenos Aires, siendo la interconexión en Rosario y Córdoba mediante equipos Gateway-E1 (Cisco-AS5300). La decisión de colocar la central se mostró acertada en el futuro por varias razones: 1.1- Por un lado, el período de startup de la plataforma IP duró cerca de 6 meses (más de lo esperado, pero no tanto como nos pareció en ese momento). Además, en Rosario y Córdoba nunca se pudo estabilizar completamente el funcionamiento hasta llegar a la segunda etapa, durante el

67 Monografías 5 (2003) Telefonía: El balance óptimo Figura 1. La primera generación tecnológica contenía un softswitch de HP (llamado OCMC) y Gateways de borde Cisco-2600 para clientes y Gateways-E1 Cisco-5300 hacia la central de conmutación NEC. Esta figura se complementa más adelante con los años posteriores Los servicios E1 soportados en IP con Gateway-E1 nunca funcionaron a satisfacción con clientes de alto tráfico. Una causa es la capacidad de procesamiento de llamadas del hardware y otra es la falta de adaptación entre el gateway y algunas PABX de usuario en señalización MFCR Además, para clientes con tramas E1, la tecnología IP es mas cara aún que la SDH, aunque es más económica para clientes de líneas analógicas FXS Por último, no pudo lograrse una Interconexión ITX completa en tecnología IP directamente desde los Gateway Cisco-AS5300 con los otros Operadores. Con Telecom fue posible hacerlo desde el 2001, pero resultó imposible con Telefónica. Esto se debió a la ausencia en aquella época de ciertos features en los gateways de ITX y de su sistema de control Cisco-SC2200, ligados a la tecnología H323 subyacente. 2- La Interconexión ITX. Se trata de las tramas E1 entre iplan y la red pública PSTN. Inicialmente se solicitaron tramas E1 en el NOC de iplan para acelerar los tiempos. Mientras tanto se construía la red y se tomaba una Coubicación en las Telcos. A mediados del 2001 ya estaba realizada la construcción hasta ambas empresas (Tasa en Barracas, Teco en Belgrano y en el 2002 con Teco en Clínicas). El enlace de interconexión no dejaría de ampliarse al ritmo del incremento de tráfico telefónico. Inicialmente se usaron los equipos SDH de Cisco que permitían trabajar con solo 8 tramas E1. Mas tarde en el 2001, se utilizarían equipos AsGa con 21 tramas E1. A fines del 2002 se instalaban los primeros SDH de 63 tramas E1, formalizando de esta manera la ITX con topología de anillo. La capacidad de la ITX nunca estuvo holgada hasta mediados del La entrega de tramas por parte de las Telco fue en cuenta gotas y cuando la congestión estaba consumada. Aunque los requerimientos se realizaran con mayor anticipación a lo indicado por el Contrato respectivo. Se trata de un modus operandi, que fuera aplicado con mayor dureza desde el 2001, obstaculizando la ITX con pequeñas empresas. Muchos de los negocios Wholesale del mercado serían con pequeñas empresas, que aún teniendo Licencia de operador, requieren de otra empresa intermediaria para hacer tránsito hacia las Telco. 3- Los Gateway-E1. Para interconectar la red de Telefonía- IP con la central se utilizaron equipos Cisco AS A partir del 2002 la introducción de equipos Cisco-5350 permitía disponer de gateways duales (para telefonía y dialup) Respecto de la ITX mediante Gateway-IP solo fue posible hacerlo desde el principio con Telecom. Poner un gateway Cisco-AS5300 en coubicación traía el riesgo de que si el equipo sufría un inconveniente deberíamos movilizarnos hasta la coubicación. Llegar con 3

68 Monografías 5 (2003) Telefonía: El balance óptimo SDH era más robusto, ya que los equipos SDH son más pasivos y de configuración más estática que un gateway. Estos gateways se utilizan actualmente solo para tráfico saliente, ya que el tráfico entrante trae también llamadas de dial-up (modem de Internet) que deben ser atendidos por access server duales Este hecho demostró ser un punto faltante de nuestra solución, pero la distribución de tráfico de iplan justificaba de sobremanera tener rutas solo salientes. Se requirió entonces conectar tramas desde la NEC lo cual llevó a la interconexión SDH. 4- Procesador de señalización SS7. Dentro de la red de Telefonía-IP se dispone del procesador de señalización SC2200 de Cisco para manejar los protocolos SS7. Este equipo hace la interfaz en SS7 entre la central NEC y la nube de VoIP (Voice over IP). 5- El softswitch OCMC. El softswitch del startup fue el OCMC de HP. El Softswitch es un software que permite ofrecer servicios de telefonía además de la simple llamada telefónica. Desde el inicio, el equipo presentaba fallas de estabilidad y falta de flexibilidad. Además, las promesas de servicios que eran de estante, en realidad estaban en pleno desarrollo. La versión de software para servicios Starvox sufrió varios upgrades y updates de parches. Para mediados de mayo 2001, se contaba con una versión de software que presentaba un cierto grado de estabilidad, pero estaba muy relacionada al escaso tráfico que en ese momento se estaba cursando. Para fines del 2001, el tráfico de telefonía obstaculizaba el funcionamiento del OCMC, si bien los valores de llamadas concurrentes y CPS (Calls Per Second) estaban aún muy lejos de las especificaciones. Se hacía inmanejable la interfase de aprovisionamiento y algunos equipos comenzaron a caerse. HP acudió al desarrollista del stack H.323 (la empresa israelí RadVission) y ellos encuentran que el origen del problema estaba en el código del stack. Sin embargo, los problemas continuaron y en abril-2002 se decide migrar todos los gateways registrados en el OCMC a Gatekeepers de Cisco (7400ASR1). Si bien esta solución dejaba afuera la posibilidad de generar CDRs (los ticket de tarifación) dentro de la red de Telefonía-IP y algunos pocos servicios mínimos que estaban disponibles en el OCMC, las llamadas pasarían por la central NEC, por lo que los CDRs para facturar estaban disponibles. Este cambio en la topología se verá reflejado en la Figura Los Gateway de usuario FXS y E1. La primera etapa, desde noviembre-2000, se realizó con equipos en la casa del usuario (CPE). Se adquirieron cerca de 1200 líneas analógicas FXS en Gateway de 4 líneas (Cisco-1750 y 2600). Se trataba del modelo de distribución mediante Nodos de Edificio. Se recuerdan memorables y acrobáticas anécdotas sobre los reclamos del Director de Ventas a este modelo, las acrobacias correspondían a la forma de indicar como debía vender todo en un solo edificio. Resultó un duro aprendizaje sobre la validez de un modelo importado y que otras empresas siguieron por mucho más tiempo. Esta primera etapa estaba identificada con el modelo de Nodo de Edificio y FTTB (Fiber To The Building). Startup en el NOC de iplan, noviembre

69 Monografías 5 (2003) Telefonía: El balance óptimo El modelo de Nodo de Manzana se inició en julio-2001 para solucionar los problemas de alto costo de inversión y dificultades de comercialización del modelo CPE. Se pasó entonces a un modelo de distribución de baja densidad con Nodos de Manzana. Este modelo utiliza un Gateway-E1 (Cisco-2611 o VG200) junto a un multiplexor de 30 líneas Edgelink. En ambos modelos, el Softswitch y Gatekepeer era el OCMC y el protocolo de comunicación el H.323. En adelante los esfuerzos en el despliegue de red estaban puestos en el Local Loop de cobre. Veamos algunos de los problemas detectados en los Gateway durante el start-up y su solución. Los equipos 1750 con líneas analógicas sufrían de re-boot, no pasaban los fax, faltaba la funcionalidad de caller ID, no había rotatividad integral de líneas con clientes de dos equipos. En cambio, los gateway para clientes E1 Cisco-2610 tenían un tiempo de establecimiento de llamada elevado y escasa respuesta en la capacidad de procesamiento para clientes de alto tráfico. Para el problema del equipo Cisco-1750 se buscó la solución de cambiar a gateway de mayor poder de procesamiento, los Cisco-2610 con 4 líneas analógicas. Para el problema de los gateway E1 se cambió del Cisco al 2650 y en los casos de clientes de alto tráfico se cambió a enlaces PDH/SDH. 2- EL SWITCH CLASS-5 Y TRANSPORTE SDH 2.1- El transporte PDH/SDH. Si bien el backbone de la red es Gigabit, nuestra red también tiene una larga lista de enlaces de acceso por fibra óptica mediante equipos PDH o SDH. Por lo expresado más arriba, la ITX con las Telco y los clientes de alto tráfico en E1 requieren enlaces que no sean IP. Los primeros equipos SDH que se instalaron fueron los Cisco Inicialmente, Cisco disponía de un plan de expansión sobre esta línea de productos, que luego abortó. Cada equipo dispone de interfaz SDH de 155 Mbps y con la posibilidad de acceder a solo 8 tramas E1. Los costos eran muy elevados y nos obligó a analizar otras alternativas de proveedores. Finalmente los equipos de AsGa fueron los seleccionados, debido al bajo costo para una granularidad reducida, como la requerida por nuestros clientes. Los primeros equipos AsGa en el 2001 fueron para el acceso punto-a-punto de E1 por FO. En el 2002 se paso a comprar equipos SDH, primero de 21xE1 para la interconexión. Luego serían llevados a los Hubs y Nodos cuando se ampliaron los equipos de ITX a 63xE1 en el Los enlaces de interconexión en Buenos Aires, Rosario y Córdoba estarían desde ese momento anillados por caminos diferentes y con equipos de 63xE1. A partir de la necesidad de servir a clientes de alto tráfico con enlaces transparentes (no IP) hasta la central de conmutación, sumado a la necesidad de interconexión con las operadoras telefónicas, se comenzó a desarrollar una reducida red SDH. El proceso se acelera ante la necesidad de incorporar clientes que tradicionalmente fueron servidos con red SDH por otras empresas competidoras Ampliación del switch class-5. La central NEC llegó en la versión Neax-61 Sigma Compacta con solo 32 tramas E1 en octubre-2000 y se instaló solo en Buenos Aires. Figura 2. Modelo de anillo típico en SDH que tiene accesos PDH (NxE1) hasta los clientes. 5

70 Monografías 5 (2003) Telefonía: El balance óptimo Un documento de inicios del 2001 (a dos meses de la liberalización del mercado), decía: El dato de entrada es que hemos vendido en unos meses tantas E1 como planeamos para un año. La conclusión es que se está modificando el mercado de las E1; cosa que siempre se estimó que ocurriera en el mercado de los datos (en donde la red IP-Gigabit está mejor preparada técnicamente). Veamos algunos elementos de análisis: 1- Muy probablemente no estamos considerando el mercado en competencia de 2000 tramas E1 del año 1999 en Argentina (20 tramas E1 vendidas en un mes sería el 1% del mercado, es poco razonable). En realidad, con una nueva estructura de precios se está llevando a un cliente de más de 10 líneas hacia una trama E1. En muchos casos se está agregando otra E1 a un cliente que ya está funcionando con el proveedor anterior (Telefónica o Telecom). Es decir, se está modificando el mercado de las E1, se multiplica casi por 4. La conclusión es que al modificar el mercado en cuanto a la cantidad de tramas E1 en juego, el volumen de tráfico y facturación por cada E1 debería disminuir. 2- Existe entonces una incidencia en el tráfico telefónico. La cantidad de Erlang (unidad de medida de tráfico) que genera el cliente debe ser menor en cada E1 que se instala. Esto es así por dos causas: el cliente necesitaba menos líneas que las adquiridas y además el nuevo entrante no es el único proveedor del servicio. Por esta razón, nos encontraremos con una fuerte concentración de tramas E1 entre el lado iplan y la red pública (PSTN). El grado de esta concentración deberá ser medida en forma constante ya que no existen antecedentes de un mercado de este tipo. El grado de concentración puede ser cercano a Si trasladamos esto al mercado de los datos e Internet, lo que quisiéramos ver es que los clientes que normalmente utilizan velocidades de Nx64 Kbps pasen a velocidades Nx1 Mbps. Otra vez, se trata de una migración hacia velocidades superiores donde el volumen de información transferida no aumenta tanto como la velocidad de conexión. Muchos operadores no pueden seguir esta migración (cosa que en telefonía si pueden hacerlo y fácilmente). Y así fue, se vendieron gran cantidad de E1, con un tráfico por cada una de ellas normalmente bajo. La facturación promedio, medida por cada trama E1 fue reduciéndose con el transcurso del tiempo, debido a la sobreventa de E1 a clientes que normalmente no estarían interesados. Lo cierto es que la central de conmutación no detendría el proceso de ampliación. Hacia abril-2002 el acuerdo con NEC incluía el traslado de la Neax Compacta desde Buenos Aires a Córdoba con 48 tramas E1; la instalación de una central Neax-61 con 32 tramas E1 en Rosario y la instalación de una central Neax Multiprocesamiento con 650 tramas E1 en Buenos Aires. A mediados del 2003, una pequeña ampliación de 32 tramas E1 adicionales se contrataba a NEC para la ciudad de Córdoba. La Neax-61 de Rosario era un caso aparte (una tecnología pasada de moda que se estaba utilizando debido a razones de control de las inversiones). A mitad del año 2002 estaban las centrales en operación en Córdoba y Rosario. En ambas ciudades la calidad de servicio estaba degradada debido a que la tecnología de tramas E1 mediante IP no respondía a clientes de alto tráfico. Por otro lado, se sumaban los problemas del core de Telefonía-IP debido al OCMC y los cortes del enlace interurbano debido al robo de cables. Este último problema solo se solucionó con la segurización de los enlaces de transmisión por distintos proveedores. Simultáneamente a la ampliación y movilización de centrales, se tenía un problema de software con el cliente Bolsa de Comercio. Desde abril-2002 el cliente Bolsa de Comercio decía tener dificultades en las llamadas salientes hacia ciertos destinos. La primer reacción se orientó a buscar las causas en la PABX del cliente. Este problema se repetiría luego sobre otros clientes con distintas centrales PABX. Después de un detallado y extenso análisis se llegó a determinar que la central de conmutación no se ajustaba a todas las normas nacionales e internacionales sobre señalización R2. A fines del 2002 el bug estaba corregido. 3- SOLUCIÓN COYUNTURAL ( ) 3.1- Introducción del Call Manager. La segunda generación de la red de telefonía incluía los siguientes cambios: -la salida de servicio del OCMC (y entrada de los 7400), -el ingreso del Call Manager como un dominio separado, -ampliación de la ITX con centrales en Rosario y Córdoba. Estos puntos se muestran como una evolución desde la Figura 1 a la Figura 3. A fines del 2001 quedaba claro que la topología existente del startup no podía continuar por mucho tiempo. Esto motivó la búsqueda de una alternativa dentro del portafolio de Cisco. La única alternativa disponible en aquel momento era el Call Manager. Con posterioridad dispondría del softswitch BTS, que solo fue liberado a la venta para América Latina en el El Call Manager es un sistema más adaptado al mercado de grandes empresas que al de Operadores; claro que cuando Cisco dice grandes empresas se trata de empresas muy, pero muy grandes. El Call Manager estuvo revoloteando durante bastante tiempo. Siempre el freno fue el costo por línea, ya que basaba sus servicio en los teléfonos IP (IPphone), cuyo costo los convertían en una curiosidad técnica, mas que un equipo comercializable. Con el advenimiento del gateway analógico de alta densidad VG248 para el Call Manager, las cuentas cerraron. Este sistema permite no solo brindar el servicio de telefonía con sus IP-phone, sino además el servicio de líneas analógicas FXS desde los equipos VG248. Había estado bajo prueba desde diciembre-2001, y los equipos definitivos fueron puestos en marcha en marzo Permitiría brindar nuevos servicios en cuanto los mismos estuvieran probados y consensuados. 6

71 Monografías 5 (2003) Telefonía: El balance óptimo Figura 3. Esquema continuación de la Figura 1. Ingresa en servicio el Call Manager de Cisco y sale el softswitch OCMC. En esta etapa se tienen dos Dominios de Telefonía-IP distintos. Los problemas iniciales del Call Manager duraron muy poco. Uno de los problemas se debió al tamaño de las tablas de enrutamiento de telefonía definidas por iplan para el servicio a brindar. Mientras que, una serie de bugs de software se fueron corrigiendo con cambios de versiones sucesivas. La mayor cantidad de bugs encontrados se debían a lo nuevo del gateway analógico VG248. En menos de un mes tenía cerca de 40 clientes conectados (unas 200 líneas). Al día de hoy, el Call Manager está orientado a ofrecer los servicios de Pack de telefonía analógica en el área de Buenos Aires. Tiene cerca de 6500 líneas conectadas. Pero, no permite ofrecer servicios E Componentes del Call Manager. Los equipos introducidos para el Call Manager forman un cluster de Server para distintas funciones, a saber: -Servers Publisher: Disponen de la Base de Datos (tiene los CDR para billing, para diagnóstico, tiene registradas las líneas, el Plan de Discado, la configuración de los servers, etc) y brinda la interfase web de administración para el personal de Operaciones. -Server de Back-up & TFTP: Cuando el VG248 se inicializa o es configurado, envía el archivo de configuración de cada línea usando el protocolo TFTP. Adicionalmente, cumple con las funciones de backup de los Server subscribers. -Server de Back-up & H323: Es la interfaz de protocolo H323 de todo el Cluster, todas las llamadas entrantes al Cluster utilizan recursos de este servidor. También cumple funciones de backup de los subscribers. Tiene la limitación de 1000 llamadas simultáneas hacia los gateway de ITX Cisco-5300 y por ello se estima en 5000 la cantidad máxima de líneas sobre el cluster de servers. -Servers de Subscriber: Atienden las registraciones de 1250 líneas cada uno y enruta las llamadas al dispositivo indicado. -Servers de Gatekeeper 7400-IGK: Uno de ellos tiene registrados los números de las líneas de Call Manager. Dialoga con el 7400 que está orientado a manejar los Cisco que interconectan la nube IP con la central de conmutación, además de los gateway VG200+Edgelink. La configuración máxima instalada en nuestra red es de dos cluster de 7 y 3 servidores respectivamente, para manejar 6500 líneas analógicas. Los equipos de borde se ubican en el cliente o en los Nodos de Manzana, pudiendo ser los siguientes: -Gateway VG248: Son multiplexores de 48 líneas analógicas que convierten a la Telefonía-IP. Se colocan en el Nodo de Manzana. Es el único equipo utilizado ampliamente en iplan; los siguientes tres equipos se han probado con usuarios internos y son equipos que se colocan en el cliente (función de CPE). 7

72 Monografías 5 (2003) Telefonía: El balance óptimo -ATA188: Este CPE permite ofrecer el servicio Pack-2 (dos líneas analógicas e Internet). -IP-phone: Es un teléfono-ip conectado a una LAN del cliente. Su costo aún es prohibitivo. Su aspecto se muestra en la fotografía anexa. -Softphone: Es una versión de un IP-phone que trabaja desde una PC Funcionamiento y Servicios. A la hora de realizar una llamada telefónica, intervienen los siguientes componentes del sistema: -Gateway (VG248 o ATA188): Se encargan de transformar la voz y los números de destino discados por el usuario en paquetes IP entendibles por el resto de la plataforma. -Call Manager: Es la parte inteligente de la plataforma. Recibe los paquetes IP provenientes desde los VG248, ATA188, SoftPhone o IP-phones y los interpreta para poder decidir como rutear la llamada, si enviar un tono de ocupado o uno de llamada en progreso, etc. Figura 4. Diagrama reducido de componentes para el Call Manager..Fotografías del cluster de Call Manager a la izquierda y de un nodo de manzana con los Gateway VG248 a la derecha. 8

73 Monografías 5 (2003) Telefonía: El balance óptimo -Gatekeeper: Si la llamada es hacia un número que no corresponde a un abonado del Call Manager, éste le pregunta al Gatekeeper con quien debe dialogar para completar la llamada. -NASGW-5300: Si la llamada corresponde a un número de otra empresa Operadora (Telefónica, Telecom, Nextel, etc.), la misma termina su flujo IP en estos equipos. Estos gateways traducen los paquetes IP en audio, enviándolo por las tramas de ITX hacia la operadora correspondiente. Cuando un usuario toma la línea para realizar una llamada, esto es interpretado por el VG248 quien transforma el evento en un paquete IP y lo envía hacia el Call Manager. Éste le devuelve el tono de invitación a marcar y queda a la espera de los dígitos del número de destino. Cada dígito marcado por el usuario, es analizado por el Call Manager, quien decide si corresponde a un número permitido para esa línea en particular. Por ejemplo, si el usuario marca como primeros dos dígitos el 15, el Call Manager seguirá aceptando dígitos solo si esta línea tiene permitidos los llamados a celulares CPP. De esta manera, todas las restricciones sobre las líneas de los clientes se configuran en el Call Manager, permitiendo así centralizar la configuración en un solo equipo. En caso que el número de destino recibido sea un patrón restringido, el Call Manager devolverá un tono de error. Una vez que el Call Manager tiene el número de destino completo intentará completar la llamada. Si corresponde a un abonado del Call Manager, éste completa la llamada indicando al gateway que origina la llamada con quien debe dialogar. Así, los dos gateways de origen y destino establecen entre ellos el flujo RTP (canal de audio sobre IP), según las indicaciones que del Call Manager. Si el destino es un número de la red pública PSTN, derivará la llamada hacia el Gatekeeper, quien buscará la salida a través de uno de los gateways de ITX. En este caso, el gateway de origen establece el flujo RTP contra uno de los NASGW-5300 hacia la PSTN.Actualmente el Call Manager es usado para ofrecer el servicio Pack de líneas analógicas en Buenos Aires. Los features de este servicio son deliberadamente limitados: llamada directa entrante/saliente desde la red pública; presuscripción a carriers y rotatividad entre líneas asignadas.es posible ofrecer el servicio de PABX-Virtual. Un servicio que reemplaza la PABX del cliente por una grupo de líneas analógicas provenientes de dispositivos controlados por el Call Manager (por ejemplo, del VG248). Los features son los mismos del caso anterior y se agregan los siguientes: -Llamadas directas entrante la red Privada del cliente. -CLIR (Calling Line Identity Restriction) Next Call: es la anulación en el destino del número de identificación (ANI) del origen de la llamada. -Caller ID: puede verse el ANI del usuario llamante. -Retención de Llamados: poner la llamada on-hold mientras se atiende otra. -Llamado en Espera: reconocer una llamada entrante mientras se atiende otra comunicación. -Transferencia de Llamados entre números internos. -Desvío de Llamados a números pre-configurados. -Captura de llamadas desde un interno cualquiera. El servicio IP-Centrex posibilita la comunicación entre sucursales (distintos domicilios) mediante discado abreviado. Las líneas de ambas sucursales deben provenir de dispositivos controlados por el Call Manager. Los features son los mismos al caso anterior Limitaciones del Call Manager. El proyecto de Call Manager no convencía totalmente. Primero porque utiliza un protocolo de comunicación denominado Skiny o SCCP, que es propietario de Cisco y por ello no es compatible con los equipos H.323 en servicio. Los servidores del Call Manager corren sobre Sistema Operativo Windows-2000 y muchos desconfían de su estabilidad de este software. Por otro lado, Cisco no tiene equipos para ofrecer tramas E1 sobre el Call Manager (por ejemplo, como los equipos 2600 que trabajan con protocolo H.323). La disponibilidad de compra a futuro era incierta, ya que Cisco clasificó este producto como Enterprise y no podía ser vendido a Operadores como iplan. El producto era ofertado como está e iplan no podía esperar futuras adaptaciones o soluciones customizadas. Por otro lado, la crisis del 2002 obligó a agudizar la imaginación para racionalizar las inversiones en dólares (flotante) con las tarifas en pesos (congeladas). Con ello las ampliaciones del Call Manager consideradas a inicios del 2002 se habían diluido a inicios del Era el momento de cambiar de planes: el Call Manager no era una plataforma con futuro para iplan. Sobrevendría entonces la última y más importante transformación. 4- LA GENERACIÓN DEFINITIVA ( ) En la Figura 5 se observa una fuertes evolución y cambios, respecto de la Figura 1 y 3. La estructura de la red definitiva (al menos por el momento) está en marcha. Un resumen de los cambios son los siguientes: -ampliación de las centrales de conmutación en las distintas ciudades, -ingresa el software COSO (la plataforma de servicios de red inteligente), -ingresa el Softswitch SI (controlando la primer generación y los nuevos gateways), -ingresan nuevos gateways (tanto de E1 como de FXS) y -ingresa el Gateway IP-IP como interfaz entre los Dominios de Telefonía-IP en iplan y el Dominio de Internet. 9

74 Monografías 5 (2003) Telefonía: El balance óptimo Figura 5. Tercera Generación en la Telefonía-IP como continuación de la Figura 3. Se mantiene el Call Manager y el remanente de la Primera Generación pasa a formar parte del nuevo Dominio Softswitch SI El switch class-5 y COSO. Ya se indicó con anterioridad la extensión y ampliación de las centrales de conmutación durante el año Sin embargo, la estructura definitiva de las centrales de conmutación no estaba terminada. La central de Córdoba fue ampliada a mediados del 2003 a 80 tramas, con una capacidad de crecimiento hasta 172 tramas E1. El caso de la central de Rosario es mucho más complejo de resolver. Veamos porqué. La central Neax-61 con 32 tramas E1 en Rosario es de una generación anterior. Se tomó esta opción en su momento debido a la restricción de inversiones. Sin embargo, seguir creciendo sobre esta tecnología tiene serias limitaciones técnicas. Las posibles alternativas analizadas han sido: Figura 6. Componentes de COSO (tomado de Journal Monografía No 2). 10

75 Monografías 5 (2003) Telefonía: El balance óptimo -Ampliación de la Neax-61E. La central ocupa un espacio exagerado debido a que es una tecnología antigua. El consumo de energía y aire acondicionado es excesivo. La metodología para obtener los CDR es muy endeble y no puede perdurar a futuro. La ampliación directa de esta central tenía la ventaja de requerir una inversión reducida, pero se trata de patear el problema para adelante. -Ampliación y cambio del procesador. Esta alternativa consideraba el cambio el precedente procesador CP91 por el CP101E. Lo cual permite reducir el consumo de energía y el espacio ocupado. -Cambio de la central. En este caso se podría pasar a una Neax-Compacta como la de Córdoba o una central de otra marca similar. Mantener la tecnología Neax-Compacta en ambas ciudades es una ventaja importante, sin embargo, en el pasado se había analizado la central EWSD de Siemens y se consideró una mejor solución técnica. -Remotizar la central de Rosario. Esta variante consiste en eliminar la central Neax-61E de Rosario y transportar el tráfico de telefonía en forma IP y E1 hasta Buenos Aires. Esta variante no es nueva, debido a que la ciudad de La Plata está remotizada desde Buenos Aires desde el inicio de las operaciones en dicha ciudad. La decisión deberá ser tomada a fines del Sin embargo en el 2002 ya existía un problema que requería una atención inmediata. La plataforma de telefonía NEC en iplan no disponía hasta el 2003 de servicios de red inteligente. Para la traslación numérica se estaba utilizando una funcionalidad de la central de conmutación, que tiene un número limitado de índices de edición los que permiten convertir un número de entrada en otro de salida. Se trata sólo de 64 índices y todos ellos estaban siendo utilizados a medidos del 2002, para configuraciones de las presuscripciones de carriers (2 índices por carrier), servicios de 0800 de clientes, para los desvíos a números de la PSTN cuando el cliente aún no estaba conectado, y para configuraciones de numeraciones de enrutamiento. La solución definitiva a este problema llegaría con el diseño de la Plataforma COSO. Esta plataforma de Red Inteligente entró en servicio de pruebas en enero-2003 y en servicio operativo desde marzo El Journal Monografía No2 fue dedicado a este tema con exclusividad, por lo que en el presente número, nos basta con mencionar la introducción de este software de Red Inteligente en la red a inicios del El Softswitch SI. También el Softswitch merece un Journal dedicado (es el número 4). Ahora solo exponemos las implicancias desde el punto de vista de la topología general de la telefonía. Se entiende por Softswitch al conjunto de software que permiten realizar las comunicaciones telefónicas IP y brindar servicios diferenciales. Antes de encarar el desarrollo interno del Softswitch SI, se analizaron 3 variantes de softswitch en dos años: OCMC de HP, NetCentrex y Alcatel. En el 2002 ensayamos versiones libres de softswitch sobre Linux lo cual nos había llevado a la convicción que era posible hacer nuestro propio softswitch. Con todo esto se obtuvo suficiente experiencia como para diseñar la arquitectura de un softswitch y encarar la inmediata programación. Desde el punto de vista topológico el Softswitch iplan SI se inserta inicialmente con los Gateway FXS de nueva generación, para luego tomar el control del los equipos Cisco-2600 (con multiplexores Edgelink que formaban la primer generación tecnológica). Esto significa que un solo Dominio involucrará a todos los gateways. Este dominio es inicialmente H.323, la posibilidad de convertir la red al protocolo SIP está en estudio. Figura 7. Componentes del Softswitch SI. 11

76 Monografías 5 (2003) Telefonía: El balance óptimo Los servicios que serán ofrecidos mediante el softswitch son diversos y, seguramente en el futuro, novedosos. Veamos solo algunos ejemplos: -Servicios mandatarios de la CNC. Por ejemplo, presentación restringida del ANI conocido como CLIR. -Generación de CDR para la facturación de llamadas entre clientes de Telefonía-IP y reportes de tráfico. -IPCentrex para todos los clientes IP (hoy es posible solo sobre los conectados al Call Manager). -Voice . Consiste en grabar un mensaje cuando el teléfono está ocupado o no responde y enviar dicho mensaje mediante un (ideal para el producto Softphone cuando la PC está apagada). -Línea control con un máximo de consumo posible (funcionando similar a una Calling Card donde el PIN de identificación ahora es el ANI del usuario). -Otros servicios de valor agregado (ejemplos, desvío de llamada, llamada en espera, presuscripción de carrier, etc). El Dominio del Call Manager quedará como una isla de protocolo SCCP, la cual se comunicará al mundo exterior mediante el Softswitch SI en protocolo H Gateway FXS, E1 y IP-IP Generalidades. Al Softswitch SI se registrarán los distintos gateway de usuario. Durante varios años hemos revisado con atención los gateways H.323 de pocas líneas (generalmente de 2, 4, 8, 16, 24 y 48). Los de gran cantidad de líneas se ubicarán en los Nodos de Manzana y los de pocas líneas como CPE en la casa de usuario. Esta última alternativa merece un párrafo a parte. Iplan inició las operaciones con el modelo CPE (equipos Cisco-1750/2610 con 4 ports analógicos FXS). Este modelo se mostró ineficiente debido a la necesidad de colocar muchos equipos en el usuario. Por otro lado, requería mantener la alimentación local en caso de corte de suministro. A primera vista no es un buen modelo para volver a intentar. Sin embargo, existe una variante que si es de interés y consiste en colocar el gateway en el extremo de un acceso de Internet de banda ancha (cablemodem, ADSL o wireless). Un tema de análisis es la introducción del protocolo SIP en la red de Telefonía-IP. Seguramente se realizará inicialmente en servicios que requieren la conexión vía Internet, para luego pasar a la red existe (de ser conveniente). Este tema es uno de los encarados por iplan con Universidades con las cuales mantiene convenios de cooperación. Tanto los gateway-fxs como los gateway-e1 están sufriendo un acomodamiento de precios que permite llevar la Telefonía-IP a aplicaciones antes prohibitiva. Un caso especial de gateway es la creación del Dominio en Internet. El objetivo es ofrecer servicios de Telefonía-IP soportado en las redes de acceso abiertas de Internet (sin necesidad de un acceso dedicado mediante la red de transporte de iplan). Para manejar esta posibilidad se requiere un Gateway IP-IP que aísla e interconecta los dominios internos (seguros) con el dominio externo (inseguro) de Internet. Figura 8. Componentes del gateway IP-IP que permite la interoperación entre redes IP sin bajas a E1. 12

77 Monografías 5 (2003) Telefonía: El balance óptimo La Figura 8 muestra la situación que se tiene antes y después de disponer del gateway IP-IP. Sin este gateway, el Dominio de Telefonía-IP en Internet debe ser aislado mediante el uso de gateway-e1 dedicados a esta función. Un cambio sustancial se observa cuando se inserta entre el Dominio iplan y el Dominio Internet el gateway. Este se encarga de actuar de Firewall (protección y seguridad de la red interna). Además puede enrutar llamadas saliente desde iplan hacia destinos también colocados en Internet (otros Operadores con gateway de este estilo). Una Plataforma de Management permite la administración de los distintos Carriers que son registrados en el gateway IP-IP. Esto permite hacer un Clearing House de tráfico de llamadas de telefonía en IP Alternativas de Gateway FXS. En Journal No 1 se trató el tema de las inversiones necesarias para ofrecer los servicios de Pack (generalmente indicado como Capex por línea analógica). Se presentó un gráfico, donde se mostraba la reducción de Capex en los años 2001, 2002 y Para el 2003 se esperaba una reducción en los Capex ligados a los equipos en el NOC y a los Nodos de Manzana. Durante el 2003 se han estudiado diferentes alternativas de gateway de líneas analógicas FXS, para reducir las inversiones para el producto Pack. Si bien el producto Locutorio también se alimenta desde estos equipos, se ha preferido una línea de desarrollo distinta: el IPGol, que no requiere de líneas analógicas. IPGol es motivo de mención en otros números de Journal en el No 3 se hace una introducción reducida. Las alternativas de gateway estudiados en orden cronológico han sido: Cisco-VG248: Se trataba de continuar ampliando la configuración de Call Manager, instalado inicialmente en marzo Las particularidades son: -El costo es elevado. -El protocolo no es standard; utiliza el protocolo SCCP. -El producto es considerado Enterprice en Cisco, con lo que no puede esperarse un desarrollo futuro. -Posee 48 líneas analógicas por equipo (en una unidad de rack). Esto tiene la ventaja de mayor densidad de puertos por nodo, pero es una inversión elevada en nodos de baja cantidad de clientes. Gateway-iplan: Iniciado a fines del 2002, el desarrollo de nuestro propio gateway involucró varias alternativas: -Como CPE se llegó a un prototipo en abril-2003 de Pack-1 en protocolo H.323 y codificador G.711. El problema de este equipo es que no soportaba un codec G.729 que ocupa menor velocidad y podría ser usado en Internet (con acceso ADSL, cablemodem o wireless). -Como equipo para Nodo de Manzana con 24 o 30 líneas. Se intentaron desarrollos conjuntos con otras empresas sin éxito. Figura 9. Diagrama de interfaces E1 y proyección de tráfico diario. 13

78 Monografías 5 (2003) Telefonía: El balance óptimo Audiocodes-MP124. En iplan conocemos a Audiocodes desde el año Pero recién ahora disponen de una línea de productos atractiva. Veamos algunas características: -Está compuesta de gateways de 4, 8, 16 y 24 puertas FXS y de gateway-e1. Utilizan protocolo H.323 y pueden manejar codificación G.729 (esto permite armar Nodos con accesos de banda angosta). -Las pruebas de Homologación en iplan han resultado favorables y permitieron introducir estos equipos en la red. Cisco-IAD2430. Este equipo estaba disponible desde inicios del 2003 pero con protocolos SIP y MGCP. Recientemente ha sido introducido con protocolo H.323, lo que lo permitió introducirlo en la red de iplan. Dispone de 8, 16 y 24 ports. Aunque la economía de precios hace que solo el de 24 ports sea económicamente interesante. Ambos equipos, MP124 y IAD2430 están operativos en iplan desde septiembre EL TRAFICO TELEFONICO 5.1- Comportamiento del tráfico. La clave del tráfico telefónico está en las interfaces. En una red como la de iplan existen varias interfaces: 1- Interfaz de E1 hacia la red de Telefonía-IP. 2- Interfaz de E1 hacia la PSTN. 3- Interfaz IP entre las ciudades iplan (Interurbano). 4- Interfaz IP hacia Carriers internacionales. La Figura 9 muestra dos de estas interfaces. La conexión con la PSTN se realiza mediante tramas E1 desde la central NEC y desde equipos Cisco-5300 (de voz). Siguiendo la numeración de la figura se tiene: 1- Interfaz de entrada de Dial-up para los Access Server de Internet Cisco Se trata de los servicios de ISP-Free. Iplan tiene cerca de 50 clientes que proveen servicios de acceso con modalidad Revenue Sharing, con tráfico entrante. 2- Interfaz Dial-up similar a 1- pero sobre equipos Cisco Estos equipos son duales (para voz e Internet), por ello se los utiliza con primera prioridad para señal vocal (interfaz 3-) y con segunda prioridad para acceso a Internet (como desborde de los Cisco-5300). 3- Interfaz desde los Cisco-5350 hacia la red de Telefonía-IP (VoIP). El tráfico es bidireccional, pero está priorizado el tráfico entrante; el tráfico saliente lo maneja la interfaz Esta interfaz bidireccional y vocal es similar a la 3-, pero no tiene canales de datos dial-up. 5- Esta es una interfaz unidireccional que se utiliza para llamadas salientes a la PSTN que no pasan por la central de conmutación En la misma Figura 9, se observa también como se comporta el tráfico en las diferentes tipos de interfaz. En parte complementario entre el servicio de telefonía diurno y el acceso a Internet nocturno. Figura 10. La figura superior muestra el crecimiento del tráfico entrante (en rojo), saliente (en azul) y total (en negro) en la red de iplan desde febrero La segunda figura muestra la evolución a lo largo de un mes y la tercera a lo largo de un día. 14

79 Monografías 5 (2003) Telefonía: El balance óptimo Figura 11. Pantallas principales de iplan-control. En la Figura 10 se observa el comportamiento del tráfico de telefonía en iplan: -arriba: evolución del tráfico entrante, saliente y total desde el inicio de las operaciones en el central: evolución del tráfico a lo largo de un mes. Se observan los valores de tráfico durante la semana laboral y el fin de semana. servicio, rangos de IP s, estado de los mismos, etc). Posibilita, también, tener la información en gráfico, discriminando por ejemplo por cantidad de bits salientes y entrantes El iplan-control. Iplan tiene implementado un sistema de consulta on-line para determinar los principales datos de consumo del usuario. Se conoce como iplan-control. El inicio de la consulta se realiza ingresando un usuario (número de cliente) y una Contraseña. Se ingresa entonces a la herramienta de consulta. Eligiendo la sección de Trafico de telefonía se accede al listado de líneas activas que tiene el cliente y el historial de ellas (desde un día hasta 90 días). Por ejemplo, se obtiene el consumo del total de las líneas, discriminado por tipo de llamadas (Local, LDN, LDI, Celulares) y se accede a los totales por líneas para luego exportarlo a un Excel. Se puede acceder a un Resumen (llamadas agrupadas por tipo y fecha) o a un Detalle (llamada por llamada) del tráfico telefónico. Es posible también seleccionar las líneas que se desean consultar y observar los totales consumidos, por línea y por tipo de llamada (LDN, LDI, Celulares). Con iplan-control se accede también a los reportes de Internet. Se puede ver la descripción de los servicios (tipo de 15

80 Monografías 5 (2003) Telefonía: El balance óptimo MONOGRAFIAS DE J: Journal monografías número 5. Edición agosto Diseño gráfico original de Marianela V. Ricardo 16

81 monografía iplantech Journal Monografías es una publicación de iplan que contiene información técnica y confidencial de la empresa. Se distribuye a un circuito limitado de lectores a fin de mantenerlos informados sobre el estado y la evolución de la tecnología y el negocio de la Telecomunicaciones, principalmente en las redes IP y la Telefonía-IP. Se ruega a los lectores a mantener el principio de Confidencialidad sobre la información aquí contenida. No está autorizada su reproducción o distribución por cualquier medio sin antes consultar con la empresa. IEl Gateway IP-IP (CHip). El Gateway con interfaz IP y la Plataforma de Management diseñada para soportar servicios de Telefonía entre redes IP. IINDICE 1- Introducción 2- Requerimientos y Características 3- Funcionamiento 4- Plataforma de Management 5- Aplicaciones IABSTRACT El Gateway IP-IP es un diseño de iplan que permite la interconexión segura entre redes IP para el tráfico de telefonía. El proyecto ha sido encarado debido a la falta de soluciones comerciales a la medida de las necesidades del mercado. Este GW IP-IP se complementa con una Plataforma de Management que permite la Administración de los distintos Carrier-IP conectados a la misma. El resultado tecnológico de ambos componentes son conocidos como CHip (la plataforma de Clearing House IP). Las aplicaciones comerciales son variadas. Inicialmente se lo utiliza para gestionar la red secundaria de Carrier nacionales e internacionales. Con posterioridad, cuando la cantidad de Carrier conectados aumenta, se pasa al concepto de servicio de Clearing House. 1

82 Monografías 6 (2003) Gateway IP-IP (CHip) 1- INTRODUCCION En una red de Telefonía es necesario interconectar Dominios de diferentes Operadores. La Interconexión ITX más simple y difundida se realiza mediante tramas E1 (desde la década de los años 80); esta alternativa es obligatoria con las grandes Telco. En algunos pocos casos se puede realizar mediante una trama SDH (STM-1), pero siempre contiene en su interior tramas E1. Cuando se tiene este tipo de ITX, existen diferentes Dominios-IP y se requiere de componentes que permitan la protección de cada una de las redes. Este componente es un Gateway con doble interfaz IP y lo denominaremos GW IP- IP, en este trabajo. El GW IP-IP tiene asociada una Plataforma de Management para la administración de los Carriers o clientes conectados a la misma. El conjunto lleva el nombre comercial de CHip (la plataforma de Clearing House IP) y tiene su logotipo e isotipo que lo identifica. En otros casos, la ITX puede realizarse en protocolo IP. Esto es posible y deseable entre Carrier cuyo soporte es IP. Por Carrier se entiende aquellas empresas que realizan el transporte de llamadas telefónicas, sea con tecnología TDM (E1) o con IP. Figura 1. Aplicación del Gateway IP-IP en la red de Telefonía-IP. 2

83 Monografías 6 (2003) Gateway IP-IP (CHip) En la Figura 1 se han representado tres alternativas posibles de ITX con los Carrier-IP. En la parte superior se observa la solución a) encarada cuando el GW IP-IP no existía aún. En este caso se utilizan Gateway-E1. Estos gateways convierten de señal IP a E1, tramas que se interconectan a la central de conmutación, la cual realiza la operación de switch. Una comunicación entre redes IP requiere pasar por la central (switch class-5). Esto es absolutamente ineficiente, pero fue necesario por falta de una solución tecnológica adecuada. apuntando cada uno a diferentes Dominios. Una vez establecida la comunicación, los paquetes RTP de telefonía fluyen a través de este gateway sin afectar la calidad en la voz. Este paso transparente incluye: -la priorización de paquetes, -admisión de los protocolos de fax relay y DTMF relay y -admisión de múltiples codificaciones de señal vocal. Otro problema adicional de esta alternativa es la necesidad de disponer de equipos Gateway-E1 dedicados para cada Carrier. Esto hacía que se adjudican equipos de diferente capacidad de manejo de tráfico para diferentes clientes. Por ejemplo, el Cisco-2600/3600 para 1xE1 o 2xE1 y el Cisco para 4xE1. En el primer caso la señalización es MFCR2 y en el segundo es SS7. La señalización MFCR2 tiene un retardo elevado en los mensajes de señalización, frente al caso SS7. La conexión entre el gateway del corresponsal y el gateway en la red de iplan es del tipo Peer-to-peer (no interviene un gatekeeper y la conexión es permanente). Una alternativa propuesta pero no utilizada, para mejorar esta forma de trabajo, era la conexión de Gateway-E1 de Frontera. Esto es, un Gateway-E1 en cada Dominio de Carrier y la interconexión con tramas E1 (ver el gráfico b en la Figura 1). La señalización entre ambos gateway debería ser ISDN-PRI (para mejorar los tiempos de señalización de MFCR2). La ventaja es que los equipos Cisco-5300 (del lado de la red IP de iplan) tendrían una carga de tráfico plena, con lo cual serían mejor aprovechados que en el caso anterior. En a) un equipo se dedica a un corresponsal y por el ello la carga de tráfico sobre el Gateway depende del intercambio con este Dominio en particular: un cliente a un equipo. Con el modelo de Gateway-E1 en la Frontera se tendría: varios clientes a un equipo. La solución aplicada en la realidad, es un tercer modelo (ítem c en la Figura 1). En iplan se ha desarrollado un equipo que tiene doble interfaz IP, de forma que elimina las desventajas de la solución de Gateway de Frontera, manteniendo las ventajas de éste. Por otro lado, el costo de este GW IP-IP es reducido, al no disponer de interfaz E1 (normalmente una de las partes más caras del server). En la práctica, es un software que corre sobre un server convencional. Un solo GW IP-IP puede abastecer a muchos usuarios. El GW IP-IP provee un mecanismo para permitir llamadas de Telefonía-IP en protocolo H.323. Además, entrega un punto de control y demarcación para llamadas IP entre los dos Dominios administrativos (iplan e Internet o dos Carriers-IP entre sí). El GW IP-IP ejecuta la mayoría de las funciones de un Gateway IP-E1 (hacia la PSTN) pero no baja la señal a tramas E1. En una conexión entre Carrier-IP, no existe carga de tráfico sobre la red de iplan. Este GW IP-IP está pensado como solución para servicios mayoristas de VoIP que originan y terminan llamadas entre su red y una red externa. El equipo se comporta, desde un punto de vista lógico, como si fueran dos Gateway-IP Las dos partes lógicas del conjunto (los Gateway-E1 de Telefonía-IP: GW1 y GW2) pueden registrarse en diferentes Gatekeepers (GK1 y GK2) y constituyen el punto extremo en cada Dominio, haciendo independiente uno del otro a nivel VoIP. Este punto de frontera entre ambas redes permite implementar un punto de seguridad para evitar los ataques desde el exterior (desde la Internet). Además, entregará los tickets CDR para la facturación de estos servicios (identificando cada cliente mediante un prefijo, como se verá más adelante). El GW IP-IP no realiza transcodificación del flujo RTP (con señal vocal codificada). Desde el punto de vista IP no constituye una unión lógica de las dos redes, no realiza NAT de flujos de datos, ni funciona como Firewall. Cada GW-IP lógico es independiente del otro y ambos se comunican al solo efecto de pasar los datos de la llamada en curso de un dominio al otro, modificados de acuerdo a las reglas de translación de dígitos. Cada vez que el GW IP-IP recibe una llamada desde uno de los dominios, iniciará una nueva llamada sobre el otro dominio con los datos de la llamada recibida y aplicando la manipulación de dígitos que sea necesaria. El flujo RTP pasa en forma trasparente, de un dominio al otro, sólo en su payload. 3

84 Monografías 6 (2003) Gateway IP-IP (CHip) 2- REQUERIMIENTOS Y CARACTERÍSTICAS A continuación nos ocupamos de los requerimientos de la plataforma, es decir el Qué debe hacer?. Más adelante nos ocuparemos del funcionamiento Requerimientos Generales. Los requerimientos generales para el gateway GW IP-IP son los siguientes: -Se requieren al menos 3 interfaces Ethernet 10/100Mbps en formato full-duplex. Dos de ellas son para las redes de VoIP y la restante para la plataforma de Management. Cada una de ellas debe permitir la configuración de ruteo independiente. Tendrá la funcionalidad de Proxy entre redes, permitiendo sólo el flujo RTP entre ambos segmentos IP. -Para la configuración y administración se posee un acceso local vía teclado y monitor. Además, se dispone de un soporte Telnet e de interfaz Web para el provisioning del GW vía SNMP. Se dispone de reportes de alarmas vía SNMP. -Se requiere un cliente NTP ó SNTP para sincronización de fecha y hora. -Debe tener interoperabilidad con diferentes equipos gateways en los diferentes Dominios. -El Gabinete es rackeable de 19 (en 1 o 2 unidades de rack), con fuente de 220 VCA, 50Hz (opcional redundante) Señalización de llamada. El equipo tiene la facilidad de registrarse en dos dominios de Telefonía-IP (dos dominios de Gatekeeper). También permite la comunicación Peer-to-Peer contra otros Gateways dentro del mismo dominio. Esto se muestra en la Figura 2. Desde este punto de vista posee las siguientes características: -Se utiliza el protocolo estándar H.323 v2/v3 de la ITU-T. Manejo de codec vocales G.711, G.723 y G.729-R8 (aunque la aplicación no realiza el transcoding de paquetes RTP). Es decir, los endpoint en los extremos tienen la capacidad de negociar el codec y el GW IP-IP será transparente a ello. -Se puede realizar la configuración manual de la facilidad Fast/Slow Connect. Se tiene previsto el cambio automático a Slow-Connect cuando Fast-Connect es rechazado por el otro endpoint. -Soporta VAD (Voice Activity Detection), aunque la aplicación no realiza el transcoding de paquetes RTP. La funcionalidad VAD se refiere a la supresión de las muestras de codificación vocal cuando el usuario genera señal ambiente por debajo de un umbral de ruido (silencio vocal). La suma de las funcionalidades de codec de baja velocidad (como en el caso G.723 y G.729) con la funcionalidad VAD, permite una reducción sustancial de los requerimientos de ancho de banda para la Telefonía sobre Internet. -Tiene capacidad de tráfico por túnel H.245 con paso transparente de los protocolos DTMF-relay y Fax-relay (T.38 y Cisco propietario). -Tiene capacidad para manejar Calidad de Servicio (QoS por IP-Precedence). -Soporta la function Timeout Light-weight-registration period configurable para H.225 RAS (keep alive). Esta funcionalidad se refiere al período de tiempo en que se refresca la registración de los GW en el GK. -Tiene la posibilidad de rutear llamadas con origen y destino del mismo dominio. En este sentido, el equipo podrá recibir llamadas por una de sus interfaz y luego volver a enrutarla a otro carrier de destino por la misma interfaz. Este enrutamiento podrá hacerse con o sin manipulación previa de dígitos. Esta funcionalidad es útil para la triangulación de llamadas sobre Internet, teniendo en cuenta que un Carrier puede tener excelentes precios de terminación de llamadas en ciertos destinos, lo cual puede ser revendido a otros Carriers Soporte de Gatekeepers. Como se dijo anteriormente, el equipo tendrá la facilidad de registrarse en dos Dominios de Telefonía-IP (dos dominios de Gatekeeper, Figura 2-c). Desde este punto de vista, la plataforma tendrá las siguientes características: -Configuración del GK en la plataforma. Se lo identifica por la dirección IP, el puerto RAS, la dirección GK_Id y dirección H.323_Id. Cada interfaz será configurada en forma independiente. -Se tiene la posibilidad de soportar Gatekeeper alternativo (en ambas interfaz). Con esta facilidad, el gateway intentará registrarse en el gatekeeper alternativo si se pierde la conectividad con el principal. -Soporte de clusters de Gatekeepers. Tal es el caso de la red de iplan antes de ingresar el Softswitch SI. Se tienen tres GK Cisco-7401 configurados especialmente en cluster. -Soporte de Directory Gatekeepers. Si bien esta es una facilidad inherente a los gatekeepers, el gateway deberá cursar llamadas a través de un Directory Gatekeeper estando registrado en un gatekeeper de infraestructura Soporte Dial-Peers y Translation-Rules. El término dial-peers es utilizado por Cisco y se refiere a configuraciones puntuales del plan de numeración y define los atributos de una conexión que puede ser VoIP o POTS. En el caso del GW IP-IP las conexiones serán en VoIP en ambos segmentos de llamada. Un dial-peer mapea un string de dígitos marcados con el dispositivo remoto en la red, el cual puede ser un router o gateway de destino o un Gatekeeper H.323. En el caso de voz sobre IP (VoIP), el dial-peer se mapea sobre la dirección IP, el nombre DNS (Domain Name System), o el tipo de dispositivo de destino en donde termina la llamada. Una llamada de voz sobre una red de paquetes está segmentada en segmentos discretos de llamada que están asociados con los dial-peers (un dial-peer está asociado a cada segmento de llamada). Un segmento de llamada es 4

85 Monografías 6 (2003) Gateway IP-IP (CHip) una conexión lógica entre dos router/gateways o entre un router/gateway y un dispositivo de Telefonía-IP (gatekeeper). El conjunto de dial-peers asociados a cada interfaz IP de esta plataforma constituye el plan de numeración o dial-plan que establece todas las posibilidades en cuanto a dígitos marcados o recibidos. Todas aquellas llamadas cuyos dígitos marcados o recibidos no posean un dial-peer asociado serán rechazadas. Las translation-rules podrán ejecutarse antes o después del barrido de los dial-peers (dependiendo del modo en que se defina el proceso del dial-plan) y son las instrucciones que permiten la manipulación de dígitos, tanto del número marcado como el número del llamante. A continuación se lista las características de los dial-peers y translation-rules: -Manejo de dial-plan (plan de numeración) asociado a cada interfaz IP en forma independiente. -Manejo de translation-rules (reglas de traducción de números) asociadas a cada interfaz en forma independiente. Esto debe permitir la manipulación de dígitos de número llamado y llamante y la inserción y reemplazo de dígitos en cualquier posición, así como el borrado de dígitos y el número completo. -Manejo de caracteres especiales (., *, #, T, etc) como parte del número. -Manejo de listas de acceso por IP pudiendo vincularse cada una de ellas a las translation-rules (ejemplo: Inserción de dígitos según la dirección IP de origen). -Funciones de screening y bloqueos (entrante/saliente): bloqueo de destinos (como acceso a celulares, por ejemplo) o de ciertos orígenes (desde carrier no registrado, por ejemplo) Tasación y CDRs. El GW IP-IP enviará mensajes de Accounting a una plataforma remota vía Radius de acuerdo a los parámetros de configuración que se ingresen. En este sentido el operador podrá seleccionar alguna de las siguientes opciones: -No generar CDRs (para los casos en que los CDRs sean generados por la plataforma siguiente) o -Generar CDRs con almacenamiento remoto vía Radius. El GW IP-IP generará un único registro de tasación (CDR) por cada llamada. El registro se genera tanto para llamadas completadas como infructuosas. El contenido de cada CDR dispone de los siguientes campos: -Número de B Traducido. Es el número de destino final si es requerida alguna traducción. En caso de número Nacional ó Internacional, sin los ceros adelante. -Fecha y hora de Setup. Es la fecha y hora del mensaje Setup de Q.931 en formato AAAAMMDD y hhmmss). -Fecha y hora de Connect. Es la fecha y hora del mensaje de Conexión-CON. -Fecha y hora de Disconnect. -Origen de Disconnect. Indica cual fue el usuario que cortó la comunicación. -Release Cause Value. Es la causa de desconexión de la llamada, según ITU-T Q IP Origen y Destino Dominio 1 y 2. Es la dirección IP del gateway que originó y terminó la llamada en el dominio 1 y 2. En el caso de llamadas infructuosas (B no contesta, ocupado, etc.) el mensaje CON está ausente, y esto se denota al encontrarse vacíos los campos Fecha y Hora de la respuesta. El equipo hará Accounting vía protocolo Radius. En este caso, el equipo generará el CDR y lo enviará a una plataforma a través de un único mensaje Radius. Es decir, que el equipo envía un mensaje Radius por cada CDR que genera localmente Otras características. Configuración, provisioning y Mediation. El GW IP-IP podrá configurarse y aprovisionarse con diferentes modos de acceso, a saber: -Por acceso local vía teclado y monitor. -Mediante conexión remota (tipo Telnet). -Por interfaz Web utilizando protocolo HTTPS (encriptado) para configuración segura desde Internet. -Desde una plataforma remota a través del protocolo de administración SNMP. Interfaces del GW IP-IP. Si bien el GW IP-IP podrá funcionar stand-alone como interfaz entre diferentes dominios de VoIP, podrá existir una plataforma de administración que dialogará con otros GW IP-IP para la implementación de servicios de valor agregado.la comunicación entre la Plataforma de Administración y el GW IP-IP para la administración será mediante el protocolo SNMP. La comunicación entre el GW IP-IP y la Plataforma de Administración para la obtención de CDRs on-line será mediante el protocolo RADIUS. -Identificador Carrier_ID Entrante y Saliente. Es el nombre de la ruta que identifica al Carrier que originó la llamada y donde terminó. Todos los gateways del mismo Carrier se identifican con el mismo Carrier_ID. -Número de A. Es el número del usuario llamante-ani. -Número de A Traducido. Es la traducción del número del usuario llamante-ani, si es requerida. Si no hay traducción, este campo repite el valor de Número de A. -Número de B Marcado. Es el número marcado por el usuario llamante, en caso de número Nacional ó Internacional sin los ceros adelante, los números no geográficos 0800 son números nacionales. 5

86 Monografías 6 (2003) Gateway IP-IP (CHip) 3- FUNCIONAMIENTO 3.1- Modos de funcionamiento. El GW IP-IP podrá establecer llamadas con dispositivos remotos mediante conexiones H.323 Peer-to-Peer o mediante la intervención de gatekeepers. La Figura 2 muestra como serían las conexiones dentro de una topología típica. El primer tipo de conexión es peer-to-peer en ambos Dominios. En el segundo se mantiene la conexión peer-topeer entre gateway en un Dominio y es mediante gatekeeper en el otro. La tercer alternativa recurre a conexiones mediante gatekeeper en ambos Dominios. Por último, se puede tener una conexión entre gateways en el mismo Dominio. En este caso el GW IP-IP actúa como espejo para la conexión El formato de conexión c) mediante Gatekeepers de la Figura 2, se analiza con mayor detalle en la Figura 3. Donde se presenta el intercambio de mensajes de señalización para el establecimiento y cierre de la llamada. Figura 2. Tipos de funcionamiento del Gateway IP-IP. 6

87 Monografías 6 (2003) Gateway IP-IP (CHip) 3.2- Flujo de mensajes. La Figura 3 muestra una secuencia típica de mensajes de señalización para una llamada a través del GW IP-IP registrado en dos GK. En H.323 la notación para cada tipo de mensaje es diferente, y de esta forma puede distinguirse de un protocolo a otro. En los mensajes en protocolo RAS se utiliza una representación mediante 3 letras (por ejemplo: ARQ). Este protocolo es usado entre el GW y GK. En los protocolos H.225/Q.931 se utiliza una representación mediante una o dos palabras con la primer letra en mayúsculas (ejemplo: Call Proceeding). Este protocolo es usado para encapsular los mensajes H.245 de señalización entre terminales. Originalmente fue diseñado como protocolo DSS1 en capa 3/7 para los accesos ISDN. A continuación se indican los pasos de señalización para establecer una comunicación en protocolo H.323 entre ambos dominios con la ayuda del GK. En otras ediciones de Journal se han analizado ejemplos similares a este (ver por ejemplo el número correspondiente al Softswitch y Softphone). El paso inicial es el proceso de Discovery, por el cual el terminal gateway GW H.323 de un dominio determina cual es el gatekeeper GK que atiende a la red en ese momento. El mensaje desde el terminal es del tipo multicast (dirigido a todos los GK disponibles en la red) y se denomina GRQ (Gatekeeper Request). El GK disponible responde con el mensaje de aceptación GCF (GK Confirmation) o de rechazo GRJ (GK Reject) a la solicitud. También el GK puede indicar un GK alternativo mediante un mensaje alternategatekeeper. Si no se está en condiciones de procesar el request GRQ se puede enviar un mensaje RIP (Request in Progress). Este mensaje indica que se está procesando el request. Esto permite el reset el timeout de la conexión (tiempo después del cual se considera que la conexión es imposible). Figura 3. Proceso de comunicación entre dominios con el GW IP-IP. 7

88 Monografías 6 (2003) Gateway IP-IP (CHip) El procedimiento de Discovery no está representado en la Figura 3 por tratarse de una operación de inicialización. El paso siguiente es el de Registración. Mediante este proceso el GW de cada dominio informa y registra sus direcciones de transporte y el alias. Utiliza el mensaje RRQ (Registration Request) y el GK responde con RCF (Registration Confirmation) o RRJ (Registration Reject), para confirmar o rechazar el pedido de registración. El mensaje RRQ se emite en forma periódica. En esta operación intervienen los Gateway en ambos dominios, junto con el GW IP-IP hacia ambos GK. La registración tiene un tiempo de duración (expresado en segundos) para lo cual se utiliza el mensaje timetolive. El terminal GW o el GK puede cancelar la registración mediante el mensaje URQ (Unregister Request) al cual le corresponde la confirmación URF (Unregister Confirmation). Esta operación no está reflejada en la Figura, debido a que no corresponde a una función durante el intento de establecer una llamada. Otro intercambio de mensajes no representados en la Figura 3 es el de Localización. Un GK que tiene un alias para un terminal GW y que quiere determinar su información de contacto puede emitir el mensaje de requerimiento de localización LRQ (Location Request). Al cual le corresponde el mensaje de confirmación LCF (Location Confirmation), que incluye la información requerida. La dirección puede ser del tipo E.164 si se trata de un GK fuera de la red El mensaje de Status es un mensaje periódico (con período mayor a 10 segundos) que emite el GK al terminal GW para determinar el estado y requerir un diagnóstico. Se trata de los mensajes IRQ (Information Request) y IRR (Information Response). La habilitación se realiza mediante willrespondtoirr enviado en el mensaje RCF o ACF. Como en los otros casos no se muestra en la Figura. En primer intercambio de mensajes incluido en la figura se refiere al Pedido de Admisión del terminal GW al GK. Este mensaje se identifica como ARQ (Admissions Request) y contiene el requerimiento de ancho de banda Call Bandwidth (en formato Q.931). El GK puede reducir las características de la solicitud en el mensaje de confirmación ACF (Admissions Confirm). Este mensaje será de gran importancia en el proceso ya que el GW IP-IP no toma partido en la negociación sobre el tipo de codec vocal utilizado. En el mismo mensaje ARQ se dispone de la funcionalidad TransportQOS para habilitar la funcionalidad de reservación de ancho de banda RSVP, para servicios unidireccionales (orientado-al-receptor). El Establecimiento de la llamada se inicia con la funciones de Registración y Admisión. Luego se pasa a la etapa de Setup de la llamada. Desde el GW1 hacia el GW IP-IP y desde este hacia el GW2 se envía la información necesaria para ejecutar el call setup a través de los mensajes Q.931. Cuando el usuario llamado tiene tono de llamada, se envía el mensaje de Alerting que permite ofrecer el tono de llamada al usuario llamante. Cuando el usuario llamado responde se envía el mensaje Connect. Desde este momento la llamada está establecida. La señal vocal se intercambia en protocolo RTP. La negociación del codec utilizado (G.711 a 64 Kbps o G.729 a 8 kbps) se realiza entre los GW extremos. Si la llamada se dirige desde un usuario de Telefonía-IP hacia la PSTN, el GW2 será un Gateway-E1 de Interconexión. Cuando la comunicación se termina, se envía el mensaje Rel_Comp. Este mensaje realiza las funciones necesarias para la tarifación Billing de la llamada (no mostrado en la figura). El cierre de la conexión se realiza mediante un intercambio de mensajes de pedido DRQ (desde los GW hacia el GK) y confirmación DCF (en sentido inverso). Si el usuario en el GW2 está ocupado no llega a completarse la fase de Alerting (durante la cual que indica que el usuario B está llamando) y se pasa directamente a la fase de desconexión. Si en cambio, el usuario B no contesta, la fase de Alerting es interrumpida por el tiempo máximo Timeout, pasándose de inmediato a la desconexión. En ambas situaciones se genera el correspondiente ticket de Billing con la descripción de la interrupción (llamada infructuosa) Codec vocal para Carrier-IP. La codificación del canal vocal G.711 (64 Kbps) es la utilizada en las redes TDM (tramas E1) y en la red IP de iplan. Sin embargo, esta velocidad no es la más apropiada para aplicaciones de Carrier-IP (en general para el transporte en Internet). Se puede aprovechar las características de la señal vocal para comprimir la velocidad y ahorrar ancho de banda (cuando las condiciones del servicio lo requieren o lo permiten). Las características de la señal vocal, que permiten reducir la velocidad de codificación, son: -Distribución de probabilidad de amplitud no-uniforme. -Alta correlación entre muestras sucesivas. -Existencia de ráfagas de muestras (períodos de silencio). -Cuasi-periodicidad de la señal vocal. Los tipos de algoritmos de codificación vocal se clasifican de la siguiente forma: -Los codificadores de forma de onda en el dominio del tiempo: PCM-G.711, ADPCM, Delta. -Codificadores de forma de onda en el dominio de la frecuencia: ATC (Adaptative Transform Coding). Se utiliza la técnica de Transformada Discreta Coseno DCT utilizada normalmente en codificadores de vídeo. -Los codificadores Vocoders (LPC, IMBE) y los híbridos (RPE, VSELP, CELP). Se codifican los parámetros de la señal vocal relacionados con la percepción del ser humano. El codificador híbrido es del tipo análisis-y-síntesis de la señal El Codec G.729. De este último tipo de codec es el G.729 (el codec G.711 data del año 1972, mientras que G.729 es del año 1995). No solo los Carrier-IP utiliza este tipo de codificación, también se aplica en diferentes sistemas celulares (en diferentes variantes). Una muy eficiente de codificación es la predicción lineal LPC (Linear Predictive Coders). Es útil para señales que pueden modelarse como un sistema lineal. Mientras que PCM (G.711) son «técnicas de codificación de forma de onda», la 8

89 Monografías 6 (2003) Gateway IP-IP (CHip) LPC (G.729) se basa en la «estimación lineal de la fuente». Las muestras de la señal vocal X(n) se determinan como una función lineal de una Secuencia de Excitación V(n) (señal de pulsos) y una predicción sobre la base de las muestras anteriores X(n-i). El orden de cálculo N es el valor total de muestras X(n-i) usadas en la predicción. Para reducir el número de bits se toman varias muestras y se transmiten los parámetros. En lugar de codificar cada muestra individual como en PCM, se codifican los parámetros de un grupo de ellas (parámetros del sistema lineal). Para el caso del codec CELP (Code Excited Linear Prediction) se dispone de un Codebook de señales de excitación al filtro. Por cada grupo de muestras se busca el código que genera la mejor aproximación como excitador. Se transmite el índice del código seleccionado. Es una codificación muy compleja, que requiere 500 millones de operaciones al segundo y entrega elevada calidad con una tasa aun muy baja de 2,4 kbps. CELP se aplica en la norma G.729 para aplicaciones de voz sobre protocolo IP (VoIP). Los atributos de los codificadores vocales se comparan mediante los siguientes parámetros: -Velocidad de codificación: en términos de kbps. -Retardo de codificación: consiste en el algoritmo de codificación, el análisis vocal y el retardo de comunicación. -Complejidad: medido en millones de instrucciones por segundo (MIPS) y tamaño de memorias ROM y RAM. Por ejemplo, G.723 requiere para 6,3 kbps una trama de 30 mseg con un retardo de algoritmo de 37,5 mseg; requiere entre 14 y 20 MIPS y 4,4, kbyte de memoria RAM. En cambio la ITU-T G.729 para 8 kbps requiere una trama de 10 mseg y un retardo de algoritmo de 15 mseg; son 20 MIPS y 5,2 kbyte de memoria RAM Calidad vocal. La calidad vocal de un codificador o sistema de transmisión se mide sobre la base de un criterio subjetivo de la señal. Se trata de la cifra de mérito CM (Circuit Merit). El valor obtenido mediante el promedio de evaluación de usuarios se denomina MOS (Mean Opinion Score). Un criterio de calidad adicional es el GOS (Grade Of Service) definido como la posibilidad de acceso al sistema. La definición indica que: -CM5(Calidad excelente); -CM4(Calidad buena, señal con algo de ruido); -CM3(Calidad fallada, requiere algunas repeticiones); -CM2(Calidad pobre, requiere repeticiones permanentes) y -CM1(Calidad insatisfactoria, no se reconoce la señal vocal). El promedio de calidad entrega valores de: -MOS4 a MOS4,5(G.711 de 64 kbps y ADPCM de 32 kbps); -MOS3 a MOS4(para ADPCM de 16 kbps); -MOS3,5 (para Carrier-IP con codec G.729) -MOS2,5 a MOS3(para LPC a 2,4 kbps. Uno de los problemas típicos de la compresión vocal es la pérdida del tinte de la voz de forma que resulta dificultoso distinguir quien es el que habla. La detección de actividad vocal y la interrupción de la codificación que involucra es otro problema clásico: resulta difícil de entender la mención de números sucesivos con intervalos de tiempo cortos, debido a que el tiempo para recomenzar la transmisión es una fracción importante del tiempo de duración. La detección del umbral entre ruido y señal vocal se dificulta cuando se realiza desde medios móviles (celulares) donde el nivel de ruido es normalmente elevado. 4- PLATAFORMA DE MANAGEMENT 4.1- Funcionalidades básicas. La Plataforma de Administración de Carriers IP trabaja en conjunto con el GW IP-IP y tiene los siguientes objetivos: -Administrar el tráfico originado y terminado en los diferentes carriers IP, -Proveer a la red de la posibilidad de explotar las ventajas comerciales que brindan este tipo de carriers para terminar tráfico hacia determinados destinos y -Asegurar un nivel de calidad en términos de ASR (porcentaje de llamadas completadas en función de la cantidad de intentos) para cada uno de esos destinos. A continuación se listan algunas funcionalidades específicas de la Plataforma: -Permite la medición on-line de la calidad del Carrier, identificado por prefijo telefónico y por nombre de Carrier-IP. -Facilita las mediciones históricas de calidad por prefijo y por Carrier-IP. -Toma decisiones de cambio de ruteo automáticas ante problemas de calidad. -Toma decisiones de cambio de ruteo por motivos comerciales: por ejemplo por crédito excedido; por desbalance de tráfico en un swaps de servicios entre carriers o por cambios de Tarifas. -Permite el Provisioning de la Plataforma vía web (ABM de rutas, carriers y tarifas). -Permite obtener Reportes de Tráfico. -Administra filtros de seguridad (por IP y por prefijo) Módulo de Administración. Este módulo esta orientado a los usuarios que serán responsables de administrar la plataforma y el tráfico. Entre las funciones de administración se encuentran: -La administración ABM (Altas, Bajas y Modificaciones) de Carrier-IP. -La ABM de Tarifas por destino y por carrier. -La ABM de las reglas de enrutamiento. -Las consultas de desempeño de carriers por cada destino. -Las consultas de volúmenes de tráfico intercambiados y estado de cuenta corriente de Carriers. La Plataforma soportará la funcionalidad de perfiles de usuario. Cada usuario tendrá acceso o lo tendrá restringuido a cada una de las funciones listadas a continuación ABM de Dominio. Un dominio es un grupo de gateways asociados a un determinado Gatekeeper. En principio existirán dos tipos de dominios: -Dominio Privado: Existirá un dominio privado que representa a los gateways de la red de Telefonía-IP privada de iplan. -Dominios Públicos: Existirán N dominios públicos, cada uno con un gatekeeper. Cada dominio puede representar a una región (por ejemplo, América, Europa, etc). Cada GW IP-IP pertenecerá siempre a dos dominios, al dominio privado de iplan y a uno de los dominios públicos. 9

90 Monografías 6 (2003) Gateway IP-IP (CHip) Para realizar el alta de un dominio se deberán ingresar los siguientes datos: -Tipo de Dominio (Público o Privado); -Nombre del Dominio (Internet o iplan); -Nombre de Gatekeeper (GKP1 o 7400GK); -Dirección IP del GK y -Número de Puerto ABM del Cluster. Un cluster es la agrupación de GW IP-IP. Todos los gateways del cluster comparten su Tabla de Ruteo y pertenecen a los mismos dominios. Para el alta de un Cluster se deberá ingresar los siguientes datos: -Nombre del Cluster (por ejemplo, Cluster 1); -Nombre del Dominio 1 y ABM de GW IP-IP. Se deberá dar de alta a los GW con los siguientes datos: -Nombre del GW IP-IP; -Nombre del Cluster al que pertenece; -Dirección IP del Dominio 1 y 2. Los gateways se registrarán a ambos Gatekeepers, correspondientes a los dominios a los que pertenece. Los GW IP-IP trabajarán en modalidad peer-to-peer para algunos prefijos, mientras que con sendos gatekeepers para otros (ver la Figura 2) ABM de Carriers-IP. El Administrador tendrá la posibilidad de dar de alta un nuevo carrier. Para esto deberá ingresar los siguientes datos: -Nombre del Carrier; -Identificación del Carrier; -Contacto Comercial y Contacto Técnico; -Dirección y Teléfono; -Dominio en el que se encuentra; -Direcciones IP que originaran tráfico; -Moneda de Cuenta Corriente (Pesos o Dólar); -Método de Tasación (por minuto, 30 seg o 6 seg). Se debe configurar un Carrier iplan, que se comporta como carrier por default para el caso que no exista carrier disponible para algún destino. Las cuentas corrientes del carrier se manejan en una sola moneda; es decir, que en el caso de seleccionar dólar, los valores representados tanto en la tabla de tarifas como en la tabla de precios son en dólares. No será posible inicialmente vender en pesos y comprar en dólares o viceversa para el mismo Carrier. Si será posible que un carrier posea una cuenta corriente en dólares y otro carrier posea una cuenta corriente en pesos ABM de prefijos de Carrier. Existirá una tabla de prefijos por cada carrier. El administrador luego de creado un carrier debe ingresar: -El listado de prefijos, -Las direcciones IP de los gateways asociados (o gatekeeper del dominio correspondiente) y -El codec a utilizar en cada caso. La tabla de prefijos podrá ser modificada en cualquier momento. Esta tabla contiene: -El Prefijo, -El Destino (ciudad y país), -La Dirección del Gateway E1, -El tipo de codec usado (G.711, G.729, etc) y -Las Reglas de Enrutamiento Automático ABM de tarifas para un Carrier. Luego de creada la Tabla de Prefijos, se deberá editar una tabla con los costos por minuto de cada uno de los prefijos creados. El administrador comercial tendrá la posibilidad de editar dicha tabla en cualquier momento. Contiene: -El Prefijo, -El destino (ciudad y país), -El Costo por minuto y -La Fecha de entrada en Vigencia Método de Tasación. La plataforma soportará dos métodos de tasación: -La tasación por minuto y -La tasación por los primeros 30 segundos y luego cada seis segundos. El método de tasación se elegirá para cada carrier. Por ejemplo, se muestra la siguiente Tabla: Destino: XXX Precio por minuto $ 1,00 Fracción 30 seg $ 0,50 Fracción 6 seg $ 0,10 Forma de Facturación: 30 / 6 Tasación Precio 30 segs $ 0,50 36 segs $ 0,60 42 segs $ 0, Consulta de cuenta corriente de Carrier. Una vez seleccionado un determinado período y un determinado carrier, el administrador puede consultar la información de la cantidad de tráfico intercambiado, valorizado en pesos. El formato contiene los siguientes campos: -El prefijo y destino seleccionado; -El Tráfico Saliente y Entrante en minutos a ese destino; -El costo por minuto y total en pesos y -El balance del tráfico entrante y saliente Edición de tabla de enrutamiento. El administrador deberá editar la Tabla de Enrutamiento. Para esto selecciona los Carriers a utilizar para cada prefijo desde un menú desplegable. Las opciones posibles son según las tablas armadas anteriormente. Si no existiese carrier disponible para un destino, ya sea porque no existe o porque se encuentra suspendido temporalmente por problemas de calidad, la llamada se enrutará por default al Carrier-iplan. Esta tabla podrá ser editada por el administrador en cualquier momento Consulta de estado de enrutamiento. En esta pantalla, el administrador podrá visualizar el estado actual del enrutamiento y algunos datos estadísticos de volumen de tráfico y Calidad. Se tienen los siguientes parámetros: -Prefijo y destino; -Carrier utilizado; -Intentos de llamada y llamadas completadas, -Cantidad de minutos, -ASR cada 5 y 60 minutos en % y MHT. 10

91 Monografías 6 (2003) Gateway IP-IP (CHip) Si la cantidad de intentos en los intervalos de medición (5 minutos o 60 minutos) es inferior a 50, entonces se considerará que no hay datos suficientes para calcular el ASR y MHT por lo que deberá aparecer el valor NA. Si los valores de ASR están entre 100% y 60% aparecerá en verde, si están entre 60% y 50% será representado en color amarillo, si son menores a 50% aparecerá en color rojo Perfil de Usuario. Existen dos niveles de perfil de usuario: -Nivel Administrador (tiene privilegios de acceso a todas las funciones de la plataforma, incluyendo altas, bajas y modificaciones) y -Nivel Operador (solo tiene acceso en modo lectura, es decir podrá realizar consultas pero no modificaciones) Reglas de enrutamiento. Existe una cantidad de reglas que podrán afectar al enrutamiento. La plataforma es capaz de detectar si se han cumplido alguna de las reglas y en ese caso se deshabilita automáticamente el prefijo de la Tabla de Prefijos. El prefijo quedará en estado deshabilitado hasta que el operador lo habilite manualmente. Cada vez que exista un cambio en las Tablas o en el enrutamiento, ya sea por acción manual del operador o por haberse cumplido una regla predefinida, se generará un evento de log que será guardado con los siguientes datos: -La Fecha y Hora; -Descripción del cambio; -Usuario que lo realizó o regla asociada. Existirá la posibilidad de enviar estos eventos al NMS (sistema centralizado de Management) vía protocolo SNMP o Syslog. El archivo de log debe rotar automáticamente si se sobrepasa un tamaño predefinido de memoria. una penalidad al carrier para ese destino según el siguiente criterio: -La Primera vez que se deshabilita un prefijo quedará penalizado (deshabilitado) por un período de 24 horas. -La segunda vez en 30 días la penalización será de 72hs. -La tercera vez en 30 días se suspenderá definitivamente la ruta y deberá ser rehabilitada manualmente. Las penalizaciones pueden ser borradas por el administrador. También será posible modificar los períodos de 24hs, 72hs y 30 días. Esta configuración será única para todos los carrier en la plataforma Bases de Datos. Existen dos bases de datos. Una llamada on-line que guardará los CDRs del día, sobre esta base se hacen los cálculos de ASR y MHT para determinar el estado y calidad de las rutas. Todas las noches se copiarán los CDRs a otra base de datos llamadas Histórica. Esta segunda base mantendrá el histórico de CDRs y tarifas a ser usado para la generación de reportes, consultas de consumos, estado de cuentas corrientes, etc. Para un tráfico proyectado sobre la plataforma de 2 Millones de minutos al mes, esto representa aproximadamente tickets (registros) mensuales. Se estima que la base de datos on-line tendrá como máximo registros mientras que la base de datos histórica deberá tener unos 5 millones de registros para mantener 6 meses Edición de las reglas de enrutamiento. El administrador puede editar las reglas para el enrutamiento. Cada regla es una agrupación de condiciones. Podrán existir N reglas de enrutamiento, donde los valores indicados como xxx son variables que deberán ser cargados al momento de editar una regla. Una regla genérica puede ser: Condición de deshabilitar el prefijo si ocurre alguna o varias de las siguientes alternativas simultáneamente: -Volumen de tráfico acumulado es mayor a xxx min (VTA). -ASR 5 minutos es menor a xxx %. -ASR 60 minutos es menor a xxx %. -MHT es menor a xxx minutos. -El tráfico total recibido del mismo carrier es menor a xxx minutos (TTRxC). -El Volumen de tráfico es mayor a xxx $ (VT). Existirá una regla particular llamada regla default que será asignada por default a todos los prefijos y que podrá ser deshabilitada desde la tabla de prefijos (id_rule= 1). La condición es deshabilitar el prefijo si ocurra alguna de estas condiciones: -ASR 5 minutos es menor a 40 %. -ASR 60 minutos es menor a 50 %. -HT es menor a 1,5 minutos Penalizaciones de rutas. Cada vez que se deshabilite una ruta por problemas de calidad se asignará Interfaz con GW IP-IP. La comunicación desde la Plataforma hacia el GW IP-IP para la administración será mediante el protocolo SNMP. La comunicación desde el GW IP-IP hacia la Plataforma para la obtención de CDRs online será mediante el protocolo Radius. El tráfico originado por el carrier se calculará a partir del campo IP Origen Dominio 1. Este campo se compara con el listado de direcciones IP de originación permitidas para el 11

92 Monografías 6 (2003) Gateway IP-IP (CHip) Carrier-IP. El tráfico destinado hacia el carrier se calculará a partir del campo IP Destino Dominio 2 y será comparado con los terminadores para este carrier Interfaz con el NMS para alarmas. Se emitirán alarmas hacia el sistema de concentración, para los siguientes acontecimientos: a) Se enviará un Trap al NMS cada vez que haya un cambio de enrutamiento. b) El Sistema Operativo emitirá alarmas con las siguientes condiciones: disco lleno, carga del CPU, servidor ntp no accesible, etc. c) Tiempo de 1 minuto del Keep-alive al NMS. d) Tiempo de 1 minuto del Keep-alive entre la Plataforma y el GW IP-IP. e) Cuando el valor ASR es muy bajo por todos los carriers y no se puede corregir (por ejemplo, para el caso de pérdida de conectividad IP aguas arriba en Internet del GW IP-IP). f) Condición de Warnings en general cuando las reglas no se pueden aplicar. g) Se emitirá una alarma cuando el Sistema de Mediación (que reúne los tickets para la facturación) no lee los archivos de CDR. Figura 4. Pantallas de Management de la Plataforma CHip en la versión 1.0 en agosto

93 Monografías 6 (2003) Gateway IP-IP (CHip) Interfaz con la Mediación para CDR. Los CDR son enviados al área Sistemas para el procesamiento desde la Plataforma mediante un acceso ftp. El usuario a utilizar será cdrs_sistemas y con un Password. La plataforma dejará diariamente en el directorio raíz del servidor ftp, donde corre la aplicación, un archivo con formato CSV. La nomenclatura de los archivos se realizara con el formato CHIPyyyymmddmmss.csv Funcionalidades adicionales. Entre varias funcionalidades adicionales se pueden citar como ejemplo: -Herramientas de consulta de CDR de la base on-line para verificación de reclamos por Customer Care y el NOC. -La emisión de un Warning por llamadas de "larga duración" provocadas por posibles problemas de desconexión, útil para evitar reclamos por llamadas "retenidas". 5- APLICACIONES DE CHIP La Plataforma CHip ha sido diseñada como una solución tecnológica ante la falta de equipos apropiados en el mercado. La aplicación inmediata es el servicio de Larga Distancia Alternativo (LDA) y el Clearing-House (CH). A continuación se describen las particularidades de estos servicios LD Alternativo. El servicio de LDA consiste en la posibilidad de realizar llamadas de Larga Distancia Nacional e Internacional en forma optativa, donde el cliente puede cursar sus llamadas LD por Carrier-IP anteponiendo un prefijo. El cliente tiene la opción de elegir en cada llamada si desea utilizar el servicio LD Alternativo o el servicio de LD Carrier Class tradicional. Este servicio es ofrecido en iplan desde inicios del El servicio está disponible sólo para clientes conectados a iplan (no existe presuscripción) y en una primera etapa fue restringido al segmento de negocios Wholesale (no disponible en clientes Retail). El cliente objetivo es aquel donde la LD es relevante y prioriza el precio sobre calidad o para aquellos donde su negocio es la reventa. Por ejemplo, clientes de Calling Card o de Call Through. Para el mercado Retail el servicio LDA se utiliza solo como herramienta de retención o cierre de negocios. Por ejemplo para Call Centre. Las características básicas del producto incluyen los siguientes tópicos: -Servicio preferencial. El cliente podrá, anteponiendo el prefijo 790 al número de destino, elegir cursar su llamada por LDA. Este servicio es optativo y convive con el servicio de tradicional, de modo que en el momento de efectuar la llamada el cliente puede elegir qué tipo de tecnología utilizar. El cliente puede configurar el prefijo 790 en su central telefónica PABX o en la plataforma, de modo que por defecto todas las llamadas del cliente se efectúen utilizando este servicio. -Canales de venta: Debido a la naturaleza del producto, LDA se posiciona como un capturador de prospects o clientes con tráfico LD relevante y como un mejorador de algunos productos existentes. -Atención al cliente: Cuenta con el servicio de Atención al Cliente 7x24 estándar de telefonía (atención telefónica personalizada y vía ). Además, mediante la utilización de un nombre de usuario y una contraseña en una página de Internet, el cliente obtiene información en tiempo real del detalle de llamadas realizado. -Service Delivery En caso de clientes nuevos, el tiempo de provisión estará condicionado por el tiempo de provisión del servicio de telefonía que contrate el cliente. En caso de clientes existentes el Service Delivery puede llevar tiempos muy reducidos. -Calidad de Servicio. Se compromete al cliente un ASR del 40%. Si bien, por la naturaleza de los Carrier-IP el servicio debería ser inestable, la Plataforma CHip permite mantener un standard comercial óptimo. Los precios son bajos, manteniendo los estándares de calidad que exige el mercado. Los Contratos son flexibles sin penalidad de salida Clearing-House CH. Se puede ver al servicio de CH como un proveedor de diferentes Carrier Alternativo. Funcionalmente, Carrier- Alternativo y Clearing-House son la misma cosa (excepto el punto donde se toman los CDR). Sin embargo, CH tiene un negocio propio que la distingue: el tráfico de arbitraje entre Carrier-IP Características del negocio CH. La funcionalidad de Clearing-House CH tiene como objetivo la compra-venta de minutos de LD (trading) con Carrier-IP nacionales e internacionales. Las claves de este negocio son: -Disponer de una gran cantidad de Carrier-IP conectados a la plataforma de manera que se puedan aprovechar las ofertas de terminación de minutos en diferentes países o ciudades. Esto genera ofertas con distribución diaria u horaria. Ningún Carrier-IP conectado a la plataforma debe conocer la ruta que se utiliza para el delivery, ni a los otros Carrier conectados. Concepto básico para la protección del negocio. -Disponer de alto volúmenes de tráfico originado. La negociación de precios se basa fundamentalmente en el volumen. Se abren entonces nuevas oportunidades de negocios al disponer de mejores precios. -Como la calidad de servicio puede no corresponder a Carrier-class, se requiere la supervisión del enrutamiento por día y hora y la vigilancia de la calidad de servicio. Funcionalidad que son automatizadas mediante la Plataforma CHip. La pieza clave es el GW IP-IP (en el negocio de CH es conocido como Proxy IP-IP). Este permite optimizar el uso de los Gateway-E1 Cisco-5300/5350 ya que el tráfico de arbitraje solo pasa por el GW IP-IP, sin usar capacidad de Gateway-E1 de interconexión hacia la PSTN. La CH le ofrece a los Carrier-IP conectados la terminación de llamadas en diferentes destinos. Según el destino es el tipo de negocio: -Terminación: El Carrier termina tráfico en la PSTN mediante la red de iplan. 13

94 Monografías 6 (2003) Gateway IP-IP (CHip) -Hubbing o arbitrage: en este servicio el Carrier termina tráfico en otros destinos internacionales usando las disponibilidades de terceros Carrier (también conectados a CHip). -Originación: el Carrier recibe tráfico desde su cliente, el que es enviado a la CH. Cuando el tráfico es bilateral, los Carriers conectados tienen el potencial de poder terminar tráfico y por lo tanto tener un balance de tráfico tasado neutro (en dinero, no en minutos) Características del Carrier-IP. Las características del tráfico del Carrier-IP son las siguientes: -Muy granular. Cada Carrier ofrece buenos precios solo donde tiene POP propios (Puntos de Presencia con interconexión a la PSTN). -Poca escalabilidad. Cada Carrier suele tener capacidad baja en cada POP. -Alta volatilidad de volúmenes y precios. Los Carrier cambian frecuentemente de ruta (es fácil) y son poco fieles al proveedor. Las ofertas pueden tener una duración limitada en la medida que se descubren nichos y estos son explotados hasta generar una contra medida. -Calidad de servicio inestable. Los Carrier no tienen instalaciones que permitan asegurar una calidad de servicio QoS con atención 7x24hs. Para lograr una QoS aceptable, la principal misión de la Plataforma CHIP es tener multiplicidad de rutas a cada destino. Los clientes de la Plataforma son básicamente de dos niveles: -Los denominados Carrier-de-carrier (como ser ITXC, Telenova, ibasis, etc) que hacen tráfico de minutos entre Carrier (o al menos no originan trafico propio) y -Los originadores de tráfico conocidos como TIER-2 (casi todos generan tráfico mediante la comercialización de Tarjetas Calling-Card). Estos últimos utilizan las redes de los Carrier Incumbentes y su principal negocio está en la originación de tráfico (son lo típicos clientes de los Carrier del primer grupo). El objetivo de la CH es tomar el tráfico de los originadores de otros países y terminar tráfico en los POP de esos operadores. En muchos destinos, donde el precio es muy parecido entre varios Carrier (como USA continental, Europa Occidental nocelular), el determinante no es el precio sino los potenciales acuerdos de swap o balance de tráfico. Cuando se rutea por los carriers TDM, los Carrier suelen ofrecer precios planos flat a cada destino (por su volumen promedian fijos y celulares, ciudades, etc) estas rutas se suelen usar para el tráfico discriminado a los destinos donde los Carrier-IP son caros Aspectos contractuales. a) Facturación. El primer aspecto contractual a tener en cuenta es la Facturación. Los períodos de facturación son usualmente semanales. Por la bilateralidad del negocio, existe en general facturas que se cruzan por el tráfico que cada uno le termina al otro. El valor neto resulta en el saldo que uno de ellos paga al otro (o compensa con tráfico en el próximo ciclo). Esto genera una Liquidación de facturas. Para clientes con domicilio en el exterior, se puede facturar sin IVA en u$s mediante una factura tipo E (Exportación de Servicios). Para clientes con domicilio local, se factura en pesos $ con factura normal. b) Disputas. Si hay diferencias entre el tráfico que uno factura y el que midió la otra parte, se genera una Disputa. Las disputas tienen un tratamiento diferencial. Hay un plazo para notificar a la otra parte de la disputa (30 días). Para la liquidación se considera como válido el monto que no se disputa. El monto disputado debe resolverse en un plazo de 90 días. Las disputas deben estar bien fundamentadas y detalladas a nivel CDR, de lo contrario no se consideran válidas. La Modalidad de Pago depende del perfil de cada Carrier: -Carrier netamente terminador: son aquellos cuyo principal interés y estructura requieren servicios de terminación de llamadas. Son 100% prepagos con pagos semanales por adelantado y umbral de corte al 80% del monto prepagado. -Carrier bilaterales: son Carrier con los que fácilmente puede lograrse un neto cero de tráfico (en tráfico tasado, no en minutos cursados). El acuerdo es simétrico y por ende no hay prepagos de ninguna de las partes. Los plazos de liquidación y pagos de los valores netos requieren el cruce de facturas en los 5 días de completado el período de tráfico. El día 5 se deben haber informado las facturaciones (vía ) y acordado la liquidación. El pago del neto se hace a las 72 hs de cerrada la liquidación. Si no hubo disputas en ese lapso inicial, se hizo el neto del tráfico, posteriores disputas se acreditarán en posteriores liquidaciones. c) Control de Riesgo. Para mantener el Control de Riesgo Crediticio, se procede al Monitoreo diario del tráfico cursado y valorizado (según Sistema de Mediación). Se trata del tráfico recibido menos el tráfico terminado por cada Carrier- IP, lo que entrega el valor neto acumulado. El Control semanal de balance por operador genera la siguiente información: -Neto semanal. -Modificaciones en los ruteos si hay una desviación del neto. -Cortes de ruta en caso de terminadores que no cubren su prepago. -Limitación (definir máximos canales permitidos) de tráfico pico, para evitar los picos de tráfico de desborde. d) Contratos. Los Tipos de contratos pueden ser de diversos tipos: -Bilateral Agreement. En formato Propios (con contratos bilaterales CH) o de Terceros. En este último caso, muchos Carrier (normalmente operadores grandes, PTTs, telcos) solo aceptan sus propios contratos o el proceso de ser aprobados en esos Carrier puede tomar mucho tiempo. Se evalúa entonces en cada caso si el contrato del Carrier cumple con los requerimientos propios. -Purchase agreement. Para el caso donde el Carrier es netamente terminador de tráfico, se firma un acuerdo de compra donde se estipula la forma del prepago, destinos y tarifas. En el caso que iplan sea un neto comprador, se aplica el mismo criterio en sentido inverso (es el caso donde un operador tiene precios muy buenos a destinos muy específicos y no tiene originación para enviar a iplan como contraprestación). 14

95 Monografías 6 (2003) Gateway IP-IP (CHip) -Broker (bilateral). Es una figura que permite a personas acercar negocios de tráfico y cobrar por eso una comisión. Las comisiones se pagan por diferencia entre los targets pedidos y ofrecidos y los precios efectivamente conseguidos por el broker. e) Precios. Con referencia a los Precios cada caso se cotiza como un caso particular. Las variables a considerar para determinar el precio: -Tipo de negocio (bilateral, unilateral). -Forma de pago (caso de terminadores). -Volúmenes comprometidos por destino. -Perfil de tráfico (composición de volúmenes y destinos). -Reputación del Carrier. El Pago mensual por adelantado es un commitment de tráfico, lo que permite lograr descuentos en los terminadores y ese descuento puede transferirse al cliente por pagar todo el mes por adelantado. f) Roles dedicados al negocio CH. Los roles necesarios para el negocio CH incluyen un Business Manager y al Router Master. El primero es responsable de: -administrar el tráfico y enrutamiento para cumplir con los acuerdos firmados con los clientes, -de requerir el enrutamiento, de que el tráfico de terminación sin swap sea prepagado y que se cumplan las compensaciones por swaps, -del análisis y medidas del balance de tráfico con cada Carrier, -del monitoreo constante del negocio a través del SGM (sistema de Gestión Mayorista) y -de fijar las tarifas de los convenios sobre la base de las pautas fijadas por Marketing. El segundo es responsable de la habilitación de rutas, de la prueba constantes y pro-activa de las rutas y de los reclamos de clientes vía Customer Care, y del enrutamiento en casos de falla. LD Alternativo puede verse como un Carrier conectado a la plataforma CHip, que es netamente originador de tráfico: -Usa los Carrier conectados al negocio CH y la gestión de rutas que garantizan estabilidad del servicio. -Los precios que consigue CH se transfieren como costo directamente a LDA (obtiene mejores precios por el volumen que mueve CH). -La gestión de rutas y monitoreo es una tarea común al tipo de carrier (VoIP) y no del negocio (LDA o CH). El route master es un recurso compartido por ambos negocios. -Operativamente, LDA y CH son la misma cosa, CH mira hacia los Carrier y LDA a los clientes. 15

96 MONOGRAFÍAS DE J Journal monografías número 5. Edición septiembre Diseño gráfico original de Marianela V. Ricardo 16

97 monografía iplantech Journal Monografías es una publicación de iplan que contiene información técnica y confidencial de la empresa. Se distribuye a un circuito limitado de lectores a fin de mantenerlos informados sobre el estado y la evolución de la tecnología y el negocio de la Telecomunicaciones, principalmente en las redes IP y la Telefonía-IP. Se ruega a los lectores a mantener el principio de Confidencialidad sobre la información aquí contenida. No está autorizada su reproducción o distribución por cualquier medio sin antes consultar con la empresa. IPlataforma Servicios Pre/Pospago Diseñada en el primer semestre del 2002 y con varios Release intermedios, la PSPP se ha convertido en una fuente inagotable de nuevos Servicios, entre ellos las Calling Card. La plataforma lleva el nombre de CVOX. IINDICE 1- Evolución histórica. 2- Componentes, Funcionamiento, Release y Features asociados. 3- Herramientas de Management. 4- Generalidades del negocio. 5- Casos de estudio. IABSTRACT Esta plataforma ha sido diseñada y ha evolucionado desde inicios del Ha tenido sucesivas versiones posteriores que agregaron nuevas e innovadoras funcionalidades a los servicios prepagos y pospagos. Las tarjetas Calling Card de iplan están distribuidas en todo el mercado, identificándose cerca de medio centenar de tarjetas. Esta monografía se encuentra dividida en dos parte: la tecnología y el negocio. Se muestra las bondades de la tecnología para producir soluciones novedosas e innovadoras en el mercado, así como la posibilidad de ingresar en este negocios con un mínimo de requisitos (el producto llave-en-mano de iplan). IAUTORES Esta monografía ha sido redactada gracias a la documentación original de Marcelo Castro, Javier Temponi, Sebastián Navarro y Gustavo Novak. 1

98 Monografías 7 (2003) Plataforma de servicios prepagos PARTE I: LA TECNOLOGIA 1- EVOLUCION HISTORICA 1.1- Plataformas arrendadas La idea de que iplan tenga su propia plataforma de Calling Card y el producto llave-en-mano es de fines del En aquel momento, se producía una expansión en el mercado de Tarjetas Prepagas; en tanto muchas de ellas aplicaban pequeñas trampas que recaían sobre el Usuario y hacían algo turbio el negocio. iplan llevada un año de vida y el negocio Wholesale adquiría una preponderancia que no había sido planeada. En ese momento se ofrecían solo servicios de originación y terminación de llamadas (similar comportamiento tenían los demás Operadores). Se trataba de una simple intermediación, con poco valor agregado. El Cliente debía tener y administrar su propia Plataforma de Servicios Prepago. La decisión adoptada fue poseer una plataforma propia, que permitiera crear servicios-a-medida y multiplicar el negocio. Sin duda, esta decisión ha tenido consecuencias comerciales muy importantes. No solo ha permitido la expansión de un negocio de interés empresario, sino que introdujo claridad y transparencia para el Usuario final. Como se verá mas adelante, disponer de un producto llave-en-mano introduce condiciones contractuales que impiden las acciones predatorias sobre el Usuario final. En enero-2003 se invitaba a cotizar a distintos proveedores y se analizaron 5 ofertas. Se trataba de plataforma Carrier- Class de costos muy elevados. La necesidad de contener las inversiones, nos llevó a cerrar un acuerdo con un proveedor local para la provisión de una plataforma en el NOC de iplan. Se realizó mediante un contrato de Revenue Sharing RS, donde el proveedor cobra un peaje por cada llamada y por cada habilitación de PIN. Como se representa en la Figura 1, esta solución contiene un Server que dispone de placas con interfaz E1, las cuales se conectan a la central de conmutación NEC. La llamada entrante desde la PSTN, ingresa al sistema mediante un número con formato MCDU. Entonces, es enrutado nuevamente por el server dedicado hacia el destino final (pudiendo ser la PSTN o un Usuario de iplan en la red de Telefonía-IP, dependiendo del número de destino). El server tiene también la función de IVR (mensajería grabada para el Usuario). En adelante se entiende por Cliente, al operador que contrata a iplan el servicio para emitir tarjetas prepagas en el formato llave-en-mano y se denomina Usuario al que utiliza la tarjeta Calling Card. En marzo-2002 se pone en funcionamiento la plataforma PSPP y los primeros Clientes se instalaban en abril Una segunda plataforma, con la misma modalidad de negocio, fue contratada para la misma época. Durante este período surgió la necesidad de disponer de una plataforma con diseño propio, pero con una estructura tecnológica diferente. Esto se hizo evidente cuando se verificó que el soporte técnico de los proveedores no permitían mantener una operación confiable y confortable. Los primeros trabajos de desarrollo se hicieron para la Calling Card de Internet y luego se pasó a la de telefonía, la cual era más compleja debido a la variedad de destinos que deben alcanzarse La Plataforma CVOX de iplan En la solución de una plataforma en Revenue Sharing, el proveedor coloca servidores con hardware apropiado para recibir tramas E1 desde la central de conmutación (normalmente se utilizan tarjetas E1 de mercado insertadas en Server industriales). Este server tiene el software y el IVR para atender las llamadas de Figura 1. Primera plataforma de Calling Card en Revenue Sharing 2

99 Monografías 7 (2003) Plataforma de servicios prepagos Figura 2. Plataforma CVOX de PSPP basada en el uso de AS-5300 de Cisco. En la plataforma de iplan en cambio, las tramas E1 se terminan en un Gateway de voz GW-E1 (equipos Cisco- 5300/5350), los que mantienen la funcionalidad de IVR y el software de validación. El accounting se encuentra en los Servers anexos. En la Figura 2 se presenta un diagrama a bloques. De esta forma, la Plataforma CVOX de Servicios Prepago y pospago PSPP utiliza el recurso de los Access Server Cisco que son usados para interconectar la red de Telefonía- IP con la central de conmutación (son conocidos como NASGW). Cada llamada ocupa dos canales (la entrada desde el 0800 y la salida hacia el número de destino final) de los GW-E1. Se utiliza un recurso común a otros servicios, pero cada llamada ocupa dos canales. En aplicaciones de menor carga de tráfico que en el caso de iplan, es posible usarse GW-E1 de menor porte que los Cisco-5300/5350, tales como los Cisco- 2600/3600. Esto es interesante para empresas que no requieren una carga de tráfico tan elevada. PSPP se diseñó en el tiempo de un trimestre. En la primer versión, el hardware utilizado fue un server LPR-1000 de HP con una unidad de rack. Disponía de 2 procesadores y 1,5 GByte de memoria RAM. Un segundo server sería instalado luego para backup del primero. El software fue desarrollado sobre Linux en lenguaje C. Una llamada típica sigue el siguiente procedimiento: -Desde la PSTN ingresa una llamada con formato MCDU. -La central de conmutación la envía al GW-E1, el cual tiene un IVR (con mensajes pregrabados de bienvenida y con instrucciones para el uso). -Una vez ingresado el PIN por parte del Usuario, el GW-E1 se comunica con el server para la validación del PIN y verificar la disponibilidad de crédito. -Luego, el Usuario ingresa el número de destino. -Nuevamente se consulta la base de datos para verificar el accounting y el tiempo restante de la llamada a ese destino. -La comunicación se sigue hasta la finalización y se descuentan los costos de la llamada del valor precomprado remanente. -En caso de agotarse el crédito, el mismo GW-E1 se encarga de interrumpir la llamada. Es decir, el GW-E1 sigue la métrica de tiempo de consumo. Entre las características técnicas generales de la plataforma CVOX, podemos mencionar: -Permite múltiples fraccionamientos por Clientes y la recarga de tarjetas con tope configurable. -Permite la utilización de distintos largos de PIN y contraseñas. -Soporta Usuarios y contraseñas alfanuméricas. -Permiten al Cliente, mediante un protocolo propietario de iplan, realizar en forma remota y automatizada la recarga, consulta de Clientes conectados, consulta y extracción de CDR, etc. -Permiten la suscripción por ANI (esto habilita a realizar la suscripción a un servicio de Internet vía 0800 donde el Usuario será identificado por el número de abonado A llamante). -Admite el servicio Roaming. -Permiten utilizar una misma tarjeta estando en las cuatro ciudades donde iplan tiene presencia (Buenos Aires, La Plata, Rosario y Córdoba), marcando un mismo número de MCDU. Para mediados del 2002, se encontraba plenamente operativa CVOX para telefonía. También se concluyó el diseño de la plataforma de Calling Card para Internet. Esta última plataforma, permite el acceso a Internet vía un 0800 a una conexión dial-up mediante tarjetas precompradas. Cada tarjeta posee un precio que equivale a minutos de conexión. Como en el caso de la Calling Card de Telefonía, la plataforma esta desarrollada íntegramente sobre el sistema operativo Linux, mediante la utilización de base de datos MySQL y programación en lenguaje C. 3

100 Monografías 7 (2003) Plataforma de servicios prepagos Figura 3. Integración de la plataforma de servicios prepago y pospago a COSO. Permite múltiples configuraciones, dándole a iplan una gran flexibilidad para adaptarse a las necesidades de los Clientes. Actualmente está disponible en Buenos Aires, Rosario, Córdoba y La Plata, utilizando los equipos de acceso a Internet Cisco-5300/5350 de Dial-up. Son los equipos utilizados para los Free-ISP (el 5300 es dedicado a telefonía o dial-up, mientras que el 5350 es compartido entre ambos servicios). CVOX fue montada inicialmente sobre un server Pentium III 650 MHz con un disco IDE de 5 Gbps y 256 MByte de memoria, corriendo sobre Red Hat 7.2. Este producto no ha tenido el éxito esperado y se debe quizás a la falta de promoción realizada entre los Usuarios El futuro de la Plataforma CVOX CVOX tiene dos vertientes de desarrollo a futuro. Por un lado, la adaptación del hardware a versiones más pequeñas y escalables, para ser adoptadas por pequeñas empresas. Este es el caso de Clientes que inician su negocio en el formato llave-en-mano utilizando la CVOX de iplan y luego, con el crecimiento de sus actividades, deciden adquirir su propia plataforma CVOX para administrarla a voluntad. Por otro lado, durante el segundo semestre del 2003 se producirá una integración de los servicios prepago y pospago (entre ellos los de Calling Card) a la plataforma COSO. El software COSO ha sido diseñado en iplan como Red Inteligente Virtual, para ofrecer servicios de traslación de llamadas. En un número monográfico de Journal, se puede seguir la evolución de la tecnología COSO con todo detalle. La relación de la plataforma Prepago y COSO es muy estrecha, lo cual puede seguirse con la Figura 3. El procedimiento para ofrecer una comunicación de servicio prepago utilizando COSO, es el siguiente: -La llamada entrante es analizada por COSO. Se hace la primera validación por origen (black list, categoría, horario, etc), con lo cual se obtiene el permiso para seguir con el paso siguiente. -La llamada es enrutada hacia el GW-E1, el que posee el IVR, que da la bienvenida al Usuario. -Cuando el Usuario ingresa el PIN, se realiza la solicitud de validación al servidor Radius. -Una vez realizada las validaciones, el IVR libera la llamada y COSO se encarga de re-discar al destino. -El canal vocal del GW-E1 se libera quedando disponible para otra llamada. Se utiliza entonces tramas E1 en loop contra la central de conmutación. La llamada entra al loop y vuelve a la central con la nueva dirección de salida. -COSO se encarga de controlar el tiempo disponible de la llamada en curso y de generar el CDR respectivo. Definitivamente, se obtienen algunas ventajas adicionales debido a la integración de CVOX con COSO: -Este sistema permite la integración entre las Bases de Datos de servicios Calling Card y Además permite la integración de aplicaciones para un mejor procesamiento y capacidad sin gastos adicionales. -Permite utilizar el IVR del GW-E1 Cisco-5300 para atender al Usuario y recolectar los datos en el mismo modo que lo hace CVOX. Pero se optimiza el uso del GW-E1, ya que una vez validados el PIN y el número de destino, el canal vocal se libera quedando disponible para una nueva llamada. -Se integran los datos de señalización con aquellos ingresados por el Usuario. Se integran parámetros y otras características tales como categoría del origen y Black o White Lists, no disponible en la plataforma CVOX en forma independiente (debido a que las mismas están contenidas en la señalización SS7, que si es analizado por COSO). -Todas las instancias de llamada pueden generar los dos CDR que se utilizan para facturar el tipo de servicio de Calling Card. -En cuanto a la ruta, COSO puede indicar un nombre de ruta especial por cada Cliente Calling Card, aunque la llamada salga por un canal del mismo loopback de trama E1 que utilizan el resto de los servicios. 4

101 Monografías 7 (2003) Plataforma de servicios prepagos 2- COMPONENTES, FUNCIONAMIENTO, RELEASE Y FEATURES ASOCIADOS Componentes. De acuerdo con la Figura 2, se disponen de Servers dedicados a las funciones de CVOX. Se trata de los siguientes módulos: Service Provisioning Module (SPM). El SPM permite el provisioning para todas las funcionalidades de la plataforma. Puede realizarse de dos formas. La primera es mediante una Interfaz web, la cual se accede mediante usuario y contraseña y la segunda en mediante un protocolo propietario, el RMP. Que es un protocolo de comunicaciones que funciona sobre un puerto TCP. La información esta codificada mediante el protocolo XML. El SPM está instalado sobre un Servidor con el sistema operativo Linux. En este también se encuentra un servidor web, donde esta alojada la interfaz de Administración Gráfica y también el servidor de RMP para administración remota. La interfaz gráfica vía web está desarrollada en PHP (Personal Home Page Tools), JavaScripts y HTML. La interfaz de administración remota esta desarrollada bajo el lenguaje C/C++. El SPM trabaja con el DBM para poder almacenar o requerir datos almacenados en la Base de Datos MySQL. Esta interacción se hace mediante la API (Aplication Program Interface) de PHP, para el caso de la interfaz gráfica y de C/C++ para el caso de la interfaz de administración remota Billing Service Module (BSM). El BSM permite que darle Inteligencia al IVR, y generar la información necesaria sobre las llamadas. Está dividido en dos partes. La primera está instalado sobre el Access Server y es un script realizado en lenguaje TCL (Tool Command Language). Esta primera parte es la que se encarga de manejar el flujo de la llamada. El script TCL dialoga con un servidor TFTP (Trivial File Transfer Protocol), donde toma el audio para reproducirlo. Está instalado en el mismo servidor donde se encuentra la segunda parte. Dialoga también con un servidor Radius que está en el mismo servidor. La segunda parte esta instalada en un Servidor con el sistema operativo Linux, en el cual se encuentra un servidor Radius (Remote Authentication Dial In User Service), que dialoga con el script TCL, dándole la inteligencia necesaria para llevar a cabo la llamada. A su vez el servidor Radius dialoga con el DBM que es una base de datos MySQL. En esta base de datos están almacenados todos los datos (Pines, Anis, Créditos, Destinos, etc). Sobre la base de los datos recogidos en el diálogo con DBM, puede decidir si permitir hacer una llamada, el tiempo de comunicación, informar o no el crédito, poner tono en lugar del mensaje ingrese el numero destino, informar o no el tiempo disponible y si la llamada va a salir por algún carrier alternativo o no Data Base Nodule (DBM). El BDM lleva a cabo manejo de los datos basándose en una base de datos MySQL. Contiene la base de datos MySQL sobre un sistema operativo Linux y HP-UX. La gestión de la base de datos se realiza en lenguaje SQL a partir de los parámetros contenidos en los mensajes Radius recibidos. Una vez obtenida la información correspondiente y luego de la gestión de la base de datos, la aplicación del BSM procederá a armar un nuevo mensaje Radius a partir de los datos recibidos. También interactúa con el SPM mediante la API de PHP y de C/C Funcionamiento. A continuación se muestra como se desarrolla una llamada normal hacia la Plataforma y de ella hacia el destino final: 1- El Usuario de Origen (Abonado A) disca un número de Iplan, pudiendo ser un número gratuito MCDU o un número geográfico. La llamada es enrutada a través de la Red de Telefonía Pública (PSTN) hasta la central. 2- En la central de acceso, si el número discado es 0800, la llamada es enviada a COSO, el cual traduce a un número geográfico (un número si la categoría es abonado ordinario y otro número distinto si es teléfono público). De no ser un numero 0800, la llamada se enruta directo al Access Server, el cual tiene configurado un dial-peer con el número geográfico y el aplication ccardv2. 3- Cuando la llamada entra al access server, el SMM (el script TCL) toma el control de la llamada. Una vez que la llamada está en control del TCL sigue los siguientes pasos: 4- Verifica que el ANI no esté en la Black List (esto lo hace por medio de una consulta Radius). De estar en la Black list la llamada se corta y no envía el answer a la central. 5- Si el ANI no se encuentra en la Black List, se procede a validar el ANI. Esto se hace mediante una consulta de Radius), en caso de que el ANI fuera validado también se envía el crédito disponible y si se quiere que se reproduzca algún audio ( Ud dispone de xx,xx pesos y/o Marque el numero al que desea comunicarse ) o se envía un audio de tono. En el caso de no ser validado el ANI, se reproduce un audio de bienvenida (el que corresponde al número discado) y otro audio que le indica que debe introducir su número de tarjeta. Una vez que se introdujo el número de tarjeta mediante una consulta Radius se valida, si ésta no ocurre se procede a pedir el número nuevamente (así hasta 3 veces). 6- En el caso que el ANI o número de tarjeta sean validados se reproduce un audio que indica que hay que ingresar el número al que se quiere comunicar o en caso contrario se reproduce un tono. Una vez discado el número se deberá discar # o esperar el tiempo de time out para que el TCL tome el número. Luego, el TCL valida mediante una consulta Radius el número discado. El número discado es validado considerando el número de origen, el PIN o ANI y el número destino. En la consulta se devuelve el costo por minuto del destino, si este destino sale por algún carrier se devuelve el prefijo para el carrier y también en la consulta se indica si hay que informar el tiempo disponible. 7- El realiza la llamada al destino marcado. En el caso de dar ocupado se lo invita a que se marque nuevamente el destino. Si el destino contesta, se enlaza la llamada. Cuando el destino atiende, se inicia un contador con tiempo máximo establecido a partir del crédito existente y el costo por minuto del destino. Cuando falta un minuto para que se corte la comunicación se reproduce un audio indicándolo. 5

102 Monografías 7 (2003) Plataforma de servicios prepagos 8- Cuando la llamada se termina, ya sea porque se alcanzo el tiempo máximo de comunicación, o porque el origen o el destino la finalizaron, se informa la duración al SMM por Radius. El cual realiza el billing correspondiente, generando un registro de la llamada con todos sus datos y descontando al PIN o ANI el monto de la llamada. 8- Una vez que la llamada termina el TCL libera el canal y finaliza Funcionalidades Servicio de Llamadas con Tarjetas Prepagas. Es un servicio en el que el cliente compra una tarjeta con determinado crédito y este se la va descontando a medida que realiza las llamadas. El cliente llama a un 0800 o un número geográfico, ingresa solo el PIN o el PIN más una contraseña, y por último el destino al cual se quiere comunicar. Una vez terminada la comunicación se le descuenta del crédito de la tarjeta el importe de la llamada realizada Servicio de Llamadas con Tarjetas Pospagas. Es un servicio en el que el cliente tiene una tarjeta sin crédito y cuando se le quiere facturar al cliente se extraen los detalles de llamadas que realizó y se factura con esta información Servicio de Llamadas con reconocimiento de ANI (Call Through) Prepago (comercialmente conocido como Identicall). Es un servicio en el que el cliente abona un determinado crédito y este se la carga a su número de teléfono (ANI), que se va descontando a medida que realiza las llamadas. El cliente llama a un 0800 o un número geográfico, la plataforma valida el número de teléfono (ANI), si esta fuera de su teléfono puede ingresar su número de teléfono (el que tiene registrado) más una contraseña y por último el destino al cual se quiere comunicar. Una vez terminada la comunicación se le descuenta del crédito el importe de la llamada realizada Servicio de Llamadas con reconocimiento de ANI (Call Through) Pospago. Es un servicio donde al cliente se le habilita su número de teléfono (ANI) para que pueda realizar llamadas sin restricciones de crédito. El cliente llama a un 0800 o un número geográfico, la plataforma valida el número de teléfono (ANI), si esta fuera de su teléfono puede ingresar su número de teléfono (el que tiene registrado) más una contraseña y por último el destino al cual se quiere comunicar. Cuando se le quiere facturar al cliente se extraen los detalles de llamadas que realizó. CVOX permite además la Confección de Registros de llamadas (CDR call detail record) El BSM arma los registros de llamadas de acuerdo con la información recibida a través del set mensajes enviados por el BSM (script TCL) y cada uno de ellos referido a una llamada. Por cada llamada se generan dos registros. Uno referido a la llamada entrante a la plataforma y uno referido a la llamada saliente de la plataforma hacia el destino. Estos registros se pueden relacionar por el id de llamada entrante. Los registros son almacenados en la base de datos del DBM. Figura 4. Pantallas de administración de la Plataforma de Calling Card. 6

103 Monografías 7 (2003) Plataforma de servicios prepagos La plataforma permite el reporte de alarmas vía mail. Las alarmas son configuradas por la interfaz web. Hay dos tipos de alarmas diferentes que se pueden configurar. La primera de ellas es por cantidad de CDR en curso. Existe un proceso que revisa cada 10 minutos la cantidad de llamadas en curso y si ellas exceden la cantidad configurada por alguna alarma envía un mail a la casilla configurada en la alarma. El otro tipo de alarma es para los consumos de Indenticall. En estas alarmas se configura un porcentaje del límite de crédito mensual de cada ANI. Si este lo excede o lo iguala, es enviada la alarma por mail Release La plataforma de Calling Card durante un año se desarrolló sobre la base de ampliaciones de Features sobre la primera versión de software. El último Release de esta línea es conocido como v1.05. Con posterioridad, fue reestructurado desde su base y se pasó a la versión 2.01, en julio Ya en la primera versión 1.05, los principales parámetros son administrados vía Internet. Entre ellos se cuenta: -la creación de nuevas tarjetas, -la carga de nuevos planes tarifarios (y su modificación), -análisis del ciclo de vida, etc. Además, el operador tiene la posibilidad de monitorear la actividad del sistema, permitiendo observar en línea el funcionamiento de la plataforma. El listado de Servicios y Facilidades disponibles en la Plataforma de Calling Card hasta marzo-2003 era el siguiente: Servicios: -Validación de PIN para las Calling Card. La plataforma CVOX permite validar a los Usuarios de tarjetas prepagas, las cuales tienen pre-impresas un PIN variable que fluctúa entre 8 a 15 dígitos. Mediante este PIN se identifica a un Usuario asociándole la carga de dinero correspondiente. -Validación de PIN y Password para Calling Card. En este caso las tarjetas tienen pre-impresas un PIN visible y un contraseña que se encuentra oculta. Esta contraseña debe ser vista únicamente por el Usuario final de la tarjeta, asegurando así una máxima confiabilidad del servicio. -Validación de ANI para Call Through. La validación de ANI permite habilitar una cantidad de dinero al identificador de cada línea telefónica (conocido como ANI) asociado a un Cliente. Cada vez que el Usuario llame a la plataforma desde ese ANI podrá utilizar el dinero previamente cargado. Facilidades: -Mensajes de bienvenida. Permite que cada Cliente pueda personalizar el mensaje que emite la plataforma al ingresar una llamada. En la Figura 2, los mensajes se encuentran grabados en un IVR que físicamente se encuentra en el Gateway-E1. -Mensaje de saldo en pesos. Permite configurar por cada Cliente un mensaje, mencionando el saldo de una llamada en pesos o únicamente en minutos. -Tabla de precios. Permite que un mismo Cliente tenga diferentes tablas de tasación. Las tablas se pueden separar por grupos de PIN, números de origen y destinos. Esto otorga mayor flexibilidad para la composición del costo de cada destino dependiendo del origen de la llamada. También, a este feature se le suma la posibilidad de cobrar un costo diferente si la llamada fue originada desde un teléfono público. -Opciones de múltiples Carrier. Permite seleccionar para cada Cliente y por cada destino un carrier alternativo. Esta característica se efectúa agregándole un prefijo delante del número que marco el Cliente. Este feature le permite al Cliente elegir el Carrier por el que quiere salir según el destino. Una monografía de Journal está dedicada al Gateway IP-IP o Plataforma CHip, la cual administra este tipo de Carrier-IP. -Traducción de numeración. Permite que la plataforma traduzca un número marcado por el Usuario. Por ejemplo, si el Cliente marcó el número de Emergencia para la Policía la llamada será enrutada como si hubiera marcado el número del Comando Radioeléctrico correspondiente. -Administración vía Web. Se puede administrar los Lotes de Clientes, lotes de PIN o de ANI, lotes de planes de tarifas y de Black list de PIN (la Black List permite neutralizar ciertos PIN, por ejemplo en caso de robo). Además permite las consultas y exportación de CDR e Informes estadísticos de consumo y facturación. -Protocolo de administración remota RMP. Este protocolo permite la utilización de funcionalidades de la plataforma en forma remota. Este feature da la posibilidad al Cliente de automatizar su sistema de gestión interno. Algunos de los mensajes soportados son: la Activación, la Consulta de saldo, la Anulación, la Solicitud de PIN y la Recarga. Más adelante se entregan mayores detalles en cuanto hace al funcionamiento del protocolo y que aplicaciones comerciales ha encontrado. -Cargo fijo por llamada (conocido como bajada de bandera). Este feature podrá ser habilitado por el Cliente, descontando un valor determinado cada vez que un Usuario realice una llamada a la plataforma. -Black List de PIN. Permite deshabilitar momentáneamente ciertos PIN, según lo desee el Cliente, desde la interfase Web o desde el protocolo de administración remota Release En julio-2003 se puso en marcha el nuevo release del software de la Plataforma de Calling Card. En él se pueden encontrar nuevos servicios y facilidades, añadidos a los anteriores. En la Figura 4 se muestran algunas de las pantallas de configuración y administración de la PSPP en su Release Servicios adicionales: -Soporte de múltiples tablas de tasación para Call Through. Permite que el Cliente pueda tener simultáneamente hasta 8 tablas de tasación diferentes que puede asociar a los ANI en el momento de su creación. Facilidades adicionales: -Integración de Calling Card y Call Through (denominada tarjeta multipropósito). En esta versión se combinan los servicios de Calling Card y Call Through de manera que 7

104 Monografías 7 (2003) Plataforma de servicios prepagos cualquier Usuario de una tarjeta Calling Card pueda dar de alta una ANI y cualquier Usuario de Call Through (asociado a un ANI) puede tener acceso a un número de PIN, cuyas cuentas corrientes estarán asociadas. -Asociación de un ANI a un PIN. Permite que un Usuario del servicio de Calling Card que posee un número de PIN válido puede llamar a un número y ser atendido por un IVR donde tiene la posibilidad de dar de alta hasta 10 ANI del servicio Call Through que compartirán el crédito de su tarjeta de Calling Card. -Asociación de un PIN a un ANI. En el modelo Call Through Retail o Call Through Revendedor, cuando se realiza el alta de un ANI se generará también un PIN que permitirá que el Usuario pueda originar llamadas desde líneas fuera de su domicilio. Comparte el crédito de ambos servicios con de Call Through. -Consulta de saldo y CDR desde la Web. Este feature permite que desde la Web, un Usuario pueda ver los CDR y el saldo actual, ingresando su PIN y Password o su ANI y Password, según corresponda. -Tasación mixta. En esta versión la plataforma CVOX soporta la posibilidad de tasar con base en tiempo de un número entero de minutos. Un Cliente determinado podría tasar las llamadas locales cada 2 minutos y las de Larga Distancia cada 1 minuto. En el fraccionamiento se puede hacer distinción entre llamadas Locales, LDN y LDI. -Elección del Carrier alternativo. Se agrega en la interfaz Web de configuración de la plataforma la posibilidad de seleccionar o no el prefijo 790 (asignado al Carrier Alternativo) por Cliente y por destino. -Funcionalidades adicionales al protocolo de administración remota RMP. Esta versión agrega dos funciones adicionales al protocolo de administración remota; el Rollback de Operación y la Generación de PIN. -Integración con Tenfold. La plataforma generará diariamente un archivo de texto plano separado por comas con un registro por cada operación realizada sobre la plataforma mediante el protocolo RMP. Esta funcionalidad le proveerá a Tenfold (el sistema de gestión de Clientes de iplan) la información para facturación y para el envío de alarmas en el caso que los Clientes excedan un límite de crédito preestablecido. -Inserto de dígito en ANI. Este es un pedido de mejora para adaptarse a particularidades de la red de telefonía de iplan. Permite agregar el digito 8 por delante de las llamadas que sean originadas en la ciudad de La Plata y tengan como destino La Plata o Buenos Aires. -Discado abreviado. Permite que si un cliente disca un número corto por ejemplo 333, la plataforma lo cambia por un número largo por ejemplo El futuro Release. -Posibilidad de hacer segunda llamada. Permite realizar una segunda llamada sin necesidad de re-llamar y reingresar el PIN, cuando el abonado B corta o cuando está ocupado. -Tarjeta DUAL. Permite tener una tarjeta que funcione como un Calling Card común, pero el Cliente cuenta con una opción adicional en el IVR que le permite direccionar las llamadas a una plataforma de Juegos con una tarifa fija. Otros features: -Diferente tasación de la llamada según banda horaria. -Estadísticas de llamadas. Estadísticas simultáneas por clientes y por Access Server. Estadísticas por banda horaria, por origen y destino. Cada cliente va a poder verlas vía web. -Detección de Fraude: está basado en logs de la plataforma. 3- HERRAMIENTAS DE MANAGEMENT Dos software han sido desarrollados como complemento de la CVOX. Uno de ellos se utiliza para obtener datos estadísticos de los clientes y el segundo para trabajar en forma remota con un Sistema del cliente Software de Management de Clientes Se ha desarrollado este software para el seguimiento de las principales estadísticas de los Clientes de Calling Card, obtenidos desde CVOX. En la Figura 5 se muestra un ejemplo típico de la información obtenida. Para obtener los datos mostrados en los gráficos de estadísticas se utiliza los software PHP y MySQL. El PHP es un lenguaje de programación del lado del servidor, gratuito e independiente de plataforma. Es rápido, con una gran librería de funciones y mucha documentación. Un lenguaje del lado del servidor es aquel que se ejecuta en el servidor web justo antes de que se envíe la página a través de Internet al Cliente. Las páginas que se ejecutan en el servidor pueden realizar accesos a bases de datos, conexiones en red, y otras tareas para crear la página final que verá el Cliente. El Cliente solamente recibe una página con el código HTML resultante de la ejecución de PHP. Como la página resultante contiene únicamente código HTML, es compatible con todos los navegadores. MySQL es una base de datos gratuita (GNU) y muy potente. Es la base de datos de código fuente abierto más usada del mundo. En PHP se obtienen de la base de datos MySQL información como por ejemplo: minutos consumidos en cada mes. La Figura 5 muestra la pantalla de Management donde se puede seleccionar la lectura de Consumo, Facturación, PIN usados, destinos, promedio de llamadas. Además se muestran algunos de los resultados como gráficos o diagrama de tortas. Para el próximo Release se están prometiendo las siguientes funcionalidades (entre otras que se agregarán y que aún no han sido anunciadas): 8

105 Monografías 7 (2003) Plataforma de servicios prepagos Figura 5. Se muestran las pantallas del software de Management de los Clientes Calling Card Software de Comunicación El protocolo de comunicación RMP permite la administración remota. Es propietario de iplan y facilita la interacción de algunas plataformas del Cliente con la Plataforma de Calling Card (Figura 6). Es utilizada en tarjetas Calling Card del tipo Norte, Hola-Baires (del Bapro) y Pago-Fácil (próximamente en las tarjetas Yenny y El Ateneo). Por ejemplo, la interacción de CVOX con el sistema de cajeros de un supermercado como Norte, o del sistema de validación de tarjetas de crédito del Banco Provincia. El protocolo de comunicaciones está montado sobre un puerto TCP en el rango comprendido entre el y el El transporte de la información está soportado sobre los estándares de XML (texto plano), haciendo fácil su compresión y posterior procesamiento. Los tipos de mensajes posibles que maneja este protocolo, son: -Solicitud del PIN, -Activación del PIN, -Consulta del saldo, -Recargo del PIN y -Anulación del PIN. El protocolo genera mensajes que están formados por los siguientes atributos: -pin. Campo numérico, de tamaño fijo, justificado con ceros. Es el número de PIN (o número de control) de la tarjeta. -fecha. Es la fecha del sistema que envía el mensaje. -hora. Es la hora del sistema que envía el mensaje. Es recomendable que ambos sistemas estén sincronizados con algún patrón de tiempo (por ejemplo, utilizando NTP) para fecha y hora. -monto. Campo numérico de tamaño variable con dos decimales fijos, separados por un punto. Es el monto que se cargará en la tarjeta. -saldo. Campo numérico de tamaño variable con dos decimales, similar al monto. -result. Campo numérico de tamaño variable. Es el código de resultado de la operación. Si el resultado fue exitoso, el código es cero (0), de lo contrario se entregará un código dependiendo del tipo de error producido. -id. Campo numérico de tamaño variable. Es el número de operación generado internamente por el sistema. -dorig. Campo numérico de tamaño variable. Es el número de la operación que está siendo anulada. 9

106 Monografías 7 (2003) Plataforma de servicios prepagos Figura 6. Componentes y funcionamiento del protocolo RMP para la administración remota. Algunos tipos de códigos de error son: -el PIN con el que se quiere operar no existe, -la transacción que ingreso no existe, -la transacción que ingreso ya tiene un rollback anterior hecho, -el PIN debe ser activado previamente a una recarga, -el PIN ya esta activo y -el saldo del PIN supera los 50 pesos. El servicio provisto entrega la incorporación del concepto de comunicaciones seguras mediante la implementación de túneles encriptados. De esta forma, la comunicación se brindará en forma segura aportando confidencialidad y autenticación a los datos transmitidos. Para lograr la conectividad IP con la plataforma de Calling Card, se utilizará una conexión del tipo VPN mediante el protocolo IPSec encripción DES de 56 bits. El sistema de criptografía DES (Data Encryption Standard) fue desarrollado por IBM y adoptado por el NBS (National Boreau of Standard) como standard de criptografía en el año 1977; solo está disponible bajo licencia del gobierno de USA. Está fundamentado en bloques de códigos conocidos ECB (Electronic Code Book). El método standard utilizado se basa en segmentar la información en bloques fijos de 64 o 128 bits de longitud para realizar una criptografía por bloques. La clave para el cifrado (Key) es un código de 56 bits y se trata de un tipo de clave privada. Para reducir la probabilidad de detección se realiza un proceso de concatenación de forma que el resultado de un bloque influye sobre el siguiente. red interna en iplan. Del lado del Cliente, existirá su propia protección. La conexión es mediante una VPN IPSec y el protocolo de comunicación es el RMP. En el caso que el Cliente desee utilizar el Cliente para VPNs VPN Client de Cisco, se entregará un CD con dicha aplicación, la cual será instalada por el Cliente en el server remoto. El Cliente es responsable de las siguientes tareas: -Instalación y configuración de las cuentas dialup en las PCs o Laptops del Cliente. -Instalación y configuración de la aplicación VPN-Client de Cisco en las PCs o Laptops del Cliente. -Configuración de los parámetros IPSec en la aplicación VPN Client de Cisco en las PCs o Laptops del Cliente. El Usuario remoto podrá establecer la conexión utilizando una cuenta dial-up o bien con servicio ADSL. Sobre esta última tecnología, la conexión DSL se deberá realizar con protocolo PPPoE con el ISP (no está soportada la conexión PPTP con el ISP). Se debe tener en cuenta que la conexión con el ISP proveedor del servicio DSL se realice utilizando las siguientes aplicaciones: NTS Ethernet, Wind River WinPoET y RASPPPoE. La solución puede implementarse sobre la red Internet o mediante un enlace punto-a-punto IP privado (TLS-layer 3). En la Figura 6 se muestran ambas alternativas de conexión entre la PSPP en iplan y el Sistema del Cliente. En ambos casos existen Firewall PIX de Cisco para la protección de la 10

107 Monografías 7 (2003) Plataforma de servicios prepagos PARTE II: EL NEGOCIO 4- GENERALIDADES DEL NEGOCIO 4.1- Producto Calling Card Llave-en-mano. iplan ha creado el producto de Calling Card llave-en-mano a inicios del Corresponde a la provisión de un servicio completo de Calling Card para Clientes que normalmente no tienen ningún conocimiento del negocio y necesitan un asesoramiento integral (incluyendo la plataforma tecnológica). Sin embargo, el Cliente tiene lo más importante en este producto: la cadena de distribución y ventas y conocen el comportamiento de los Usuarios finales. Normalmente se le entregan las tarjetas ya impresas, mientras que el Cliente selecciona el look de la misma para darle su toque personal de acuerdo con el público objetivo. La necesidad de reducción de gastos en servicios, hace que el público opte por las llamadas Línea Control. Algunos piensan en que en épocas de posible inflación el público prefiera precomprar asegurando el valor de su gasto en telefonía. iplan es el único operador de telecomunciaciones que posee un producto de Calling Card Llave-en-mano de estas características. En los años en el mercado, se ha acumulado una amplia experiencia en poner en la calle este tipo de tarjetas; de forma que además de la plataforma tecnológica, se ofrece un buen asesoramiento a los Clientes por el conocimiento de la operatoria y los tiempos involucrados. Cerca de medio centenar de tarjetas Calling Card han sido desarrolladas como producto llave-en-mano y operan sobre la Plataforma CVOX diseñada en iplan. Muchas veces se requieren cambios en el producto standard, lo que lleva un tiempo de programación para la correcta configuración de la plataforma. Cada Cliente tiene un detalle que los diferencia y normalmente los negocios son casi todos distintos. El producto Calling Card Llave-en-Mano, consiste de tarjetas de llamadas entregadas a un Distribuidor o Comercializador. Las características principales son: -La Marca es la que pone el Cliente. -La Impresión la realiza el Cliente o directamente iplan mediante las imprentas homologadas. -La Comercialización y Distribución está a cargo del Cliente. -El Customer Care al Usuario final está a cargo de iplan. -El Pricing al Usuario final lo fija iplan. Es parte de la oferta de producto. -El Márgen al Cliente es un porcentaje sobre el valor de venta de la tarjeta neto de IVA, fijado por el producto. Normalmente la comisión del Cliente es un porcentaje que ronda el 35%. Esto depende de la calidad que se le quiera dar al producto final: mayor comisión significa mayor costo por minuto y menor cantidad de minutos disponibles por el Usuario final. Si el cliente quiere crear un producto duradero y que los Usuarios vuelvan a comprar su marca, debe resignar para de la comisión. En la vereda opuesta están quienes prefieren las rápidas ganancias y generan Tarjetas de corta vida. El Cliente es el responsable de: -Elegir la marca, color, diseño, look, etc. -Elige la cantidad y valor de las tarjetas entre las posibilidades que le da el producto. -Recibe los PIN (para imprimir sus propias tarjetas) o las tarjetas entregadas por iplan, contra pago en concepto de adelanto de un porcentaje del valor de las tarjetas o PIN. -En el caso de recibir PIN, su responsabilidad es la correcta impresión de las tarjetas. -Contra el pago del saldo, se habilitan los PIN o tarjetas. -El Cliente se encarga de la distribución y comercialización de las tarjetas. La clave del negocio. Por su parte, a iplan le corresponde la: -Definición del producto y de las Opciones de valores y cantidades. -El precio de las llamadas a debitar de las tarjetas. -La generación y entrega de PIN o tarjetas. -La administración de plataforma y enrutamiento. -La atención al Usuario Final. Los Clientes son empresas que no tienen Licencia de Revendedor en la CNC. Por esta razón el responsable de brindar el servicio frente al Usuario final es iplan. Una leyenda en la tarjeta Calling Card indica esto como Servicio provisto por NSS/iplan. Todas las precauciones tomadas por iplan se deben a que, en definitiva, es el responsable del servicio final. El Cliente es solo un intermediario que, a cambio de una comisión, utiliza su cadena de distribución o comercialización ya montada. Con estas características generales iplan ha obtenido muy buenos beneficios gracias a la amplia flexibilidad: -Es posible abastecer a un mercado mucho más amplio. Cualquier distribuidor de cualquier producto es un Cliente potencial para comercializar las Calling Card. Se le ofrece sumar una nueva línea de negocios. -Se pueden seleccionar Carrier-IP para la Larga Distancia, con lo cual el tiempo de utilización de la tarjeta se prolonga. -Con ingenio, se pueden desarrollar colecciones donde se agrega un ingrediente más al tema de la llamada telefónica. -Se ofrece un servicio de amplia difusión y acelerado desarrollo, abarcando todas las posibilidades de negocio (desde la provisión de E1, hasta las tarjetas llave-en-mano). Emitir Calling Card es como emitir dinero. Las tarjetas tienen un espesor de 350 micrones, son impresas a 4 colores frontales y uno en el dorso. Tiene la funcionalidad conocida como Scracht Off para descubrir la clave. En el caso de entregar PIN, para evitar posibles fraudes iplan entregará los lotes encriptados y bloqueados mientras que en el caso de entregar tarjetas, las entregará bloqueadas. La habilitación se realiza a pedido o mediante un acceso de Internet bajo responsabilidad del Cliente (se trata de una cláusula contractual). En el caso de entregar la lista de PIN de acceso al servicio al Cliente, estos son 9 dígitos y el número de la tarjeta lleva 6 dígitos, con una clave de 4 dígitos para el acceso al servicio. Las tarjetas se entregan en un blister (pudiendo agregarse propaganda adicional). El tipo de envoltorio de las tarjetas es individual, en tiras de 5 tarjetas juntas o sin envoltorio. 11

108 Monografías 7 (2003) Plataforma de servicios prepagos 4.2- Datos estadísticos. La experiencia obtenida con cerca de 50 marcas distintas de Calling Card, entrega datos valiosos que muestra el comportamiento de los Usuarios. A continuación se mencionan solo algunos de estos tópicos. este diagrama muestra el promedio de todas las tarjetas. Muy distinto es la distribución en las tarjetas que están orientadas a ciertos mercados objetivos. Por ejemplo, aquellas que están orientadas a comunidades de extranjeros obviamente tienen una carga de tráfico en LDI predominante. 1- Se encuentran fuertes fluctuaciones en el tráfico para cada Cliente individual. Cuando se analiza un Cliente con suficiente tráfico para seguir una evolución razonable, se puede ver la figura inferior. El gráfico muestra el período entre septiembre-2002 y mayo Se notarán ciclos semanales, mensuales y aún estacionales (con una caída durante los meses de verano). 5- El porcentaje de llamadas desde Teléfonos Público es del 10%. El origen del 0800 fuera de las ciudades de iplan es del 3%. Las ciudades donde opera iplan tienen excelentes tarifas (Buenos Aires, La Plata, Rosario y Córdoba). Muchas tarjetas han sido creadas aprovechando este diferencial. 6- Cada Tarjeta tiene una duración promedio de 7 días, y generalmente queda un porcentaje de crédito sin utilizar cuyo promedio es del 5% del valor facial. 2- Por un lado, la distribución de llamadas por hora durante el día y diaria durante la semana, sigue el promedio de los siguientes gráficos. Naturalmente existe una actividad máxima entre las 12 y 20 hs y los días de semana. 7- Sobre un total de mas de un millón de tarjetas emitidas la distribución indica que las más solicitadas son las de 5$ (con cerca del 75% del mercado). Se han generado tarjetas desde 1 a 100$ (estas últimas en cantidad muy reducida) Algunas trampas en el mercado. El producto Calling Card llave-en-mano a colaborado mucho a ordenar el mercado. Cuando el Cliente tiene su propia plataforma puede administrar a su gusto el negocio. Con el producto llave-en-mano se encuentra mas acotado, pero también dentro de un producto sano. La flexibilidad de la plataforma permite la creatividad, mientras que los límites de un producto standard permite disminuir el riesgo de burlar la buena fe del Usuario final. 3- La duración de la llamada promedio del Usuario a un destino local y LD-Nacional es 2 minutos. La duración de la llamada promedio del Usuario a destino LD-Internacional es 3 minutos. 4- La distribución de destinos (llamadas locales, LDN, LDI y celular) se muestra en el siguiente diagrama. Desde ya que En el mercado de las Calling Card se han manejados varias trampas o simplemente omisiones que pueden perjudicar o confundir al Usuario. Veamos algunos casos como ejemplo: -No fraccionar por minuto. Algunas tarjetas no fraccionaban por minuto, no lo aclaran concretamente, pero se podía descubrir cuando se indica la cantidad de minutos disponibles. -Se cobra un Cargo por Conexión Exitosa con el destino. Es conocido como bajada de bandera. Se trata de un descuento adicional cuando el abonado llamado responde. -En otros casos si la llamada es atendida por el destino, se le suma al cargo de la llamada el tiempo que se estuvo conectado con el IVR del