DOCUMENTO GUIA MESA DE TRABAJO TÉCNICA PORTABILIDAD NÚMERICA. Versión 001 AVANTEL S.A

Transcripción

1 DOCUMENTO GUIA MESA DE TRABAJO TÉCNICA PORTABILIDAD NÚMERICA Versión 001 AVANTEL S.A Bogotá, Marzo de 2010

2

3 2.1 Descripción General de una solución para la administración de números portados De manera breve, el presente tema se debe orientar a la elaboración de una descripción integral de la solución de Portabilidad Numérica All Call Query esperada y de su entorno de operación, teniendo en cuenta lo expresado en el artículo 10 de la Resolución CRC 2355 de Para el efecto, se plantean los siguientes aspectos, los cuales se entiende deben ser abarcados desde una perspectiva general: Entorno colombiano Operadores móviles Número de suscriptores Cubrimiento de conexión Tecnologías de redes existentes Servicios prestados Distribución de usuarios Proyecciones de crecimiento!! *Los servicios prestados por Avantel son PTT (radio digital de dos vías), Telefonía móvil, SMS, Internet inalámbrico banda ancha, internet móvil, enlaces corporativos, aplicaciones móviles, sin embargo en la tabla solo se hace referencia a los servicios relacionados con portabilidad numérica. Definiciones: Definición de términos relativos a la portabilidad numérica, que faciliten la estandarización del lenguaje utilizado en las mesas de trabajo y que no hagan parte de las definiciones presentes en el artículo 3 de la Resolución CRC 2355 de Formato de Solicitud de Portabilidad.: Documento que deberá ser debidamente completado por el Abonado o la persona que exhiba poder expedido por el Abonado, y entregado al Proveedor Receptor para iniciar el Proceso de Portación. Número de A: Número telefónico que identifica el origen de la llamada. Número de B: Número telefónico que identifica el destino de la llamada. CC.- Código de País: Representa la combinación de una, dos o tres cifras que identifica a un país determinado, a países de un plan de numeración integrado o a una determinada área geográfica.

4 IAM: Mensaje Inicial de Dirección (IAM por sus siglas en inglés Initial Address Message). LDI: Larga Distancia Internacional. MSISDN: Número de Estaciones Móviles para Redes Digitales de Servicios Integrados. Identifica de manera univoca a un subscriptor móvil dentro de la red de telefonía móvil. Este número identifica al subscriptor dentro de la red GSM de acuerdo con la recomendación E.164 de la UIT-T. El MSISDN se encuentra compuesto por el código de país, el código nacional de destino y el número del subscriptor. (MSISDN por sus siglas en inglés Mobile Station International Subscriber Directory Number). NDC.- Indicativo Nacional de Destino: Campo de código opcional a nivel nacional, que combinado con el número del abonado (SN), constituye el número nacional (significativo) del número de telecomunicaciones públicas internacionales para áreas geográficas. El NDC tiene una función de selección de indicativo de red o interurbano. SN.- Número de Subscriptor: Número que identifica a un abonado en una red o zona de numeración. Rechazo: Es el impedimento para ejecutar la Portabilidad cuando se actualiza alguna causal establecida en las Especificaciones del proceso de Portación, advertida por el ABD, o por el Proveedor Donador. Suscriptor: Usuario que mantiene la titularidad de la relación contractual con el Proveedor de Redes y Servicios. Usuario: Aquella persona que hace uso de un servicio de telecomunicaciones. TON: Parte de la mensajería de señalización en el IAM donde se define el tipo de red (TON por sus siglas en inglés Type of Number). RN: Prefijo de enrutamiento para portabilidad numérica, (RN por sus siglas en inglés Routing Number). SMS: Servicio de mensajería corta (SMS por sus siglas en inglés Short Message Service). SMS MO: SMS Mobile Originated. SMS MT: SMS Mobile Terminated. Descripción funcional: Descripción de la forma en que el usuario, proveedor donante, proveedor receptor, proveedor asignatario y otros actores 1 interactúan con el ABD, bajo un esquema de enrutamiento ACQ. Como complemento a la descripción funcional, se sugiere la construcción de un diagrama complementario que ilustre dicha interacción.

5 DIAGRAMA DE FLUJO DE PROCESO DEPORTABILIDAD # -. #$# 2 "* & + - "* ', + # # & & 6"!" - &6" 5 %! " & # "% " # # ) 7 " %! '( "( ' " - " %"% " #$# )" # )"* + # "*, + # "* - + # - -! "/ ( " - & " 5 & & ' 28 33%"& 31*339 & & "/ "& / -( & "/ ' / 0 1 " * /,23 "/& /, 13 " % /, 13 2!/& 2!/& *43 *#%' & * '2 * '2 5

6

7 Sistema de Intercambio de información (Clearinghouse): Características generales de un sistema de intercambio de información transaccional entre los proveedores donante y receptor y el ABD, considerando lo especificado en el artículo 17 de la Resolución CRC 2355 de Se hará referencia en el desarrollo del presente documento -Sistema de Intercambio de información (clearinghouse). Base de datos Administrativa Centralizada (BDA): Características generales de una BDA en función de la información de enrutamiento y de la información administrativa que deban estar contenidas en dicha base de datos, considerando lo especificado en el artículo 11 de la Resolución CRC 2355 de Se hará referencia en el desarrollo del presente documento en el punto Base de datos administrativa centralizada. Sistema de Respaldo: Teniendo en cuenta la descripción funcional, y las características requeridas del sistema de intercambio de información (Clearinghouse) y la BDA, establecer las condiciones y características bajo las cuales se debe considerar la implementación de un sistema de respaldo.

8 El proveedor deberá describir los procedimientos para copia de respaldo de las aplicaciones y de la Base de datos así como también los procedimientos de restauración de las aplicaciones y los datos incluyendo posibles escenarios de falla. Se deben incluir procedimientos de manejo de históricos. Interfaces: Características deseables de formas estandarizadas que aseguren la interoperabilidad 2 entre los sistemas de los proveedores de redes y servicios obligados a implementar el esquema de enrutamiento ACQ y e ABD, 3,4 teniendo en cuenta lo establecido en el artículo 11 de la Resolución CRC 2355 de Interfaces manuales: Web GUI. Middleware: Infraestructura intermediaria entre el ABD y los sistemas de información de los proveedores de redes y servicios. Se deben usar protocolos abiertos y estandarizados. Se debe considerar la implementación de al menos los siguientes protocolos abiertos: Conjunto de protocolos para Servicios Web (Web Services Protocol Stack), SOAP (Simple Object Access Protocol)/XML (Extended Markup Language), HTTP s (HyperText Transfer Protocol) y SFTP (Secure Shell File Transfer Protocol). Con respecto a la conexión SMPP con los proveedores de redes y servicios ésta debe estar habilitada para la versión 3.4. Ubicación física Características generales de ubicación física y geográfica de la solución tanto para el sistema de intercambio de información (Clearinghouse), como de sus sistemas de respaldo. Se hará referencia en el desarrollo del presente documento en el punto Criterios de Ubicación. Infraestructura de conexión con el ABD Opcional: Punto de Presencia (POP): Características generales de los diferentes medios de conexión física entre operadores de redes y servicios y el ABD, valorando su conveniencia y haciendo una descripción general de las características de posibles POPs que faciliten el acceso e interacción entre los proveedores de redes y servicios y el ABD. La infraestructura de conexión deberá estar soportada por canales de comunicaciones redundantes con un ancho de banda de acuerdo a las necesidades de la demanda del tráfico que requiera la ABD y que permitan soportar la operación con calidad de servicio, disponibilidad, seguridad (encripción de los datos que viajan por el canal) y facilidad de gestión. Seguridad La solución deberá presentar las condiciones de seguridad de la red, los sistemas operacionales, las bases de datos, y las redes de comunicaciones que permitan blindar la información basado en las normas seguridad como ISO y estableciendo políticas de seguridad integrales. Para las conexiones que se dan desde los proveedores de redes y servicios a los recursos del ABD se deben determinar controles para limitar la capacidad de conexión Los servicios ofrecidos por el ABD deben contar con los mínimos atributos de seguridad definidos por los fabricantes y por los estándares de seguridad.

9 Las plataformas que soportan los sistemas de información del ABD deben ser inequívocamente identificadas y monitoreadas a través de los diferentes ámbitos, con el fin de prevenir conexiones no autorizadas y de establecer los intentos de acceso no autorizados para fortalecer los esquemas de seguridad frente a ellos. Todos los usuarios que se conecten a la Base de datos centralizada deben tener un identificador único para las estaciones de trabajo que usen para la conexión a los recursos del ABD. Entre los niveles de seguridad que se deben revisar para la implementación, se deben considerar al menos los siguientes aspectos: Tipo de autenticación Nivel de encripción Seguridad de contraseñas Para implementar un servicio de conectividad física y lógica, se deben tener en cuenta los siguientes estándares y guías: Estándar de conexión por VPN. Estándar de configuración de enlaces WAN,LAN, Internet. Estándar de Políticas de dominio y de autenticación para usuarios externos. Estándar de transferencia de archivos entre plataformas y usuarios. La creación de un usuario nuevo para un tercero debe ser aprobada por el responsable del proveedor de redes y servicios. Se debe definir un procedimiento y formato que debe contemplar el tiempo de duración de ese usuario, si se vence este plazo y aún se requiere el usuario se debe hacer solicitud de prórroga. El ABD es el responsable de la eliminación del usuario una vez finalizada su vigencia. Debe haber una clasificación de los privilegios de los usuarios habilitados para el acceso a la Base de datos, Cada usuario es responsable del buen uso de los passwords que le sean asignados. Para interconexión con la Base de datos se permitirán establecer enlaces punto a punto, cifrados o no, y VPN site to site desde internet. Administración y monitoreo de la solución: Descripción de aspectos generales relacionados con las facilidades necesarias que aseguren una operación bajo condiciones técnicas de calidad, confiabilidad y seguridad, que deben hacer parte de la solución que le permita a los proveedores de redes y servicios interactuar con el ABD. La solución debe cubrir todas las facilidades necesarias para asegurar la operación bajo condiciones técnicas de calidad, confiabilidad y seguridad, y deben hacer parte de la solución que permita a los proveedores de redes y servicios interactuar con el ABD. Así como generar estadísticas sobre alertas, logs y reportes con la periodicidad que se defina, que permita garantizar y hacer seguimiento a la disponibilidad de la solución Arquitectura de una solución para la administración de números portados

10 A continuación se presentará una lista de temas sugeridos para el desarrollo de todos los aspectos relacionados con la arquitectura tanto general del sistema como la del software y la del hardware de la solución. En esta sección, se plantea que los temas propuestos sean abordados con un mayor nivel de profundidad y detalle. Arquitectura General de la solución: Definidas las arquitecturas de software y hardware, se sugiere la construcción de un diagrama de arquitectura general de la solución, que en bloques muestre con una visión de conjunto y la interacción entre los diferentes elementos que conforman la solución. Esta sección describe en términos generales la arquitectura para la implementación del sistema de portabilidad numérica en Colombia. Arquitectura de Software: Diagrama que refleje la arquitectura e interacción de las diferentes aplicaciones que hacen parte de la estructura de software, incluyendo sistemas operativos, complementado con información de funciones y especificaciones deseables con un nivel de detalle que facilite contar con la mayor cantidad de opciones para la correspondiente toma de decisiones. Entre otros aspectos, deberá incluir los siguientes: Sistema de Intercambio de información (Clearinghouse) Sistema de respaldo Opcional: Puntos de Presencia POP Arquitectura de middleware La Figura 1 ilustra la arquitectura de software con los respectivos módulos que debe soportar la solución de los proponentes. En esta arquitectura se observa cómo los módulos interactúan entre ellos para dar soporte al proceso de gestión de una solicitud de portabilidad realizada por un usuario. El proponente debe describir claramente la solución física y lógica considerada para cada uno de los módulos descritos a continuación.

11 Sistema de bases de datos Información histórica: contiene toda la información histórica de transacciones entre los proveedores y la empresa que administra la base de datos de portabilidad. Información de números a portarse: contiene la información de los números a ser portados. Información de números que regresan al proveedor asignatario del número: contiene la información necesaria para retomar los números portados al proveedor al que le fue asignado Información administrativa: contiene la información de los números que han sido portados. Información de documentación: contiene la información en formato digital de las solicitudes de portabilidad realizadas, facturas y contratos. Información de auditoría: contiene toda la información de incidentes que hayan ocurrido en las otras bases de datos y de los sistemas que intervengan en el proceso de portabilidad numérica. Sistema de Transferencia Electrónico Este módulo debe administrar todo el intercambio de información entre el proveedor donante y receptor que cursa en todas las operaciones de portabilidad. Se debe garantizar integridad y confidencialidad de esta información, como también establecer ventanas de tiempo para las acciones de aceptación o rechazo de una solicitud de portabilidad. Sistema Automático de Verificación Este módulo debe generar, almacenar y notificar a los suscriptores el número de identificación personal de la confirmación a solicitud de un proveedor receptor. Aplicaciones de Soporte Módulo que realiza las funciones de reportes, registro de logs, entre otras funcionalidades. Arquitectura de hardware Construcción de un diagrama que refleje la arquitectura e interacción de los diferentes componentes de hardware que sustentan la infraestructura de software, complementados con

12 información de funciones y especificaciones deseables con un nivel de detalle que facilite contar con la mayor cantidad de opciones para la correspondiente toma de decisiones. Entre otros aspectos, deberá incluir los siguientes: Sistema de Intercambio de información (Clearinghouse) Sistema de respaldo Opcional: Puntos de Presencia - POP Arquitectura de middleware La mejor propuesta de la solución de hardware evaluada será aquella que garantice un excelente soporte a la solución del fabricante y alta disponibilidad de la solución garantizando las mejores prácticas para el manejo, eficiencia y optimización de los recursos tecnológicos, junto con las mejores prácticas de implementación. Esta arquitectura debe ser robusta y soportar: Escalabilidad Alta disponibilidad Seguridad Granularidad Capacidad de cómputo Plataforma de estándar abierto Redundancia geográfica en una ciudad diferente al nodo principal. Adicionalmente el proponente de la solución deberá presentar un diagrama de arquitectura que permita establecer los elementos redundantes que contiene la solución para base de datos, plataforma de servidores clústeres, redes de área local y enlaces de comunicaciones incluidos los anillos redundantes. 2.3 Condiciones Técnicas, Administrativas y Operativas de una solución para la administración de números portados El propósito de esta sección se centra en plantear una lista de temas a desarrollar para la determinación de condiciones técnicas, operativas y administrativas, que en su detalle describan y especifiquen la solución. Condiciones Técnicas Aspectos de red Plan de Señalización Plan de Enrutamiento Opcional: Plan de Numeración (gestión)

13 Plan de Enrutamiento Enrutamiento Interno Estructura del RN (Routing Number) El RN, prefijo de enrutamiento para portabilidad numérica, será de una longitud de 2 dígitos. Este código será único para cada prestador del servicio de telecomunicaciones móviles y será asignado por la CRC. Enrutamiento de LDI Será responsabilidad del prestador servicio de larga distancia internacional el correcto enrutamiento de las llamadas entrantes al hacia el proveedor receptor en el caso que un número destino haya sido portado. Plan de Señalización Los proveedores de Redes y Servicios de Telecomunicaciones deberán adoptar los siguientes formatos para el intercambio de dígitos del Número B en la señalización entre redes públicas de telecomunicaciones: Llamada RTM RTM: La estructura del número B que irá dentro del mensaje IAM para el intercambio de señalización entre redes de telefonía móvil a partir de la implantación de la Portabilidad Numérica será: 2 dígitos 3 dígitos 7 dígitos Numero B Llamada RTM RTPC: La estructura del Número B que irá dentro del mensaje IAM para el intercambio de señalización cuyo origen es la RTM con destino a la RTPC a partir de la implantación de la Portabilidad Numérica será: 1 dígitos 7 dígitos Numero B Llamadas RTPC RTM: Los prestadores de servicios de telefonía fija, de conformidad con el Artículo 10, numeral de la resolución 2355, emplearan la modalidad Onward Routing para la terminación de llamadas en las RTM en el caso de números portados, por lo que la estructura del Numero B para el enrutamiento indirecto (tránsito sobre la operadora móvil asignataria del número portado) será: 3 dígitos 7 dígitos

14 Número B Llamadas entrantes de larga distancia internacional: La estructura del Número B que irá dentro del mensaje IAM para el intercambio de señalización cuyo origen es una red de telefonía en el extranjero, con destino a una RTM a partir de la implantación de la Portabilidad Numérica, teniendo en cuenta el artículo 10, numeral 1, de la resolución 2355 de la CRC será: 2 dígitos Type of Number (TON): El TON para el intercambio de mensajería entre operadoras nacionales deberá estar definido dentro del IAM en formato nacional (NAT) y para llamadas internacionales en formato internacional (INT), de acuerdo a la recomendación UIT-T Q.763. Número de A: El intercambio del número de A en los mensajes IAM no tendrá ningún prefijo, ni modificación alguna. Bucles de Llamadas En llamadas entrantes provenientes de otras redes que contengan el prefijo de enrutamiento para portabilidad numérica, cada operador será responsable de implementar soluciones a fin de evitar bucles de llamada. Servicio de Mensajería Corta (SMS) Escenario SMS MO y SMS MT Offnet.- El prestador de servicio de la red en la que se origina el mensaje será el responsable de consultar la base de datos de portabilidad para obtener y enviar la información necesaria para el enrutamiento de los mensajes hacia el destino. Escenario SMS MO desde Operadores Internacionales.- El prestador de servicio de LDI será el responsable de consultar la base de datos de portabilidad numérica para obtener y enviar la información necesaria para el enrutamiento de los mensajes hacia el destino. Bucles en SMS Cada prestador de telefonía móvil será responsable de implementar soluciones a fin de evitar bucles para SMS s. 2 dígitos 3 dígitos 7 dígitos Numero B - Sistema de Intercambio de Información (Clearinghouse) Requerimientos generales: El Sistema de Intercambio de Información (Clearinghouse) deberá contar con la infraestructura necesaria para cumplir con el conjunto de procesos que se requieren para la implementación efectiva de la Portabilidad Numérica en el Servicio de Telefonía Móvil y que a la vez, soporte las necesidades de todos y cada uno de los Proveedores de Servicios de Telecomunicaciones, sin que

15 la solución propuesta implique adquirir del Administrador de la Base de Datos programas de software o equipos adicionales. El Sistema de Intercambio de Información (Clearinghouse) debería estar integrado por un Sistema de Verificación Automática, un sistema de bases de datos, un Sistema de Transferencia Electrónico y sus interfases, los cuales deberán cumplir con los requerimientos de disponibilidad. Este sistema de Intercambio de Información debe soportar las siguientes transacciones: Tramitación de una solicitud de Portabilidad Verificación de rechazo por parte del Proveedor Donante Verificación de rechazo por parte del ABD Cancelación de la numeración portada Soportar los procesos de gestión de incidencias, y de consolidación de bases de datos, para garantizar la coherencia de la información Funcionalidades: o Definición de Mensajes La definición de mensajes del proceso de portabilidad resultará de los procesos definidos en el diagrama de flujo del proceso portabilidad definido en el ítem Descripción Funcional del Numeral 2.1, Descripción General de una solución para la Administración de números portados. o Número de Identificación Personal de Confirmación (NIP)5 El Sistema Automático de Verificación deberá tener como mínimo, las siguientes funciones: Generar, almacenar y notificar a los Suscriptores, el NIP de confirmación a solicitud de un proveedor Receptor. Los Proveedores Receptores podrán solicitar al ABD, la generación, almacenamiento y notificación de un NIP de confirmación a los Suscriptores Móviles. Para ello, el sistema deberá cumplir con lo siguiente: Recepción de solicitudes El Sistema Automático de Validación debería estar en condiciones de recibir las solicitudes de Proveedores Receptores de generación de NIP, a través del Sistema de Transferencia Electrónico. - Generación de NIPs Una vez recibida la solicitud, el ABD deberá generar de manera aleatoria un NIP compuesto de X dígitos y enviarlo al número a portarse, por medio de un mensaje de texto, entregándolo en el centro de mensajes del proveedor Donante, en menos de 5 minutos en el 95% de los casos y en ningún caso podrásobrepasar los 10 minutos. El ABD deberá almacenar fecha y hora de confirmación de la red de destino del mensaje de texto. Para la entrega de mensajes de texto, cada proveedor establecerá un enlace físico o vía Internet y se utilizará el protocolo SMPP (Short Message Peer-to-Peer Protocol). Los mensajes que se intercambien a través de estos enlaces serán exclusivamente para el Proveedor Donante. Si se recibiera una nueva solicitud,durante el periodo de vigencia del NIP, deberá reenviarse el mismo NIP, otorgando una nueva vigencia de 10 días calendario.el ABD debe mantener almacenados los NIPs enviados al menos 6 meses.

16 - Validación de NIPs Cuando el Sistema Automático de Validación reciba una Solicitud de Portabilidad de un número del servicio de telefonía móvil, debe verificar que el NIP de Confirmación y el Número móvil incluidos en la solicitud, correspondan con el que el ABD haya enviado al Suscriptor y tenga almacenado. Como resultado de esta validación, el Sistema Automático de Validación debe generar un mensaje de: Validación exitosa de NIP, cuando el Número móvil y el NIP de Confirmación enviado en la solicitud, coincida con el almacenado en el repositorio de datos de NIPs. - Validación errada de NIPs En caso de que los datos enviados no coincidan con los almacenados o no se encuentren, el Sistema Automático de Validación debe enviar alguno de los siguientes mensajes según sea el caso: No existe el NIP. Cuando el Número móvil no esté registrado en el repositorio de datos de NIPs, indicaría que expiró el plazo durante el cual el Sistema Automático de Validación debería mantener almacenados los NIPs de Confirmación, o bien que el Proveedor Receptor nunca solicitó la generación de un NIP para ese Número móvil. Esta condición generaría inmediatamente el rechazo de la Solicitud de Portabilidad con la causa: No existe el NIP. Validación errónea del NIP. Se generará cuando exista el Número móvil en el repositorio de datos de NIPs, pero el NIP de Confirmación enviado para ese número, a través de la Solicitud de Portabilidad, no corresponde al NIP almacenado en el repositorio datos de NIPs. Esta condición generaría inmediatamente el rechazo de la Solicitud de Portabilidad con la causa: Validación errónea del NIP Base de datos administrativa centralizada Las bases de datos deberán cumplir con las siguientes características: Relacional, proporcionando integridad referencial. Transaccional (múltiples operaciones simultaneas sobre la base de datos) Exportable a otro sistema manejador de base de datos (que se pueda migrar, exportar) Escalable (hacer crecer las característica del servicio planeado inicialmente, que permite mantener la calidad del servicio a medida que aumenta la demanda del servicio) Independencia de las aplicaciones y los servicios Seguridad (mantener adecuados niveles de seguridad que eviten a posibles acciones de fraude o ataque informático) Fiabilidad (tolerancia a fallos, respaldo, recuperación) Auditable

17 Funcionalidades o Información de enrutamiento a números portados La información contenida en los registros de la Base de Datos de Administrativa, deberá incluir al menos los siguientes campos: Número de usuario Routing Number o Información de números en proceso de portación de número La Base de Datos de números a portarse debe tener mínimo los siguientes campos: Fecha de creación de la solicitud. Número de consecutivo asignado durante el proceso de portabilidad. Número(s) a portar. Código de Proveedor Receptor. Código de Proveedor Donante. Esta información deberá generarse diariamente en días hábiles y conservarse por 5 días hábiles. o Información de números portados devueltos y en proceso de devolución La Base de Datos de números portados devueltos o en proceso de devolución debe tener mínimo los siguientes campos: Fecha de creación de la solicitud. Número(s) Portado(s) Devuelto(s) Código de Proveedor Receptor que notifica la devolución. Código de Proveedor Asignatario. Esta información deberá generarse diariamente en días hábiles y conservarse por 5 días hábiles. o Documentación complementaria a los procesos de portación de número Los campos mínimos requeridos para esta base de datos son: Número de consecutivo asociado al proceso de portabilidad. Los archivos electrónicos asociados a cada solicitud de portabilidad. o Histórico de portaciones La base de Datos Histórica debe contener mínimo los siguientes campos: Número de consecutivo asociado al proceso de portabilidad. Información de la solicitud de portabilidad: Número a portar. NIP Esquema de contratación: prepago o pospago Código de Proveedor Receptor. Código de Proveedor Donante. Fecha-hora de solicitud de portabilidad. Fecha de ingreso o asignación de NIP de Confirmación. Estado del proceso: exitoso, rechazado, en proceso. Información sobre procesos exitosos:

18 En su caso, causa de rechazo por parte del Proveedor Donante. En su caso, causa de improcedencia del rechazo. Fecha-hora en que la solicitud está lista para ser programada. Fecha en que se programó la portabilidad. Fecha de ejecución de la portabilidad. Información sobre procesos rechazados: Causa de rechazo. Fecha-hora del rechazo o Información de supervisión y monitoreo del sistema La siguiente es la información mínima que se debe tener para la supervisión y monitoreo del sistema: La cuenta de usuario (identidad) de los usuarios que se firman o intentan firmarse en el sistema. Un registro por cada intento. Fecha y hora de acceso. Dirección IP de la estación de trabajo. Actividades de la sesión. Estampado de Tiempo (Timestamp) Nombre o clave de la aplicación ejecutada. Nombre o clave de la tabla de información utilizada. Operación / transacción realizada sobre la tabla ( Lectura, Escritura, Actualización, Borrado) Código de terminación de la operación previa. Fecha y hora de la salida del sistema La contraseña de los usuarios no deberá ser registrada. o Acceso a la información de enrutamiento El ADB deberá generar diariamente la Base de Datos de números portados utilizando los campos descritos en Información de enrutamiento a números portados. La información deberá estar disponible para su descarga por parte de los Proveedores de Servicios de Telecomunicaciones al finalizar las ventanas de cambio. o Número de Identificación Personal de Confirmación (NIP) La base de datos de NIP debe tener mínimo los siguientes campos: Número Telefónico asociado al NIP. NIP de confirmación. Fecha: de generación, de ingreso por parte del usuario, de envío a través de solicitud de portabilidad. - Interfaces con la solución para interactuar con el ABD Se deben usar protocolos abiertos y estandarizados. Se debe considerar la implementación de al menos los siguientes protocolos abiertos: Conjunto de protocolos para Servicios Web (Web Services Protocol Stack), SOAP (Simple Object Access Protocol)/XML (Extended Markup Language), HTTP s (HyperText Transfer Protocol) y SFTP (Secure Shell File Transfer Protocol). Con respecto a la conexión SMPP con los proveedores de redes y servicios ésta debe estar habilitada para la versión 3.4.

19 - Infraestructura de Conexión entre Operadores y la solución para interactuar con el ABD La solución de interconexión entre cada operador deberá estar soportada por canales redundantes que permitan garantizar la disponibilidad y calidad del servicio. Para tal efecto es necesario realizar una descripción detallada del modelo de conectividad propuesto y sus niveles de servicio comprometidos. - Capacidad y desempeño de la solución para interactuar con el ABD Número estimado de portaciones por año Tomando como base estadísticas de otros países donde operan proveedores de servicios de redes y servicios similares a AVANTEL ( iden ), cuyo servicio principal es el PTT para mercado corporativo, se puede estimar que el porcentaje de portaciones al año es de 0.2 % del total de usuarios. Carga transaccional 8 El sistema deberá ser especializado para el manejo transaccional y con la suficiente capacidad de procesamiento para soportar los procesos de la carga transaccional de forma eficiente generada por la base de datos y los diferentes procesos que permita lograr tiempos de respuesta eficientes para los diferentes usuarios, y operadores que intervienen en tráfico de información. Con la posibilidad de ampliación de esta capacidad de computo si es necesario en línea y por demanda. Siendo así, se espera una carga transaccional entre el 80% y 90 % Tasa Transaccional 9 Conforme al número de portaciones por año mencionado anteriormente, para el caso AVANTEL, se estima un número promedio de transacciones procesadas en un día de 32. Tiempo de requerimiento-respuesta 10 El proponente deberá determinar este parámetro teniendo en cuenta el flujo del proceso de portación y para cada uno de los protocolos definidos, cumpliendo los tiempos definidos en la Resolución 2355 de la CRC. Número de requerimientos 11 de usuario concurrentes 12 Este valor debe ser el consolidado de las estadísticas proporcionaos por todos los proveedores de servicios, por lo tanto la CRC podrá realizar este cálculo una vez se tenga la información de todos los proveedores. Promedio estimado de mensajes por segundo bajo un esquema transaccional El proponente deberá determinar este parámetro teniendo en cuenta los protocolos requeridos para las interfaces, cumpliendo los tiempos definidos en la Resolución 2355 de la CRC. Valor pico de mensajes por segundo.

20 El proponente deberá determinar este parámetro teniendo en cuenta los protocolos requeridos para las interfaces, cumpliendo los tiempos definidos en la Resolución 2355 de la CRC. Disponibilidad: El proponente deberá ofrecer las características de disponibilidad encaminadas a la oferta de un servicio permanente en el tiempo que garantice el acceso a la información y que la operación no se vea afectada por incidentes de no disponibilidad de la infraestructura. La disponibilidad del sistema integral debe estar por encima del 99,9% mensual. El proponente deberá presentar periódicamente (semanal o mensual) los reportes de la medición de la disponibilidad. Es necesario que se incluya una solución de alta disponibilidad que permita la mitigación del riesgo de pérdida prolongada de acceso a la información por fallas en los componentes de la infraestructura. Confiabilidad El proponente debe ofrecer una solución tecnológica que contenga las siguientes características: Resistente: Al producirse una interrupción del servicio por alguna causa, deben existir los mecanismos de solución que deben ser transparentes para los usuarios. El usuario no debería percibir la interrupción. Recuperable: En caso de falla del servicio, la solución debe garantizar la recuperación automática o intervenida sin que se generen pérdida de los datos y se debe continuar después del incidente en un estado coherente manteniéndose la integridad de los datos hasta el momento anterior a la falla. Controlado: El servicio debe prestarse con oportunidad, es decir, cuando los usuarios lo necesiten. Ininterrumpible: El sistema no debe tener interrupciones por las labores de mantenimiento programado o por los cambios que se definan realizar. Deben existir los mecanismos que permitan la continuidad del servicio. Operativo: La solución debe tener un alto grado de completitud, de tal manera que una vez puesto en operación los cambios a los que haya lugar sean mínimos. Es decir que la funcionalidad definida debe cumplirse para que la operación no se vea afectada. Predecible: La solución debe funcionar de la manera que fue planeada o definida. Los cambios que se realicen deben generar comportamientos en la funcionalidad de acuerdo a lo que se espera. Escalabilidad La solución ofrecida por el proponente no solo debe garantizar el adecuado funcionamiento de la infraestructura para el servicio de acuerdo al dimensionamiento inicial que se realice, sino que además, su arquitectura permita el crecimiento escalonado en la medida que las condiciones tecnológicas o del mercado lo exijan. La escalabilidad necesaria debe garantizar que las características de disponibilidad y de oportunidad de la información no se verán comprometidas y se mantendrán los niveles de servicio acordados.

21 Extensibilidad El oferente debe ofrecer una solución cuyo diseño permita la adaptación a cambios, esto es, un diseño simple, organizado, con independencia de los módulos que componen la solución de tal forma que las adaptaciones que se requieran se puedan realizar sin generar traumatismos en la operación. Flexibilidad La solución propuesta le debe permitir al administrador de la base de datos, con base en la experiencia respecto a la implementación y en la operación, realizar modificaciones al sistema que permita la optimización de la infraestructura y de los procesos. Por esta razón la solución propuesta debe poderse configurar o parametrizar para evitar su rigidez que vaya en contra del dinamismo que exige el negocio. Criterios de ubicación Física La operación deberá estar soportada sobre Data Center, con sistema redundantes de potencia, seguridad física de acceso, monitoreo lógico y físico. Geográfica El sistema deberá estar ubicado en la ciudad de Bogotá. Condiciones Operativas Gestión Operativa Administración, monitoreo, mantenimiento y control de calidad del sistema El proponente deberá proporcionar los procedimiento para establecidos para el monitoreo, administración, mantenimiento y control del sistema de calidad. Es procedimiento debe incluir los siguientes temas: Procedimientos de recuperación de fallas Acciones preventivas y correctivas Manejo de inconsistencias, fallas e incidencias del sistema general. Definición de indicadores claves de desempeño (KPI) e indicadores claves de calidad (KQI) o Calidad y desempeño de las aplicaciones KPI-1 Desempeño de procesamiento: Este indicador medirá la rapidez con la que la aplicación responde las solicitudes recibidas,

22 KPI-1= Tiempo promedio de procesamiento por tipo de solicitud (de acuerdo a lo considerado en la resolución 2355). KQI-1 Calidad de la información: Este indicador medirá la integridad de datos del sistema de producción. Estos pueden ser tratados como tickets en la mesa de ayuda. o Calidad y desempeño de la infraestructura y de los servicios operacionales Los indicadores de Calidad y desempeño de la infraestructura y de los servicios operacionales evaluarán la eficiencia de atención de las solicitudes enviadas al BDA KPI-2 Tiempo del proceso de portación: tiempo de atención de solicitudes KPI-2= (número de solicitudes de portación atendidas a tiempo) / (número de solicitudes de portación recibidas) KPI-3 % de Notificaciones al NIPs Atendidas a Tiempo: Porcentaje de notificaciones atenidas a tiempo al usuario, se mide de forma independiente a la aceptación o rechazo de la solicitud. KPI-3= (numero de notificaciones enviadas a tiempo al usuario)/ (número de solicitudes de portación recibidas) Se pueden establecer KPIs para cada uno de los tiempos definidos en el proceso de portabilidad. KPI-4 Disponibilidad: Mide la disponibilidad de la infraestructura y los servicios sobre el sistema de producción KPI-4= 100% - (tiempo de no disponibilidad)/(tiempo observado) o Calidad y eficiencia de los servicios de soporte Los indicadores de soporte evaluaran la eficiencia de atención de la Mesa de ayuda para atender los casos reportados por los operadores. KPI-5 Tiempo de atención de la mesa de ayuda por categorías: Se calculará de forma independiente según la categoría (Menor, Mayor, Critica, otro) el tiempo de atención (solución y cierre) de los tickets creados. con el siguiente fórmula: KPI-5= Tiempo promedio de atención a tickets por categoría Monitoreo de errores El proponente debe detallar los procedimientos establecidos para hacer seguimiento a la solución de errores de inconsistencias que se presente en los datos. Este documento debe incluir la definición de acciones preventivas que incluyan pruebas exhaustivas sobre la solución y de los servicios en producción, así como acciones correctivas en caso de presentarse cualquier inconsistencia. o Archivos Log La solución deberá proveer un registro (trace log) de todas las actividades de cada usuario. La pista de auditoria deberá incluir como mínimo: la identidad del usuario, la acción realizada y la fecha, y el sistema deberá proveer de una herramienta para ver e imprimir la información.

23 o Gestión de errores El proponente debe detallar los procedimientos establecidos para el manejo de errores e información inconsistente. La gestión de incluir funcionalidades como : -Verificación automática de la integridad de los datos. -Verificación de la integridad de los datos de la solicitud -Verificación de campos vacios o en formato incorrecto -Verificación de solicitudes duplicadas Help Desk ( soporte) o Recursos de soporte El administrador de la base datos deberá contar con una mesa de ayuda en español, disponible para contacto vía mail, vía web y vía telefónica. En la mesa de ayuda se deben prestar servicios registro de incidencias, de solución a fallas y solución de preguntas técnicas, solicitud de reportes, incidencias de administración, solicitud de cambios. La mesa de ayuda debe contar con un sistema de registro de tickets que cuente por lo menos con las siguientes funcionalidades. Creación en el sistema de la incidencia, falla o consulta Asignación de un consecutivo para cada uno de los contactos Asignación de prioridades para cada contacto Comunicación del plan de implementación de la solución Seguimiento de la respuesta a través de una página o portal web Sistema de autenticación para los usuarios autorizados Módulo de estadísticas de atención o Personal asignado al servicio y formas de contactarlo El administrador de la base datos (ABD) proponente deberá contar con el personal de amplio conocimiento y experiencia en la solución de incidencias, fallas y preguntas técnicas que se puedan presentar en cualquiera de los operadores. Para garantizar la comunicación fluida entre las personas que encontraron el problema y la mesa de ayuda, el proponente deberá permitir el acceso a la mesa de ayuda a través de una página o portal Web, vía mail a correos determinado para tal fin y vía telefónica. En todos los casos los contactos se harán en español y debe quedar registro de todos ellos. o Tiempos de respuesta Los tiempos de respuesta estarán asociados al nivel de criticidad establecida para cada ticket y al tipo de ticket. Los tipos de ticket identificados son: * Incidencias y fallas * Reportes * Administración * Solicitud de cambios

24 o Disponibilidad horaria La mesa de ayuda debe estar disponible 5X8. o Documentación disponible El proponente debe contar con un repositorio de documentos disponibles para todos los operadores con la documentos tales como : - Información detalla de las estructuras de la base de datos con las que los operadores locales requieran hacer interfaces. - manuales de procedimiento o Protocolos para el manejo de contingencias y problemas operativos El proponente deberá anexar a la propuesta un Documento detallado de los procedimientos establecidos para manejar contingencias, recuperaciones y fallas. El documento debe tener información de: - Puntos de contacto establecidos - Niveles de escalamiento tiempo de atención. - Perfil de las personas que atenderán los casos - Acciones a seguir cuando ocurre una falla crítica - Indique el procedimiento de registro y administración de las bitácoras de fallas o Definición de niveles de criticidad y de eventos para el inicio de acciones Todos los tickets se agrupan en cuatro categorías: Critica: Cualquier defecto que no permita que la solicitudes al sistema sean completadas o sean abortadas, así como cualquier falta que impida la comunicación con el sistema o el deterioro significativo de todas las funcionalidades del sistema que impida a los operadores la utilización del sistema Mayor: Cualquier defecto que afecte significativamente el desempeño de cualquier funcionalidad del sistema y no permita el uso efectivo del sistema por parte de los operadores Menor: Cualquier defecto que no aplica para defecto mayor o critico Otros: Se refiere a solicitudes de cambio, reportes, administración, preguntas técnicas que no afectan el funcionamiento correcto del sistema o Condiciones de uso y restricciones El administrador de la base datos (ABD) proponente debe especificar las restricciones que pueda tener en la prestación del servicio, en horarios o cualquier otro factor que pueda afectar la utilización por parte de los operadores Backup y recuperación de información o Escenarios de falla y recuperación - Describir los procedimientos de respaldo y recuperación para cada uno de los módulos de la solución. - Se debe especificar recuperaciones por pérdida parcial de datos, de aplicaciones, de archivos de configuración. - Se debe especificar procedimiento en caso de falla de dispositivos de hardware (por ejemplo, discos duros) - Especifique si alguno de estos procedimientos requiere detener la prestación del servicio y cuanto tiempo toma.

25 - Defina los tipos de Backus realizados ( totales, incrementales, parciales ) e indique la periodicidad de cada uno de ellos. Así como las estrategias de almacenamiento de dichos Backus. Seguridad Políticas de identificación ante el sistema Todo usuario que ingrese a la base de datos deberá ser validado por una clave de acceso, el usuario tendrá asignado uno o varios roles que definirán las actividades que este puede realizar dentro de la base de datos, bajo ninguna circunstancia el usuario tendrá más permisos de los que realmente necesita para realizar sus operaciones, el defecto debe ser sin acceso. Se deben especificar todos los roles que serán definidos en la base de datos especificando como mínimo los permisos que el rol tiene sobre uso de la B.D., Consulta de datos, inserción, actualización y borrado de datos, creación de objetos, ejecución de procedimientos y creación de nuevas cuentas de usuario. Los permisos de actualización de datos deberán otorgarse a nivel de columnas y si es necesario los permisos deberán restringirse a determinadas horas del día. Los permisos para realizar operaciones de definición de datos (dropa, trúncate, alter) se asignarán de manera exclusiva a los administradores de la base de datos. Las claves definidas para el acceso a las bases de datos deben cumplir los siguientes requerimientos. Password diferente del username Mínima longitud del password 6 Password diferente de ('avantel', 'password', 'oracle') Password contiene al menos una letra y un dígito Password difiere del anterior en al menos 3 letras. Para evitar accesos no autorizados se deben implantar técnicas como: Se deben Registrar todas las entradas. Cada vez que un usuario entra, chequear cuándo y desde dónde entró la vez anterior. Demorar la respuesta ante claves erróneas; aumentar la demora cada vez. Alertar si hay demasiados intentos. Se debe especificar para cada perfil de usuario: Número de intentos fallidos de conexión a una base de datos antes de bloquear la cuenta del usuario. Número de días que la cuenta permanecerá bloqueada después de exceder el número de intentos de conexión. Número de días de gracia después de expirado el password de una cuenta, que se dará al usuario antes que la cuenta sea bloqueada Máximo número de días en que el mismo password puede ser usado antes de que este expire. Número de cambio de password requeridos para que una clave pueda ser reutilizada. Número de días requeridos para que una clave pueda ser reutilizada. Tiempo máximo que una sesión puede permanecer inactiva antes que esta sea desconectada. Control de acceso a través de interfaces manuales y middlewares Las interfaces deberán soportar autenticación de usuarios individuales basado en roles y deberán incluir mecanismos de confirmación de la llegada de los mensajes al receptor los cuales quedarán registrados en un log. Para cada mensaje entrante se debe poder identificar:

26 - El origen de los datos - Si el mensaje ha sido modificado - Si la información está siendo reenviada. - Debe soportar demoras en el envío de los mensajes. Se deben especificar los protocolos de comunicación que se utilizarán para conectar las interfaces con la Base de Datos. Control de acceso al Sistema de Intercambio de Información Deberá soportar autenticación de usuarios individuales basado en roles y perfiles Control de acceso al Sistema de Respaldo El sistema de respaldo debe estar habilitado cuando el sistema principal presente algún tipo de falla. Control de acceso a los recursos de datos Se asignará permiso sobre los datos sólo a las personas debidamente autorizadas, las restricciones se harán utilizando roles y perfiles. Políticas generales de autenticación de información Se establecerá un servicio de confiabilidad mediante alguna política de contraseñas o mecanismos de firmas digitales. Establecimiento de mecanismos de auditoría Se manejaran auditorias de sesión en las que se registrará cada intento de las conexiones a la base de datos detallando si la conexión fue válida, y la información de la dirección del usuario que se conecta. Detección y reporte de accesos no autorizados Se generará un reporte semanal resumen en el que se especificarán los intentos de conexión denegados por clave, dirección, hora o cualquier otro motivo, en caso de requerirse se suministrará el reporte detallado - Auditoría Se debe guardar un registro de todas las actualizaciones sobre la Base de Datos en el que se especifique el usuario y la dirección IP del responsable de la modificación, también se debe llevar un registro de las conexiones e intentos de conexión y de cualquier operación de consulta que sea rechazada por permisos. El proponente deberá almacenar todos los registros necesarios para realizar procesos de trazabilidad. Solución de problemas a usuarios: Herramienta para el seguimiento a usuarios Se deberá contar con una herramienta de auditoría que permita registrar el detalle de cada una de las transacciones realizadas contra la la base de datos,las interfaces y aplicaciones Procedimientos técnicos para asegurar el cumplimiento de la regulación Se deben definir procedimientos automáticos de control que verifiquen el correcto cumplimiento de las normas obligatorias. Generación de reportes de auditoría

27 La solución de auditoría implementada debe permitir la generación de un reporte resumen de conexiones a la base de datos,las interfaces y aplicaciones. El informe deberá agruparse por nombre de usuario, dirección IP, tipo de operación realizada. Definición de procedimientos de auditoría Todos los procedimientos de auditoría deberán documentarse y serán entregados a los operadores. Integridad y confiabilidad de la Base de Datos Administrativa de Referencia Para garantizar la confiabilidad cada usuario que ingrese a la BDA deberá identificarse por medio de una clave, al validarse el usuario se otorgarán los permisos asignados previamente y se llevará registro de cualquier intento de modificar o consultar cualquier tipo de datos sobre el cual no se tiene permiso. Integridad y confiabilidad de las Bases de Datos Operativas BDO- de los operadores Para garantizar la confiabilidad cada usuario que ingrese a la BDO deberá identificarse por medio de una clave, al validarse el usuario se otorgarán los permisos asignados previamente y se llevará registro de cualquier intento de modificar o consultar cualquier tipo de datos sobre el cual no se tiene permiso Integridad y confiabilidad de la funcionalidad de clearinghouse del Sistema de Respaldo Se elaborará un cronograma de backups a realizarse y se llevará un registro de cada uno de los backups realizados indicando el usuario que realizó el backup, la fecha, hora, contenido y status del backup. Procesos relativos a la portación de un número Solicitud general de portación de número Solicitud de portación de múltiples números Solicitud de portación de números prepago Solicitud de portación de números pospago Rechazo de una solicitud de portación de número Cancelación de una solicitud de portación de número Retiro voluntario del servicio por parte de un usuario previamente portado Regreso de un número previamente portado al rango de numeración del proveedor de redes y servicios original Borrado de un número portado de la base de datos administrativa de referencia