Diseño de Red Multiservicio para Montevideo

Transcripción

1 Diseño de Red Multiservicio para Montevideo Eduardo Lucas, Gabriel Arambillete, Pablo Cuello Resumen Este es el documento final del proyecto de fin de carrera, cuyo objetivo es el diseño de una red de telecomunicaciones multiservicio. Se comienza con una descripción detallada del proyecto incluyendo: especificación, objetivos específicos, hipótesis, fronteras y restricciones. Luego se ingresa de pleno en las actividades vinculadas con el diseño, comenzando con una descripción de la legislación en el área de telecomunicaciones. Como estudio preliminar se muestran datos socio-económicos sobre la zona para la que se diseña (Montevideo), desglosando en cada caso dichos datos por sub-zonas (barrios). Estos datos tienen como principal objetivo describir las características económicas y de distribución de habitantes en cada sub-zona. En etapas posteriores se hará uso de estos datos para determinar que servicios se podrían ofrecer en cada sub-zona. Dado que se diseñará en función de los requerimientos de los usuarios, se relevan los servicios de telecomunicaciones que se ofrecen actualmente a nivel mundial, para luego definir aquellos servicios que serán ofrecidos en las distintas zonas. Una vez que se han finalizado las etapas anteriores se conocen los requerimientos que tendrá la red y por lo tanto se está en condiciones de abocarse al estudio de las tecnologías adecuadas para brindarlos. Esta nueva etapa se comienza haciendo un breve análisis de las diferencias entre redes tradicionales y redes convergentes, pera luego estudiar en detalle las arquitecturas convergentes. Así se llega al diseño de la Red de Acceso, para lo cual previamente se estudian las tecnologías más extendidas y se realizan análisis comparativos de las más adecuadas. Entre ellas se elige la tecnología que finalmente es utilizada en esta parte de la red y se presenta el diseño. Mas adelante se comienza a trabajar sobre las redes de Transporte y Conmutación. Para esto, primero se estudian los protocolos que se consideran mas adecuados para el transporte ATM y MPLS. Luego se estudian y analizan los protocolos utilizados para brindar los servicios, entre estos se incluyen los protocolos para transporte y señalizacion de voz y multimedia, así como protocolos y tecnologías para transmisión de video y faxes, e interconexión con centrales tradicionales. Para finalizar con esta etapa, se realiza el diseño de la red de transporte y conmutación. Se comienza estudiando el volumen de tráfico necesario para soportar los servicios de voz y datos proyectados para los tres primeros años; luego se estudian las distintas tecnologías y formas de implementación. Posteriormente se describe brevemente la necesidad de un sistema de provisionamiento de servicios para luego concentrarse en la arquitectura y diseño de la red de transporte. También se describen las características de distintos equipos necesarios en estas redes que han sido relevados. Para finalizar el documento se hace un resumen del diseño y de la metodología utilizada para llegar al mismo. También se incluye una breve descripción de la forma en que ( según el diseño presentado) se pueden implementar algunos de los servicios mas comunes.

2 Capítulo 1 Prefacio 1.I DESCRIPCIÓN DEL PROYECTO 1.I-A Planificación de red de comunicaciones. 1.I-A.1 Introducción LAS infraestructuras son fundamentales para el desarrollo económico y social de un país. Constituyen un factor clave en la consolidación y ampliación de un tejido, tanto industrial como de servicios. Una red moderna, ordenada y eficiente de comunicaciones, constituye hoy en día un factor muy importante de competitividad de una zona geográfica, ya que beneficia el desarrollo de sus empresas en el contexto del mercado. Asimismo, la inversión en el negocio de las telecomunicaciones como en cualquier otro, debe ser acorde a la rentabilidad que de ella pueda obtenerse. Esto implica que la diversidad de servicios que la red debe ser capaz de manejar, tiene que estar de acuerdo a la demanda de servicios de los usuarios que esta tendrá. Por lo tanto los modelos utilizados en otras partes no siempre pueden ser aplicados con exito. 1.I-A.2 Descripción El proyecto trata del diseño de una red de comunicaciones multiservicio 1, creada para incorporarse a la ciudad de Montevideo teniendo en cuenta la situación actual de esta. Para el diseño deberán diferenciarse distintos escenarios que se pueden ver en la ciudad. Para esto se estudiaran las distintas zonas de la ciudad de manera de ajustar a cada una de ellas, los servicios a brindar teniendo en cuenta, índices demográficos y socio-económicos, proveedores de telecomunicaciones y legislación existente. El punto de partida será el interés de los usuarios, en cuanto a servicios requeridos y capacidad de compra de los mismos. También habrá que considerar los proveedores existentes, desde el punto de vista de competencia así como las interconexiones necesarias con los mismos y los posibles acuerdos para la utilización de sus instalaciones. Se estudiará la conveniencia de instrumentar una única red convergente o varias redes en paralelo, teniendo en cuenta entre otras cosas la oferta de servicios (voz, datos, video analógico y digital, Internet, etc.). El marco legal de Uruguay está en desarrollo por lo que se supondrá un marco legal que quedará explícito como parte de este proyecto. 1 Como una red multiservicio se entiende aquella que sea capaz de brindar servicios de voz, datos, video, etc. Se tomarán decisiones sobre el equipamiento a utilizar, de modo que sea el que mejor se adapte a los requerimientos, investigando la oferta actual de distintos proveedores, teniendo en cuenta la relación costo-beneficio así como las facilidades para la administración, operación y mantenimiento. Se entregará como producto final el proyecto de una red de comunicaciones para Montevideo incluyendo recomendaciones tales como las tecnologías y equipamiento a utilizar y relación con otros operadores de la zona. 1.II OBJETIVOS Para lograr el diseño de la red de telecomunicaciones multiservicio para la ciudad de Montevideo se establecen los siguientes objetivos generales: Caracterización de las zonas. Debe ser suficiente para decidir que servicios y tecnologías para cada zona. Definición de servicios. Teniendo en cuenta las zonas diferenciadas en el paso anterior se decidirán los servicios a ofrecer. Interconexión con otros Proveedores. Necesaria desde el punto de vista de brindar algunos servicios, así como convenientes desde el punto de utilización de parte de su infraestructura. Definición de Tecnologías. En esta parte se completará el diseño de la red, determinando el diseño final de la misma. Estudio de aplicación de redes convergentes a la implementación de redes multiservicio. Interpretación de una norma regulatória de telecomunicaciones. 1.III ESPECIFICACIÓN / FRONTERAS 1.III-A Fronteras / Alcance a) No se realizará la implementación del diseño propuesto. b) Se presentaran ventajas comparativas entre distintas tecnologías, pero no un estudio específico de cada una. En su lugar, se dará una lista de documentos de referencia. c) Se marcaran requerimientos a nivel de hardware, pero no se realizará la elección de los proveedores ni los modelos específicos de cada equipo. d) No se hará análisis de costos para las diferentes opciones analizadas, no obstante se pueden mencionar relaciones comparativas para los mismos. 1

3 2 CAPÍTULO 1. PREFACIO e) Las zonas de Montevideo se clasificaran dentro de una gama de posibles perfiles, y será para estos perfiles que se diseñaran las posibles soluciones. f) No se estudiaran acuerdos comerciales ni de facturación. 1.III-B Hipótesis a) Se tomará como marco legal de referencia el argentino, con excepción de telefonía básica nacional, de acuerdo a lo establecido en la ley b) No hay restricciones preestablecidas de costos, de tecnologías, ni de proveedores. c) Los proveedores existentes no tienen problemas extra tecnológicos para interconectarse con la red. d) Se supondrá que los datos que se manejan sobre la zona, servicios y tecnologías son fiables. En los casos en que se carezca de información se harán hipótesis sobre los mismos. e) No se tendrán en cuenta intereses políticos ni de terceros. f) La interconexión con otros proveedores se planificará a partir de las interfaces estandarizadas de interconexión de dichos proveedores. Se tomaran como base las interfaces de los proveedores argentinos. 1.III-C Restricciones a) Tiene que estar terminado antes del comienzo del primer semestre del b) No se podrá dar telefonía nacional. Esta restricción fue levantada en común acuerdo con el tutor, en una etapa posterior ya que se consideró agrega interés al diseño de la red. En el resto de los puntos correspondientes a la legislación, se tomará como referencia la legislación existente en Argentina a la fecha de inicio del proyecto. c) Al diseñar la red de acceso y en caso que se decida crear una red propia, no se planificará recorrido de cables en detalle manzana a manzana. mundial, para luego definir aquellos servicios que serán ofrecidos en las distintas zonas. Capítulo 5. Se hace un breve análisis de las diferencias entre redes tradicionales y redes convergentes, pera luego estudiar en detalle las arquitecturas convergentes. Capítulo 6. Se estudian las tecnologías de red de acceso más extendidas. Luego se realizan análisis comparativos de las más adecuadas, y se decide la tecnología que finalmente se utilizará para diseñará esta etapa de la red. Capítulo 7. Se estudian los protocolos que se consideran mas adecuados para el transporte. Estos son ATM y MPLS. Se hace un estudio mas detallados de MPLS, por tratarse de un protocolo mas nuevo del cual se conoce menos. Capítulo 8. Se estudian y analizan los protocolos utilizados para poder brindar los servicios que se ha optado por ofrecer. Entre estos se incluyen los protocolos para transporte y señalizacion de voz y multimedia, así como protocolos y tecnologías para transmisión de video y faxes, e interconexión con centrales tradicionales. Capítulo 9. Se realiza el diseño de la red de transporte y conmutación. Se comienza estudiando el volumen de tráfico necesario para soportar los servicios de voz y datos proyectados para los tres primeros años; luego se estudian las distintas tecnologías y formas de implementación (contratación,tendido propio, etc) para la capa física de esta red discutiendo la conveniencia de cada una. Posteriormente se estudian las formas de distribución del reloj hacia los distintos nodos de la red, dando pautas básicas para el diseño de la red de sincronismo. Se describe brevemente la necesidad de un sistema de provisionamiento de servicios para luego concentrarse en la arquitectura y diseño de la red de transporte. Finalmente se describen las características de distintos equipos relevados. Capítulo 10. Se hace aquí un resumen del diseño y de la metodología utilizada para llegar al mismo. También se incluyen una breve descripción de la forma de implementar algunos de los servicios mas comunes. 1.IV ORGANIZACIÓN DEL DOCUMENTO Este documento está estructurado en capítulos. Estos capítulos intentan cubrir los pasos imprescindibles en el diseño de una red de telecomunicaciones. Capítulo 2. Se intenta reflejar en forma concisa y resumida las características sobre la legislación existente. Para esto se toma como referencia en la legislación argentina actual, ya que la correspondiente uruguaya está recién en sus primeros pasos, y por lo visto hasta el momento no variará sustancialmente con la primera. Sin perjuicio de lo anterior, se relacionaran o marcaran las diferencias oportunamente en caso de existir. Capítulo 3. En esta etapa se recopilan datos sobre la zona objeto de estudio (Montevideo), desglosando en cada caso dichos datos por sub-zonas (barrios). Estos datos tienen como principal objetivo describir las características económicas y de distribución de habitantes en cada sub-zona. En etapas posteriores se hará uso de estos datos para determinar que servicios se podrían ofrecer en cada sub-zona. Capítulo 4. Comienza con un relevamiento de los servicios de telecomunicaciones que se ofrecen actualmente a nivel

4 Capítulo 2 Legislación en telecomunicaciones Resumen En este capítulo se intenta reflejar en forma concisa y resumida las características sobre la legislación existente. Para esto se toma como referencia en la legislación argentina actual, ya que la correspondiente uruguaya está recién en sus primeros pasos 2, y por lo visto hasta el momento no variará sustancialmente con la primera. Sin perjuicio de lo anterior, se relacionaran o marcaran las diferencias oportunamente en caso de existir. LA legislación argentina sobre telecomunicaciones se basa de un conjunto de reglamentos que cubre todas las áreas de las telecomunicaciones. Los mismos son: Reglamento General de Licencias para Servicios de Telecomunicaciones. Reglamento General de Interconexión. Reglamento General del Servicio Universal. Reglamento sobre Administración, Gestión y Control del Espectro Radioeléctrico. A continuación se presentan las principales características de los reglamentos existentes relacionados al tema, para finalizar luego con una reseña de los aspectos técnicos que habitualmente aparecen en los convenios de interconexión, y que se deberá tener en cuenta al momento de diseñar la red. 2.I REGLAMENTO DE INTERCONEXIÓN 2.I-A Objeto, Alcances y Definiciones Es la parte inicial del reglamento, donde se establece que es lo que se está reglamentando, se marcan las fronteras de influencia de este reglamento y finalmente se exponen definiciones de términos técnicos que se usaran en el mismo. 2.I-B Principios generales y objetivos Se fija como meta el beneficio del usuario y en base a esto se establecen los objetivos del reglamento. Los mismos incluyen la promoción del ingreso de nuevos prestadores, garantizando a todos condiciones equitativas. También se trata de asegurar el correcto funcionamiento ínter prestadores. Todos estos principios orientados a la disminución de costos, transparencia, igualdad, reciprocidad y no discriminación del sistema. 2 El estudio fue realizado en febrero del I-C Contenidos de los convenios de interconexión En lo que refiere al contenido de los convenios de interconexión entre diferentes prestadores, el Reglamento Nacional Argentino de Interconexión (RNI) aclara que se deberán contemplar como mínimo los siguientes puntos: Los principios generales de dicho convenio. La descripción de los servicios de Interconexión objeto de acuerdo. Las contraprestaciones económicas. Las características técnicas y operativas de la Interconexión. Los plazos y las condiciones de la implementaron y desarrollo de la Interconexión. Asimismo indica que se deberán incluir en caso de ser necesario, una descripción pormenorizada de los siguientes aspectos: 1) Servicios de Interconexión que se prestaran. 2) Condiciones de pago. 3) Facilidades complementarias de tasación. 4) Identificación y localización de los Puntos de Interconexión. 5) Parámetros respecto a la calidad, confiabilidad y/o disponibilidad de las interconexiones y las compensaciones por incumplimiento de aquellas. 6) Recaudos para operación y mantenimiento de las interconexiones. 7) Procedimientos a aplicar en caso de que se propongan modificaciones de la red o de los servicios de Interconexión. 8) Condiciones en el uso compartido de instalaciones, incluida la coubicación. 9) Funciones y elementos de red desagregados y facilidades esenciales. 10) Protocolos, formatos, señalización, niveles, impedancias, conectores y demás características necesarias para que la información pueda ser intercambiada en el punto de Interconexión. 11) Fechas o periodos en los cuales las partes se obligan a cumplir los compromisos de interconexión. 12) La capacidad inicial necesaria y la proyectada para la gestión del tráfico futuro. 13) El acceso a servicios auxiliares y suplementarios, de así 3

5 4 CAPÍTULO 2. LEGISLACIÓN EN TELECOMUNICACIONES corresponder. 14) Los procedimientos de resolución de litigios que puedan surgir entre las partes. 15) La determinación de la responsabilidad de cada una de las partes. 16) Plazo de vigencia y pautas para la renegociación de los Convenios de Interconexión. Dado el alcance de nuestro proyecto y los requerimientos del mismo, en los sucesivo solamente se consideran los aspectos puramente técnicos de los antes detallados. Específicamente, se trataran con mayor profundidad los temas relacionados a los puntos 1, 4, 5, 6, 8, y Servicios de Interconexión que se prestaran: Describe tanto los objetivos generales del convenio, como las características globales de la interconexión. 4. Identificación y localización de los Puntos de Interconexión: De acuerdo a este, se establecen las condiciones de provisión de puertos de acceso, y se indica la cantidad que inicialmente requiere cada una de los prestadores. 5. Parámetros respecto a la calidad, confiabilidad y disponibilidad de las interconexiones: Establece los parámetros necesarios para realizar el dimensionado de las interconexiones y poder realizar medidas de control sobre el tráfico existente. Asimismo, se detalla la responsabilidad de cada prestador con respecto a cantidad de puertos, de acuerdo al tráfico cursado. También se especifican requerimientos en cuanto a estos factores para los elementos que componen la Interconexión. 6. Recaudos para operación y mantenimiento de las interconexiones: Básicamente en este punto se deja constancia que cada parte está obligada a mantener en correcto estado de funcionamiento y operatividad, los equipos que afecten a la interconexión de redes. 8. Condiciones en el uso compartido de instalaciones, incluida la coubicación: Detalla todos los aspectos técnicos, incluidos ubicación, cableado, conexionado y características del local. 9. Funciones y elementos de red desagregados y facilidades esenciales: En caso de ser necesario se detallan las funciones y elementos de red, así como en el caso de contar con infraestructura propia las facilidades esenciales de la misma. 10. Protocolos, formatos, señalización, niveles, impedancias, conectores, etc.: Especifica estos aspectos en forma explícita. 12. La capacidad inicial necesaria y la proyectada para la gestión del tráfico futuro. 13. El acceso a servicios auxiliares y suplementarios. 2.I-D Elementos técnicos de la Interconexión En el RNI se establecen los elementos técnicos de la interconexión que deberán ser respetados, Estos son: Arquitectura abierta de redes, interoperabilidad y compatibilidad. Se entiende por esto la obligación del Prestador Solicitado de permitir el uso eficiente de su red por parte de los Prestadores Solicitantes, bajo parámetros tecnológicos que posibiliten el acceso y la individualización de funciones. Los Prestadores deberán prever la compatibilidad e interoperabilidad de sus redes, a los fines de permitir la Interconexión con las demás redes. Puntos y Niveles de Jerarquía de Interconexión. El Prestador Solicitante podrá requerir Interconexión en los diferentes niveles de jerarquía de la red y en cualquier Punto de Interconexión que se solicite, siempre que sea técnicamente razonable. Equipos e Interfaces. Todo Prestador está obligado a conectar a su red los elementos de red homologados por la Autoridad de Control, evitando limitar al otro Prestador en la selección de sus equipos o en la configuración de su red, aumentando sus costos o demorando la concreción de la Interconexión. Coubicación. Los Prestadores deberán poner a disposición de los demás Prestadores, el espacio físico y los servicios auxiliares que se les solicite, en sus propias instalaciones, en la medida que sea técnicamente factible y en las mismas condiciones que las de sus propios equipos o las pactadas con otros Prestadores. Facilidades Esenciales. Los Prestadores con Poder Dominante deberán proveer, al costo incremental de largo plazo y en forma desagregada, acceso a las funciones y elementos de su red identificados como Facilidades Esenciales. Como podrían ser: acceso o terminación local, bucle de abonado, puerto, coubicación, servicio de operadora y tránsito local. Calidad de los Servicios. Las condiciones de la Interconexión provista por el Prestador Solicitado deben ser por lo menos de igual calidad a las que él se provee a sí mismo, a sus compañías vinculadas o controladas y/o a terceros. El Convenio de Interconexión deberá incluir las condiciones destinadas a garantizar la calidad de la Interconexión, como así también la calidad de los servicios. Interrupciones. Se especifican las pautas a seguir en caso de interrupciones en los servicios, y el proceder para informar de los mismos. Señalización. La información transferida en la Interconexión a través de la señalización deberá ser acorde lo establecido en el Plan Fundamental de Señalización Nacional. Igual Acceso. Los Prestadores deberán brindar a otros Prestadores de

6 5 servicios de telecomunicaciones igual acceso que el ofrecido a sus propios usuarios y/o clientes y servicios y a las compañías vinculadas. Planes Fundamentales de Numeración Nacional y de Señalización Nacional. La Autoridad de Aplicación administrará los recursos de numeración para la prestación de los servicios de telecomunicaciones, elaborando los planes respectivos y disponiendo las asignaciones, de manera tal de propender al objetivo de hacer disponible los números y códigos para los diferentes servicios y Prestadores. 2.II REGLAMENTO DE SERVICIO UNIVERSAL El objetivo del establecimiento esta categoría es que todos los habitantes de la región objeto del contrato tengan acceso a los estos servicios de telecomunicaciones independientemente de la zona de residencia, o limitaciones físicas o necesidades sociales. En este reglamento se establece cuales de los servicios de telecomunicaciones se consideran universales. Así como el significado de esta definición y las consecuencias que esto implica sobre los operadores. En éste el Poder Ejecutivo determina que servicios deberán prestarse obligatoriamente en forma independiente de la rentabilidad de los mismos, pero también se establecen las compensaciones o subsidios que tendrán aquellos operadores que los presten. El concepto de SU (Servicio Universal) establece que servicios deben ser prestados, a quienes, su calidad mínima y precios accesibles. Se indica que este concepto es dinámico, por lo que periódicamente se debe revisar su contenido. En este reglamento se especifica la forma de financiamiento de los programas de SU, mecanismos de recaudación, y administración de los fondos tanto los monetarios como los beneficios no monetarios que se les pueda asignar a los prestadores. Se crea un organismo encargado de generar los programas específicos a subsidiar y efectuar control de la realización de los mismos así como del manejo de los fondos destinados a estos fines. Finalmente se da un listado de los programas iniciales incluidos como SU entre los que se encuentran: Telefonía pública de larga distancia. Telefonía pública social (zonas de bajos recursos). Atención diferencial a usuarios con limitaciones físicas. Planes para Jubilados y pensionistas. Programas para centros educativos y culturales. Programas para áreas de alto costo. 2.III SERVICIOS DE EMERGENCIA, SERVICIOS NTS Y OTROS SERVICIOS 2.III-A Servicios de emergencia El Reglamento de Licencias para Servicios de Telecomunicaciones establece en su punto 10.3 (Obligaciones de los Prestadores hacia los Clientes y/o Usuarios): a) Ofrecer a sus Clientes y Usuarios, toda vez que se trate de un servicio telefónico o si la naturaleza del servicio lo requiere, el acceso a servicios de llamadas gratuito para emergencia, policía, bomberos, ambulancias y relativas a siniestros de navegación. Si se encontrare disponible, este servicio deberá ofrecerse con numeración uniforme de carácter nacional, dentro de lo técnicamente posible. El reglamento uruguayo no menciona este punto ya que no se ofrecen servicios locales de telefonía. 2.III-B Servicios NTS Los servicios NTS son los que, para ser accedidos por su cliente, requieren de la traducción del número por el Prestador de servicios telefónicos al que está conectado dicho cliente (accesos a INTERNET, a audiotexto, cobro revertido automático, etc.). Dicha traducción se realiza en alguna central del Prestador al que está directamente conectado el Cliente. Cada prestador debe asegurar el enrutamiento de todas las llamadas de este tipo y de cualquier prestador. En caso de que estos servicios se usen para el acceso a Internet se discute donde es conveniente dejar la red de telefonía e ingresar a la red Internet ya que el uso prolongado de estas llamadas hacen un uso ineficiente de un recurso dedicado. En un extremo se puede limitar el tráfico a nivel local para sacar el tráfico de Internet de la PSTN lo más próximo al origen del llamado, esto hace que los ISPs tengan que armar fuertes estructuras de red con gran cantidad de POPs o establecer acuerdos de transporte de llamados con Prestadores desde localidades del interior a los POPs centrales. Esto favorecería claramente a los ISP s relacionados con los Prestadores. Por otro lado la complejidad de la tarificación de estos servicios crece con el tamaño de las redes y la cantidad de POPs de los ISPs y no se puede permitir que el Prestador de telefonía la imponga. La Oftel estableció para la British Telecom un modelo para establecer cargos por el tráfico generado por los servicios NTS en base a mediciones de tráfico, cantidad de puntos de interconexión, números promedio de etapas de conmutación de la PSTN, etc. 2.IV LICENCIAMIENTO Se describe brevemente puntos a tener en cuenta para el licenciamiento. Se toma como base el Reglamento de Licencias para Servicios de Telecomunicaciones (anexo I del decreto 764/2000) el cual establece en su artículo 9 los requisitos para

7 6 CAPÍTULO 2. LEGISLACIÓN EN TELECOMUNICACIONES la obtención de la licencia y en su artículo 10 las obligaciones de los Prestadores. Se establece primero las características de las licencias (plazo de la licencia, tipos de servicios que se autorizan a brindar, etc.). En los requisitos se establece el tipo de información que se debe brindar (como la descripción de los elementos de red, tipos de servicio a ofrecer, inversiones, áreas de cobertura, etc.). En las obligaciones se establece los plazos para comenzar a brindar el servicio, tipo de información que debe proporcionarse a la AC, calidad de servicio, obligaciones respecto al servicio universal, obligaciones hacia Clientes y demás Prestadores, planificación técnica, de inversiones, de crecimiento, etc. 2.V ASPECTOS TÉCNICOS Aquí se presentarán varios de los aspectos técnicos que se tendrán que considerar al momento de diseñar la red, y en particular los puntos de Interconexión con las redes de los otros proveedores. Calidad: La calidad de la transmisión se establece sobre la base de la norma G826 de la UIT-T. Para establecer la calidad de los enlaces se sugiere que cada uno de los proveedores evalúe la calidad de la mitad de las tramas y establezca los umbrales de calidad de acuerdo a las recomendaciones de la UIT. Disponibilidad: Se establece sobre la base de la norma G 826 de la UIT-T, y como el porcentaje de la relación disponibilidad real con la esperada. Ambas partes pueden sufrir de indisponibilidad y se establece que cada una de ellas solo reconocerá las fallas propias. Se explícita la disponibilidad de: puertos de acceso, circuitos y enlaces, y se establecen objetivos de disponibilidad diferenciales según el medio físico a utilizar (fibra, radios, mixtos). También se marcan los tiempos de reparación de fallas, el método de gestión de reclamos así como las sanciones aplicables a la parte que no cumpla lo establecido. En forma individual se acuerdan los parámetros de: 2.V-A Comunicación Para esto será necesario detallar los tipos de enlaces a utilizar en la interconexión, aclarando cuando sea necesario las características particulares de los mismos y/o estándares que se deben cumplir. 2.V-B Intercambio de dígitos en las rutas de Interconexión Se deberán definir para cada tipo de llamada el formato en el cual se enviaran el numero de B entre prestadores. En la tabla 2.I, incluimos parte de una tabla del convenio entre Techtel y Telecom 3.[1] 2.V-C Parámetros de calidad y disponibilidad El reglamento es breve, pero establece que la calidad ofrecida a otros prestadores debe ser al menos igual a la que el prestador ofrece a sus clientes, también explícita que el convenio entre prestadores deberá incluir las condiciones que garanticen la calidad tanto de la interconexión como de los servicios ofrecidos. En cuanto a la Disponibilidad el reglamento establece referencias de tiempos de interrupción así como las sanciones que la Autoridad de Control podrá imponer a aquellos prestadores que no los cumplan. Se incluyen aquí, a modo de ejemplo, algunas características al respecto del convenio de interconexión entre Impsat SA y Telecom Argentina.[2] 3 Anexo IV, Convenio de interconexión de redes entre Techtel LMDS comunicaciones interactivas S.A. y Telecom Argentina STET France Telecom S.A. Calidad de Tráfico: Este punto de los convenios se refiere a la calidad de servicio especificando la tasa de pérdida y el tráfico por circuito para enlaces que reciben tráfico de desborde y los que no lo hacen. También se establece las mediciones a efectuar, así como la cadencia de las mismas y los parámetros a medir. Eficacia: Se define la eficacia de las llamadas (hacia el Prestador, desde el Prestador y de LD) y se establecen las tasas de eficacia globales mínimas para los Prestadores y las mediciones a efectuar para controlar ese índice. Estabilidad: Esta medición permite asegurarse que el otro Prestador entregue un tráfico regular y no únicamente tráfico de desborde. Se comprometen a tener una duración promedio de llamadas sobre una variación limitada de tráfico (En el ejemplo de convenio de Interconexión entre Telecom e Impsat no mayor o igual a 120 segundos.) Otro indicador que se calcula es la cantidad de minutos cursados dividido el tráfico medio a la hora de mayor carga y se establece un máximo. Estos indicadores se miden día a día y mensualmente. Para las tasas de eficacia se considera el promedio de nivel nacional sobre los tres últimos meses. 2.V-D Gestión de reclamos Los convenios deberán especificar los procedimientos de gestión de reclamos, incluyendo el ingreso del reclamo, la generación de los tickets y la forma de cierre de los mismos. Asimismo, se establece que no será factible el ingreso de reclamos por conceptos de mantenimientos programados.

8 7 TABLA 2.I INTERCAMBIO DE DÍGITOS. 2.V-E Sincronización Para cubrir este aspecto, se deberán especificar los estándares o recomendaciones a seguir en lo que refiere a características físicas, sincronismo y ritmo de cada red. Como ejemplo, del convenio entre Techtel y Telecom 4 : Las características físicas de la conexión deberán estar conforme a la recomendación G823 de UIT-T. A fin de asegurar un interfuncionamiento correcto, los equipos de cada una de las PARTES deberán estar sincronizados conforme al punto 3 de la recomendación Q541 de UIT-T. Para las características del ritmo en cada red, el objetivo es la conformidad a las recomendaciones ETS y G811 de UIT-T. 2.V-F Señalización y protocolos de aceptación Son las pruebas que se realizan entre los Prestadores para validar sus interconexiones de SSCC N 7. Se listan las recomendaciones usadas en estas pruebas. - G821 define las pruebas de nivel 1 4 Punto 5 del Anexo V, Convenio de Interconexión de redes entre Techtel LMDS Comunicaciones Interactivas S.A. y Telecom Argentina STET France Telecom S.A. - Q781 define las pruebas de nivel 2 referentes al enlace de señalización. - Q782 define las pruebas de nivel 3 referentes a la Red de Señalización. - Q784 define las pruebas de nivel 4 referentes a las llamadas básicas. 2.V-G Planes de Numeración LD y local Se establece un Plan de Numeración Nacional para los Prestadores tanto para la numeración geográfica como la no geográfica, además se establecerá para cada PLDI un prefijo (en Uruguay de 3 dígitos) para el acceso internacional en la modalidad de selección por marcación. La AA administrará este plan de numeración. 2.V-H Selección por presuscripción o marcación LDI Se refiere a los métodos de acceso al Prestador de LDI desde cualquier otro prestador de telefonía local. Básicamente existen tres modalidades, la modalidad por presuscripción en la que se enrutan todas las llamadas del suscriptor al PLDI, la selección por operadora, (la AA debe encargarse de dar este servicio de operadora para que sea transparente), y la selección por marcación, en la cual cada PLDI tiene un sufijo propio y se accede con la marcación previa del mismo.

9 8 CAPÍTULO 2. LEGISLACIÓN EN TELECOMUNICACIONES El RNI establece las obligaciones de los Prestadores a implementar los sistemas de selección de larga distancia. 2.V-I Portabilidad de números Se refiere al derecho del Cliente a mantener la numeración ante un cambio de Prestador en determinadas circunstancias. El RNI argentino menciona sobre este tema: La Autoridad de Aplicación determinará los plazos y condiciones en que los Prestadores proporcionarán la Portabilidad de números entre ellos, entre servicios y entre áreas geográficas, conforme los siguientes supuestos: a) Cambio de Prestador de red telefónica fija, sin modificación de servicio ni de ubicación física. b) y c) aplicados a telefonía celular y servicios de red inteligente. 2.V-L Características técnicas para la facturación Ni el Reglamento Nacional de Interconexión, ni los convenios disponibles especifican requerimientos en cuanto a las características técnicas necesarias para realizar la facturación. Los documentos existentes solamente hacen referencia a el formato de los archivos para intercambio de información entre los proveedores. Por lo anteriormente expuesto, al momento de diseñar la red solamente habrá que tener en cuenta las capacidades necesarias para poder facturar los servicios sin tener en cuenta otros aspectos. En particular no se trabajara en el formato de los archivos de intercambio por considerarlo fuera del alcance del proyecto. 2.V-J Solicitud de Interconexión, puertos de acceso y comunicación Otro aspecto importante a considerar, es la correcta especificación de Puntos de Interconexión, así como los plazos relativos a su puesta en funcionamiento. Es usual realizar tablas señalando Área Local (AL) correspondiente, ubicación del POI, cantidad y tipo de puerto por servicio, datos relativos a la coubicación y fechas en las que estarán disponibles. Como ejemplo incluimos la tabla 2.II extraída del convenio entre Techtel y Telecom 5. [1] De la misma forma se podrán realizar las tablas correspondientes a la capacidad a largo plazo, sin perjuicio de ampliaciones que se pudieran realizar en los POI de acuerdo a los controles de calidad y tráfico establecidos. 2.V-K Encaminamiento Se deberán confeccionar tablas de encaminamiento que se hay que respetar a la hora de entregar el tráfico de intercambio entre redes. Esto es, por ejemplo, donde entregar el tráfico dirigido a la red de otro prestador de acuerdo a la característica de numero de B solicitado. Como ejemplo incluimos un fragmento de tabla extraída del convenio entre TECHTEL Y TELECOM 6. Tab. 2.III 5 Anexo XII, Convenio de interconexión de redes entre Techtel LMDS comunicaciones interactivas S.A. y Telecom Argentina STET France Telecom S.A. 6 Anexo XIII, Convenio de interconexión de redes entre Techtel LMDS comunicaciones interactivas S.A. y Telecom Argentina STET France Telecom S.A.

10 9 TABLA 2.II ESPECIFICACIÓN DE PUNTOS DE INTERCONEXIÓN. TABLA 2.III ENCAMINAMIENTO.

11 10 CAPÍTULO 2. LEGISLACIÓN EN TELECOMUNICACIONES

12 Capítulo 3 Montevideo 3.I CARACTERIZACIÓN DE LA ZONA Resumen En esta etapa se recopilan datos sobre la zona objeto de estudio (Montevideo), desglosando en cada caso dichos datos por sub-zonas (barrios). Estos datos tienen como principal objetivo describir las características económicas y de distribución de habitantes en cada sub-zona. En etapas posteriores se hará uso de estos datos para determinar que servicios se podrían ofrecer en cada sub-zona. 3.I-A Distribución de habitantes por sub-zona Se resumen en la Tab. 3.I datos de cantidad de habitantes por áreas aproximadas a barrios, de acuerdo con datos de INE (Instituto Nacional de Estadística). [3] De acuerdo con estos y al área aproximada de cada barrio, se le asigna un índice relativo a la densidad de habitantes, que va de 0 a 100 moviéndonos en franjas de 20. Este índice se muestra en la Tab. 3.II. 7 3.I-B Distribución económica Del plano de densidad económica de Montevideo [3], se obtiene un índice porcentual que refleja el poder económico promedio de cada barrio. Este se detalla en la Tab.3.II. 3.I-C Otros factores a considerar Se intentó incluir en este lugar algún índice que reflejará el gasto promedio en servicios relacionados con las telecomunicaciones, pero al no encontrar estos datos se consideró conveniente incluir algún otro índice de utilidad relacionado con el gasto en estos servicios. Es por esto que se incluye en la Tab. 3.III los dos que a nuestro entender son mas interesantes, como ser densidad telefónica y de computadoras por barrio (porcentualmente) [3]. Estos datos son solamente para hogares, lo que traerá como consecuencia que los índices para algunos barrios con fuerte presencia empresarial estén claramente distorsionados. Cuando se utilice esta información para crear los perfiles se tendrá esto cuenta. Cabe mencionar que se podrían haber confeccionado en esta etapa otros índices para este tipo de estudio, pero a los efectos de este proyecto, y dadas las restricciones de tiempo impuestas, será suficiente con lo hasta ahora expuesto. No Barrio Cantidad de habitantes Índice de densidad 1 CIUDAD VIEJA CENTRO BARRIO SUR CORDÓN PALERMO PARQUE RODÓ PUNTA CARRETAS POCITOS BUCEO PARQUE BATLLE - VILLA DO LORES 11 MALVÍN MALVÍN NORTE PUNTA GORDA CARRASCO CARRASCO NORTE BAÑADOS DE CARRASCO MAROÑAS - PARQUE GUARANÍ 18 FLOR DE MAROÑAS LAS CANTERAS PUNTA DE RIELES - BELLA ITALIA 21 JARDINES DEL HIPÓDROMO ITUZAINGÓ UNIÓN VILLA ESPAÑOLA MERCADO MODELO Y BOLÍVAR 26 CASTRO - CASTELLANOS CERRITO LAS ACACIAS AIRES PUROS CASAVALLE PIEDRAS BLANCAS MANGA - TOLEDO CHICO PASO DE LAS DURANAS PEÑAROL - LAVALLEJA CERRO CASABÓ - PAJAS BLANCAS LA PALOMA - TOMKINSON LA TEJA PRADO - NUEVA SAVONA CAPURRO - BELLA VISTA AGUADA REDUCTO ATAHUALPA JACINTO VERA LA FIGURITA LARRAÑAGA LA BLANQUEADA VILLA MUÑÓZ - RETIRO LA COMERCIAL TRES CRUCES BRAZO ORIENTAL SAYAGO CONCILIACIÓN VELBEDERE NUEVO PARÍS TRES OMBÚES - VICTORIA PASO DE LA ARENA COLÓN SURESTE - ABAYUBÁ COLÓN CENTRO Y NOROESTE LEZICA - MELILLA VILLA GARCÍA - MANGA RU RAL 62 MANGA TABLA 3.I POBLACIÓN E ÍNDICE DE DENSIDAD DE HABITANTES POR BARRIO. 7 Ver también mapa de referencia de densidad de población, Fig

13 12 CAPÍTULO 3. MONTEVIDEO No Barrio Índice Porcentual 1 CIUDAD VIEJA 25 2 CENTRO 75 3 BARRIO SUR 50 4 CORDÓN 75 5 PALERMO 75 6 PARQUE RODÓ 75 7 PUNTA CARRETAS POCITOS BUCEO 87,5 10 PARQUE BATLLE - VILLA DO- 87,5 LORES 11 MALVÍN MALVÍN NORTE PUNTA GORDA CARRASCO CARRASCO NORTE BAÑADOS DE CARRASCO 37,5 17 MAROÑAS - PARQUE 37,5 GUARANÍ 18 FLOR DE MAROÑAS 62,5 19 LAS CANTERAS PUNTA DE RIELES - BELLA 50 ITALIA 21 JARDINES DEL HIPÓDROMO ITUZAINGÓ UNIÓN VILLA ESPAÑOLA MERCADO MODELO Y 50 BOLÍVAR 26 CASTRO - CASTELLANOS CERRITO 62,5 28 LAS ACACIAS AIRES PUROS 62,5 30 CASAVALLE PIEDRAS BLANCAS MANGA - TOLEDO CHICO 37,5 33 PASO DE LAS DURANAS PEÑAROL - LAVALLEJA CERRO CASABÓ - PAJAS BLANCAS 37,5 37 LA PALOMA - TOMKINSON LA TEJA PRADO - NUEVA SAVONA 62,5 40 CAPURRO - BELLA VISTA AGUADA REDUCTO 62,5 43 ATAHUALPA JACINTO VERA LA FIGURITA 62,5 46 LARRAÑAGA 87,5 47 LA BLANQUEADA VILLA MUÑÓZ - RETIRO 87,5 49 LA COMERCIAL 62,5 50 TRES CRUCES 87,5 51 BRAZO ORIENTAL SAYAGO CONCILIACIÓN 37,5 54 VELBEDERE 62,5 55 NUEVO PARÍS 37,5 56 TRES OMBÚES - VICTORIA 37,5 57 PASO DE LA ARENA COLÓN SURESTE - ABAYUBÁ 62,7 59 COLÓN CENTRO Y NOROESTE 37,5 60 LEZICA - MELILLA 37,5 61 VILLA GARCÍA - MANGA RU- 37,5 RAL 62 MANGA 25 TABLA 3.II ÍNDICE PORCENTUAL DEL PODER ECONÓMICO POR BARRIOS. No Barrio Densidad telefónica Densidad computadoras 1 CIUDAD VIEJA 67% 8% 2 CENTRO 84% 14% 3 BARRIO SUR 79% 11% 4 CORDÓN 80% 13% 5 PALERMO 74% 12% 6 PARQUE RODÓ 89% 21% 7 PUNTA CARRETAS 95% 28% 8 POCITOS 94% 23% 9 BUCEO 84% 12% 10 PARQUE BATLLE - VILLA DO- 86% 15% LORES 11 MALVÍN 90% 20% 12 MALVÍN NORTE 80% 7% 13 PUNTA GORDA 95% 30% 14 CARRASCO 95% 40% 15 CARRASCO NORTE 75% 18% 16 BAÑADOS DE CARRASCO 51% 3% 17 MAROÑAS - PARQUE 63% 4% GUARANÍ 18 FLOR DE MAROÑAS 56% 4% 19 LAS CANTERAS 71% 6% 20 PUNTA DE RIELES - BELLA 36% 2% ITALIA 21 JARDINES DEL HIPÓDROMO 45% 2% 22 ITUZAINGÓ 55% 4% 23 UNIÓN 76% 8% 24 VILLA ESPAÑOLA 66% 5% 25 MERCADO MODELO Y 76% 9% BOLÍVAR 26 CASTRO - CASTELLANOS 66% 5% 27 CERRITO 63% 5% 28 LAS ACACIAS 42% 3% 29 AIRES PUROS 72% 10% 30 CASAVALLE 23% 1% 31 PIEDRAS BLANCAS 40% 3% 32 MANGA - TOLEDO CHICO 24% 2% 33 PASO DE LAS DURANAS 75% 10% 34 PEÑAROL - LAVALLEJA 54% 4% 35 CERRO 54% 4% 36 CASABÓ - PAJAS BLANCAS 31% 1% 37 LA PALOMA - TOMKINSON 16% 1% 38 LA TEJA 58% 4% 39 PRADO - NUEVA SAVONA 79% 15% 40 CAPURRO - BELLA VISTA 76% 11% 41 AGUADA 74% 10% 42 REDUCTO 74% 9% 43 ATAHUALPA 81% 13% 44 JACINTO VERA 80% 9% 45 LA FIGURITA 79% 9% 46 LARRAÑAGA 83% 13% 47 LA BLANQUEADA 89% 15% 48 VILLA MUÑÓZ - RETIRO 72% 7% 49 LA COMERCIAL 78% 9% 50 TRES CRUCES 85% 15% 51 BRAZO ORIENTAL 75% 8% 52 SAYAGO 72% 7% 53 CONCILIACIÓN 57% 3% 54 VELBEDERE 60% 5% 55 NUEVO PARÍS 46% 2% 56 TRES OMBÚES - VICTORIA 45% 2% 57 PASO DE LA ARENA 30% 2% 58 COLÓN SURESTE - ABAYUBÁ 51% 3% 59 COLÓN CENTRO Y NOROESTE 46% 4% 60 LEZICA - MELILLA 55% 5% 61 VILLA GARCÍA - MANGA RU- 23% 1% RAL 62 MANGA 30% 2% TABLA 3.III ÍNDICE DE DENSIDAD TELEFÓNICA Y DE COMPUTADORAS POR BARRIO.

14 13 3.II DEFINICIÓN DE PERFILES Y ESCENARIOS 3.II-A Definición de zonas Antes de comenzar con la definición de las zonas, se marcaran los criterios a utilizar según sea la naturaleza del barrio que se analice. De acuerdo con este criterio se tratara en forma diferencial a los barrios teniendo en cuenta su característica residencial o comercial. La razón por la cual se realiza esta distinción es que luego de discutir sobre los factores que afectan los servicios a ofrecer, se llega a la conclusión de que estos se ven claramente distorsionados para algunas zonas ( Centro y C. Vieja ) de Montevideo, donde los servicios requeridos son totalmente diferentes a los que podrían ser necesarios para casas de familia. Por tanto, se tomarán los barrios del centro de Montevideo apartados del resto, para los que se elaborará un índice que resulta de ponderar las siguientes características: Densidad de población (0.3). Nivel socioeconómico (0.5). Densidad telefónica (0.7). Densidad de computadoras personales(0.6). En la Tab. 3.IV se muestran los valores obtenidos. Si bien la forma de este índice es totalmente discutible, se considera que este refleja los puntos mas importantes a tener en cuenta para este tipo de planificación. Antes de llegar a la conclusión del índice a utilizar, se definieron y presentaron en los planos varias opciones, cada una ponderando diferentes aspectos de los barrios, y por tanto presentando posibilidades que podían mover a un barrio de una zona a otra. Es así que luego de ver los mejores y peores aspectos de cada uno se decidió utilizar el presentado anteriormente. Separando los barrios en franjas de acuerdo a este índice se obtiene en la Fig. 3.2 una primera aproximación de las zonas. Luego de analizar los resultados obtenidos, y hacer los cambios necesarios teniendo en cuenta otras consideraciones (como ser la existencia de otros proveedores y expectativas de crecimiento),se obtiene el plano final de zonas (ver Fig CIUDAD VIEJA 52% 2 CENTRO 84% 3 BARRIO SUR 73% 4 CORDÓN 82% 5 PALERMO 79% 6 PARQUE RODÓ 89% 7 PUNTA CARRETAS 99% 8 POCITOS 100% 9 BUCEO 84% 10 PARQUE BATLLE - VILLA DOLORES 86% 11 MALVÍN 93% 12 MALVÍN NORTE 76% 13 PUNTA GORDA 92% 14 CARRASCO 96% 15 CARRASCO NORTE 78% 16 BAÑADOS DE CARRASCO 39% 17 MAROÑAS - PARQUE GUARANÍ 52% 18 FLOR DE MAROÑAS 57% 19 LAS CANTERAS 60% 20 PUNTA DE RIELES - BELLA ITALIA 39% 21 JARDINES DEL HIPÓDROMO 47% 22 ITUZAINGÓ 52% 23 UNIÓN 75% 24 VILLA ESPAÑOLA 62% 25 MERCADO MODELO Y BOLÍVAR 64% 26 CASTRO - CASTELLANOS 58% 27 CERRITO 64% 28 LAS ACACIAS 50% 29 AIRES PUROS 70% 30 CASAVALLE 29% 31 PIEDRAS BLANCAS 45% 32 MANGA - TOLEDO CHICO 27% 33 PASO DE LAS DURANAS 71% 34 PEÑAROL - LAVALLEJA 48% 35 CERRO 52% 36 CASABÓ - PAJAS BLANCAS 29% 37 LA PALOMA - TOMKINSON 23% 38 LA TEJA 54% 39 PRADO - NUEVA SAVONA 71% 40 CAPURRO - BELLA VISTA 72% 41 AGUADA 75% 42 REDUCTO 70% 43 ATAHUALPA 79% 44 JACINTO VERA 77% 45 LA FIGURITA 76% 46 LARRAÑAGA 84% 47 LA BLANQUEADA 91% 48 VILLA MUÑÓZ - RETIRO 80% 49 LA COMERCIAL 76% 50 TRES CRUCES 89% 51 BRAZO ORIENTAL 74% 52 SAYAGO 69% 53 CONCILIACIÓN 45% 54 VELBEDERE 59% 55 NUEVO PARÍS 40% 56 TRES OMBÚES - VICTORIA 43% 57 PASO DE LA ARENA 33% 58 COLÓN SURESTE - ABAYUBÁ 47% 59 COLÓN CENTRO Y NOROESTE 41% 60 LEZICA - MELILLA 41% 61 VILLA GARCÍA - MANGA RURAL 26% 62 MANGA 29% TABLA 3.IV ÍNDICE ASIGNADO PARA CADA BARRIO. 3.II-B Relevamiento de proveedores y servicios existentes en Uruguay 3.II-B.1 Proveedores de servicios de Telecomunicaciones ANTEL Ofrece servicios de Telefonía básica en la cual es el o- perador dominante, así como en datos (ANTELDATA), y telefonía móvil (ANCEL). A su vez ofrece infraestructura a proveedores mas pequeños de servicios de datos. Movicom BellSouth Se desarrolla en el área de telefonía Móvil y Datos. Se prepara para ingresar al mercado de telefonía internacional. Telefónica-Data Datos. Se prepara para ingresar al mercado de telefonía internacional. Dedicado Datos. También ofrece infraestructura a proveedores mas pequeños de servicios de datos. TechTel

15 14 CAPÍTULO 3. MONTEVIDEO Fig Zonas a utilizar. Fig Índice por barrios.

16 15 Fig Distribución de abonados en Montevideo. Fig Alturas y tipos de edificaciones.

17 16 CAPÍTULO 3. MONTEVIDEO Fig Curvas de nivel (cada 10mts.). Datos. ISPs varios Datos, dan servicio de acceso a Internet, redes privadas y gestión de las mismas, utilizando generalmente infraestructura de otros de los proveedores aquí mencionados. Otros proveedores Listos para entrar al mercado de Telefonía Internacional, hay varios proveedores, la mayoría de los cuales preparan soluciones de Voz sobre IP o Voz sobre Internet. Equital Televisión de Abonados. DirecTV Televisión de Abonados. 3.II-B.2 Servicios de Telecomunicaciones Ofrecidos Servicios de Datos Servicios de Voz Telefonía Básica: Local e internacional. Sobre par trenzado o redes inalámbricas (wll). Servicios de Video Telefonía Celular Esta área de las telecomunicaciones queda fuera del presente estudio. 3.II-B.3 Servicios de Datos Los servicios de telecomunicaciones orientados a la transmisión de datos son los que han tenido un mayor desarrollo en los últimos años y es en ellos que se encuentra la oferta mas variada en cuanto tipo de servicio y tecnología utilizada para brindarlos. Se puede clasificar de varias formas: Según tiempo de conexión, el tipo de servicio o la tecnología que utilizan. Clasificados por tiempo de conexión Servicios On Line: Aquellos en los que el vínculo está establecido todo el tiempo, ya sea como conexión física o lógica. El costo de estos servicios varia según el ancho de banda disponible, el proveedor y tipo de servicio brindado, es decir si es enlace punta a punta, acceso a Internet, etc. Servicios Dial Up: Aquellos que se establecen, durante el tiempo necesario para la transmisión de datos y luego se finalizan. Estos servicios son facturados por tiempo de conexión establecida. Los casos mas comunes son Módem o ISDN (RDSI) Clasificados por Tipo de servicio Redes WAN, VPN, Enlaces Dedicados, Frame Relay y Acceso a Internet Clasificados por Tecnología de acceso Inalámbricos: a) LMDS, Frequency Hoping Spread Spectrum y otras Se pueden dar servicios de hasta 30 Mbps con un canal

18 17 de 6 MHz. Las distancias de acceso están entre los 16 a 30 Km. de radio. La capacidad de datos, así como el radio de cobertura de cada radiobase dependen del sistema utilizado, la frecuencia de la banda en que transmiten y la configuración, punto a punto o punto-multipunto. b) Satelital : Servicio satelital compuesto por estaciones terrestres con antenas de muy pequeño diámetro (VSAT) instaladas en el domicilio de los clientes, controladas y gestionadas desde una estación maestra (HUB). * El Servicio permite conectar vía satélite, grupos de terminales de datos que se encuentran dispersos geográficamente, con el Host o computadora central del cliente. * El Host del cliente se conecta (mediante el servicio de líneas digitales) al Telepuerto de el proveedor, mientras que en los puntos remotos se instalan los equipos necesarios para la conexión satelital (antena y equipo digital). Cableado: a) ADSL : Línea de usuario digital asimétrica, es una tecnología de transmisión de datos a alta velocidad a través de las líneas telefónicas de cobre actuales. Se mantiene simultáneamente el canal de voz/fax, independiente a la portadora digital utilizada para los datos cursados desde Internet. Los canales de datos utilizan altas frecuencias, separadas de las señales telefónicas tradicionales de baja frecuencia (0,3 a 3,4 KHz). El primer tramo de las frecuencias utilizadas para transmisión de datos son para el upstream y el tramo de frecuencias más altas se utiliza para el downstream, este último es el que ocupa un gran ancho de banda en el par de cobre. b) DTU: Líneas directas digitales con anchos de banda disponibles desde 64 Kbps a 2 Mbps. El Servicio dispone de supervisión centralizada de todos sus enlaces alcanzando la misma hasta el propio terminal del cliente. c) ISDN: Red Digital de Servicios Integrados (RDSI). Estos servicios si bien se usan para datos, brindan la posibilidad de combinar servicios de voz y datos. Dentro de la RDSI existen dos interfaces de abonado uno es el acceso básico y otro es el primario. El primero está orientado a necesidades de bit rate bajos (2B +D) (2X 64Kbits/s + 16Kbits/s) y el segundo a bit rates medianos (30B +D) (30X64 Kbits/s + 64 Kbits/s). Como restricción se debe cumplir que la distancia entre el cliente y la central telefónica, no supere los tres kilómetros (restricción de los módem HDSL). d) ATM: Servicios sobre F.O. con velocidades de hasta 155 Mbps con interfaces varias ( G.703, E3, OC3, ethernet, fast ethernet, etc) e) Módem: Equipos Moduladores Demoduladores que hacen la conversión de la señal de datos digital a analógica y luego la adaptan para su transmisión usando la misma banda por la que se transmite el audio en el sistema telefónico convencional. 3.II-B.4 Servicios de Voz Telefonía básica. Además del servicio de voz básico, el proveedor incluye servicios de valor agregado de red inteligente como: llamada en espera, identificador de abonados para llamadas entrantes, correo de voz, transferencia de llamadas, (preprogramada, en caso de ocupado o no respuesta), teleconferencia, servicio de alarma, marcación abreviada, conexión sin discado, etc. Estos servicios se ofrecen sobre diferentes tecnologías de acceso. Puede ser par de cobre o inalámbricas (WLL). Este punto es interesante ya que si bien básicamente cumplen la misma función hay algunas diferencias a destacar entre unos y otros, como por ejemplo: la posibilidad de aprovechamiento para conexiones con FAX o Módem, así como la telealimentación de el equipo de abonado. Servicio de voz sobre ISDN Se ofrecen varias modalidades según el sistema contratado y la interfase que se instale. 1) Se le proporciona a todos los clientes que soliciten este producto un terminal NT, con una interfaz universal de tipo S, que posibilitará la conexión de hasta 8 terminales ISDN con capacidad de hasta dos comunicaciones simultáneas (o 2 enlaces de datos a 64kbps). Con este producto no será posible conectar los equipos convencionales de telefonía. 2) Se le proporciona a todos los clientes que soliciten este producto un terminal, conversor NTab, que incluye: una interfase universal de tipo S, que ofrece las mismas posibilidades que la opción 1), 2 conectores RJ11 que brindan la posibilidad de conexión de equipos convencionales. 3.II-B.5 Servicios de Video Video conferencias sobre ISDN Dado que la RDSI permite conmutación de circuitos de una gran calidad: Muy baja tasa de errores, latencia mínima, etc., se puede ver a la RDSI como una solución adecuada para servicios o aplicaciones de videoconferencia. La aplicación de videoconferencia puede darse en conexiones punto a punto, dos videoteléfonos, o también en multipunto. En este último caso se utiliza normalmente un terminal RDSI llamado UCM (unidad de conferencia multipunto) al cual se conectan todos los videoteléfonos participantes en la sesión. Normalmente, dado que la UCM debe soportar varias conexiones el acceso que utiliza es un primario, aunque no es estrictamente necesario.

19 18 CAPÍTULO 3. MONTEVIDEO Televisión para abonados sobre Red de Cable Este servicio se da sobre una red de fibra óptica y cable coaxial, actualmente dedicada solo a este fin. Si bien actualmente solo se ofrece televisión para abonados, esta tecnología tiene la capacidad de integrar servicios de comunicación de datos, aunque seguramente esto requiera modificar partes importantes de la red actual. Televisión Satelital DirecTV. Si bien actualmente solo se ofrece televisión para abonados, esta tecnología tiene la capacidad de integrar servicios de comunicación de datos. 3.II-C Perfiles De lo visto anteriormente concluimos que las tres zonas definidas presentan las siguientes características: Zona A: Nivel socioeconómico medio y alto con densidad de población importante. Se destacan también en estas zonas los centros comerciales más importantes y barrios de Montevideo en crecimiento. Estos barrios son los de mayor poder adquisitivo, y presentan los mayores índices de penetración para servicios de telecomunicaciones. Zona B: Zona de nivel socioeconómico medio que presenta densidades de población entre media y alta. Si bien con menos crecimiento hasta ahora, esta zona presenta gran interés en servicios de telecomunicaciones, y que pueden llegar a crecer en la medida que se fomenten. Zona C: Se ve aquí una combinación de densidad de población baja, junto con un nivel socioeconómico medio y bajo. Principalmente integrada por zonas de bajo poder adquisitivo y/o áreas rurales, se destaca por tener una demanda mínima de recursos de comunicaciones. 3.II-D Escenario actual Se presentara aquí en forma resumida los escenarios actuales de cada una de las zonas definidas: Zona A: Presenta en casi toda su extensión la totalidad de los servicios ofrecidos, como se describe en 3.II-B. En todos sus puntos la concentración telefónica es elevada y se cuenta con TV cable. Asimismo cualquier usuario puede acceder a una gama importante de tecnologías para acceso para datos o Internet, que van desde líneas discadas, pasando por enlaces directos o acceso inalámbrico, hasta llegar servicios xdsl. Zona B: Esta zona cuenta con muchos de los servicios ya detallados, mientras que carece de otros por diferentes motivos. En particular la sub-zona B1, en la cual se pueden llegar a contratar la totalidad de los servicios ofrecidos para la zona A (incluidos telefonía, casi todos los servicios de datos y TV Cable). Para la sub-zona B2 se encuentran con características bastantes similares a las de B1, con la salvedad de que aquí no hay cobertura de TV Cable (si TV para abonados por aire) y muchos proveedores de datos o Internet no tienen actualmente cobertura para estos barrios. Zona C: Por sus características socioeconómicas, esta zona no es de mayor atracción para los proveedores privados, y por tanto presenta posibilidades mucho mas reducidas a la hora de elegir los prestadores de servicios. No hay cobertura de TV Cable, y en las zonas mas alejadas solamente se cuenta con telefonía básica y otros servicios brindados por ANTEL. 3.III PROYECCIÓN DE CRECIMIENTO Y PENETRACIÓN EN 3.III-A Introducción EL MERCADO Para el diseño de toda red es necesario saber la cantidad de clientes a los que apunta así como la distribución de los mismos. La primer parte de este estudio, se analizó la ciudad de Montevideo para conocer su realidad socioeconómica así como la infraestructura en telecomunicaciones existente. Además se ha tomado un marco regulatorio al cual habrá que adecuar la red. 8 Finalmente para tener un panorama claro de a donde se apunta se debe saber que porción del mercado de las comunicaciones de Montevideo se proyecta cubrir. Esto está más allá de un proyecto de ingeniería y debería ser un dato aportado por un departamento de mercadeo, al grupo de ingenieros que desarrollen la red. Al no contar con estos datos, se harán algunas hipótesis de crecimiento y penetración en el mercado. Si bien las mismas no representan exactamente la realidad, se ha tratado de llegar a modelos tan aproximados de la misma como nuestros medios lo permiten. Estas hipótesis se basan en modelos de crecimiento de empresas de telecomunicaciones que ingresaron a diferentes mercados en un marco de apertura similar al que como base de este proyecto se supone. 3.III-B Paquetes de servicio Con el objetivo de entender las ideas de desarrollo y crecimiento de la red, y si bien escapa al alcance de nuestro proyecto, se darán aquí varias de las ideas que se consideraron para manejar la estrategia de marketing. Se intenta poner en funcionamiento una red multi-servicio que tendrá que instalarse en un mercado competitivo. La ciudad de Montevideo presenta un mercado chico y resultará muy difícil sobrevivir con varias de las empresas que ya brindan uno o varios de los servicios que se ofrecerán. Es por 8 Al momento de este estudio el marco regulatorio de telecomunicaciones de Uruguay no estaba terminad, por lo cual se tomó como referencia el argentino. Por mas detalles sobre el marco regulatorio a utilizar ver el capítulo 2

20 19 esto, que se considera que la única forma de ganar mercado es a través de la oferta de paquetes multi-servicios. Con estos paquetes se podrían ofrecer varios servicios en uno, que al abrir el mercado llevaran a que un cierto grupo de personas se cambiará a esta red. Si se ofrecieran por separado cada uno de los servicios, no se notará un mayor cambio a los potenciales clientes. Mientras que al crear paquetes estas personas podrían encontrar ventajas tanto económicas como técnicas que le llevaran a cambiar de proveedor. También se podrían hacer ofertas que incentiven a los usuarios de un sistema a cambiar de proveedor y contratar otros servicios. Habitantes en Montevideo Personas que accederán a Internet Clientes de acceso a Internet TABLA 3.V RESUMEN CANTIDAD DE CLIENTES Clientes de la nueva red (20%) En adelante se trabaja con el supuesto que las ofertas sean principalmente de paquetes de servicio, y se harán todos los estimativos y predicciones siguiendo estas ideas. 3.III-C Hipótesis Objetivo final 20% del mercado de datos. Esta hipótesis se basa en suponer un mercado formado por el operador incumbente y 3 operadores entrantes. Fig Cobertura porcentual Se supone también que el incumbente se quedará con el 40% del mercado y el resto se repartirá entre los operadores entrantes. Por otro lado se estima el universo de clientes de Internet en Montevideo. de la siguiente forma: La penetración actual de INTERNET en Uruguay es 13%. Suponiendo que el 70% de los internautas reside en Montevideo, se obtiene una cantidad de usuarios. Según otros estudios el mercado crecerá 50% anualmente hasta el 2003 en Latinoamérica, y otro estudio mas conservador en [4] predice que un 7.5 % de la población de América Latina ingresará a Internet para el Tomando una hipótesis conservadora se puede proyectar que la cantidad de usuarios se duplique para el 2007, y se supone que de este total un 80% son usuarios residenciales y el resto empresariales. Si una familia promedio se integra por 4 personas la cantidad de hogares que se conectaran para esta fecha a INTERNET en Montevideo será de De forma análoga se puede calcular el numero de empresas conectadas en aproximadamente De este total, se estima que solamente un 50% de los usuarios tenga conexión de banda ancha, por lo que el numero total de clientes para todo el mercado seria de En la tabla 3.V se resume lo anterior: Curva de crecimiento en abonados de datos indicada en Fig. 3.6 y Fig. 3.7 Este formato de crecimiento es el que siguieron algunas compañías en países latinoamericanos. Los clientes de datos serán también clientes de telefonía fija, debido a que el servicio será un paquete incluyendo ambos. Penetración adicional de un 5% del mercado de telefonía fija. Para entrar a este mercado se darán servicios adicionales a telefonía fija, al mismo precio que actualmente lo da el incumbente. Tanto los servicios telefónicos como los de datos serán dados sobre la misma red de acceso, ya que el ancho de banda utilizado por un canal de voz (en G.711 es de 64 Kbps) no es significativo frente al ancho de banda alcanzable con muchas de las tecnologías de acceso actuales. Por otro lado la gran cantidad de equipos, que significa el 5% del mercado telefónico, pondrá en posición de conseguir mejores precios de equipos de acceso. Con respecto a esto cabe notar que los costos de equipos de telecomunicaciones son altamente sensibles a la escala del proyecto. Clientes Porcentaje Fecha ene jul ene jul ene jul ene jul ene jul 2007 TABLA 3.VI EVOLUCIÓN DEL NUMERO DE CLIENTES DE INTERNET

21 20 CAPÍTULO 3. MONTEVIDEO Fig Cantidad de clientes de Internet El 5% del mercado telefónico de Montevideo en el año 2007 serán según estimaciones, aproximadamente usuarios. Se puede estimar la misma evolución, en la penetración porcentual sobre estos usuarios que sobre los de Internet. En la Tabla 3.VII. Se muestra la evolución de los puestos de telefonía fija, esta incluye tanto los usuarios que solamente contraten telefonía, como a aquellos que contraten otros servicios. Clientes Fecha TABLA 3.VII EVOLUCIÓN DEL NÚMERO DE CLIENTES DE TELEFONÍA FIJA 3.III-D Distribución de clientes por sub-zonas Una etapa posterior será el decidir la ubicación de las instalaciones de la red. Para hacerlo hay que decidir previamente que sub-zonas contarán con puntos de presencia desde un principio, y en cuales se arrendará servicios de acceso al incumbente u otro proveedor. Esto dependerá básicamente de la cantidad de clientes que se estimen en cada sub-zona y de la estrategia comercial de la empresa. Hay aquí un compromiso entre la economía y la estrategia de crecimiento. Por un lado el tener una red propia en todas las subzonas aumenta los costos de locales, red de transporte y equipamiento. En cambio, es estratégicamente conveniente tener instalaciones propias ya que de lo contrario la celeridad con la cual se pueden instalar nuevos servicios y acaparar nuevos clientes estará determinada por el operador incumbente. En otras palabras, el crecimiento depende de la competencia. Si bien existen procedimientos para resolver problemas de interrelacionamiento, el reglamento de interconexión prevee etapas de conciliación frente a la Unidad Reguladora que podrían retrasar un proyecto hasta en 6 meses. También habrá que tener en cuenta que: Sea cual fuere la tecnología elegida, será necesario interconectar la red con la de ANTEL, por lo que será necesario estar cerca de por lo menos 2 de sus centrales. Se cuenta con datos aproximados de clientes telefónicos por central. En caso de decidir que el acceso del cliente será realizado por medio del unbundling de la red de cobre de ANTEL, usando tecnologías ADSL 9, lo que se debe diseñar es hasta donde llegará la red propia, y cuales serán recursos rentados al proveedor incumbente. Queda claro que el dato relevante es la distribución por central telefónica ya que este es el límite de la red de acceso de pares de cobre. Para tener en cuenta estos aspectos, se dividirá la zona de Montevideo de acuerdo a la distribución actual de centrales de ANTEL,y se presentaran las estimaciones de clientes desglosadas por categoría de servicios: Clientes telefónicos: En la Tab. 3.VIII es presenta una estimación de cantidad y crecimiento en los servicios telefónicos que hoy tiene ANTEL en cada Central. Ponderando esta tabla según la curva penetración previamente descrita se obtiene la tabla 3.IX que muestra la cantidad de clientes exclusivamente telefónicos. Clientes de Internet y Datos: Se ha hecho previamente una estimación del total de clientes que tendrá la nueva red. Promediándo los índices de la tabla 3.IV para los barrios cubiertos por cada central y normalizando, se obtiene el 9 Gran parte de la bibliografía recalca las ventajas de esta solución sobre otras.

22 21 Central Aguada Atahualpa Cerrito Cerro Colón Lezica P. de la Arena P. Molino S. Vázquez Sayago Buceo Centenario Centro Ciudad Vieja Cordón Palacio Parque Rodó Pocitos Punta Carretas Aeropuerto Barra Carrasco Paso Carrasco Carrasco Euskalerría Ituzaingó Malvín Manga Manga S Manga S Manga S Unión Total Central Índice Promedio Índice Prom. Norm Aguada 74,9 0, Atahualpa 73,3 0, Cerrito 51,7 0, Cerro 34,7 0, Colón 44,7 0, Lezica 36,0 0, P. de la Arena 36,0 0, Paso Molino 58,6 0, S. Vázquez 33,0 0, Sayago 58,3 0, Buceo 90,0 0, Centenario 78,1 0, Centro 69,7 0, Ciudad Vieja 52,0 0, Cordón 83,2 0, Palacio 75,0 0, Parque Rodó 84,0 0, Pocitos 93,0 0, P. Carretas 96,0 1, Carrasco 76,2 0, Euskalerría 61,2 0, Ituzaingó 40,9 0, Malvín 86,7 0, Manga 26,7 0, Manga S. 1 27,0 0, Manga S. 2 27,0 0, Manga S. 3 32,5 0, Unión 65,8 0, Total 1746,3 13, TABLA 3.X CLIENTES DE INTERNET Y DATOS EN LA NUEVA RED TABLA 3.VIII TELÉFONOS FIJOS EN MONTEVIDEO Central Aguada Atahualpa Cerrito Cerro Colón Lezica P.de la Arena Paso Molino S. Vázquez Sayago Buceo Centenario Centro Ciudad Vieja Cordón Palacio P. Rodó Pocitos P. Carretas Carrasco Euskalerría Ituzaingó Malvín Manga Manga S Manga S Manga S Unión Total índice que junto con el crecimiento estimado en la Tab. 3.VI, se utiliza para llegar a la cantidad final de clientes de Internet y datos por central. TABLA 3.IX TELÉFONOS FIJOS EN LA NUEVA RED

23 22 CAPÍTULO 3. MONTEVIDEO

24 Capítulo 4 Servicios Resumen Este capítulo comienza con un relevamiento de los servicios de telecomunicaciones que se ofrecen actualmente a nivel mundial, para luego definir aquellos servicios que serán ofrecidos en las distintas zonas. 4.I RELEVAMIENTO DE SERVICIOS 4.I-A Servicios de Voz LOS servicios de voz que hoy ofrecen las compañías de Telecomunicaciones son muy variados. Entre ellos se encuentran los servicios que originalmente se crearon con el invento del teléfono, aquellos que fueron posibles luego con el ingreso de la conmutación automática, pasando por las nuevas funciones de las redes inteligentes, servicios de valor agregado, y llegando hasta los nuevos productos que hoy en día se crean pensando en la convergencia de los servicios de telecomunicaciones como la forma de acceder con sistemas de voz a servicios que inicialmente fueron de datos como el comercio o la información en Internet (VoiceXML). Los operadores de la red están muy interesados en agregar todos los servicios que sean posibles, para lograr un uso mayor de sus redes así como la preferencia de los clientes frente a redes que ofrecen menos cantidad de servicios. Con respecto a los Servicios de Valor Agregado hay tres partes interesadas: Usuarios, Operadores de la red telefónica y proveedores de los servicios en sí. Los 2 últimos tienen un interés en común que es facilitar al primero lo más posible el acceso a los servicios ofrecidos. El operador de la red facilita a los proveedores de los servicios nodos de red inteligente para que estos conecten sus equipos. Muchas veces el propio proveedor de red es también proveedor de algunos de los servicios. Se ve aquí la arquitectura de los servicios de valor agregado brindado por las redes Inteligentes (ver Fig. 4.1). Se dará un listado de los distintos servicios que hoy en día ofrecen los distintos operadores telefónicos en el mundo. Esto no implica que todos los operadores den toda esta gama de servicios, aunque la mayoría de ellos son comunes a los principales operadores. 4.I-A.1 Servicio básico Llamada Origen - Destino Es la transmisión de voz desde el origen hasta destino, Fig Funciones y nodos de redes inteligentes. con una cierta calidad de servicio mínima. Este servicio fue el primer servicio de voz ofrecido por los operadores a partir del invento del teléfono. Accesos básicos ISDN (BRI), accesos primarios (PRI) ISDN y tramas E1 (R2 digital). Salto de llamada (número colectivo): Se asocian a un número de teléfono varias líneas, cualquier llamada a este número es dirigida a una de las líneas libres de este grupo. Línea directa o hotline. Conecta un canal de voz punto a punto sin necesidad de discar. 4.I-A.2 Servicios suplementarios distribuidos Son aquellos que se implementan en las centrales a las que está conectado el usuario. Generalmente estos servicios o tienen costo diferencial a de las llamadas estándar. Servicios de Telefonista: Incluye todos los servicios de información, que generalmente ofrecen los operadores telefónicos como informes de guía, información de tarifas, intermediación en llamadas por cobrar, etc. Servicio de Despertador: Consiste en que el operador telefónico genere una llamada al usuario que así lo solicito a una hora indicada. Redireccionado de llamadas (call fordward): Se trata de la posibilidad de redireccionar las llamadas entrantes a un abonado hacia otro elegido por el usuario de destino de la llamada. Hoy día, puede contratarse el direccionamiento de todas las llamadas o un redireccionamiento selectivo según el uso. En este ultimo caso 23

25 24 CAPÍTULO 4. SERVICIOS se requerirá de servicio de bases de datos por lo que la implementación no se hace localmente en la central. Llamada en espera: El abonado que contrate este servicio, contará con la posibilidad de saber que tiene una llamada en espera mientras está en medio de otra anterior. El aviso se realiza mediante un tono audible que se superpone a la conversación en curso. Identificación de llamada entrante: Un equipo con display (caller ID) puede identificar la llamada entrante (numero y nombre) Llamadas de discado rápido: El operador genera al usuario la posibilidad de discar un numero preprogramado con solo oprimir una de las teclas de su teléfono. Contestador automático: En caso de llamadas no atendidas el operador puede redireccionar las mismas hacia un equipo de correo de voz, que emitirá un mensaje personalizado y a continuación graba el mensaje de voz del usuario llamante. Posteriormente el usuario del servicio podrá escuchar estos mensajes llamando al operador. Este servicio ofrece notificación de mensajes nuevos a un radiomensaje, y/o el aviso a algún otro teléfono. CallBack Automático: Es una función que permite que el sistema detecte cuando un numero que está ocupado se desocupa e inmediatamente genera la llamada. 4.I-A.3 Servicios suplementarios centralizados Estos servicios se comenzaron a brindar con la introducción de Redes Inteligentes. Son servicios brindados con equipos especiales (Periféricos Inteligentes) que están conectados a la red a través de nodos especiales (Nodos Inteligentes) por lo tanto cualquier usuario podrá acceder a los mismos sin importar a que central este conectado. (Ver Fig. 4.2) Estos servicios son brindados por el propio operador de la red o por prestadores de servicios y en general tienen un costo diferencial. Fig Arquitectura de servicios de Valor Agregado. Personalización de Llamadas Entrantes y Salientes: Se pueden bloquear llamadas entrantes o saliente de acuerdo a su origen o destino. Llamada gratis (0800) La llamada la paga el abonado que la recibe y por esto se suelen conocer como llamadas sin cargo. Servicio 0800 global. Permite tener un único número que será enrutado sin costo para el usuario al destino nacional o internacional que corresponda según plan establecido. Timbrado Selectivo: En una modalidad se puede hacer que 2 números telefónicos en una misma línea cada uno de ellos con un timbre distintivo. Otra modalidad es en la cual el timbrado es diferente según el origen de la llamada. Servicios con Tarifas especiales (0900) Estos números en general tienen tarifas diferenciales, de valor bastante mayor a las estándar, y esto se debe a que llamando a este numero el usuario obtiene servicios de valor agregado prestados por un proveedor de servicios que cobra por los mismos. Entre estos servicios de valor agregado se encuentran: información, acceso a Internet, sorteos, horóscopos, etc. Numero Único de acceso: Es la posibilidad que se le da a una empresa de que varias oficinas ubicadas en distintas partes de un país o una región, puedan ser llamadas con el mismo numero y el operador se encarga de encaminar la llamada hacia la oficina más cercana al usuario que llama. Numero Personal Universal Al contratar este servicio el usuario recibe un numero telefónico y un código, de modo que este en el equipo telefónico en el que este, cuenta con la posibilidad de registrarse ingresando su código y a partir de ese momento todas las llamadas que se hagan hacia su numero personal, serán dirigidas al equipo en el que se registro. Llamada con Tarjeta de Crédito: Desde cualquier equipo llamando a un numero especial se habilita el cobro de la llamada a realizar a una tarjeta de crédito con solo ingresar su numero y el PIN de seguridad. Llamada a cobrar a una tercera persona: Se pueden configurar los abonados para que algunas llamadas especiales, o todas las que se realicen en cierto periodo sean cargadas a una tercera persona. Televoto: Generalmente asociados con programas de TV este servicio registra automáticamente la opinión de los usuarios llamantes. Suele usarse el teclado del teléfono (DTMF) como forma de automatización del proceso. Encuestas Telefónicas automáticas: Servicio que ofrecen los operadores telefónicos mediante el cual un equipo llama automáticamente a números preprogramados y realiza una serie de preguntas a las que quienes reciben la llamada responde con el teclado de su teléfono (DTMF) Encolado automático de llamadas

26 25 Los usuarios podrán contratar este servicio en le cual las llamadas que no pueden ser atendidas por operadoras serán dirigidas a una maquina que administra una cola de espera de modo que quien llama recibe información sobre la empresa a la que llama mientras espera a ser atendido. Este servicio puede incluir un reporte con información estadística que puede ser de interés para quien contrata el servicio. Llamadas en conferencia: Varios usuarios podrán discar a un numero telefónico y el operador los interconectará a todos de manera de generar un teleconferencia. Portabilidad de Números: El uso de bases de datos permite hacer una traducción entre el numero del cliente y el numero físico del teléfono que usa. Distribución de fax multidestino: Este servicio permite transmitir un documento simultáneamente a miles de destinos mediante el envío de listas de distribución. Central telefónica virtual: Permite a una empresa contar con todas las ventajas y prestaciones de una moderna centralita, sin necesidad de adquirirla o realizar instalaciones. Lo único necesario son las líneas de teléfono. Si tiene más de una oficina o local, y sus líneas pertenecen a la misma central telefónica, podrá realizar llamadas a precios diferenciales entre ellas, se encuentren o no en el mismo lugar. Consta de las siguientes facilidades: Marcación abreviada: de dos a cinco cifras en sus llamadas internas. Restricción de tráfico: para evitar el abuso telefónico, podrá limitar las llamadas al exterior de cualquier línea, ya sean provinciales, nacionales o internacionales. Desvío de llamadas: esta prestación le permite desviar automáticamente las llamadas que recibe una línea a cualquier línea que esté libre, cuando ésta comunica, no es atendida o simplemente si usted lo desea. Llamada en espera: cuando esté hablando con alguien, podrá atender otra llamada entrante sin perder la que estaba realizando. Captura de llamadas: siempre podrá atender una llamada dirigida a otra línea, desde cualquier extensión. Servicio contestador: gracias a él, la persona que llame podrá grabar mensajes en el buzón de la extensión marcada cuando no haya nadie o no pueda, en ese momento, atender la llamada. Etc. 4.I-A.4 Servicios convergentes Voice Browser Servicio con el cual el usuario podrá acceder a portales de voz y navegar en paginas de Internet y de este modo obtener todos los beneficios de Internet desde el teléfono. Este servicio no está siendo ofrecido en este momento Fig pero se prevee su puesta en operación para los próximos años. ( Fig. 4.3) Ejemplo de Voice Browser. Fonomail: Este servicio permite enviar y recibir correos de Internet desde cualquier teléfono, sin necesidad de un PC. Mediante conversión texto-voz escucha los mensajes nuevos de su cuenta y tiene opción de contestarlos, remitirlos o borrarlos. Llamado sin marcar. Se utiliza el reconocimiento de voz para efectuar llamadas a números preestablecidos por el usuario. Correo de voz vía . La central envía el mensaje grabado a su casilla de . Correo de fax vía . La central envía el fax directamente a su casilla de . Servicios de voz sobre IP. En redes privadas de voz y datos. Para llamadas urbanas, interurbanas e internacionales. 4.I-B Servicios de Datos 4.I-B.1 FRAME RELAY Tecnología de conmutación de tramas basada en circuitos virtuales permanentes (PVC) o conmutados (SVC) que permite velocidades de hasta 2 Mbps. 4.I-B.2 Servicios TDM Estos servicios se ofrecen como líneas punto a punto de nx64kbps (son posibles configuraciones sincrónicas a menores velocidades), es un servicio transparente al protocolo. Se comercializan tramas E1 canalizadas para soportar sobre una misma interfaz física (G703) hasta 30 circuitos punto a punto o interconectar PBX s. 4.I-B.3 Servicios de acceso LMDS Hasta 10 Mbps LAN to LAN, acceso a Internet, o flujos E1-R2 o accesos PRI para telefonía Interfaces G.703, Ethernet, V35, video, fraccional STM1. 4.I-B.4 Accesos inalámbricos tecnología Spread Spectrum hasta 2mbps Accesos de radio en la banda de 2.4 GHz (o banda pública disponible), se brindan servicios TDM, Frame Relay o accesos a INTERNET.

27 26 CAPÍTULO 4. SERVICIOS Interfaz física Caudal (CIR) garantizado para PVC s. Caudal (CIR) garantizado para PVC s Pasarela X.25 Caudal total agregado para SVC s Respaldo por RDSI Respaldo por RTC Gestión de red Facilidades Circuitos virtuales 4.I-B.5 Accesos satelitales TABLA 4.I V.35 = 2 Mbps G.703/704, V.35 0, 8, 16, 32, 48, 64, 96, 128, 192, 256, 384, 512, 1024, 1536, 1984 Kbps 4, 8, 16, 32, 48, 64 Kbps 8, 16, 32, 48, 64, 96, 128, 192, 256, 384, 512, 1024, 1536, 1984 Kbps Hasta 256 Kbps, funcionando a 64 Kbps Para 64 Kbps, respaldo de hasta bps Permanente PC para gestión de cliente Redirección Informes a cliente. PVC estándar PVC Plus+ (de backup) PVC Prioritarios PVC Pasarela X.25 Circuitos Virtuales Conmutados (SVC) FICHA TÉCNICA DE FRAME RELAY. VSAT hasta 19200bps. Se instala una antena en cada cliente, estos se comunican entre sí accediendo a una estación terrena central. Accesos de 64kbps a 34Mbps banda C y banda Ku 4.I-B.6 Redes privadas virtuales Paquetes de redes privadas virtuales (VPN s) para la transmisión de voz y datos sobre IP, con accesos mediante líneas punto a punto (Frame Relay, TDM, ATM) o discados sobre RDSI con PPP, con opción a conectividad a INTERNET centralizada o nó. Topología en estrella: el servicio se define con una Central y una o varias sucursales accediendo en estrella a la Central. Accesos mediante líneas punto a punto (TDM, Frame Relay, ATM, ADSL, LMDS, etc) o discados sobre RDSI con PPP o sobre ADSL usando PPPoE, en estos dos últimos casos es opcional el uso del servidor de AAA del proveedor. Red de Área Local Ethernet 10base T. Tráfico de datos IP. Direccionamiento IP privado. Servicio gestionado de principio a fin, de todos los elementos y recursos de red propios del servicio así como el equipo en domicilio del cliente (routers). Respaldo de la línea de acceso. Presencia en Internet. Compresión de voz y supresión de silencios. Gestión dinámica del ancho de banda Backups por ISDN o POTS. Ingreso a la RED IP-FR del proveedor o por circuitos punto a punto. 4.I-B.7 Nodo de red multiservicio Se instala en el domicilio del cliente un switch multiservicio (ATM o TDM) para brindar servicios Frame Relay, TDM, X.25, X.21, accesos a Internet, LAN to LAN Ethernet (hasta 100Mbps), flujos E1-R2, accesos básicos ISDN, E3 ATM, STM1, etc. La conexión de este nodo se realiza con flujos de 2 Mbps o fibra óptica. 4.I-B.8 Accesos a Internet Sobre FR con router y ancho de banda garantizado. Sobre FR y compartiendo acceso. Sobre ATM hasta 155Mbps. Sobre ADSL direcciones IP públicas fijas (provisión de modem-router) Sobre ADSL IP dinámica usando PPPoE ó PPPoATM para servicios de IP dinámica (provisión de modembidge). Acceso conmutado (POTS) a Internet discado, V.34, V90, etc. Acceso conmutado (ISDN BRI) a Internet Servidores de Cache y la posibilidad de interconectar servidores de cache privados con los de la empresa. Implementación de Newsgroups. Coubicación de Servidores: modalidad servidores de en instalaciones del proveedor con conectividad a 10 o 100 Mbps en modalidades individuales o compartidas Servidores de información multimedia con conexiones al backbone (a 100 Mbps) y con cobro en función de conexiones simultáneas, espacio en disco y/o volumen traficado usando servidores del proveedor de servicio (real networks o Windows media). Web hosting con posibilidad de conexión a base de datos (Unix o Microsoft) con conectividad al backbone a 100Mbps. Se brinda espacio en disco, cuentas para la administración del site, etc. Acceso discado: con acceso a través de números 0800, con tarifa local en algunos puntos del país (por ejemplo en Uruguay a través de UruguayNet), con espacio en disco para realizar FTP s con la posibilidad de reservar puertos para asegurarse un mínimo de disponibilidad, con cuentas de correo. Asesoramiento en la configuración de nombres de dominio. 4.I-B.9 Línea ADSL Internet (Asymmetric Digital Suscriber Line) Tecnología de acceso sobre el local loop de la PSTN que usa una banda superior (30kHz-1.1MHz) a la usada en telefonía (0-3.4kHz) para el envío de datos a alta velocidad. Es un servicio asimétrico ya que se obtienen velocidades mayores en el downstream (hasta 8Mbps) que en el upstream (hasta 640kbps) las cuales dependen fuertemente de la calidad de la línea y la distancia. Velocidades alcanzables

28 27 Data rate (Mbps) Wire gauge (AWG) Wire size (mm) Distance (km) 1.5 or or Standares ITU: TABLA 4.II VELOCIDADES ALCANZABLES. G (G.dmt)-Full rate ADSL [5](Anexo A y B,ADSL sobre ISDN). G (G.lite)-Splitterless ADSL. G (G.hs)-Handshaking protocol for ADSL. ANSI: T1.413 Issue2 Sentido Modalidad PCR SCR downstream Reducida 256 Kbps - Básica 256 Kbps 25,6 Kbps Class 512 Kbps 51,2 Kbps Premium 2 Mbps 200 Kbps upstream Reducida 128 Kbps - Básica 128 Kbps 12,8 Kbps Class 128 Kbps 12,8 Kbps Premium 300 Kbps 30 Kbps PCR= Máxima velocidad alcanzable (Peak Cell Rate) SCR= Mínima velocidad garantizada (Sustainable Cell Rate) 4.I-B.10 Internet-seguridad TABLA 4.III MODALIDADES DE CONTRATACIÓN. Servicio de firewall, VPN s encriptadas, autenticación de usuarios, filtrado de contenido web para empresas, scanning de sitios para evaluar la seguridad, servicio antivirus, etc. 4.I-B.11 SERVICIOS X.25 Servicios de Red Privada Virtual (RPV) para comunicaciones del sector financiero (Bancos, Cajas y Seguros), que por su carácter crítico para el negocio necesitan comunicaciones muy fiables. Fig Ejemplo de Voice Browser. Línea ADSL incluye: Equipo ADSL de usuario: Módem ADSL. 5 buzones de correo electrónico (5 MB/buzón) más subdominio. La lectura se podrá hacer a través de POP3 y Webmail. 10 MB de páginas web. Herramientas FTP para la publicación de páginas web personales. Instalación y configuración a domicilio que incluye: prolongación de cableado, instalación del splitter ADSL RDSI, del módem ADSL RDSI, y configuración de del servicio de acceso a internet. - Opcionales: MB adicionales en el buzón de correo. Buzones de correo adicionales. Dominio propio de correo y web. Traslado de dominio. Tarjeta Ethernet 10baseT (necesaria para módem externo) Extensión de garantía de equipos ADSL. Intervención fuera de garantía de equipos ADSL. Modalidades de contratación según las velocidades máximas disponibles en el acceso. Ver Tab. 4.III. 4.I-B.12 Servicios de mensajería Correo individual X.400. Interconexión de equipamiento de correo privado con red pública usando el protocolo X.400. Casillas POP de correo electrónico. EDI Local: para usuarios que ya poseen una casilla postal para enviar documentos EDI (Electronic Data Interchange (EDI) es el intercambio electrónico de documentos. Estos documentos incluyen ordenes de compra, facturas, pedidos, planificación, calendarios, resultados de pruebas, pagos y reportes financieros.). EDI Central: Servicio prestado a usuarios que ya poseen una casilla postal para intercambio de documentos EDI. La traducción de documentos y el control son realizados en el sistema central. Web EDI: Ofrecido para clientes que no poseen sistemas automatizados que proporcionen la utilización de EDI, pero que necesitan intercambiar documentos padronizados con otras empresas. A través de una interfase WEB, o cliente llena un formulario que es traducido, por el EDI Central, en un documento EDIFACT o cualquier otro padrón, sea ANSI X.12 o propietario. EDI para comercio exterior. 4.I-B.13 Otros servicios, productos CPE s para redes privadas (routers, muxes, etc.) Servicios de housing de equipamiento. Subidas de señales de televisión para difusión. Servicio Inmarsat (telefonía, telex, fax, datos) servicios en aeronaves, envío de mensajes entre terminales móviles

29 28 CAPÍTULO 4. SERVICIOS y redes terrestres (store and forward) para servicios de antirrobo, información de telemetría, etc. (600bps) Servicios de redes privadas con acceso discado (TUNEL L2TP) usando INTERNET o redes IP nacionales o regionales. 4.I-B.14 Ejemplo de servicios convergentes Very-Hight-Data-Rate Digital Suscriber Line (VDSL) Tecnología que presenta una alternativa a la FTTH (Fiber To The Home), alcanza alta velocidades en el downstream (hasta 55Mbps) en cortos tramos (300 mts.). Una velocidad típica es 13 Mbps que se alcanzan en unos 1,5kms. En el upstream son alcanzables velocidades de 2.3 Mbps y mayores en cortas distancias. Ancho de Banda (Mbps) Canales de TV y de audio: Distancia (metros) TABLA 4.IV VELOCIDADES ALCANZABLES. 82 básicos, 24 Premium, 24 PPV. Cada canal es enviado en formato digital(mpeg- 2). Cada canal es enviado desde la oficina central a diferencia del modelo de broadcast del sistema de cable. 45 canales de audio digital (Dolby AC- 3). Caller ID/ y mensajes de voz en la TV. Interactive Program Guide (IPG). Canal secundario de Audio (por ejemplo español disponible en 18 canales premium). Servicio de datos de alta velocidad. paquetes de 256kbps y 1Mbps para acceso a Internet simétricos. Funciones de telefonía avanzada. Un gateway residencial para todos los servicios. Paquete único para todos los servicios. 4.I-B.15 Servicios a otras empresas o carriers Derecho de pasaje: ofrece conectividad 2Mbps-155Mbps por cables submarinos. Servicios de interconexión con otros prestadores Para proveedores de telefonía fija. Para proveedores de telefonía celular. Para proveedores de servicios móviles globales satelitales. 4.I-C Servicios de Video Cada vez mas, los proveedores de servicios están obligados a ofrecer una mayor cantidad de nuevos servicios diferenciales que les permitan tanto atraer nuevos suscriptores como mantener los actuales. Este hecho, conjuntamente con el desarrollo de los servicios de banda ancha, ha permitido que se surjan una gran cantidad de nuevos servicios basados en la posibilidad de transmitir video sobre las redes de datos. Se presentar a continuación un resumen de servicios de video que se pueden encontrar disponibles mundialmente. 4.I-C.1 Video broadcasting En cuanto a la transmisión de video de TV/cable sobre las estructuras de datos, existe un gran espectro de posibilidades entre las cuales los poseedores de servicios de banda ancha podrían optar. Estas incluyen tanto la posibilidad de elegir entre diferentes paquetes de canales, como la de elegir la calidad de acuerdo con el ancho de banda disponible. Los diferentes paquetes de canales se dividen habitualmente en: Canales públicos Canales de compras Canales básicos de cable Canales premium Pay-per-view channels. 4.I-C.2 Video bajo demanda A diferencia de los canales de broadcasting, estos servicios no cuentan con una programación en la cual los usuarios esperan al horario especificado para ver el programa que desean. Por el contrario, permiten que la persona elija y vea el momento que esta lo desee, algún programa de los disponibles dentro del servicio. Se ofrece también servicios denominados near-video-on-demand, en los cuales el suscriptor no tiene la posibilidad de ver en el momento la película elegida, pero si de solicitar que la misma sea parte de una programación que se confecciona en base a las solicitudes. Fig Arquitectura VDSL. 4.I-C.3 Monitoreo remoto Este servicio permite que personas o empresas cuenten con un circuito cerrado de vigilancia o de monitoreo en lugares alejados, solamente utilizando su conexión a la red de datos y sin aumentar mayormente sus costos. Esto permite realizar reuniones virtuales entre personas que potencialmente se encuentren en cualquier lugar del mundo.

30 29 4.I-C.4 E-learning El acceso a salones de clase virtuales o a bibliotecas multimedia, permite a los alumnos, que por estar alejados del lugar de aprendizaje no podrían concurrir, aprender de la misma forma que lo harían asistiendo físicamente a clases. 4.I-C.5 Learning on demand Este servicio permite el acceso, por ejemplo, a cursos de actualización o de perfeccionamiento en forma permanente. La persona solamente tiene que solicitar que se le transmita de los opciones disponibles el curso de su interés. 4.I-C.6 Información bajo demanda personalizada Este tipo de servicios se basa principalmente en la posibilidad de que una persona reciba información a demanda sobre temas específicos (por ej. noticias, deportes, financieras, entretenimiento, etc.). 4.I-C.7 Tele-medicina Este es un nuevo servicio desarrollado para poder compartir experiencia, diagnósticos y información médica en forma remota. 4.I-C.8 Live event webcasting Ofrece la posibilidad de transmitir por Internet videos provenientes de WebCams u otros eventos. 4.II SERVICIOS A OFRECER POR ZONAS Aquí se especifican que servicios serán ofrecidos por la red a diseñar en función de las zonas previamente definidas. ZONA A: privadas de voz, voz sobre IP, servicios de red inteligente, etc. Datos: Acceso a Internet a nivel residencial y empresarial, redes privadas, líneas punto a punto, accesos discados, hosting 10, servidores de streaming-media, coubicación 10. Video (sub-zona B1): Video digital, video conferencia, video vigilancia. ZONA C: Servicios a ofrecer: Telefonía, Datos. Telefonía: Telefonía local y larga distancia, telefonía empresarial, redes privadas de voz, voz sobre IP, servicios de red inteligente, etc. Datos: Acceso a Internet 10, redes privadas 10, accesos discados 10, hosting, servidores de streaming-media, coubicación. Nota: Estos servicios han sido seleccionados para cada zona a partir de los indicadores de densidad de población y nivel socioeconómico de las mismas. La decisión se ha tomado pensando en que servicios serían rentables en cada una de estas. Esta decisión será tomada como un rumbo a seguir pero con cierta flexibilidad ya que las tecnologías necesarias para implementar los mismos no nos son completamente familiares en este punto del diseño y podrían (al igual que otros factores) obligar a modificar la decisión. Esto implica que habrán etapas de revisión de la conveniencia de esta decisión. 11 Servicios a ofrecer: telefonía, datos, video. Telefonía: Telefonía local y larga distancia, soluciones de telefonía empresarial (hotelería, hospitales, call centers, etc), redes privadas de voz, voz sobre IP, servicios de red inteligente, etc. Datos: Acceso a Internet a nivel residencial y empresarial, redes privadas, líneas punto a punto, accesos discados, hosting 10, servidores de streaming-media, coubicación 10. Video: Video digital, video conferencia, video vigilancia, video on-demand 10. ZONA B: Fig Zonas definidas en Montevideo. Servicios a ofrecer: Telefonía, Datos, video 10 (sub-zona B1). Telefonía: Telefonía local y larga distancia, soluciones de telefonía empresarial (hotelería, hospitales, call centers, etc.), redes 10 Servicios a confirmar posteriormente. 11 Es recomendable hacer un proceso de espiral donde se volviera sobre decisiones tomadas pero con datos más precisos en cada vuelta para de esta forma mejorar las mismas.

31 30 CAPÍTULO 4. SERVICIOS

32 Capítulo 5 Redes Convergentes Resumen Este capítulo se comienza haciendo un breve análisis de las diferencias entre redes tradicionales y redes convergentes, pera luego estudiar en detalle las arquitecturas convergentes. LAS PSTN claramente han demostrado su capacidad de mantener el mundo comunicado a lo largo de mucho tiempo. Hoy en día, la tendencia de las compañías de telecomunicaciones es brindar la más variada cantidad de servicios que les sea posible. Esto se debe principalmente a que las ganancias por los servicios de voz tradicionales, aunque son muy grandes, (380 billones en telefonía en US), tienden a decaer debido a la competencia y avances de la tecnología (ejemplo transporte de voz por IP dentro de redes privadas de grandes compañías). Al mismo tiempo que se espera el crecimiento en ventas de servicios innovadores de alto valor. En este sentido los proveedores de servicios han desarrollado durante los últimos años redes separadas para voz y datos (ver Fig. 5.1), basadas principalmente en equipamientos caros de grandes empresas proveedoras. De esta forma se mantenía una estructura clásica basada en el transporte de voz, y se solucionaban las necesidades, hasta entonces pequeñas, en cuanto a tráfico de datos, haciendo de esta una muy exitosa estrategia en términos de rentabilidad. Fig Arquitectura de VoDSL Actualmente esto está cambiando, y el crecimiento de algunas compañías en su backbone de datos es inmenso. En algunos casos este alcanza un ritmo de 800 % anual, mientras que el tráfico de voz aumenta 4 % anual (aun así no hay que olvidar que el 80 % de las ganancias provienen de servicios de voz). De la misma forma, hoy en día los accesos discados a Internet devoran los circuitos de las PSTN. Con una duración de llamada imprevista estos derivan en una caída del grado de servicio, obligando a las compañías a sobre dimensionar los circuitos para evitar congestión, lo que claramente termina con una reducción real en la rentabilidad del negocio. Se mencionan aquí algunos de los inconvenientes de las actuales PSTN: Son caras de instalar, esto limita la entrada de empresas nuevas al mercado de las telecomunicaciones. Son sistemas propietarios, lo que dificulta la incorporación de nuevas funciones y servicios. No son adaptables a la incorporación de otros servicios de telecomunicaciones como televisión de abonados, o datos, a menos que se incorporen sistemas (redes) en paralelo para ofrecer algunas de estas funciones. Imposibilidad de facturación on-line o de generar reportes (disponibles para el usuario) en tiempo real. La convergencia de voz y datos en telecomunicaciones no es un nuevo paradigma, anteriormente se han realizado serios esfuerzos por realizar esta convergencia a través de la introducción de ISDN. Sin embargo, esto no prospero debido a la falta de contenido de datos para su utilización. Con la introducción de ATM en el transporte y conmutación de voz y datos sobre la misma estructura, la convergencia tuvo un nuevo impulso. Sin embargo, tomo muchos años antes de que el equipamiento se encontrara disponible a precios aceptables. Actualmente, tanto ATM como IP (o IP sobre ATM) son candidatos a ser las tecnologías básicas para las redes convergentes, ya que ambas permiten bajar los costos en la instalación de la red, así como bajos costos de operación y mantenimiento de la misma. Es así que nacen las denominadas Redes Convergentes, que plantean entre otras virtudes: mejorar la eficiencia de la red y reducir los costos operativos gracias a la convergencia hacia las redes de banda ancha basadas en paquetes. Reducir la cantidad de redes superpuestas no solo redunda en la reducción del costo de la red instalada, sino también en lo relativo al mantenimiento, los recursos humanos y el entrenamiento duplicado (o triplicado) que se requiere. incrementar la flexibilidad para desarrollar rápidamente servicios de voz y datos innovadores basados en arqui- 31

33 32 CAPÍTULO 5. REDES CONVERGENTES Fig Topología de Redes Convergentes tecturas abiertas a múltiples proveedores. ofrecer servicios más rentables, relacionados con la convergencia de voz, video y datos. Los servicios innovadores desplazan parte de la rentabilidad que hoy se encuentra en el fabricante de equipos hacia el proveedor de los servicios. Esto se debe a que la oferta de servicios a brindar depende en gran medida de la capacidad del proveedor de desarrollarlos y venderlos. crea un dilema a los proveedores que queriendo minimizar la inversión y maximizar las ganancias, se dan cuenta que algunos de los equipos de redes convergentes que se fabrican actualmente les permitirían obtener beneficios a corto plazo, pero que construir una red convergente antes de que los estándares estén maduros haría peligrar las inversiones. Asimismo existe preocupación por la credibilidad y estabilidad de los productos ofrecidos por los proveedores (tanto grandes como pequeños). Si a todo esto, se suma que actualmente el costo económico que presenta la compra de equipos convergentes (ej. Softswitches) es muy elevado, se encuentra una realidad donde son muy pocos los proveedores que intentan desarrollar una red íntegramente convergente. En cambio, se puede ver entre estos proveedores (tanto nuevos como ya instalados) una tendencia creciente a desarrollar redes de telecomunicaciones híbridas, que les permitan moverse hacia uno u otro lado de acuerdo con la evolución de los problemas mencionados. Estas redes, que técnicamente están en el limite entre las PSTN y las NGN, generalmente presentan redes de acceso convergentes, mientras que en su etapa de transporte y conmutación pueden presentar ambas tecnologías. [6] y [7] El camino hacia la convergencia de voz y datos, está profundamente relacionado con el desarrollo de los protocolos de control adecuados. La idea de tener Softswitches es mover las llamadas y los servicios de telecomunicaciones que hoy están ubicados en los conmutadores de las PSTN, hacia servidores montados enteramente en redes de paquetes. Tal vez, el aspecto más prometedor es que de esta forma la creación de servicios dejará de estar en manos de los fabricantes de equipos, para pasar a manos de los proveedores y también de los usuarios. Esto revoluciona la relación entre los usuarios y sus necesidades de servicios de telecomunicaciones, ya que estos dinámicamente podrán auto aprovisionarse de los servicios necesarios, a través por ejemplo, de una interfase web. Una aplicación de call center puede ser fácilmente creada por un proveedor para generar un Call Center con agentes localizados donde se quiera (como ejemplo en sus hogares). El procesamiento y manejo de las llamadas puede seguir siendo monitoreado como parte de la aplicación. Sin embargo, la evolución hacia la convergencia de las redes a nivel mundial no se dará de la noche a la mañana. La introducción de elementos convergentes se debe hacer progresivamente en distintos puntos de la red. La red de acceso es uno de los puntos principales a tener en cuenta. Un servicio en el cual la voz y los datos se combinan en un mismo equipo de abonado, usando IADs, y luego distribuidas desde un nodo de acceso (un DSLAM por ejemplo), permite a los proveedores de servicios disfrutar de una significativa reducción de costos como resultados de esta convergencia. Es importante destacar, que si bien la realidad actual muestra que la idea de incorporar redes convergentes es aceptada por gran parte de los proveedores, todavía falta madurez en lo que refiere a arquitecturas y protocolos. Esto Características fundamentales de una red convergente Como ya se vio, la convergencia implica como primer paso la interconexión entre las PSTN y las redes de paquetes conmutadas en una única red de paquetes. Pero esto también requiere de ciertos cambios o consideraciones en dicha red de paquetes, es así que cualquier red que pretenda sustituir a las actuales PSTN debe cumplir con todas sus funciones y con un grado de servicio al menos igual. Entre los aspectos básicos de esta transición, se encuentran las expectativas de los usuarios, que seguirán siendo: Que su teléfono funcione bajos las condiciones más adversas, incluyendo falta de corriente eléctrica. Tener la posibilidad de seguir haciendo llamadas toda y cada una de las veces que se levanta el tubo. Una calidad de voz igual o mejor a la de la telefonía actual. Que el contenido de sus comunicaciones con el resto del mundo sean confidenciales. (y no fácilmente decodificables por piratas informáticos). Para asegurar estos requerimientos de los usuarios y alcanzar los niveles actuales de las PSTN, estas nuevas tecnologías deberán contemplar los siguientes aspectos: Confiabilidad - Se deben utilizar componentes de tipo Carrier Class, cuyas características esenciales son: Las llamadas activas no se pueden caer por fallas % de disponibilidad. (menos de 3 min. por año) Caminos de comunicación redundantes entre dispositivos del sistema Software y hardware confiable y con tolerancia a fallas (seguramente redundante).

34 33 Escalabilidad En tamaño pero también en cantidad y tipos de servicios que brinda. Propiedades de línea primaria: Posibilidad de rastrear llamadas entrantes a un servicio de emergencia, hasta su ubicación en un lugar físico. Capacidad de interceptar llamadas legalmente. Otro punto de gran importancia en la creación de redes convergentes, es que estas no podrán existir aisladas de las actuales PSTN. Es así, que mucha de la actividad en este sector se concentra en crear estándares que permitan mantener la compatibilidad y permitir esta interconexión. Esta conexión se deberá dar tanto a nivel de voz y datos, como a nivel de señalización (por ej. SS7 e ISDN). [8] [9] Evolución hacia las redes convergentes Cuando se evalúa la posibilidad de evolucionar a una red convergente existen varios factores a ser considerados. Estos afectan en forma un poco distinta a los nuevos proveedores que a los ya instalados, pero básicamente ambos tendrán que manejar en algún momento las siguientes consideraciones con respecto a la arquitectura y equipamiento que se pretende instalar: Ubicación de la inteligencia del servicio deberá estar dentro de un nuevo elemento de la red convergente. Es improbable que cualquier elemento de la red conmutada evolucione para convertirse en el núcleo de la red convergente. Utilización de estándares abiertos de no ser así, se corre el riesgo de quedar atrapado en una solución propietaria, con las desventajas de estas. Convergencia en la red de acceso la tecnología de acceso debe poder evolucionar para entregar voz y datos, logrando a largo plazo una convergencia total de la red. Convergencia en el backbone las ventajas de mantener un backbone convergente (un solo backbone) son muchas, al igual que en las líneas de acceso. Integración con sistemas conmutados debido a que el proceso de cambio de PSTN a NGN (Next Generation Network) puede llevar muchos años, es muy importante mantener la compatibilidad con los servicios, sistemas y señalización de las redes actuales. Aun más, los sistemas de managment y aprovisionamiento deberán ser capaces de integrarse con los procesos actuales. La solución está lo suficientemente madura además de lo detallado más arriba, se deberán tener en cuenta otros requerimientos como Carrier-class, disponibilidad, administración y calidad de servicio. Para poder cumplir con esto, tanto protocolos como equipos deberán pasar por exigentes pruebas de laboratorio y producción, que les permitan alcanzar niveles de credibilidad y calidad adecuados. Para una PSTN ya instalada, por ejemplo, se puede sugerir que la evolución de la red sea de la siguiente forma: Parar el crecimiento de la PSTN para, con el tiempo, permitir que los servicios de voz sean atendidos por servicios de voz sobre paquetes (por ej. VoIP). Convertir la red en multiservicio. Esto se lograría instalando servidores especializados, elevando así la cantidad y calidad de los servicios ofrecidos. La red de transporte evoluciona para proporcionar calidad de servicio totalmente garantida, lograda utilizando métodos como conmutación por medio de etiquetas. Incremento de la inteligencia en los equipos de usuario y proveedores para permitir así el desarrollo de servicios aun más avanzados. Convergencia en el backbone. Para una compañía ya instalada, el usar sus instalaciones ATM como backbone parece ser el método más adecuado. Esto se debe al hecho de que casi todas tienen una infraestructura ATM que podrían reutilizar (Recordar que ATM tiene previsto capacidad de QoS). De todos modos, para esto muchas de las compañías aun deben adaptar sus redes para que puedan interconectarse con la señalización SS7. Es decir, conseguir conmutadores ATM con integración para SS7. Para proveedores nuevos a instalarse, tanto ATM como IP/MPLS son opciones a manejar, lo importante es que sea cual sea la red a instalar tiene que cumplir con los requerimientos mencionados anteriormente, y para eso el requisito mínimo es que maneje QoS. Uno de los primeros pasos es seleccionar el hardware correcto, teniendo en cuenta que cada hardware normalmente tiene su grupo propio de APIs de control y administración. Problemas de integración con hardware de otros proveedores deben ser analizados. Es necesario decidir la red a utilizar: Para capas 2 y 3 las principales alternativas son ATM y IP/MPLS. Para capa 1 aparecen como las alternativas más adecuadas la fibra óptica o sistemas inalámbricos. Dentro de las soluciones de fibra de todos modos hay que evaluar, primero las posibilidades permitidas por el reglamento de telecomunicaciones, y luego la alternativa más conveniente desde el punto de vista económico y estratégico. Algunas de las posibilidades a tener en cuenta son: Instalación de Fibra propia, Renta de fibra oscura, contratación del transporte al proveedor incumbente, etc. Por más información ver [6] [8] Redes Híbridas Básicamente, el cambio de esta respecto a una red íntegramente convergente radica en que la inteligencia del servicio no está en un elemento convergente. Hay que tener en cuenta que este elemento es generalmente el de conmutación, lo que prácticamente no influye en la decisión sobre las etapas de acceso y transporte, permitiendo que estas redes sean prácticamente idénticas (las diferencias son principalmente funcionales y no tanto de arquitectura).

35 34 CAPÍTULO 5. REDES CONVERGENTES La idea de montar este tipo de redes es muy clara para los proveedores ya instalados, quienes antes de optar por un cambio total en la red, prefieren hacerlo en forma parcial utilizando los elementos de cada tecnología que le resulten más convenientes. Esto no es tan claro en el caso de nuevos proveedores que ingresan al mercado. Estos deberán instalar su red desde cero teniendo que decidir entre un tipo de equipo u otro, y arriesgarse de acuerdo con su plan de negocios a recuperar la inversión en un plazo razonable. Actualmente la tendencia a la convergencia es muy grande, y aunque rezagada por los problemas económicos se llevará a cabo tarde o temprano. 5.I DESCRIPCIÓN DE REDES CONVERGENTES 5.I-A Arquitectura de red Como se ha dicho anteriormente, para definir cualquier arquitectura que soporte servicios de voz, es primordial mantener los teléfonos (tanto fijos como móviles) actualmente instalados, ya que estos son y serán por largo tiempo los que prevalezcan. En este sentido, se plantean actualmente muchos escenarios concretos en cuanto a desarrollo de redes convergentes. No obstante, se hará aquí una referencia general sobre la estructura de estas redes. Esta arquitectura de referencia se crea de acuerdo a las siguientes consideraciones y criterios: Se debe utilizar terminología de la industria y definiciones de la arquitectura, esto es que se consideraran tanto elementos existentes de hecho, como otros que realmente se basan en estándares. Identificar elementos que permitan la innovación de servicios. Identificar elementos que de alguna forma estén de acuerdo con la visión actual de la industria, de forma de maximizar la flexibilidad de la arquitectura para poder luego desarrollar servicios innovadores con menores costos de desarrollo y operación. Las divisiones verticales de la Fig. 5.3 muestran las interfases entre las redes de circuitos (legacy circuit-switched networks) y las redes fijas de paquetes, y entre las redes fijas de paquetes y las redes móviles de paquetes. En adelante se trabajará principalmente sobre elementos introducidos por redes convergentes, y no se darán detalles adicionales sobre los componentes de las redes de circuitos más allá de los casos puntuales donde estos se utilicen. 12 Los elementos de referencia en las redes convergentes son: Gateways proveen la conmutación/conversión para los contenidos y señalización en el acceso o en los puntos de interconexión. Softswitch se encarga de las funciones de ruteo de llamadas, autorización, autentificación y contabilidad (AAA), y de controlar las capacidades de conmutación y señalización de los gatways. 12 Por más información sobre estos temas, dirigirse a la bibliografía del curso de Telefonía Digital de la Facultad de Ingeniería UDELAR Feature server estos servidores de facilidades implementan los servicios básicos de los conmutadores y funciones habitualmente relacionadas con los SCP (Service Control Point). Estos servidores proveen los mismos servicios que PSTN, de modo transparente para el usuario. Media server implementa las capacidades de transmitir anuncios, brindar servicios de mensajes, detección de progreso de las llamadas, conferencias, reconocimiento de voz, y sintetización de voz. Las capacidades de estos servidores son utilizadas por los servidores de aplicación y por los Softswitches que requieren anuncios, generación de tonos, conferencias, etc. Application server aquí se encuentran las aplicaciones para el funcionamiento de servicios nuevos e innovadores. Estos se basan principalmente en herramientas de Java o Microsoft.Net, y proveen integración entre voz y datos. 5.I-A.1 Gateways El propósito de los Media Gateways es el de proveer conmutación y conversión para los flujos multimedia, tanto en los puntos de acceso a la red como en los puntos de interconexión de redes. Tipos: En las Fig. 5.3 se pueden encontrar 5 tipos de gateways que se definen a continuación 13 : 1. Trunk Media Gateways proveen las interfase para los flujos de voz (conmutación y conversión) entre las redes de circuitos (PSTN) y el backbone de paquetes (voice-over-packet networks). Esto incluye los protocolos para modems definidos por V.90. Los circuitos que terminan en un trunk gateway son transportados generalmente por flujos T1, E1, DS3, OC3 o OC12, y son principalmente troncales señalizados SS7 (ISUP o TUP). También se pueden terminar en estos gateways troncales ISDN o de protocolos senñalizados en banda. Generalmente, la información de señalización es enviada al Softswitch vía SCTP (M2UA, M3UA, IUA, o MGCP) SS7 Signaling Gateways permiten el transporte de las capas superiores del protocolo SS7 (ISUP, SCCP, TCAP, etc.) a través de una red IP. Estos gatways pueden terminar la señalización SS7 de una o varias PSTN, y transmitir la capa superior del protocolo SS7 hacia uno o varios elementos de la red de paquetes(por ej. Softswitches). Para esto se utiliza un transporte de protocolos de señalización basado en IP, como por ej. SCTP. 3. Access Media Gateways también conocidos como IADs, proveen interfases (tanto para los suscriptores residenciales como empresariales) entre los dispositivos analógicos tradicionales o dispositivos digitales ISDN, y las redes de paquetes (voice-over-packet network). Estos también pueden interactuar con sistemas telefónicos empresariales como PBXs 13 Equipos con igual funcionalidad se pueden encontrar en documentación y bibliografía con diferentes nombres. 14 Ver sección 5.I-C.1.

36 35 Fig Arquitectura de NGN ya sea en forma analógica o con interfases de tipo ISDN Primarias. En alguno casos, estos dispositivos pueden contar con detección y generación de señalización analógica de línea (tomar línea, cortar, generación de Ring, etc.), efectuar la colección de dígitos DTMF y proveer control para otros dispositivos de usuario como por ejemplo caller ID. 4. Access data Gateways Es la interfase de última milla entre la red de paquetes hasta el cliente (local loop) y el backbone. Estos son los encargados de introducir al backbone de paquetes todo lo que proviene de los clientes, ya sea voz, datos o video. Hoy en día estos gateways son usados principalmente para proveer acceso a Internet y VPNs para computadoras y PBXs. Estos gateways de última milla son utilizados principalmente en redes de cable o en redes de acceso de pares de cobre (a través de DSLAMs). 5. Packet Gateways Actúa en los limites entre dos redes de paquetes y puede ofrecer una o varias de las siguientes funciones: traductor de capa de aplicación, conversión de flujos multimedia y roaming (para redes de celular). Los traductores en capa de aplicación (Application Layer Gateway - ALG) son situados entre dos redes de paquetes por razones de seguridad, así como para ocultar la estructura interna de cada prestador. En este contexto, capa de aplicación refiere a la capa de aplicación del stack de protocolos (por ej SIP, H.323, etc.). El ALG también brinda los servicios de NAT tradicionales convirtiendo las IP publicas en otras privadas cuando los paquetes pasan la frontera entre las redes internas y externas. Los packet Media Gateways llevan a cabo la conversión de flujos multimedia, de forma similar a lo que hace un trunk Media gateway. En la mayoría de los casos las redes están habilitadas a negociar las sesiones multimedia para usar formatos de codificación comunes, así que en estos casos este tipo de gateways no son necesarios (esto es bueno ya que evita la latencia y degradación adicional de señal). Sin embargo, existen situaciones como cuando redes móviles (redes celulares) se conectan al backbone de paquetes, donde se precisa la conversión de una codificación (por ej CDMA) a otra (por ej G.711). Formas de implementación: Una diferencia distintiva de los gateways es si estos están separados o integrados con el Softswitch. La primera opción representa una arquitectura de gateways distribuida, mientras que el segundo se conoce en la literatura como una arquitectura de gateways monolítica. Una arquitectura de gateways distribuida incluye Media Gateways, SS7 signaling Gateways y Softswitches (que incorpora las funciones de controlador de Media Gateways) separados físicamente los unos de los otros Esta arquitectura separa la ingeniería de la conversión de flujos multimedia, conversión del control de llamadas y gerenciamiento del control de llamadas, permitiendo desarrollar grandes redes (decenas de miles de suscriptores) mientras se minimizan los costos de equipamiento de la misma. Las llamadas arquitecturas monolíticas no requieren la existencia de Softswitches para realizar el control de los

37 36 CAPÍTULO 5. REDES CONVERGENTES Media Gateways, ya que estos realizan las funciones de ruteo de llamadas, autentificación y conteo. Se pueden incluir Softswitches en esta arquitectura para cumplir roles similares a los H.323 Gatekeeper o los SIP proxy. Esta arquitectura recrea en cierta forma el escenario existente con las centrales telefónicas de la PSTN donde la conmutación, señalización y forma de tratar el contenido son parte del mismo producto. Otra distinción importante que se debe tener en cuenta, es en cuanto a los IADs que se utilizan. Como ya se menciono, estos pueden o no contar con capacidades para hablar con las entidades de control. En el caso de los IADs que no cuentan con esta capacidad, estos simplemente actúan como interfase entre las conexiones de voz del cliente y la red de paquetes (red de acceso). A su vez, estos están conectados en forma lógica con otros gateways que si poseen estas capacidades. Este caso se puede ver en la Fig. 5.4, donde los IAD no pueden conectar llamadas con otros dispositivos directamente. Fig IAD s que pueden hablar con SoftSwitches de llamada en la hora más ocupada (BHCA busy hour call attempts) Interoperabilidad ayuda a minimizar el costo de la infraestructura de la red, permitiendo armar una plataforma de Media Gateways y Softswitches que no tengan que ser del mismo fabricante. Disponibilidad tiene que ser suficiente para asegurar el factor de servicio establecido. QoS (calidad de servicio) baja latencia en el pasaje por los gateways para garantizar la transparencia del servicio. Utilización del ancho de banda se deben soportar codecs con baja tasa de bits (por ej. G.729, G.723, GSM, CDMA) de forma de minimizar el costo en la estructura de la red en términos de ancho de banda. Este aspecto se vuelve vital en el caso de los proveedores que utilizan infraestructura arrendada para el transporte. Fig IAD s que no pueden hablar con Softswitches En el caso que si las posean, estarán equipados también con capacidades de colección de dígitos y la posibilidad de establecer llamadas a través de la red por ellos mismos. Este caso se puede ver en la Fig. 5.5, donde estos establecen conexiones directamente y de acuerdo a las instrucciones de controlador. Parámetros: Los parámetros más importantes en la ingeniería de los Media Gateways son: densidad de conexiones afecta los costos de espacio locativo de los proveedores. En un rack de 19 se pueden colocar Trunk Media Gateways que manejan desde 100 circuitos (esto es 4 E1s) hasta 8000 (interfases OC12), mientras que los access Media Gateways empresariales típicamente soportan entre 4 y 100 líneas digitales o analógicas. Capacidad de establecer llamadas se mide en intentos 5.I-A.2 Softswitch El termino Softswitch generalmente refiere al un sistema de comunicaciones que emplea estándares abiertos en el cual la inteligencia y el control del servicio están separados del flujo multimedia. Softswitch deriva de software que provee el control central de un sistema de conmutación. Las funciones principales de un Softswitch son ruteo de llamadas, administración de recursos, conversión de protocolos, AAA y controlador de Media gateway. Los Softswitches también abren interfases de aplicación que posibilitan la creación de servicios brindados por los servidores multimedia. Además, los Softswitches posibilitan el control de llamadas para clientes de VoIP (por ej. clientes H.323 o usuarios SIP), incorporando funcionalidades de SIP proxy y/o H323 Gatekeeper. Generalmente se instalan Softswitches adecuados para el tipo de servicio que se quiera ofrecer 15, por ej.: 15 Los nombres utilizados guardan relación directa con las categorías de las centrales tradicionales que están diseñados para reemplazar.

38 37 Equivalentes clase 4 Los switches Class 4 sustituyen a las centrales de larga distancia (centrales interurbanas o internacionales) e incluyen funcionalidades como 0800 y tarjetas de discado pre-pago. Equivalentes clase 5 Los switches Class 5 se sitúan en lugar de las tradicionales centrales locales para servicios residenciales y clientes empresariales. Telefonía sobre Internet ideales para ofrecer servicios de telefonía básicos de muy bajo costo sobre Internet, la idea de estos servicios es ofrecer llamadas internacionales con costos y tarifas muchos más bajas. Equivalente conmutadores para celular equivalente a los switches responsables por redes móviles. Tipos: Existen al menos dos posibilidades: Programables las aplicaciones de control de llamadas son provistas por otras compañías a través de: interfases de entrada, protocolos de control de llamadas o una interfase de programación aceptada por la industria (como por ej. JAIN JCC o Parlay) Integrados la lógica del servicio está completamente integrada con el Softswitch (por ej. los servidores de facilidades de Softswitches importantes). No existe interfase estándar entre el Softswitch y el servidor de facilidades. Parámetros: Los parámetros más importantes en su ingeniería son: Capacidad de establecer llamadas se mide en intentos de llamada en la hora más ocupada (BHCA busy hour call attempts) Interoperabilidad debe soportar ambientes en los que convivan Media Gateways y otros Softswitches de múltiples vendedores. Disponibilidad se debe contar con elementos redundantes con capacidades a prueba de fallas. 5.I-A.3 Media Servers En las redes de circuitos conmutados las innovaciones en cuanto a servicios se logran generalmente desarrollando una solución adyacente. Estas soluciones habitualmente presentan interfases hacia la red de circuitos, tal como si estas fueran un cliente más, y proveen de esta forma capacidades avanzadas para control de llamadas y procesamiento de voz. La intención inicial de crear arquitectura de red para voz modular, se enfoco principalmente en recrear estos servicios de voz básicos en una red de paquetes. La realidad actual indica, que estos Media Servers emergen como una posibilidad de brindar servicios innovadores de valor agregado, con una flexibilidad adicional de poder brindar servicios a sesiones multimedia provenientes tanto de redes de paquetes como de circuitos. Las capacidades de estos servidores incluyen: Anuncios la reproducción de anuncios de voz que pueden ser codificados en una gran variedad de formatos (por ejemplo reproducir un anuncio grabado en un formato, en otro formato dependiente de la sesión establecida). Interactive voice response (IVR) permite la reproducción de mensajes y detección de tonos DTMF por parte de la aplicación. Conferencia consiste en la interconexión simultánea de N usuarios en una misma conversación. El número de partes no está explicitado ni acotado, pero habitualmente está entre 3 y 20. Correos de voz y fax da la posibilidad de poder guardar o reproducir mensajes, faxes o correos electrónicos, en o desde algún lugar de la red. Sintetización de voz (TTS) típicamente utilizado para aplicaciones donde es imposible utilizar mensajes pre-grabados, como por ejemplo lectura de correos electrónicos. Reconocimiento de voz es la habilidad de reconocer las características del habla, pudiendo ser posible tanto el reconocimiento de palabras o frases, como la identidad de una persona por medio de su voz. Tipos: Actualmente, los Media Servers son muy utilizados en las redes de circuitos y están evolucionando hacia las redes de paquetes para poder interactuar con Softswitches y Media Gateways. Los Media Servers pueden ser controlados directamente por el Softswitch, o también por un servidor de aplicación. La flexibilidad de estos servidores es la razón principal por la cual son utilizados para imponer nuevos servicios. Entre los tipos de Media Servers desarrollados se encuentran: Nodo de servicios/periférico inteligente provee procesamiento multimedia (IVR, conferencia, casilla de voz, TTS, fax) y conmutación. Habitualmente por cada conexión se diseña un recurso de IVR/mensajería, y menos de uno para el resto. Conmutador programable provee capacidades de conmutación escalables, así como servicios de mensajería básicos (típicamente se suele proporcionar servicios de IVR/anuncios para cada conexión). Speech server proporciona interfases con capacidades vocales simples, como por ejemplo TTS para acceso al contenido de correos electrónicos o Internet. Aquí también se suele asignar un recurso por usuario. Servidores de conferencia multimedia provee servicios de voz y video conferencia, para conferencias en uno o varios sentidos (esto es, como conferencias normales de 3 a N participantes, o tipo broadcast donde uno habla y todos los demás escuchan, o cualquier combinación de estas). Servidores de anuncios es el responsable de proporcionar los anuncios, la detección de tonos y conferencia de tres para Softswitches clase 4 y 5. Se

39 38 CAPÍTULO 5. REDES CONVERGENTES suele asignar por conexión un recurso de anuncios, tonos y menos de uno de conferencia. Los Media Servers pueden ser diseñados para concentrarse en una única tecnología de procesamiento, o para proporcionar todas las tecnologías. Este ultimo integra todos los tipos de procesamiento de voz avanzados en un único servidor, lo que proporciona un modelo de diseño de red mucho más sencillo. También hay que tener en cuenta que si bien el diseño de estos MS pretende dar independencia de los proveedores más importantes (por medio del uso de una interfase de control estándar), este objetivo es aun difícil de alcanzar debido a lo inmaduro del proceso de estandarización de las interfases. Parámetros: Los parámetros a tener en cuenta para la elección de Media Servers son: Funcionalidad las capacidades de soportar servicios básicos (IVR y anuncios) y/o servicios avanzados (TTS y reconocimiento de voz). Capacidad de conexión número de conexiones posibles (mínimo y máximo). Capacidad de conexiones cruzadas la flexibilidad para establecer conexiones internas entre puertos (estas pueden ser circuitos-circuitos y/o circuitos-paquetes). Capacidad de recursos el número de recursos por puerto para procesar flujos multimedia. Disponibilidad nivel de confianza del equipo. Capacidad de establecer llamadas el número de intentos de conexión en la hora más ocupada que pueden ser terminados y originados en un Media Server. Por más información ver [10] 5.I-B Protocolos de Control La forma en que interactúan estos elementos dentro de una red convergente se puede visualizar en el diagrama de la Fig Fig Protocolos de control de elementos de las NGN Como se ve en la Fig. 5.6, se pueden separar en 5 tipos los flujos de control entre los elementos de esta red: Call control paths IN control paths Gateway control paths Media control paths Application programming interface (API) paths 5.I-B.1 Control de sesión (Call control) Se agrupan aquí las habilidades de un elemento de la red para establecer llamadas (o trayectos de llamadas). Una llamada en el contexto de redes convergentes, hace referencia al establecimiento de N flujos de contenido (N 2 para tener flujos full duplex), donde cada flujo puede transportar desde voz, hasta audio y video simultáneamente. Hay dos tipos de control de llamada: First-party cuando la parte que solicita el establecimiento de la llamada participará como miembro en la llamada. Third-party cuando el elemento que solicita el establecimiento de la llamada actúa solamente como intermediario, y no participará activamente en la llamada. Este tipo de control puede ser utilizado por ejemplo en servicios como los call centers, donde las llamadas entrantes se conectan a los agentes por parte de Servidores de Aplicación que no participan en las llamadas. Los dos protocolos más usados para realizar llamadas en una red de paquetes son H.323 y SIP. H.323 Es el protocolo de control de llamadas basado en IP más pretencioso y extendido. Sin embargo, H.323 no es un único protocolo, sino que es una colección de protocolos integrados que permiten efectuar señalización, registro, control de admisión, seguridad, intercambio de datos entre dominios y transporte. La terminología especifica de H.323 incluye términos como terminales y gateways, algunas entidades como ser unidades de conferencia multipunto y Gatekeepers. La primera versión de H.323 fue estandarizada por ITU en Su objetivo original fue las comunicaciones de voz y video en LANs. Así, la versión 2 fue liberada en 1998, y una de sus características era el rápido procedimiento de establecimiento que corregía el largo tiempo de establecimiento que habían experimentado hasta entonces los usuarios. La arquitectura de H.323 fue heredada de los protocolos de conmutación de circuitos, y como tal, algunos creen que puede ser muy compleja como para permitir aplicaciones innovadoras en las redes convergentes. 16 Session Initiation Protocol (SIP) Resultó de un estándar propuesto (RFC 2543) por el IETF (Internet Engineering Task Force) en 1999, y hereda la mayoría de sus conceptos de los protocolos de correo electrónico y los utilizados para navegar en Internet (SMTP 16 Ver estudio mas detallado de H.323 en la sección 8.IV.

40 39 y HTTP respectivamente). SIP tiene sus orígenes en el grupo de trabajo de IETF MMUSIC, que se concentro en el control de sesiones multimedia ( multimedia session control ), definiendo el anuncio, la dirección y la coordinación de múltiples sesiones, usuarios y contenidos (por ej. audio y video). MMUSIC fue encargado de diseñar y especificar 3 protocolos que llevaran a cabo estas funciones, y asegurar interoperabilidad a nivel de sesión entre diferentes implementaciones de teleconferencia. Session Initiation Protocol (SIP) Session Description Protocol (SDP), que es usado actualmente por SIP y por algunos protocolos de control entre Media Gateways Session Announcement Protocol (SAP) definido en RFC 2974 pero no muy usado actualmente. Las actualizaciones de SIP se presentan en RFC2543bis, siendo esta, una versión casi compatible con la anterior. El grupo de trabajo de SIP de IETF también documentó un método por el cual este encapsula señalización ISUP en el cuerpo de un mensaje SIP. Este método es habitualmente conocido como SIP-T (SIP for Telephony). Debido a sus raíces en IP, su popularidad crece entre los proveedores centrados en la innovación de servicios. SIP a sido identificado como la base para los protocolos utilizados por los sistemas movibles de 2,5 y tercera generación I-B.2 Control de facilidades de red inteligente (IN Control) Los servidores de facilidades se comunican con las centrales y los Softswitches a través de disparadores de control (Inteligent Networks control triggers). Estos disparadores generalmente habilitan tres tipos de control para servicios: Third-party call control (como se definió anteriormente). Traslación de datos (obtención del numero discado de acuerdo con el nombre, ruteo de llamada de acuerdo a la ubicación de donde se disco un servicio 0800). Control de facturación (por ej. en llamadas con cargo revertido o sin cargo). Algunos ejemplos básicos de estos disparadores incluyen los eventos de notificación de inicio y fin de llamada. Muchos de los Softswitches ya implementan estos protocolos de control logrando así los objetivos de innovación y ubicuidad. El más generalizado de los protocolos de control es el INAP (Intelligent Network Application Part), que es parte de la familia de protocolos de aplicación de SS7. 5.I-B.3 Control de Gateways (Gateway Control) En la serie H de estándares de la ITU-T, se define que los Gateways suministren tanto señalización de llamada como traducción del flujo de contenido entre las terminales basadas 17 Ver secciones 8.V y 8.IV por más detalles, incluyendo sus capacidades y limitaciones. en H.323 y otros tipos de terminales, incluyendo los POTS de las redes de circuitos conmutados. Sin embargo, como ya se ha mencionado antes, la industria ha preferido en muchos casos descomponer estos gateways monolíticos en varios (como ser Gateways señalización, Media Gateways, y Media Gateway Controllers), obteniendo así la posibilidad de escalar las redes de acuerdo con sus necesidades, y permitiendo obtener diferentes productos de diferentes proveedores. Es entonces, que se crean los protocolos de control de Gateways (gateway control), que permiten crear Media Gateways más simples y centralizar la inteligencia de la red en los controladores de Gateway (también llamados Call Agent o Softswitch). Estos controladores instruyen a los Media Gateways sobre las acciones a realizar, como por ejemplo, establecer o terminar conexiones, realizar traducción de contenidos o realizar tareas rutinarias como reportar estadísticas. Un caso extremo de este tipo de señalización (visto en 5.I-A.1) ocurre en algunos tipos de CPE de usuarios como los IAD, los que funcionan como si fueran Media Gateways pudiendo recibir información del Softswitch para realizar las funciones nombradas anteriormente. Con respecto a que protocolos adoptar, la industria se ha concentrado alrededor de dos posibilidades: Media Gateway Control Protocol(MGCP) que se ha adoptado como le estándar de hecho. H.248/Megaco como estándar aprobado por ITU y IETF. También se puede mencionar como sus antecesores a SGCP (Simple Gateway Control Protocol), IPDC (Internet Protocol Device Control), y MDCP (Media Device Control Protocol). Ambos, MGCP y H.248/Megaco controlan el establecimiento y finalización de conexiones entre los Media Gateways, como se vera más adelante, la principal diferencia entre ellos es la forma como modelan las conexiones entre los gateways. Por más información ver [11] 5.I-B.4 Control de Media (Media Control) Este es un método específico de control, usado entre elementos de la red especializados en el procesamiento de contenido. Incluye por ejemplo, instrucciones para reproducir y grabar archivos de voz, detectar y generar tonos, establecer conferencias entre N partes, habilitar las funciones de TTS, Reconocimiento de voz, etc. Tradicionalmente estos protocolos de control (entre el control central y los periféricos) de las centrales fueron propietarios de cada fabricante. Con el surgimiento de las llamadas redes convergentes se pacta la creación de un estándar abierto que permita incluir en una red elementos de distintos fabricantes. Sin embargo, a sido justamente esta el área que a tardado más en madurar en cuanto a estandarización, y por esto han aparecido en la industria 5 ideas diferentes de como implementarlo: Extensions to Media Gateway Control Protocols

41 40 CAPÍTULO 5. REDES CONVERGENTES Extensible Markup Language (XML) Java Technology Intelligent Network Media Control Streaming Media Control Protocols 5.I-B.5 Application Program Interface (API) Otra parte de la industria se ha dedicado a desarrollar APIs de ruteo, facturación, control de llamadas y control de contenidos para servidores de facilidades y aplicación. El éxito de las APIs radica principalmente en que estas permiten: Lógica del servicio independiente de los protocolos, arquitectura y elementos de la red. Servicios escalables que permiten organizar la red como una estructura central única, o una completamente distribuida permitiendo un ahorro significativo (ya que no hay necesidad de realizar cambios en esta). Actualmente la mayoría de las APIs están especificadas y cubren todas las necesidades básicas de las redes convergentes. De todos modos existe la posibilidad de que cada proveedor desarrolle las suyas propias de acuerdo con sus necesidades. Por más información ver [10], [12], [13], [14]. 5.I-C Transporte de señalización y contenido. Hasta ahora no se ha hecho mención a la forma como se realiza el transporte de señalización y de contenido entre puntos de la red. A continuación se tratará en forma breve estos dos puntos. 5.I-C.1 Transporte de señalización Concebido para transportar la señalización de las PSTN (señalización basada en paquetes, por ej. ISDN, SS7, V5.2, etc.) sobre redes IP, el grupo de trabajo SigTran (Signaling Transfer) de IETF desarrollo un método de transporte denominado SCTP (Stream Control Transmission Protocol). Actualmente, este método permite no solo transportar la señalización generada por las PSTN, sino que se generalizo para poder realizar un transporte transparente de cualquier tipo de señalización basada en mensajes como los utilizados por las redes convergentes (incluido SIP y H.248). Entre los beneficios de SCTP se encuentra su capacidad para: Entrega secuencial de los mensajes de usuario que se encuentran en varios flujos. Entrega ordenada de mensajes de usuarios individuales (de modo similar a UDP). Incluir varios mensajes de usuario dentro de un solo paquete SCTP. (Opcional) Tolerar fallas a nivel de red a través de el uso múltiples conexiones. Monitoreo constante de los enlaces para detectar fallas inmediatamente. Fig Diagrama representativo del funcionamiento de SCTP Las capas de adaptación definidas por el grupo de trabajo para realizar el traslado de la señalización de la PSTN (en realidad son protocolos que operan sobre SCTP), son: ISDN Q.921 User Adaptation Layer (IUA) utilizada para el transporte de señalización ISDN Q.931. MTP2-User Peer-to-peer Adaptation layer (M2PA) simula un enlace SS7 sobre IP. Es una forma muy efectiva en costo para agregar redundancia o hacer crecer los enlaces de un nodo SS7. MTP3, User Adaptation Layer (M3UA) utilizada para el transporte de protocolos SS7 de alto nivel (principalmente ISUP y SCCP) que utilizan MTP (la capa de transporte original de SS7) SCCP User Adaptation Layer (SUA) utilizada para el transporte de protocolos SS7 (por ej. TCAP) que utilizan SCCPSS7. No pueden ser usados para control de llamadas pero pueden ser utiles para realizar transacciones como por ej. consultas en bases de datos. MTP2, User Adaptation Layer (M2UA) utilizada para el transporte de protocolos de capa de enlace de MTP-SS7. Se usa principalmente por los elementos de la red que tienen mecanismos de direccionamiento tanto por SS7, como por IP. Permite por ej., terminar enlaces SS7 con la misma dirección SS7 en diferentes ubicaciones de la red. También existe otro protocolo definido llamado IPlink que tiene la misma funcion que M2PA pero que no utiliza SCTP.

42 41 En su lugar este establece un enlace SS7 virtual sobre TCP/IP. 5.I-C.2 Transporte del Contenido El verdadero encargado de llevar el contenido paquetizado de las sesiones abiertas por cualquiera de los mecanismos mencionados anteriormente (menos cuando se utiliza AAL1 o AAL2 en redes ATM), se denomina RTP (the Real- Time Transport Protocol), y fue diseñado para realizar el transporte (de punta a punta de la red) de los servicios de comunicaciones que requieren transporte en tiempo real (por ej., voz y video). La calidad del transporte de datos es monitoreada por RTCP (Real-Time Control Protocol). Ambos, RTP y RTCP, fueron diseñados para ser implementados independientemente de capa de red subyacente (ej., UDP/IP, MPLS, o ATM). Es importante destacar que RTP no se encarga de realizar ningún tipo de reserva de recursos que asegure una determinada calidad de servicio (QoS), y por tanto otros protocolos tienen que ser utilizados para esto: RSVP (Resource Reservation Setup Protocol) reserva recursos en los routers para poder brindar la calidad de servicio requerida por la sesión. MPLS (Multi-Protocol Label Switching) ver sección 7.II. ATM AAL2 ver sección 8.VII. 5.I-D Resumen de protocolos utilizados en redes convergentes. En la Fig. 5.8 se muestran específicamente los protocolos que habitualmente se están usando en este tipo de redes. BICC, provee una separación funcional entre los protocolos de señalización de la llamada (call control) y los protocolos de señalización del portador (bearer control). Es decir que permite una independencia total del protocolo de transporte utilizado para la señalización (SS7), con el protocolo de la red portadora del mismo. Por ejemplo, se pueden iniciar y terminar llamadas entre PSTNs, utilizando señalización SS7 de principio a fin, mientras que en realidad esta pasa por redes IP o ATM (en forma transparente). SIP, es un protocolo de control de la capa de aplicación,. Este puede establecer, Modificar y terminar sesiones. SIP ofrece escalabilidad (H.323 no), baja latencia, mayor velocidad, y contabilidad de Carrier-Class. SGCP, fue el primer protocolo hecho publico, que buscaba ampliar las capacidades de los gateways de VoIP. En general estos intentos para extender las capacidades eran muy simplistas y terminaban chocando en las realidad con las características de SS7. Su evolución y unión con otros protocolos dio como resultado el surgimiento de MGCP. MGCP y MEGACO / H.248, son protocolos de control de llamadas que se basan en la idea de un control de llamadas separado de los gateways, que reside en entidades de control conocidas como Call Agents o Media Gateways Controlers (MGC). 18 Real-Time Transport Protocol (RTP), también conocido como RFC 1889 de IETF, define un protocolo de transporte para aplicaciones de tiempo real. Específicamente, RTP provee transporte para los flujos de audio o media, y es el utilizado por todos los protocolos de VoIP. Ver Refs. [15] y [16] Con el diagrama de la Fig. 5.9 se pretende clarificar las ideas sobre los protocolos usados para intercomunicaciones entre los diferentes elementos de una NGN. Fig Protocolos usados en redes NGN SIGTRAN, como ya se vio SIGTRAN representa un grupo de protocolos que permiten la interacción entre nodos de Señalización SS7 y nodos IP. A estos efectos, actúa como traductor de idiomas y medios simultáneamente. Fig Protocolos y partes en una red convergente. Si bien éste no muestra todas las posibilidades ni todos los protocolos, muestra los más usados y sus usos más comunes. 18 Se hace un estudio mas detallado de H.248 en la sección 8.III

43 42 CAPÍTULO 5. REDES CONVERGENTES

44 Capítulo 6 Red de Acceso Resumen En este capítulo se estudian las tecnologías de red de acceso más extendidas. Luego se realizan análisis comparativos de las más adecuadas, y se decide la tecnología que finalmente se utilizará para diseñará esta etapa de la red. LA decisión de la tecnología de red de acceso es la más importante de los factores de éxito o fracaso de una nueva empresa de telecomunicaciones, ya que esta deberá asegurar las características necesarias para poder brindar los servicios actuales y los que se quieran dar en el futuro. Asimismo es precisamente la red de acceso en donde puede ser necesario realizar la mayor inversión, por lo que esta deberá tener una vida útil que permita, por lo menos, amortizarla. Por esto se analizarán en las próximas secciones varios factores que habrá que tener en cuenta para hacer esta elección de forma que mejor se adecúe a las características de la ciudad y a los requerimientos en cuanto a servicios. Fig Espectro ADSL Como se muestra en la Fig. 6.2, este arreglo del espectro ADSL presenta incompatibilidades con el de los servicios ISDN. 6.I ESTUDIO DE TECNOLOGÍAS 6.I-A Tecnologías alámbricas 6.I-A.1 Red de par telefónico (ADSL) Esta tecnología permite obtener un mejor aprovechamiento del par de cobre usando la porción del espectro no usada para telefonía. De acuerdo con el estándar, la división del espectro podrá ser efectuada de 2 formas distintas: Frequency Division Multiplexing (FDM), que asigna una banda para el upstream y otra para el downstream (Fig. 6.2). - 0 a 4kHz Telefonía POTS - 30 KHz. a 138kHz Upstream de datos kHz a 1104kHz Downstream de datos. A su ves en estos canales usa TDM para de este modo tener uno o mas sub-canales. Cancelación de Eco, que superpone la banda del upstream sobre la del downstream, y son separadas localmente en el equipo a través de la técnica de cancelación de eco que también es usada en los Módems V.32 y V.34. Fig Superposición de espectros ADSL-ISDN Por lo que existe también una variación del estándar permite brindar servicios de ADSL sobre líneas ISDN. Esta se presenta en la Fig. 6.3, y coloca la banda de upstream entre 300 y 700 KHz, y la de downstream por encima de los 1000 KHz. En un principio se usaron dos esquemas de modulación diferentes: CAP (Carrierless Amplitude Phase Modulator) y DMT (Discrete Multitone Technology), finalmente se adoptó como estándar el DMT por ANSI e ITU-T. (Ver Apéndice G) DMT: Esta tecnología divide la porción del espectro entre 0 y 1104kHz.en 256 subcanales de kHz. 43

45 44 CAPÍTULO 6. RED DE ACCESO En la Fig. 6.5 se muestra la arquitectura típica de un servicio ADSL. Fig Arquitectura típica de un servicio ADSL Fig Espectro ADSL Estos canales son usados de la siguiente forma: Canal 1 POTS Canal 2 al 6 (sin uso) Canales 7 al 38 upstream. Canales 39 al 256 downstream. En cada canal se modula una portadora en forma independiente con esquemas de codificación que permiten enviar hasta 15 bits por Hz. En las frecuencias bajas donde hay una buena SNR se usan típicamente hasta 8 bits/hz y en la porción alta hasta 2 bits/hz. En el proceso de selección del número de bits/hz usado en cada subportadora se tiene en cuenta: La potencia usada en el canal. La relación señal ruido en esa banda. Que el BER obtenido por canal sea similar. Ver Fig. 6.4 Se intercala entre el distribuidor principal y la PSTN un splitter que tiene como función separar la porción del espectro dedicado a la voz de la porción dedicada a datos. De este splitter salen conexiones para la PSTN y para un equipo llamado DSL Access Multiplexer (DSLAM) que provee el acceso a la red de datos. Del lado del usuario se utilizan también splitters o microfiltros (pasivos y de bajo costo) para evitar interferencias desde el aparato telefónico del abonado hacia la banda reservada a datos y viceversa. Por lo general, los DSLAMs usan una red ATM para el transporte; desde estos equipos se establecen circuitos virtuales permanentes (PVCs) hacia gateways de voz y/o datos. Esta tecnología junto con la posibilidad del unbundling permite a un operador entrante establecerse rápidamente evitando los altos costos de un nuevo cableado en la red de acceso. En Montevideo el operador Incumbente (ANTEL) cuenta con una planta externa con un largo medio de líneas de 4 Kms. con diámetros que varían entre 0.4 y 0.7 mm., con un promedio de 0.5 mm. Estos largos y diámetros de línea permitirán obtener (Tab. 6.I) una velocidad promedio de 6.3Mbps en el downstream lo que es suficiente para brindar servicios de telefonía, acceso a INTERNET y vídeo comprimido. Distancia (m) Downstream (Mbps) TABLA 6.I VELOCIDAD VS. DISTANCIA EN EL SERVICIO ADSL (CABLE DE 0.4 MM DE DIÁMETRO-POLYETHILENE INSULATED) Fig Relación señal ruido en cada banda El entrenamiento de la línea ocurre al conectar el módem o cuando el BER baja de cierto valor preestablecido, este entrenamiento toma aproximadamente 12 s. Arquitectura de red A continuación se brinda una descripción de los servicios posibles. Telefonía VoDSL con compresión (G.711, G726, G729) sobre IP o directamente voz sobre ATM (AAL2).[17] Del lado del abonado es necesario un CPE del tipo IAD (Integrated Access Device) que provea interfaces

46 45 analógicas para POTS e interfaces Ethernet para datos. Ver Fig Para poder conmutar llamadas entre clientes de la red de VoDSL es necesario un Softswitch. Para posibilitar además la interconexión con la PSTN o red del Incumbente es necesario un Voice Gateway (VGW) que maneje la señalización adecuada. Ver Fig directamente MPEGoATM o MPEGoIP facilitando la distribución de vídeo en la casa del abonado mediante tecnologías de HOMEPNA, inalámbricas o con cableado estructurado. Para la difusión del vídeo es posible usar directamente multicast de ATM o IP Multicast. 6.I-A.2 Red HFC de CaTV (DOCSIS) La arquitectura de red se basa en anillos de fibra óptica que interconectan nodos. Ver Fig Fig Modelo de voz sobre ADSL Fig Una forma de brindar VoDSL usando AAL2, es crear PVCs que comienzan en el IAD y terminan en un Voice Gateway, de forma de reservar el ancho de banda en forma permanente. Ver Fig La otra posibilidad es crear SVCs entre el IAD y un Voice Gateway (u otro IAD) en el momento de establecer la comunicación. Estas posibilidades dependen de la configuración y de las facilidades de los equipos disponibles. PVC en líneas DSL Accesos a Internet o datos Típicamente se ofrecen en estos paquetes, accesos de 256/128kbps o 512/128kbps. sobre la interfaz ethernet con PPPoATM o PPPoE o con IP/Ethernet/ATM (IP fija). Video Para poder brindar servicios de vídeo se almacena el contenido en servidores de vídeo en formatos MPEG. Con esta tecnología no es redituable (por el momento) brindar Video on Demand (VoD) debido a los altos costos de transporte y/o de servidores replicados de vídeo. Es posible si brindar servicios de NearVoD (tipo PPV) con compresión MPEG. En este caso es posible enviar Fig Arquitectura CATV Cada nodo alimenta a una red de cable coaxial que da servicio a 500 casas en promedio, estas redes de coaxial pueden ser a su vez segmentadas con el uso de amplificadores de RF. Esta tecnología permite distribuir señales de televisión analógica, digital y datos en forma bidireccional, lo que es usado por ejemplo para brindar servicios de acceso a INTERNET. Para hacer posible el transporte bidireccional de datos hay que realizar una actualización del sistema de cable tradicional (actualmente instalado en Montevideo). Los servicios de datos se proveen usando un dispositivo llamado Cable Módem en el cliente y un dispositivo llamado Cable Modem Termination Sistem (CMTS) en el Head End. Se ha adoptado un estándar para el cable módem llamado DOCSIS (Data Over Cable Service Interface Specification) desarrollado por un consorcio formado por la industria del cable, lo que provocó que el estándar haya sido desarrollado más rápidamente que en los procesos normales de institutos de estandarización. DOCSIS ha demostrado ser estable y ya se han certificado más de 70 módems. El sistema permite las comunicaciones punto a punto, usando VPN (Virtual Private Networks); es decir una conexión punto a punto virtual, donde toda la información transita encriptada por el medio compartido y a su vez cada nodo de la punto a punto solo responde a solicitudes de su nodo correspondiente. En el upstream (hacia el CMTS) se utiliza como tecnología de acceso TDMA y FDMA con modulación QPSK o 16QAM soportando múltiples canales, que van desde 320 Kbps (QPSK a 160 Ksym/sec) hasta Mbps (16 QAM a 2560 Ksym/sec) por cada canal de 6 MHz. [15].

47 46 CAPÍTULO 6. RED DE ACCESO En el downstream se utiliza TDM con modulación 64 o 256QAM, se utiliza una subcapa de convergencia MPEG2 y se pueden alcanzar velocidades de 100Mbps. El estándar 1.0 fue diseñado para un servicio de mejor esfuerzo, proveía de mecanismos para garantizar el acceso a los canales de upstream, también ofrecía mecanismos básicos de calidad de servicio por módem y encriptación DES de 56 bits. El estándar 1.1 agregó extensiones de QoS. Es importante destacar que al ser un medio compartido, el cable necesita tener funciones de encriptado (por ej. DES) para mantener la confidencialidad de la información de cada usuario. El último estándar de la industria a la fecha es el DOCSIS 2.0, este estándar introduce un incremento en el throughput del upstream usando TDMA con modulación QAM 256 permitiendo, en teoría una utilización de 8bits/Hz (alcanzando 6.5 bits/hz en situaciones reales.). Una red de cable típica ocupa desde los 5MHz a los 750MHz y se divide aproximadamente en 112 canales de 6MHz, los cuales se destinan a brindar los distintos tipos de servicios como se muestra en la Figs. 6.9 y método utilizado como del fabricante de los productos (no está estandarizado). [16] [18]. A modo de ejemplo se listan algunos de los proveedores existentes en el mercado detallando las principales características de sus productos: ADC Permite hasta 233 conversaciones simultaneas por HDT (Host Digital Terminal) en un canal bidireccional de 6 MHz Hacia el lado de la central se ofrecen 24 interfaces E1 (GR-303) Utiliza OFDM (Ortogonal Frequency Division Multiplexing), que permite mas conversaciones de voz sobre el mismo canal de 6 MHz y con mejor tolerancia al ruido (sobre todo para bandas de upstream donde son mas inmunes al ruido los amplificadores). Tiene equipos de usuarios que manejan desde 2 hasta 32 POTS, e incluyen canales de datos desde 512kbps hasta 8 Mbps. Fig División típica en canales de la señal de CATV Aris Interactive Permite colocar 24 canales de vos en bandas de 1,8 MHz bidireccionales. Del lado de RF del HDT acepta hasta 1344 canales de vos en simultaneo. El lado de switcheo posee hasta 56 DS1s, permitiendo con una concentración de 5:1, brindar servicios a 6720 usuarios por cada HDT Utiliza tecnología TDM (los grupos de líneas pueden ser movidos de frecuencia para evitar la interferencia, poro a diferencia de OFDM, siempre tienen que ser de a grupos de líneas). Los NID (Network Interface Device) tienen desde 2 a 12 POTS y soportan servicios CENTREX. (También puede estar disponible un Universal Acces Port para servicios como ISDN, etc.). Otra opción es usar VoIP con unas cajitas que traen hasta 4 líneas de VoIP con interfaces RJ-11. El HDT envía las llamadas a switches digitales o a Gateways de acceso. Estos Access gateways soportan hasta 672 llamadas simultaneas y se conectan al backbone IP por interfaces 100BaseT. Fig Posibles uso de los canales de la señal de CATV Servicios soportados: Telefonía En términos generales, lo que se hace es dedicar parte del espectro para estos servicios incluyendo hardware adicional tanto en el cliente como en el headend. En el lado del cliente se entrega uno o varios conectores RJ11(dependiendo del numero de líneas contratadas), mientras que del lado del headend se entregan enlaces E1 para conectar con centrales telefónicas. Por otro lado, el tamaño del espectro que se ocupe, así como la cantidad de canales a transportar, dependen tanto del Tellabs Pone 30 DS0s en canales de 1,5 MHz de downstream y 1,9 MHz de upstream. El HDT puede manejar hasta 672 conversaciones simultaneas. Con concentración 6:1 se pueden brindar 3960 líneas de voz por cada HDT. Utiliza tecnología TDM. Las NID manejan de 2 a 12 líneas. Existen equipos alternativos que permiten utilizar DS0 para dar acceso a datos de hasta 2 Mbps. Estos salen del HDT a través de interfaces 10BaseT.

48 47 Accesos a Internet o datos. En una configuración típica pueden usarse 6 canales de 6MHz en el upstream (5-40MHz) codificados en QAM16, 30 canales de 6MHz para el downstream de datos y para vídeo digital ( MHz) codificados en QAM64 o QAM256. De estos 30 canales se usan 20 para dar servicios de 10Mbps y 3 para dar servicios de 100Mbps, (en ambos casos compartidos). Vídeo Como se ve en la Fig el espectro se puede dividir de la siguiente forma: Vídeo analógico (20 canales NTSC). 20 canales para 200 programas de vídeo comprimido (SDTV). 10 canales para 20 programas de HDTV. 20 canales para 200 programas de VoD (en canales de datos nombrados anteriormente). 6.I-A.3 Red de fibra óptica (FTTH) Esta tecnología es considerada como la solución ideal desde la aparición de la fibra óptica como medio de comunicación debido a sus características físicas y al enorme ancho de banda disponible. Existen actualmente diversas implementaciones de esta tecnología, que se conocen como PON (Passive Optical Networks). Estas son ATM-PON (APON) (ver Fig. 6.11) y Ethernet-PON (EPON) [19]. APON está estandarizada por ITU-T/FSAN según la especificación G.983.1, mientras que EPON es una de las soluciones consideradas dentro de las especificaciones IEEE Ambas utilizan CWDM y TDM para brindar una comunicación punto a punto bidireccional, y mantener sus estructura de marcos (frames) para el upstream y el downstream. APON utiliza celdas ATM y permite velocidades de Mbps (upstream y downstream), con posibilidades de llegar a Mbps de downstream. Mientras tanto, EPON permite alcanzar velocidades de upstream y downstream de hasta 1 Gbps (escalable a 10 Gbps). Además utiliza ethernet como protocolo de transferencia obteniendo los siguientes beneficios sobre APON: Menor overhead Mayor ancho de banda Menor costo Mejores posibilidades de servicios broadband Mejor integración con con WANs basadas en Ethernet. Fig FTTH Fibra hasta el hogar civil que implica el trabajo (levantar veredas y calles, canalizar, permisos de construcción, etc.).de la misma forma los equipos de abonado necesarios para instalar FTTH son actualmente un poco elevados, aunque están bajando junto con el avance de esta tecnología. Tal vez, el segundo problema que atenta contra la instalación de FTTH es que actualmente no hay tantas aplicaciones o programas de contenido para llenar el ancho de banda que esta tecnología permite obtener. Esto quiere decir que se estaría haciendo una gran inversión, y no se obtendrían ganancias adicionales a las que hoy se obtienen con redes ya instaladas, lo que indudablemente hace que en la actualidad esta tecnología sea inviable. No obstante lo dicho anteriormente, se debe destacar que todos esperan que con el paso del tiempo, el surgimiento de nuevas aplicaciones y contenidos, así como la caída de los precios, permitan que FTTH se convierta en una de las principales formas de acceso. Es por esto que casi todas las empresas que por algún motivo tienen que realizar obra civil en la vía publica (gas por cañería, electricidad, telefónicas, etc.), aprovechan para cablear fibra óptica en su camino, esperando poder obtener ganancias de esta en el futuro. Si bien las capacidades de las fibras son totalmente superiores sobre cualquier otra tecnología de acceso, existen varios factores que hacen que actualmente ningún proveedor en el mundo considere el cablear sus redes de acceso íntegramente con fibra, mas que para proyectos de prueba o soluciones a complejos residenciales. Una de estas razones, y tal vez la principal, es que el costo de construir una nueva red es gigantesco. Donde es importante destacar que este la parte mas importante de este costo no es la fibra es si, sino la obra

49 48 CAPÍTULO 6. RED DE ACCESO 6.I-B Tecnologías inalámbricas Puede implementarse sobre bandas públicas o licenciadas. Bandas licenciadas: En estas bandas algunas implementaciones permiten 2 Mbps de throughput por celda (usando un canal por celda). En una configuración típica se divide la zona en celdas de 6 sectores (de 60 cada uno), en sectores adyacentes se usan 6 MHz. canales de separación. Se usan también dos frecuencias una para el upstream (CSMA-CA) y otra para el downstream de datos ( FDD ), estas dos bandas tienen 100MHz de separación. Para compartir el ancho de banda se usa una sobreasignación en el aire hasta 90 o 100 usuarios de 64kbps lo que da un valor aproximado de hasta 3:1 de sobre-asignación. Fig I-B.1 MMDS Arquitectura de red inalámbrica Esta tecnología inalámbrica permite brindar servicios de banda ancha punto multipunto con grandes zonas de cobertura y tiempos de instalación bajos. Para el acceso pueden usarse distintas tecnologías: FDMA-conveniente para servicios fijos de gran ancho de banda. TDMA-para lograr la asignación dinámica del ancho de banda CDMA-para servicios de bajos anchos de banda y alta densidad. OFDM-cuando se presentan en la zona interferencias de fuentes discretas. Para el acceso dúplex se usa FDD o TDD. El radio máximo (típico) de cobertura ronda los 40kms. Necesita línea de vista. En caso de usarse configuraciones de multi-celdas típicamente el radio de cobertura baja a entre 10 y 15 Kms. En un caso típico la porción del espectro asignado ( GHz.) provee 32 canales de 6 MHz. Cada canal se puede dividir a su vez en 2 de 1 MHz., separados por una guarda de 3 MHz. obteniendo así 64 portadoras. Por lo general se usan 6 sectores por radio base. A cada sector de la radiobase se le asigna el mismo grupo de 3 canales MMDS (6 portadoras), se sincronizan luego los sectores adyacentes para que salten con un shift de 6 MHz. MMDS permite la distribución de vídeo analógico y digital además de voz y datos en los 22 Canales de 6MHz disponibles. 6.I-B.2 Spread Spectrum-Frecuency Hoping (SS-FH) Esta tecnología es usada principalmente (en Uruguay) para la distribución de datos (principalmente accesos residenciales y de PyMEs a INTERNET) aunque es posible también distribuir telefonía y realizar videoconferencias. Banda pública 2.4GHz ( MHz). En esta banda se usan canales de 1MHz. Con un total de 79 canales TDD (Time division duplex). En este caso los canales son half dúplex (se usa el mismo canal en transmisión que en recepción) por lo que las estaciones deben competir por los canales. No existe una guarda entre los canales ya que se hace Frecuency Hoping entre ellos. También se dividen las zonas en sectores y se pueden superponer hasta 18 sectores (trabajando en frecuencias distintas) para lograr una mayor cantidad de abonados por sector, este número se remite a 3 sectores (o niveles de celdas superpuestos). Sistema BreezeAccess El ejemplo estudiado de los sistemas WLL SS-FH es el sistema BreezeAccess de Alvarion. Se listan a continuación varias de las características de este sistema, y se muestra un diagrama esquemático de su arquitectura junto con la terminología propia. Características interesantes: Radio de la celda de 5 a 15 Km. Frecuencias 2.4 GHz/ GHz /4.2 GHz Velocidad: Máximo 3 Mbps por usuario. Esta es la capacidad de datos en el aire siendo el throughput de datos de usuario 2 Mbps máximo. Capacidad: un total de 54 Mbps por celda Sistema WLL broadband basado en paquetes IP, con parámetros de servicio que lo adecúan para datos y voz. Red de estilo celular, es decir la red consta de celdas múltiplex, cada una con varios sectores, y en cada uno de estos varias unidades de radio, una por cliente. El backbone es ethernet y puede ser construido sobre cualquier WAN, inalámbrica o no. Usa modulación FH-CDMA. Telefonía: protocolo ITU-T H.323. VoIP Hasta 720 llamadas telefónicas simultaneas por celda. Unas 7000 líneas con 0.1 Erlang. Este calculo es realizado usando H323 usando VAD 19. Para ingresar mas al detalle del sistema, se hace aquí una breve descripción de la arquitectura del mismo que está 19 Protocolo de compresión por detección de silencios.

50 49 formado por 3 módulos: CPE, BSE y NOC. Ver diagrama del sistema en la Fig CPE, Customer Premises Equipment. Es la unidad de usuario instalada en edificio del cliente. Provee conexiones 10BaseT y telefónicas. BSE, Base Station Equipment. Es la unidad instalada en la radio base y está compuesta por las unidades de acceso y sus equipos de control. Las unidades de acceso son una por sector y como máximo 18 por radio base. Se instalan en grupos de 6 por chasis. Estos chasis proveen alimentación, y sincronización de las unidades por medio de GPS. El tráfico de las distintas unidades de acceso es combinado en un switch Cisco, que se conecta con el BSE o NOC mas cercano a través de una conexión punto a punto fast ethernet (100Mbps). NOC, Network Operation Center, que es el edificio donde se encuentran los servidores, gateways, equipos de monitoreo, etc. Fig I-B.3 Satélite Arquitectura de la red de acceso BreezeAccess. Los sistemas de comunicación satelital se distinguen por sus características de cobertura global, capacidad inherente para broadcasting, flexibilidad de ofrecer ancho de banda a demanda y la posibilidad de ofrecer movilidad a sus usuarios. [20] Un sistema satelital consiste de un segmento espacial y un segmento terreno. El segmento terreno está constituido por gateway stations (GSs), NCC (Network Control Center), OCCs (Operation Control Centers). El segmento espacial se compone de satélites, que pueden ser clasificados como de orbita geoestacionaria (GSO) o de orbita no geoestacionaria (NGSO), que incluyen los MEO (Medium Earth Orbit) y LEO (Low Earth Orbit). GSO De este tipo son la mayor parte de los satélites que están actualmente en operación. A una altura de Km sobre el ecuador, su rotación alrededor de la Tierra coincide con la de esta, por lo que parece estar fijo en el cielo para un observador terrestre. Por estar a una gran altura, alcanza con solo 3 satélites de este tipo par cubrir toda la Tierra. Debido a la gran distancia son necesarias grandes antenas y potentes transmisores. Asimismo los retardos de propagación son significativos, y con un valor típico de ms se convierten en poco recomendados para tráfico en tiempo real. MEO Se encuentran a una distancia de la tierra entre los y km, con con un tiempo de retardo (en un salto) típico de ms. Por estar mas cerca de la superficie terrestre se pueden utilizar tanto antenas cono transmisores mas pequeños. Como contrapartida, son necesarios mayor cantidad de satélites para cubrir toda la superficie terrestre, ya que a esta altura las huellas de cada uno son mucho mas pequeñas. LEO Están localizados entre los 200 y 3.000km de altura. A esta altura los tiempos de retardo son comparables a los valores de enlaces terrestres, con valores típicos de entre 20 y 25ms. Como en los MEO, el tamaño de las antenas y los transmisores se puede reducir,y como contra, la cantidad de satélites tiene que ser aun mayor para obtener la misma cobertura. Bandas de frecuencias: Las bandas de frecuencias mas usadas en comunicación satelital son las: C (4-8 GHz), Ku (10-18 GHz) y Ka (18-31 GHz). Algunos satélites utilizan la banda C por lo que emplean grandes antenas con un diámetro medio de 2-3 m. La mayoría de los satélites de broadcast utilizan la banda Ku, este es el caso de las conexiones de Internet con downlink por satélite y uplink por un enlace terrestre (generalmente par telefónico). Las antenas necesarias tienen un diámetro medio de 45cm. Actualmente esta da la posibilidad de usar la banda Ka en ambos sentidos y con antenas mucho mas pequeñas. Esta banda ofrece mucho mas ancho de banda que la banda Ku pero presenta impedimentos ambientales como fading y atenuación por la lluvia. Según las recomendaciones de la ITU-T: Una conexión de un solo salto por satélite, incluso con un enlace entre satélites (ISL, inter-satellite link) de longitud moderada, introduce un retardo de transmisión en un sentido que no rebasa el límite recomendado de 400 ms. Sin embargo, un detenido análisis de las contribuciones adicionales al retardo probables debidas, entre otras cosas, al procesamiento de la señal digital (por ejemplo, acceso múltiple por división en el tiempo (TDMA, time division multiple access), interpolación digital de la palabra (DSI, digital speech interpolation), DCME, codificación a velocidades binarias de 32 kbit/s, 16 kbit/s y más bajas, regeneración digital, conmutación de paquetes, etc.), muestra que, en algunos casos, podría rebasarse el límite recomendado de 400 ms para el tiempo medio de transmisión en un sentido. [21]

51 50 CAPÍTULO 6. RED DE ACCESO Teniendo en cuenta los puntos analizados hasta el momento, concluimos que el satélite no cumple con varias de las características deseables para construir la red de telecomunicaciones objeto del proyecto (confiabilidad, grado de servicio, problemas con tráfico de tiempo real, etc.), por lo cual se descarta como opción a utilizar. 6.I-B.4 LMDS Local Multipoint Distribution Systems (LMDS) es una tecnología de arquitectura celular, que permite ofrecer conexiones de gran capacidad en forma flexible. Se caracteriza por ser cara para brindar servicios residenciales, resultando competitiva para la distribución de grandes anchos de banda. Este sistema realiza una bajada punto-multipunto a modo de broadcast, con una capacidad local de 34 a 38 Mbps por flujo. Mientras que el canal de subida (también denominado canal interactivo) realiza una conexión punto a punto utilizando diferentes tecnologías de acuerdo con la disponibilidad y demanda de ancho de banda. Esta puede ir desde pocos kbps hasta de 26 Mbps. En EEUU, LMDS utiliza 1,3GHz en la banda de 28 a 29GHz. Los países europeos en cambio, colocan estas frecuencias en distintas bandas, siendo la banda de 40,5 a 42,5 GHz la que presenta mayor capacidad. Es por esto que se pueden encontrar sistemas en diferentes bandas desde 24 GHz hasta 43,5 GHz. La operación en rangos de milímetros impone varias restricciones. Las precipitaciones provocan grandes atenuaciones que limitan el rango de operación a 3-5 Km (dependiendo de la zona climática y las frecuencias de trabajo). También se requiere visibilidad total para un correcto funcionamiento, siendo la principal restricción la atenuación causada por la vegetación. Esto implica que edificios cubiertos por la vegetación tengan que colocar antenas a grandes alturas, elevando también los costos de instalación. Por lo detallado anteriormente, con una radiobase solamente se logran coberturas de entre un 40 y un 70% dentro del rango, siendo que un servicio ofrecido al publico debería alcanzar, al menos, un 95% de cobertura. La superposición de celdas permite alcanzar índices de cobertura razonables pero a costa de tener una mayor cantidad de radiobases con un costo significativamente mayor. Si además se toma en cuenta que los equipos de abonado son significativamente mas caros que los utilizados por otras tecnologías de capacidades comparables, se puede llegar fácilmente a la conclusión de que se está ante una tecnología cara al compararla con otras. [22] Se presenta en la Tab. 6.II, un resumen de las principales tecnologías de acceso. 6.II VIDA PROMEDIO DE LAS TECNOLOGÍAS DE ACCESO 6.II-A Introducción El ciclo de vida de la tecnología de acceso es un factor de suma importancia que habrá que tener en cuenta al momento de su elección. Cada tecnología tiene un ciclo de vida, en el cual deberá (por lo menos) ser amortizado el valor de instalación de dicha red. Es de esperar que un nuevo operador no instale una red de acceso que por sus proyecciones en cuanto a clientes y ciclo de vida de la tecnología usada no pague la inversión realizada en ella. Aquí se considerarán los factores a tener en cuenta para estimar el tiempo de vida de cada tecnología. Esto permitirá decidir las tecnologías que sean factibles de ser utilizadas. 6.II-B Características principales Una tecnología está dentro de su vida útil, mientras se pueda brindar con esta los servicios que el proveedor y sus clientes esperan. En el momento en que haya que brindar un servicio que la tecnología de esta red no permita, se estará ante la necesidad de cambiar de tecnología, y se considerará entonces que ha expirado el tiempo de vida de la misma. Es necesario entonces que para estimar la vida promedio de una tecnología se contrapongan lo que se espera de esta en determinado periodo, con lo que se estime que esta podrá brindar en ese momento. En el caso de una red de acceso y sus tecnologías se espera que con el paso de los años esta cumpla con determinadas características en cuanto a: ancho de banda, características físicas, coexistencia con otros sistemas,flexibilidad, etc. Ancho de banda: Tanto los proveedores como los usuarios que utilizan servicios de datos (ya sea Internet o redes privadas) manejan expectativas en cuanto al ancho de banda que tendrán disponible, y los diferentes contenidos que podrán ofrecerse en determinado momento. Características físicas: Por ejemplo en el largo máximo que deberá tener el loop local para alcanzar una velocidad o una taza de error determinada. Coexistencia: Tal vez el ejemplo mas claro de esto sea lo que ocurre entre ISDN y ADSL en Europa, donde mucha gente ya acostumbrada a tener ISDN exige que ADSL mantenga su servicio de ISDN disponible. Flexibilidad: algunas tecnologías son creadas con características especiales para brindar algún servicio especifico, haciendo difícil que posteriormente se adapten nuevos servicios. 6.II-C Estudio de vida promedio de las tecnologías Para cada uno de los factores detallados anteriormente es posible estimar lo que se esperará, pero se considera que el de mayor peso y el más usado a la hora de hacer cálculos es el ancho de banda. Por esto se basará el análisis en esta

52 51 Nombre ISDN SDSL SHDSL (1o2 Pares) HDSL (2 pares) ADSL VDSL Costo-Red (U$S)) unbundling y coubicación unbundling y coubicación unbundling y coubicación unbundling y coubicación unbundling y coubicación FTTH por casa Costo Instalación (U$S) Tecnología Banda Velocidad Downstream (max) Velocidad Upstream (max) Servicios posibles infimo 2B1Q 10Hz - 80kHz 128kbps 128kbps Telefonía, datos videoconf B1Q kHz. 2.3 Mbps. Telefonía, datos videoconf. (1.7 kms. max) TC-PAM KHz. 2.3 Mbps 4.7 Telefonía, datos, videoconf. Mbps (2 kms. max) B1Q kHz. 2 Mbps. 2 Mbps. Telefonía, datos, videoconf. (3.5 kms. max) DMT /CAP kHz- 8 Mbps Mbps. Telefonía, datos, video 1.104MHz comprimido (3 kms.) (POTS) 138kHz MHz ISDN DMT/CAP 120kHz Mbps Telefonía datos, video- CABLE MO- DEM (HFC) unbundling y coubicación 500 por casa 250 FDM canales de 6Mhz, datos en DOCSIS TDMA-QAM- CDMA 500- DWDM, ETH ERNET, ATM SATELLITE 10 bill 1000 CDMA IP/ATM. 20,30MHz MHz (112 canales) canales de 10/100Mbps compartido (GEO y LEO) Ku (14/12GHz) 16kbps - 20Mbps MMDS 500 mil Canales de MHz, FH. Mbps HDTV (1.5, 0.3 km.) 10,24 Mbps Telefonía, datos, video analog, digital comp y HDTV.) 1Gbps 1Gbps Telefonía, datos, video (VoD, analog, HDTV, etc.) Ka (40/20GHz) 200 Mbps 20 Mbps Telefonía, datos, video (analog, digital, HDTV, etc) 16kbps - 2Mbps 2.1, 2.5, 2.7 GHz. 1Mbps. tip. Telefonía, datos y video analógico/digi-tal 50kms. max LMDS 1 mill >1000 TDM/TDMA 24 a 43.5GHz. 26Mbps. 26Mbps. Telefonía, Datos, Video. (Celdas de 3-5 kms. max) Spread Spectrum FH (B.A.) 250 mil FDD, TDD, CSMA-CA 2.4, 2.6, 3.5, 5.7, 5.8 GHz. TABLA 6.II 3 Mbps compartidos (por aire) TECNOLOGÍAS DE ACCESO Y SERVICIOS RED Telefonía y Datos. (20km. max.) característica, haciendo consideraciones especiales para los otros puntos cuando sean necesarias. Como ya se menciono anteriormente, el ancho de banda y los servicios disponibles están íntimamente relacionados. Históricamente se han ido desarrollando tecnologías que permitían satisfacer las necesidades de ancho de banda de los usuarios principalmente formadas por el advenimiento de servicios como las BBs y luego Internet. En nuestros días este panorama ha cambiado considerablemente, así se han desarrollado tecnologías que permiten obtener anchos de banda muy grandes, mientras que no se ve claramente cual es el contenido que será dado sobre este. Basándose en los posibles servicios a implementar, y la respuesta de los usuarios a estos últimos, es que se confecciona una curva que permite estimar el ancho de banda requerido para los próximos años. En la Fig. 6.14, se puede ver que cualquiera de las tecnologías propuestas en los capítulos anteriores tendría un tiempo de vida de por lo menos 4 años si solo se pensara dar servicio de datos. Se considera aquí que 3 años es un plazo prudencial para esperar que se amortice esta red. Este periodo se encuentra en casi toda la literatura actual sobre el tema. Por otro lado este proyecto parte de la base que se montara una red multiservicios, y la idea es la de ganar mercado ofreciendo paquetes que incluyan no solo datos, sino también voz y en lo posible vídeo. Esto hace que la Fig sea la que hay que tomar en cuenta para examinar que tecnología se amortiza antes de concluir su vida útil. 20 Como conclusión de este análisis, se obtiene un grupo de tecnologías con las cuales seria factible diseñar la red, estas son: ADSL En principio hay tres zonas con diferentes objetivos en cuanto a servicios, y por ende posibilidad de nuevas tecnologías. Esta será analizada al momento de hacer la elección final de la tecnología a utilizar. 21 La evolución de velocidades que esta tecnología se puede estimar haciendo una estimación del estilo de la ley de Moore. Este estudio se presenta en el Apéndice II.

53 52 CAPÍTULO 6. RED DE ACCESO del mismo y puede elegir libremente el tipo de servicio y tecnología a brindar sobre la infraestructura, lo que se transforma en una gran ventaja. Ver Fig Fig Ancho de banda promedio requerido por el cliente Fig Full unbundling. Esquema de interconexión de los distribuidores principales del operador incumbente y del entrante, para la distribución de voz, datos y video. 6.III-B Unbundling físico compartido (line sharing) Existen variaciones de lo anterior que permiten que el competidor y el incumbente compartan el par físico (y por consiguiente el espectro) para brindar servicios de POTS o ISDN además de servicios del tipo xdsl. En este caso existe un splitter que es compartido con el operador incumbente y el competidor, que conecta servicios hacia las redes de telefonía y hacia los DSLAM s correspondientes. Fig Ancho de banda por cliente. Incluye Voz, Vídeo y Datos Satélite Cable Módem No obstante este resultado, se tendrá en cuenta que para zonas donde los requerimientos o proyecciones de servicios no sean tan exigentes (en términos de ancho de banda), se podrá utilizar otra tecnología alternativa (por ej. algún sistema WLL). Para realizar el unbundling de tipo físico el competidor debe instalar sus equipos en la central telefónica del incumbente o en las cercanías a la misma, en la segunda opción debe realizarse un cableado entre las instalaciones que agrega puntos de falla y tiene restricciones de distancia. Ver Fig Además de esto debe colocar enlaces que alimenten los servicios en dichas ubicaciones. 6.III UNBUNDLING Este término es usado para describir una situación en la cual el propietario de un recurso físico es obligado a poner a disposición de su competidor una porción del mismo. Loop de Abonado. El Unbundling del loop de abonado (LLU) puede implementarse en forma física o lógica. 6.III-A Unbundling físico completo (full unbundling) En caso de realizarse un LLU del tipo físico el incumbente asigna un determinado número de pares para el competidor, en este caso el manejo de este par de cobre depende únicamente Fig Coubicación a distancia. El operador entrante se instala en las cercanías del incumbente. El competidor paga una tarifa previamente convenida con el incumbente que, en caso de no haber acuerdo, es fijada por el Organismo Regulador. Estas tarifas se establecen por cantidad de líneas arrendadas. A estos costos se deben agregar los asociados a la coubicación de equipamiento que por lo general se cobra por metro

54 53 cuadrado y por los servicios que se brindan (energía, seguridad, aire acondicionado, detectores de humo e incendio, bandejas de cableado, distribuidores, iluminación, etc.) 6.III-C Unbundling lógico En este caso el incumbente especifica el CPE y opera los equipos terminales, el competidor comercializa servicios de capas superiores. Un ejemplo de esto es un operador incumbente brindando accesos ADSL con enlaces hacia los competidores, los cuales, brindan el servicio de acceso a Internet o de VPN s. Este tipo de LLU hace que la coubicación de equipos se restrinja al equipamiento de interconexión entre prestadores el cual podría ser único y compartido (por ejemplo router ATM terminando circuitos hacia los competidores). Además puede hacer más fácil el cumplimiento de acuerdos de Service Level Agreements (SLA s) ya que no hay tramos físicos compartidos. Las desventajas de este tipo de LLU es que las características de performance del link implementado por el incumbente puede restringir los tipos de servicios que el competidor comercialice y limita la capacidad del competidor de diferenciarse del incumbente. 6.III-D Sub-loop unbundling Este tipo de LLU puede establecerse para brindar servicios de altas velocidades (principalmente VDSL) y donde las distancias de los LL deben ser menores. La conexión entre el LL del Incumbente y del OLO se hace en las cajas de distribución o equivalentes. Ver Fig. 6.18, el OLO en este caso debe estar en las cercanías de la misma, la reglamentación establece los requerimientos físicos de los elementos de interconexión y las características de las señales en las líneas (frecuencia mínima y máxima, valor máximo de la PSD, etc) para evitar la interferencia entre operadores (crosstalk, etc), Para esto se establece un Plan de Frecuencia para la Red de acceso. 6.III-E Costos Los costos del LLU se desglosan de la siguiente forma: 1) Licenciamiento y coubicación. Metro cuadrado de coubicación por año. 2) Servicios: Tarifa fija por KW por año. Consumo por KW. Iluminación, instalación eléctrica extra, aire acondicionado, backup de energía. Cargo por HDF por pares por año. Cableado entre MDF y HDF por año y por pares. Acceso al MDF por año por pares. Inspecciones, pruebas, conexiones, traslados, etc. En el caso de la coubicación a distancia se agregan los costos del cableado hasta la ubicación remota dependiente de la cantidad de pares ( también se eliminan algunos costos como energía, aire, etc.). Relevando la información de algunas compañías se llega a una tarifa media de unos U$S 10 por línea por mes a lo que hay que sumarle los costos de la coubicación. Como referencia la tarifa de coubicación ofrecida por ANTEL ronda los U$S 500 mensuales por rack de 19 e incluye seguridad, energía e iluminación (esta tarifa se aplica para la instalación de servidores o equipos en salas de coubicación). 6.IV-A Introducción 6.IV ELECCIÓN DE TECNOLOGÍA De los resultados obtenidos anteriormente es fácil concluir que solo tres de las tecnologías listadas en primera instancia cumplen con los requerimientos necesarios para la construcción de la red de acceso, y estas son: WLL (BREZEE ACCESS) 22 ADSL CABLE Se estudia en primera instancia definir cual de las dos tecnologías alámbricas es la mas conveniente. 6.IV-B ADSL vs. Cable Para cualquiera de estas dos tecnologías existe la posibilidad de cablear una red propia, o hacer unbundling de las redes existentes. La opción mas conveniente para un operador entrante será la de hacer unbundling, ya que permite entrar en competencia con una inversión significativamente menor. El solo argumento de la falta de legislación para el unbundling del CABLE justificaría decidirse por la utilización de ADSL 23, no obstante se analiza a continuación los pros y Fig Sub-loop unbundling. El operador entrante se conecta en un punto intermedio de la planta externa para poder brindar servicios de alta velocidad sobre distancias menores al abonado. 22 Entre los sistemas inalámbricos estudiados, se ha concluido que el que tiene mejor relación costo beneficio, para el tipo de mercado proyectado es el sistema BreezeAccess de Alvarion 23 Si bien no hay documentación formal de unbundling en Argentina, Telefónica, uno de sus principales operadores ya estan haciendo unbundling de su par de cobre.

55 54 CAPÍTULO 6. RED DE ACCESO contras de utilizar ADSL o Cable: Precio: Ambas soluciones precisan de un equipo en el abonado cuyo precio es ligeramente superior en el caso de ADSL. Si se mira por el lado de los costos de red, los cambios necesarios en la red de cable para poder brindar los servicios de datos (bidireccionales) son mucho mayores que los de hacer unbundling sobre ADSL. Confianza: Según encuestas realizadas en otros países la credibilidad del cable es menor que la del ADSL. [23] Esto viene dado principalmente por la desconfianza que genera en la gente, y sobretodo en las empresas, el envió de información privada por medios compartidos. Existe la opción de encriptar la información, pero en cualquier caso esto es mas fácil para los usuarios elegir un medio como el ADSL que no presenta este tipo de inconvenientes. Posibilidades técnicas: De acuerdo a las velocidades de transmisión de datos que son capaces de manejar ambas tecnologías permiten cubrir ampliamente los objetivos presentes y futuros. Cableado: Para hacer unbundling de ADSL no hay que hacer ningún cableado, en el caso de cable habría que terminar de cablear el resto de Montevideo. Esencialmente, lo que definimos como zona C es la zona desprovista de red de cable. Experiencia: Mientras que los servicios sobre ADSL crecen a ritmo constante en todas partes del mundo, los respectivos del cable parecen estar mas estancados, e incluso en muchos casos en retroceso. Fig ADSL vs. CABLE De lo previamente analizado se concluye que dar ADSL haciendo unbundling sobre los pares de cobre del operador incumbente es la mejor decisión en base a la situación actual del departamento de Montevideo. 6.IV-C ADSL vs. Spread Spectrum Los sistemas inalámbricos son especialmente apropiados para zonas de baja densidad de clientes o áreas nuevas en desarrollo. Para las zonas de baja densidad porque el costo no depende esencialmente de la distancia, como en los medios cableados en dónde los costos son altamente dependiente de la distancia entre proveedor y cliente, e incluso entre clientes. Para las zonas en crecimiento porque se instalan muy rápidamente en comparación con los tiempos de obra civil que exige un medio cableado. En cambio, ADSL resulta muy conveniente para zonas con gran concentración de clientes donde los equipos centrales se encuentran a poca distancia de los abonados. Teniendo en cuenta estas características, se puede ver que la zona de Montevideo mas apropiada para sistemas inalámbricos es la definida previamente como zona C. Sabiendo que los objetivos no son los mismos para todas las zonas, y por ende las tecnologías que mejor se adapten a cada zona no tiene por que ser la misma. Sería perfectamente posible tener una red de acceso híbrida que constara de 2 tecnologías, donde por ejemplo se podría utilizar WLL para la zona C y una tecnología cableada para acceder a los usuarios de las zonas A y B. Si bien ésta parece ser la solución ideal, existen otros factores que hacen que esta opción sea prácticamente inviable para una escala de red como la que es esta diseñando. Si se termina eligiendo una red híbrida, entonces en algún momento habrá que hablar del servicio de mantenimiento donde la pregunta que surge inmediatamente es: Hay que tener un servicio de mantenimiento para cada red, o sería suficiente un mejor servicio que cubra ambas?. Si bien esta pregunta no es fácil de contestar, lo que si salta a la vista es que tener dos servicios de mantenimiento cuesta casi el doble que tener uno solo, y por otro lado para tener un servicio que cubra ambas redes hay que capacitar a todos los técnicos, lo que sin duda redundaría en una situación similar. Lo mismo ocurre en el caso de los sistemas de management y posiblemente también en otras áreas como Ingeniería, Desarrollo y Marketing. También se estaría pagando equipos a costos mayores debido a la sensibilidad del costo de los mismos a la cantidad de equipos comprados. Por ende se considera que no es factible utilizar 2 tecnologías para la red de acceso, y habrá que elegir una que pueda cubrir de mejor manera toda las zonas. Se relizará entonces un prediseño de la red para la zona C (donde la posibilidad de instalar WLL es mas factible) con cada una de estas 2 tecnologías, y se e intentará obtener conclusiones al respecto de cada uno. Se recuerdan aquí las principales características de esta zona: Edificación de altura poco importante No se prevee clientes de gran ancho de banda.

56 55 Baja densidad de Usuarios. 560 usuarios telefónicos y 100 usuarios datos e Internet el 1er año usuarios telefónicos y 1500 usuarios de Internet como objetivo final. Dado el alcance del proyecto y debido a que se está realizando un prediseño comparativo, este prediseño tendrá las siguientes características: Los costos incluidos son aproximados. Apenas lo suficiente para permitir la comparación. Solo se incluyen las partes diferenciales de las redes. No aquellas que tienen en común, como consolas de administración, facturación, etc. De acuerdo a la estrategia de crecimiento la red se implementará en 3 etapas. Se analizará aquí la primera y la ultima. Para el primer año el diseño deberá cumplir los requerimiento del mercado detallados anteriormente, es decir: 560 usuarios telefónicos y 100 usuarios datos e Internet (128 Kbps). Para el tercer año el diseño deberá contemplar 7760 usuarios telefónicos y 1500 usuarios de Internet (128 Kbps). 6.IV-D Prediseño BreezeAccess Primer Año: Tomando un radio de celda de 8 Km se puede cubrir la zona C con la ubicación de 3 radio bases. Esta situación es la recomendada por el proveedor como medida conservadora, ya que los 15 Km. indicados en las hojas de datos solo son aceptables bajo condiciones de línea de vista clara. Esto significa que en promedio por celda habrá que manejar 190 usuarios telefónicos y 34 usuarios de datos e Internet. Esto es un total de 4.5 Mbps de datos e Internet y unas 19 llamadas simultáneas (0.1 Erlang) lo que según el proveedor equivale a 1.5 Mbps. Con lo cual habrá un total de 6Mbps por radio base el primer año. Para cubrir esta demanda alcanza con instalar 1 chasis por radio base. Se adjunta el calculo aproximado de costos en Tabla 6.III. Este cálculo de costo no es completo ya que podrían y deberían agregarse costos tales como, mantenimiento, entrenamiento de personal, etc. Pero es suficiente como estimativo preliminar, que permitirá comparar con redes de acceso alternativas. Tercer Año: En este caso el tamaño de las radio bases no lo determina la distancia máxima entre cliente y radio base sino la capacidad de datos de cada celda (54Mbps). Teniendo en cuenta los usuarios el ancho de banda total que se debe manejar es 251Mbps. Si cada radio base maneja un máximo (real) de 36 Mbps se necesitaran 7 torres, Cantidad Elemento Precio unitario (U$S) Precio total (U$S) Comentario 3 Torre y Lugar n/a 3 Chasis Unidad BSE 3 Switch Cisco Catalist Router H323 Gateway Gateway 18 Antenas UPS Incluye generador y UPS 1 Licencias de Banda de frecuencia 1 año. 560 Equipos de Usuario CPE Total Total por usuario (periodo 1 año) 1284 TABLA 6.III COSTOS DE RED DE ACCESO BREEZEACCESS EN SU PRIMER AÑO DE OPERACIÓN con la capacidad máxima (3 chasis) casi colmada. Es necesario evaluar nuevamente los costos, ahora con los equipos para el diseño de la red final, Tabla 6.IV. Cantidad Elemento Precio unitario (U$S) Precio total (U$S) Comentario 7 Torre y Lugar n/a 21 Chasis Unidad BSE 7 Switch Cisco Catalist Router H323 Gateway Gateway 42 Antenas UPS Incluye generador y UPS 1 Licencias de Banda de fercuencia 1 año Equipos de Usuario CPE Total Total por usuario (periodo 1 año) 1131 TABLA 6.IV COSTOS DE RED DE ACCESO BREEZEACCESS EN SU TERCER AÑO DE 6.IV-E Prediseño ADSL OPERACIÓN En el caso de ADSL no es necesario instalar equipos en todas las centrales del incumbente desde el comienzo (de acuerdo con la estrategia de crecimiento), y a medida que crece la cantidad de usuarios, según el caso se incluirán nuevas centrales o solamente habrá que agregar tarjetas de abonado, o gabinetes extras. En cada central se deberá instalar un DSLAM, compuesto por: gabinete, tarjetas de abonado, tarjetas de control, tarjetas

57 56 CAPÍTULO 6. RED DE ACCESO de interfase; y un switch ATM para conectarse con el resto del backbone. Asimismo puede ser necesario de acuerdo con el diseño de la red el instalar un voice gateway y un soft switch que permita la conexión con la central PSTN y la conmutación de llamadas de la red. Si bien estos equipos serían considerados como parte de la red de transporte o de conmutación, igualmente los se tendran en cuenta para este prediseño. Ver Tabs. 6.V y 6.VI. Cantidad Elemento Precio unitario (U$S) Precio total (U$S) Comentario 13 DSLAM Tarjetas de Tarjetas de 24 abonado abonados c/u 13 Tarjetas de control 13 Tarjetas de interface Tarjetas STM1 13 Switch ATM Router ATM Unbundling Por Año 13 Coubicación Por Año 1 Voice Gateway Equipos de Usuario CPE Total Total por usuario (periodo 1 año) 1433 TABLA 6.V COSTOS DE RED DE ACCESO ADSL EN SU PRIMER AÑO DE OPERACIÓN Cantidad Elemento Precio unitario (U$S) Precio total (U$S) Comentario 25 DSLAM Tarjetas de Tarjetas de 24 abonado abonados c/u 25 Tarjetas de control 25 Tarjetas de interface Tarjetas STM1 25 Switch ATM Router ATM Unbundling Por Año 25 Coubicación Por Año 1 Voice Gateway Equipos de Usuario CPE Total Total por usuario (periodo 1 año) 743 TABLA 6.VI COSTOS DE RED DE ACCESO ADSL EN SU TERCER AÑO DE OPERACIÓN 6.V-A Introdución 6.V ESTRATEGIA DE CRECIMIENTO Tan importante como la elección de la tecnología, es la decisión de cuando se irán instalando los distintos equipos de la red. La mejor estrategia no es montar la totalidad de la red proyectada al principio de la operación de la misma, sino que es preferible instalar lo necesario para comenzar el funcionamiento y planificar las ampliaciones de acuerdo al crecimiento esperado. Así mismo es posible que haya subzonas no ameriten ser contempladas hasta que la demanda de servicios en ellas sea la suficiente para que sea una buena inversión. Como contrapartida a esto están los reglamentos de servicios esenciales los cuales obligan a dar servicios en este tipo de zonas en las que el negocio no es rentable, y también pueden influir medidas de imagen como ser una empresa que está presente en el 100 % de la ciudad. De todos modos como medida intermedia o provisoria se puede recurrir al arrendamiento de servicios a otro proveedor hasta el momento en que la inversión amerite instalar la red propia. Teniendo en cuenta estas consideraciones se describe aquí, a partir de el crecimiento estimado anteriormente, el plan de trabajo propuesto, y las consideraciones a tener en cuenta en la consolidación de la red. 6.V-B Pasos a seguir La primer decisión que se toma es estratégica e implica que se tendrá la mayor cantidad de zonas cubiertas por equipos propios, sin olvidar las consideraciones económicas realizadas anteriormente. La segunda decisión es hacer planes anuales, y dado que según consideraciones actuales la vida útil de una red de comunicaciones debe ser de 3 años, se diseñaran 3 etapas de la red. Si la red planificada será desarrollada sobre ADSL, usando unbundling de la red de cobre de ANTEL, la primer decisión a tomar es el tipo de unbundling a utilizar. De acuerdo a lo expuesto en la introducción, hay que analizar que tipo de unbundling es conveniente en cada zona. Es de esperar que para zonas donde la penetración sea muy baja no será viable instalar los mismos equipos que para zonas de mas usuarios, e incluso podría ser conveniente no instalar equipos y recurrir al unbundling de tipo lógico. Se comienza este estudio analizando en que centrales del Incumbente convendría pagar coubicación y tener equipos propios, haciendo unbundling físico. Al carecer de un estudio estratégico económico y financiero que en conjunto con las condicionantes técnicas marquen la frontera entre las centrales en las que se estará presente y las que no, se usaran los siguientes criterios: La modalidad de equipos propios de acceso, el criterio decidido es estar presente en las centrales que cubran zonas con mas de 35 usuarios de datos al finalizar el año. Así que de acuerdo a la evolución estimada de usuarios por central, se separará para cada año las que cubran este requisito de las que no. Como excepción a esta regla incluimos desde el primer año la zona de Ciudad Vieja, en el entendido de que el perfil de la misma es de clientes principalmente comerciales y consumidores de gran ancho de banda. Esto hace que el negocio pueda ser rentable aunque los clientes no sean muchos. Como se ha dicho antes este criterio es discutible, pero de todas formas no es relevante al momento de diseñar (aunque si en el diseño resultante) ya que en caso de usar otro criterio

58 57 solo cambiaría que centrales son cubiertas y cuales no, y no la forma de proceder para diseñar la red. Por lo tanto se planifica para el primer año coubicación en las centrales : Aguada, Atahualpa, Buceo, Centenario, Centro, Ciudad Vieja, Cordón, Palacio, Parque Rodó, Pocitos, P. Carretas, Carrasco y Malvín. Fig Zonas con presencia directa el primer año Para el segundo año la modalidad de cubicación se extenderá a: Cerrito, Colon, Paso Molino, Sayago, Euzkalerria, Unión. Fig Zonas con presencia directa el tercer año Fig Zonas con presencia directa el segundo año Entre el tercer y cuarto año incluir: Cerro, Lezica, Santiago Vazquez, P. De la Arena y Manga S3. En las zonas no cubiertas por equipos propios se brindaran servicios en la modalidad de unbundling lógico, de acuerdo a lo explicado en 6.III-C.

59 58 CAPÍTULO 6. RED DE ACCESO 6.VI DISEÑO DE LA RED DE ACCESO Del prediseño presentado anteriormente se puede ver que en grandes números, la solución de WLL sugerida sigue siendo igual o mas costosa que la posibilidad de usar ADSL (principalmente 3er año), incluso al plantear el prediseño en la zona que mejor se presta para el uso de tecnologías inalámbricas. Se considera entonces, que si los costos de WLL son iguales o mayores para la zona mas apropiada, entonces más los serán en zonas con la A y B donde la situación es mas apta para ADSL. Si también se tiene en cuenta que las prestaciones y el tiempo de vida de ADSL pueden ser mucho mejores que los de WLL, se podra concluir entonces que la mejor tecnología para usar en la red a de acceso es ADSL. 6.VI-A Introducción En esta etapa ya se cuenta con todos los medios técnicos para tomar la decisión de que equipos instalar y donde. Solo harían falta estudios económicos y financieros. Se ha planteado desarrollar la red en tres etapas anuales, y también se ha dicho que cada inversión de la misma debe ser recuperada en un periodo de 3 años. Los estudios antes mencionados son necesarios, tanto para decidir entre los distintos equipos, así como para tomar decisiones sobre en que zonas se darán servicios directos, tercerizados y eventualmente, en cuales no dar servicios. Pese a que no se tienen estos estudios, se hará referencia a precios de lista de los equipos estudiados. Se ha decidido hacer una red de acceso propia, cubriendo las zonas de servicio con Unbundling Físico. De este modo la única parte de la red que no estaría bajo el control directo sería el par de cobre, como medio físico. Tanto el CPE instalado en el cliente, como el DSLAM ubicado en la central serán propios. En este caso además de la cuota de unbundling del par de cobre habrá un costo de coubicación de los equipos en la central. Los equipos a ser utilizados son: CPE en cada usuario. DSLAM, instalados en la central, con las tarjetas necesarias de acuerdo a lo indicado en la parte II (Descripción de tecnología ADSL). Equipos de interconexión con la red de transporte (elegidos en la etapa de diseño de transporte). Se presenta en las tablas 6.VII, 6.VIII, y 6.IX la lista de centrales para cada año, de acuerdo al criterio previamente establecido. En estas tablas también se presenta la cantidad de abonados por año. Estos datos son importantes porque son indicadores de la inversión a realizar, así como la cantidad de racks necesarios también indican el costo de la coubicación. Central Clientes Solo Voz 1er Año Clientes Voz, Internet y Datos Total Aguada Athagualpa Buceo Centenario Centro Ciudad Vieja Cordon Palacio Parque Rodó Pocitos P. Carretas Carrasco Malvin TOTAL TABLA 6.VII CENTRALES CON RED DE ACCESO PROPIA EL 1ER AÑO Central Clientes Solo Voz 2do Año Clientes Voz, Internet y Datos Total Aguada Atahualpa Colón Cerrito Paso Molino Sayago Buceo Centenario Centro Ciudad Vieja Cordon Palacio P. Rodo Pocitos P. Carretas Carrasco Euskalerria Ituzaingo Malvin Union TOTAL TABLA 6.VIII CENTRALES CON RED DE ACCESO PROPIA EL 2DO AÑO 6.VI-B Equipamiento Se presentan aquí las características principales de los equipos necesarios para la conformación de una red de acceso DSL. Para cada equipo se presentan las opciones de los principales proveedores de estos equipos. También se presentan precios aproximados de los equipos, en los cuales además no se hacen distinción entre proveedores ya que se comprobó que los distintos proveedores tienen costos similares. 6.VI-B.1 Equipos DSLAM 1. Cisco Systems Cisco 6160 IP DSL Switch

60 59 Central Clientes Solo Voz 3er Año Clientes Voz, Internet y Datos Total Aguada Atahualpa Cerro Colón Lezica Cerrito P.de la Arena Paso Molino S. Vazquez Sayago Buceo Centenario Centro Ciudad Vieja Cordon Palacio P. Rodo Pocitos P. Carretas Carrasco Euskalerria Ituzaingo Malvin Manga S Union TOTAL TABLA 6.IX CENTRALES CON RED DE ACCESO PROPIA EL 3ER AÑO Características técnicas. 32 slots para tarjetas multipuertos. Compatible con standards de ANSI. Equipo carrier-class ATM estándar compatible. Conexiones a la red de transmisión de tipo T1/E1 IMA (8x), DS3, OC-3 STM1 (single mode y multimode). Hasta 256 puertos por shelf y 3328 puertos en configuración multi-shelf. Facilidades ATM: ATM UNI 3.1/4.0 UBR, ABR, VBR-nrt, VBR-rt, CBR. PVCs, SPVCs, y SVCs. 512K Vcs, 256 Vps (32 shaped). ILMI - IISP/PNNI Egress traffic shaping. Traffic policing ITU-T I.371 y ATM Forum UNI. Early packet discard (EPD), partial packet discard (PPD). Facilidades IP: RFC 1483 Routed to MPLS VPN RBE to MPLS VPN PPPoE to L2TP PPPoA to L2TP Sistema de Supervisión: Cisco DSL Manager (SNMP based). Management interfaces In-band: ATM VC Out-of-band: 10BaseT Ethernet (RJ-45) EIA/TIA-232 Console (RJ-45) EIA/TIA-232 Auxiliary (RJ-45) Tarjetas de línea: Tarjetas DSL de 4 puertos (DMT y CAP). ANSI T1.413 Issue 2, 32- a 8032 kbps downstream y 32 a 1024 kbps upstream. ITU G (G.dmt), 32 a 8032 kbps downstream y 32 a 1024 kbps upstream. ITU G (G.Lite), 32 a 1536 kbps downstream y 32 a 512 kbps upstream. ITU G (G.hs) RADSL-CAP, hasta 7.1 Mbps downstream y 1 Mbps upstream. Tarjetas de 8 puertos ADSL (solo DMT) ITU G (G.dmt), 32 a 8032 kbps downstream y 32 a 1024 kbps upstream. ITU G (G.lite), 32 a 1536 kbps downstream y 32 a 512 kbps upstream. ITU G (G.hs) Tarjetas de 8 puertos G.SHDSL (TC- PAM) ITU G Hasta 2.3 Mbps simétricos. Medidas: 11 RUs (54.2 cm x 46.6 cm x 30.0 cm.) Energía: 1 fuente DC (posibilidad de 1+1 redundante) Alimentación de -48/ -60 V DC Nominal. Timing: Interface para referencia externa (BITS). Derivado de una interface de red. 2. ALCATEL ALCATEL 7300 ASAM (Advanced Server Access Manager) Características técnicas. Soporta ADSL sobre ISDN o POTS. Hasta 16 tarjetas por equipo (shelf). Hasta 4 equipos por rack de puertos por shelf y 1152 puertos por rack. Hasta 2304 puertos en configuración multi-shelf (hasta 12) alimentados por una única interfaz de red (E3 o STM1). Hasta 576 interfaces de red de tipo E1 (IMA), hasta 36 interfaces E3/DS3 y STM1 ATM. Con tarjeta de IP Services Modules se provee de 4 interfaces 10/100 Base- T. Posibilidad de redundancia 1+1. VoDSL Tarjeta de VoDSL para el 7300 o un nodo stand alone (7310 Loop Voice Gateway) con DSP s para compresión Comunicación vía V5.2 con la PSTN. Configuración típica: 1 tarjeta puede manejar 8 interfaces E1 para sostener 240

61 60 CAPÍTULO 6. RED DE ACCESO llamadas de voz simultáneas. Se puede extender a 8 tarjetas con un total de 1920 llamadas activas. Tarjetas de línea: Tarjetas de línea de 12 o 24 puertos Tarjetas Multimodo ADSL (DMT). Soporte de G (G.shdsl), 1 y 2 pares. G.shdsl inverse multiplexing sobre ATM (IMA) para alcanzar los 9.2 Mbps con 4 pares. Soporte de G (ADSL G.Lite), hasta 1536 kbps downstream y 384kbps upstream. Facilidades ATM: Servicios CBR, UBR y UBR+, rt-vbr y nrt-vbr y GFR. Point-to-multipoint virtual circuit usando UNI 3.1 multicast para streaming de video o audio. Soporta hasta PVC s o SVC s por interfaz de red. Facilidades IP (ISM): Tarjeta opcional de servicios IP. Agrega funcionalidad de BRAS al DSLAM. IP Routing, VC aggregation, IP multicast. Soporte para VPN L2TP, Layer 2 RFC 2661 y Layer 3 RFC Sistema de supervisión: Supervisión end-to-end de hasta 1 millón de suscriptores y 5000 nodos en un solo dominio. Acceso local NMTI Local o remoto vía 5620 NM o SNMP 5740 SSM Medidas: Hasta 4 shelfs por rack de 19 y 45 Rmu. Energía: 40 V a 75 V DC 115 W máximo por tarjeta de abonado. Timing: Clock recovery from PSTN (any E1). Internal oscillator (holdover). 3. SIEMENS AG Attane XpressLink Características técnicas. DSLAM con arquitectura de slots universales. XL M - Mini-shelf de 6 slots-64 puertos ADSL (con splitters) XL H - Versión de alta densidad, Con dos DSLAMS se consiguen 960 puertos ADSL por rack o 720 puertos SHDSL. XL C -192 puertos ADSL incluyendo splitters en un pequeño shelf. POTS e ISDN, 30/120kHz a 1.1MHz. Interfaces STM1,OC-3c, E3, DS3, nxe1, nxds1 (hasta 8). Soporta ADSL, ADSL.Lite, SDSL, G.shdsl y VDSL. Pueden colocarse los splitters en racks separados, las tarjetas de splitters soportan 32 líneas POTS o ISDN. Cada sistema tiene 2 subracks, uno para las tarjetas de control, interfaz de red y tarjetas de abonado y otra para las tarjetas de splitters. 32kbps de granularidad en ADSL y 64kbps en SHDSL. Facilidades ATM: ATM UNI 3.1/4.0 CBR, UBR, ABR, VBR-nrt, VBR-rt. PVCs (VP y VC cross connect), full ATM OAM support policing. Facilidades IP: Solo funcionalidad de DSLAM, producto Attane XpressPass con funcionalidades de BRAS y concentrador de servicios. Sistema de Supervisión: Siemens AccessIntegrator. Protocolo SNMP Interfaces de supervisión Ethernet 10 BaseT o ATM inband. Local Craft Interface Web para mantenimiento, Plataforma PC o laptop con Windows NT para conexión ethernet local o por IP. Arquitectura de cliente-servidor escalable y visualización del nodo, download de software remoto, ATM path management, funciones de OAM. Tarjetas de línea: Tarjetas xdsl. ANSI T1.413 Issue 2, ITU G (G.dmt) hasta 8.16 Mbps downstream y 800 kbps upstream (5 km. Max), tarjetas de 16/32 puertos. ITU G (G.Lite DMT) hasta 1536 kbps downstream y 512 kbps upstream (5 km. Max.) tarjetas de 16/32 puertos. SDSL (2B1Q y PAM) ETSI TS ,2 y ITU-T G (G.shdsl) (PAM 16) hasta 2.3 Mbps (3.5 km. Max.), tarjetas de 16 puertos. VDSL hasta 28 Mbps. (max. 300 a 1500 m) Medidas: Mini DSLAM 700x600x300 mm. Compact DSLAM 1800x600x300 mm. Energía: Entrada de -48V/-60V nominal. 6.VI-B.2 Equipos CPEs y IADs 1. Cisco Systems IAD2400 Interfaces Broadband: Una puerta T1 (PPP, HDLC, FR o cell) RJ48 Una puerta ADSL (RJ11) ANSI T1.413

62 61 ITU-T G.992.1(G.dmt) ITU-T G (G.Lite) Una puerta SHDSL (RJ11) ITU-T G (G.shdsl) Interfaces de voz: Analógicas 8 FXS/16 FXS/16 FXS + 8 FXO (RJ-21). Digital: Una T1-PBX (CAS, PRI) (24 DS0s, RJ48). Voz TDM, VoIP (RTP, crtp), VoATM (AAL2) DSPs: CELP (G.729a), ADPCM (G k, 16k), PCM (G.711). 24 llamadas simultáneas (interfaz digital) y 16 llamadas simultáneas en la interfaz analógica. Facilidades de voz (xgcp): Call waiting, cancel call waiting Caller ID nombre y número. Caller ID blocking Caller ID con nombre/número y call waiting. Call forwarding: no answer/busy/variable Call forwarding: acceso remoto Transferencia de llamada. Conferencia de 3 Message waiting indicator/tone (stutter) Call return. Re-dial, busy call return. Call blocking with toll restriction. Call trace Call screening Distinctive-ring services. Off-hook warning tone. Selective/anonymous call rejection. Interfaces de datos: Una interfaz 10BaseTX (RJ45) WAN: PPP, HDLC, MLPPP, FR. ATM hasta 1024 Vcs, VPI: 0-255, VCI: Frame Relay: FRF.5/FRF.8, FRF.12. QoS ATM: CBR, VBR (rt y nrt), UBR. QoS IP: LLQ, DSCP, IP precedence, CAR. Routing: RIP v1, v2, OSPF, BGP, static. VPN/firewall NAT/PAT, DHCP (server, cliente, relay), IEEE 802.1d. Interoperabilidad DSLAM: Alcatel, Cisco 6100/6200 series, Lucent Stinger. Trunking Gateway: Cisco 3660, AS5x00. Call Agents: Broadsoft, Cisco BTS, Cisco CallManager, IpVerse, Starvox, Telcordia, VocalData, y otros con protocolo xgcp. VGW (GR.303/V5.2): Commatch, General Bandwidth, TdSoft. Management: SNAP auto-installation technology Cisco CNS 1.5 CiscoView ALCATEL SpeedTouch 700 Series Interfaces Broadband: Una puerta ADSL (RJ11) ANSI T1.413 ITU-T G (G.dmt) ITU-T G (G.Lite) Interfaces de voz: SpeedTouch 700: 2 POTS (RJ11) SpeedTouch 710: 4 POTS (RJ11) SpeedTouch 720: 2 ISDN S0 (RJ45) QoS support (CBR) Traffic management por VC queuing o priorización de voz y traffic shaping. Codecs: PCM (G.711), ADPCM (G kbps.), ley u o ley A. Fax, modem support, Cancelación de eco G.165, G.168 interna, control de eco interno G.131. VoDSL AAL2VC (PVC) Switching de modo de compresión durante la llamada (soportado / controlado por el gateway) Facilidades de voz (xgcp): VoDSL Centrex support Flash hook Distinctive ringing Caller ID VoIP RTP (RFC 1889) y RTP audio profile (RFC 1890) Señalización H.248 RFC3015 Generación de tonos localmente Distinctive ringing Echo cancellation y control de ganancia. On y Off hook data transmission. Fax/textphone/modem detección. Ipsec authentication/encryption. Call waiting, cancel call waiting Caller ID nombre y número. Call forwarding: no answer/busy/variable Conferencia de 3 Call return. Distinctive-ring services. Off-hook warning tone. Selective/anonymous call rejection. Interfaces de datos: SpeedTouch 700: 1 10/100 Base-T (RJ45) SpeedTouch 710: 4 10 Base-T (RJ45), 1 serial RS232. SpeedTouch 720: 4 10 Base-T (RJ45), 1 serial RS232. Hasta 15 PVCs. RFC 1483 multiprotocol encapsulation over AAL5/ATM, LLC-SNAP y VC-based multiplexing. Multiport bridging (hasta 4 PVCs), bridging transparente, soporta IEEE 802.1d.

63 62 CAPÍTULO 6. RED DE ACCESO Soporta PPPoE. PPPoATM (RFC 2364) PPPoA to PPTP relaying. PAP/CHAP authentication. RFC 1577 IPoATM InATMARP protocol, RFC 1293 ARP (RFC 826) RFC 1483 routed encapsulation. Ruteo IP estático, LAN y PPP routing. NAT/PAT (RFC 1631), DHCP cliente, server y DHCP to PPP spoofing. DNS server y relay. Interoperabilidad VoDSL ETSI: 7300 IntegratedVoDSL GW, 7310 LVG, TDSoft VoNGATE. Management: Interfaz HTTP. Línea de comando por serial o telnet. Download de software remoto. Monitoreo F4/F5 loopback. 3. NETOPIA 4752/53/41 SDSLVoice/DataIAD Interfaces Broadband: Netopia 4752: Una puerta SDSL desde 144kbps a 2.3Mbps simétricos (RJ45). Netopia 4753: Una puerta SHDSL ITU-T G (G.shdsl) desde 192kbps a 2.3Mbps. Simétricos (RJ45). Netopia 4751: Una puerta ADSL, ANSI T1.413, ITU-T G (G.dmt), ITU-T G (G.Lite), velocidades desde 32kbps a 8192kbps de downstream y desde 32kbps a 1024kbps de upstream en incrementos de 32kbps (RJ45). Interfaces de voz: Netopia 4752: 8 interfaces analógicas FXS (RJ11). Netopia 4753: 8 interfaces analógicas FXS (RJ11). Netopia 4751: 4 interfaces analógicas FXS (RJ11). En todos los modelos: Compresión PCM (G.711) y ADPCM (G kbps). Echo Cancellation G.168, supresión de silencios y generación de ruido ambiente local. Facilidades de voz: Call waiting, cancel call waiting Caller ID nombre y número. Caller ID blocking Call forwarding: no answer/busy/variable Call forwarding: acceso remoto Transferencia de llamada. Conferencia de 3 Call return. Re-dial, busy call return. Distinctive-ring services. Interfaces de datos: Una interfaz 10/100 BaseTX (RJ45) ATM hasta 8 PVCs, VPI: 0-255, VCI: Termina PVCs ATM con AAL5 y AAL2. QoS ATM: CBR, VBR (rt), UBR. Encapsulación ATM multi protocolo (RFC 1483). PPPoATM y PPPoEthernet, PAP, CHAP y no authentication (RFC2364), control compresión protocol.(rfc 1974). IP control protocol (RFC 1332). WAN IP numerada o no numerada. Soporte de bit ToS Routing: RIP v1, v2 (RFC 2453), soporta hasta 32 rutas estáticas. VPN PPTP/firewall, soporte para IPSec interno con DES y generación manual de claves. NAT/PAT, DHCP (RFC 2131, server, cliente, relay), BootP Servers. IEEE 802.1d. Cliente Radius para la autenticación en la configuración. Netopia 4752/3 Soporte de Frame Relay ANSI T1.617 y ANSI T1.618 Anexo D LMI, Anexo A y Cisco LMI (RFC1490). Multi protocolo sobre FR y fragmentación FR.12 Interoperabilidad DSLAMs: de casi todos los fabricantes incluyendo Alcatel, Cisco, Ericsson, Lucent Technologies, Nokia, Orckit, etc. Voz: compatible con la mayoría de los Voice Gateways que manejan G.303 y V.52. Management: Acceso por consola RS232. Protección con password. Leds de diagnóstico. upgrade de firmware via TFTP o X-Modem. ICMP Ping. Trace Route. Cliente TFTP, telnet en LAN y WAN. Cliente syslog. SNMPV1 (RFC 1157) y MIB II (RFC 1213) Etheret MIB y enterprise MIBS. 6.VI-B.3 Precios Aproximados Chasis DSLAM U$S Tarjeta DSLAM de 8 Puertos ADSL U$S STM1 para acceso a backbone (DSLAM) U$S E1 IMA acceso a backbone (DSLAM) U$S Equipo CPE abonado (ethernet) U$S 150. Equipo IAD abonado (1 ethernet, 4 Voz) U$S 600

64 63 6.VI-C Diseño De acuerdo a lo visto en las etapas anteriores, ya se sabe cuantos usuarios habrá por central en cada año, así como la capacidad de los distintos equipos. Estos son todos los datos necesarios para culminar el diseño de la red de acceso. Esto es, en cada central con presencia directa se colocaran los equipos necesarios para soportar los usuarios conectados a la misma. El diseño se elabora para tres proveedores, ya que la comparación de tecnologías, precios y prestaciones de estos no arroja grandes diferencias que indiquen la elección en un sentido u otro. En la suposición que el proveedor pueda ser decisivo en alguna de las otras partes de la red (transporte por ejemplo), se diseña aquí la red con los equipos necesarios para todos los proveedores y se posterga la elección de este a etapas posteriores del diseño. De acuerdo a esto se elaboran las tablas 6.23, 6.24 y 6.25 que muestran los equipos que se instalaran en cada central en cada año. Estas tablas pretenden incluir todos los materiales necesarios para cada año, de manera que lo único necesario después de esta etapa sea la compra e instalación de los equipos aquí mencionados. Fig

65 64 CAPÍTULO 6. RED DE ACCESO Fig

66 Fig

67 66 CAPÍTULO 6. RED DE ACCESO

68 Capítulo 7 Protocolos de transporte Resumen En este capítulo se estudian los protocolos que se consideran mas adecuados para el transporte. Estos son ATM y MPLS. Se hace un estudio mas detallados de MPLS, por tratarse de un protocolo mas nuevo del cual se conoce menos. 7.I ATM 7.I-A Resumen de la tecnología ATM es una tecnología de transmisión de datos de alta velocidad de conmutación y bajo retardo, que utiliza unidades de datos de largo fijo llamados celdas. La característica de conmutación de celdas de largo fijo posibilita la conmutación por hardware a alta velocidad brindando, además del soporte para la transmisión de datos, soporte para aplicaciones en tiempo real como ser voz y video. La celda ATM tiene un largo de 53 bytes, 5 de ellos son usados para el encabezado, dejando los 48 restantes para la información. El encabezado (header) de la celda está dividido en diferentes campos. El más importante es el de dirección que identifica el circuito y provee un direccionamiento único para el enlace entre dos nodos. El direccionamiento en ATM se divide en un campo de VCI (Virtual Circuit Identifier) y un campo de VPI (Virtual Path Identifier), los cuales hacen posible la división de los flujos de celdas en dos niveles: a nivel de VC y VP como lo muestra la Fig Los grupos de canales con el mismo VPI pero diferentes VCI son ruteados sobre los mismos nodos de la red. Esto habilita al usuario a crear redes privadas utilizando un número de VC s que necesite sobre un único VP. Fig Relación entre el VC y el VP Siguiendo con los demás campos (ver Fig. 7.2), el PTI (Payload Type Identifier) especifica cuando la celda contiene información de usuario o información de operación y mantenimiento. El campo CLP (Cell Loss Priority) especifica el nivel de prioridad de esa celda que se toma en cuenta en caso de descarte. El campo HEC (Header Error Control) contiene un valor que es usado por todos los nodos para detectar algún error de bits en el encabezado. En la interfaz UNI (Userto-Network Interface), los cuatro bits del campo VPI son reemplazados por el GFC (Generica Flow Control) el cual es empleado para controlar la capacidad de recursos entre el terminal y la red. Fig Contenido del encabezado en la celda ATM ATM alcanza las tres capas bajas del modelo de referencia OSI de la ITU-T: Layer 1 - Capa física. Layer 2 - Capa ATM. Layer 3 - Capa AAL (ATM Adaptation Layer) Capa AAL La capa AAL puede asimilarse a una capa de transporte. Se encarga de proveer servicios a programas de aplicación y liberarlos de segmentar los datos en celdas en el emisor y reensamblarlos en el destino. La capa AAL se divide en dos partes, una de las cuales es a su vez frecuentemente subdividida en otras dos partes como se muestra en la Fig La parte superior de AAL o subcapa de convergencia, funciona de interfase con las aplicaciones. Consiste en una parte común a todas las aplicaciones (para un AAL dado) y una subparte de aplicación específica. Las funciones de estas partes son dependientes del protocolo. La subcapa de convergencia es también responsable, en el emisor, de aceptar flujos de bits o mensajes de largo arbitrario 67

69 68 CAPÍTULO 7. PROTOCOLOS DE TRANSPORTE Fig Capa de adaptación ATM y sus subcapas Item AAL1 AAL2 AAL3/4 AAL5 Clase de servicio A B C/D C/D Multiplexado No NO SI NO Padding CS bytes 0-47 bytes Overhead CS bytes 8 bytes Checksum CS NO NO NO 32 bits Tamaño bytes 44 bytes 48 bytes payload SAR bytes Overhead SAR 1 2 bytes 3 bytes 4 bytes 0 bytes Checksum SAR NO NO 10 bits NO TABLA 7.I DIFERENCIAS ENTRE PROTOCOLOS AAL desde las aplicaciones y segmentarlas en unidades de 44 a 48 bytes para la transmisión. Este tamaño depende del protocolo. La parte inferior de la AAL es llamada SAR (Segmentation and Reassembly). Esta parte puede agregar headers y trailers a las unidades de datos que le entrega la subcapa de convergencia para formar luego el payload de la celda y entregarlo a la capa ATM para que los transmita. En el destino la subcapa SAR reensambla las celdas en mensajes. La subcapa SAR tiene algunas funciones adicionales para algunas clases de servicio. Estas funciones pueden ser de detección de errores y multiplexación. Las posibles formas de operación de las subcapas de convergencia y SAR se muestran en la Fig Necesidad de sincronización entre el usuario que envía y el receptor. Tasa de datos constante o variable. Transferencias orientadas o no a conexión Para el manejo de los distintos tipos de servicio, ATM tiene definidas cinco categorías de servicio: CBR (Constant Bit Rate), rt-vbr (real time Variable Bit Rate), nrt-vbr (no-real time Variable Bit Rate), UBR (Unspecified Bit Rate) y ABR (Available Bit Rate). De estas categorías, generalmente son usadas CBR y VBR para el transporte multimedia. El tráfico CBR consiste en un flujo continuo de datos sensible a la pérdida de paquetes, latencia (delay) y jitter (variación del delay). Esta categoría reserva una cantidad constante de ancho de banda para cada conexión durante todo el tiempo para soportar las aplicaciones de datos voz y video, esto hace que tenga una baja eficiencia en el uso del ancho de banda. VBR -en su modo Real Time- garantiza una QoS especificada para aplicaciones sensibles al delay. VBR típicamente negocia el PCR (Peak Cell Rate), El SCR (Sustainable Cell Rate), el MBS (Maximum Burst Size) y el CTD (Cell Transfer Delay). Con estos parámetros queda definido el peor caso para la configuración de QoS requerida. Fig red ATM Headers y trailers que pueden ser agregados a un mensaje en la Cuando un mensaje llega desde la aplicación, la subcapa de convergencia puede agregarle o no un header o un trailer. Este mensaje es segmentado en unidades de 44 a 48 bytes y las unidades son pasadas a la subcapa SAR. La subcapa SAR puede agregar su propio header y trailer a cada segmento para pasarlos luego hacia la capa ATM para su transmisión en celdas independientes. En la tabla 7.I se muestra un resumen de los headers y trailers agregados en los distintos protocolos AAL. Para identificar los distintos tipos de servicio se definen cuatro clases (ver Fig. 7.5) A, B, C y D que engloban los distintos requerimientos. Estas clases son manejadas por los protocolos de adaptación AAL1, AAL2, AAL3/4 y AAL5 [24]. 7.I-B Servicios en ATM La transmisión de audio, datos y video sobre una misma red, fija ciertos requerimientos para la adaptación de distintas funcionalidades. Esto se puede resumir en los siguientes items: Fig Capas y tipos de servicio ATM

70 69 7.I-B.1 Servicios clase A Los servicios Clase A incluyen a servicios que necesitan una tasa de bit constante (CBR-Constant Bit Rate) para transferencias orientadas a conexión que necesitan sincronización origen-destino (end-to-end). El protocolo AAL 1 da soporte para estas aplicaciones. 7.I-B.3 Servicios Clase C Los servicios clase C incluyen a los servicios VBR de transferencias orientadas a conexión sin requerimientos de sincronización end-to-end. Los servicios clase C son soportados por los protocolos AAL3/4 o AAL5. Algunos ejemplos de estos servicios son mostrados en la Fig. 7.8 Fig Servicios Clase A Fig Servicios Clase C Ejemplos de estos servicios -mostrados en la Fig son la voz codificada en PCM, enlaces tipo emulación de circuitos (CE-Circuit Emulation) de nx64kbps o nx2mbps y señales de video codificadas con CBR. 7.I-B.2 Servicios clase B Los servicios Clase B incluyen a servicios de tipo VBR (Variable Bit Rate) con transferencias orientadas a conexión que necesitan sincronización end-to-end. 7.I-B.4 Servicios Clase D Los Servicios clase D incluyen a los servicios VBR que realizan transferencias no orientadas a conexión sin ningún requerimiento de sincronización end-to-end. Estos servicios son soportados por el protocolo AAL3/4 o AAL5. Fig Servicios Clase D Fig Servicios Clase B Ejemplos de estos servicios -mostrados en la Fig son la transmisión de video-on-demand, music-on-demand y voz codificada. El protocolo AAL2 es el apropiado para estos servicios aunque también es usado el AAL5. Para facilitar la transferencia de video digital, el flujo de bits debe ser comprimido. El método usado es la codificación MPEG2 que reduce en un factor de 20 la tasa necesaria (logrando tasas de 5-6 Mbps). El problema de las variaciones rápidas de la imágen, y por consiguiente un aumento rápido de la tasa de bits, es solucionado sincronizando el transmisor y receptor. Ejemplos de estos servicios son interconexiones de LAN, servicios SMDS (Switched Multimegabit Data Services) y fundamentalmente Internet, ver fig. 7.9 Se hace un estudio complementario para servicios multimedia sobre ATM en la sección 8.VII. Por mas información sobre ATM ver [24]. 7.II-A Introducción 7.II MPLS El crecimiento que han tenido las redes IP, con un firme apoyo en Internet, pero también en el gran uso de este tipo de redes como soluciones corporativas de grandes compañías ha colocado a este protocolo en una posición dominante frente a los demás. El advenimiento del paradigma de las redes convergentes ha obligado a adaptar las redes existentes

71 70 CAPÍTULO 7. PROTOCOLOS DE TRANSPORTE para cumplir con los requerimientos de los distintos tipos de servicios de telecomunicaciones. MPLS surgió como una solución para cumplir con las necesidades del management de ancho de banda, ingeniería de tráfico, escalabilidad y requerimientos de calidad de servicio, en las redes cuyos backbones son basados en IP. Pero como se vera más adelante, es más que eso ya que entre otras cosas brinda un estándar para la interoperabilidad de diferentes redes, como IP, ATM y Frame Relay. 7.II-A.1 Ruteo y Conmutación tradicional Los equipos que utilizan IP procuran enviar los paquetes normalmente de acuerdo al camino más corto, sin tener en cuenta otros parámetros como delay, jitter y congestión, que pueden causar una degradación mayor de la performance de la red. Se han buscado algunas soluciones a esta situación, como manejar caminos predefinidos. El problema de estas soluciones es que introdujeron en el cabezal IP de cada paquete, la información necesaria para ser tratados en forma diferencial en los distintos routers. Esto genera paquetes con encabezados de mayor largo, y a su vez variable. Aumentando el procesamiento de estos paquetes en cada router. ATM parece ser una mejor solución debido a que los diferentes tipos de servicios estandarizados permiten manejar los flujos de datos de acuerdo a la calidad de servicio que estos ofrecen. El problema de esta solución es que la mayoría de los datos que se mueven hoy por hoy en el mundo son datos IP, lo que ha llevado a la necesidad de implementar IP sobre ATM. La incapacidad de IP de ver ATM ha llevado a que la solución más usada, es crear en ATM circuitos virtuales entre todos los nodos, de manera que IP vea un camino de un nodo a todos sus vecinos. Esta solución trajo como consecuencia un problema importante en la escalabilidad de las redes, ya que a medida que estas crecen la estructura de red necesaria para tener un PVC entre cada nodo genera una cantidad de PVCs del orden de N 2 (siendo N el numero de nodos). Ver Fig flujos de datos sobre la red. Ref. [25] Tiene las siguientes funciones: Especifica la forma de manejar el tráfico de distintos tipos de flujos, así como flujos entre diferentes equipos, o incluso entre diferentes aplicaciones. Es independiente de los protocolos de capa 2 y 3. Provee una forma de mapear direcciones IP a etiquetas simples, de largo fijo usadas por distintas tecnologías de conmutación de paquetes o reenvío de paquetes. Sirve de interfase con protocolos de ruteo como RSVP o OSPF. Soporta los protocolos de capa 2 más usados como ATM, Frame Relay, Ethernet, etc. 7.II-A.3 Como funciona? En MPLS la transmisión de datos ocurre sobre LSP (Label Switching Paths). Cada LSP es una cadena de etiquetas, una por cada nodo, desde el origen al destino. Hay 2 formas en las que se establecen los LSP, una es antes de la transmisión y es generada manualmente o por los protocolos de control (Ej. BGP) y en la otra los LSP se crean a medida que se detectan los flujos de datos en los nodos. Estos dos procesos reciben la denominación de Control Driven y Data Driven respectivamente. Ver Fig La conmutación de alta velocidad de los paquetes es posible debido a que las etiquetas son de largo fijo y están insertadas en el cabezal de los paquetes (o celdas), de modo que no hay que desarmarlos para acceder a ellas, esto permite la conmutación de los paquetes a nivel de hardware. Ver Fig Fig Generación de Etiquetas en MPLS Fig Problema de escalabilidad de IPoATM 7.II-A.2 Que es MPLS? MPLS es una especificación del IETF, para proveer una designación, ruteo, reenvío y conmutación eficiente de los 7.II-A.4 Porque usar MPLS? Combina las mejores propiedades de IP con las de conmutación de circuitos. reenvío muy rápido de celdas y paquetes. Permite ingeniería de tráfico sobre IP. Posibilidad de usar switches ATM ya instalados. Control de calidad de servicio sobre IP, permite manejar en forma apropiada servicios como voz y video. La capacidad de manejar túneles facilita la administración de la red, así como también es sumamente apropiada para la generación de Redes Privadas Virtuales (VPN)

72 71 instalado en el núcleo de la red MPLS. Tiene dos funciones fundamentales: 1) Participa en la creación de los LSPs usando alguno de los protocolos de señalización creados para manejar la creación e intercambio de etiquetas. 2) Sirve como conmutador (switch) de paquetes de alta velocidad basado en los LSP establecidos. Fig Conmutación por etiquetas Es multiprotocolo tanto en las capas inferiores como en las superiores. Ver Fig LER El LER es el dispositivo que opera en el borde entre la red de acceso y la red MPLS. Por esto un LER soporta múltiples protocolos y múltiples interfases de red (ATM, Frame Relay, Ethernet). Es el encargado de reenviar los flujos de datos de cualquiera de estas redes hacia la red MPLS luego de haber creado el LSP, así como de devolver el tráfico de regreso hacia las primeras. Este dispositivo es el encargado de asignar y remover las etiquetas al ingreso o egreso de la red MPLS. Fig Independencia de protocolos 7.II-A.5 Terminología y conceptos básicos de MPLS LSP: Label Switched Path LSR: Label Switching Router LER: Label Edge Router FEC: Forwarding Equivalence Class LDP: Label Distribution Protocol LSP Como se mencionó antes, es el camino que seguirá un flujo de datos a lo largo de la red MPLS. Este camino está determinado por la etiqueta que tienen los paquetes de cada flujo. Ver Fig FEC Es un grupo de paquetes que requieren el mismo tratamiento en su transporte. El mapeo de un paquete a una FEC es asignado una sola vez al ingreso en la red MPLS (recordar que en IP la dirección es comparada contra la tabla de ruteo en cada paso). Una FEC se puede generar por ejemplo para todos los paquetes que tienen un mismo origen, pero también para paquetes de un tipo de servicio especifico, aunque estos provengan de orígenes diferentes. Cada LSR genera una tabla donde almacena el tratamiento que se debe dar a los paquetes de cada FEC. Esta tabla se llama LIB (Label Information Base), y establece por un lado las relaciones Etiquetas-FEC y por otro el mapeo FEC-Siguiente Paso. Este mapeo indica para cada LSR cual es el siguiente nodo que corresponde a una FEC determinada. Esta información es todo lo que se necesita para reenviar los paquetes paso a paso entre origen y destino. Ver Fig Cuando un paquete llega a un LSR, lo único que este debe hacer es mirar su etiqueta, la cual indica a que FEC pertenece, esto a su vez permite identificar a que LSR será reenviado y la prioridad con la que el paquete será tratado. Ver Fig Fig Label Switched Path LSRs y LERs Son los dispositivos que participan activamente para implementar MPLS. Un LSR es un router de alta velocidad Fig Creación de la tabla de conmutación por etiquetas Ejemplos de distintas FEC podrían ser:

73 72 CAPÍTULO 7. PROTOCOLOS DE TRANSPORTE Fig Forward Equivalence Class Un conjunto de paquetes cuya dirección de red de destino es cierta IP especifica. Un conjunto de paquetes multicast cuyas redes de origen y destino son las mismas. Un conjunto de paquetes cuya red de destino es la misma y cuyos bits de Tipo de Servicio (ToS) son iguales. Una característica importante del concepto de FEC, es su capacidad de manejar reenvío de paquetes a diferentes escalas. Por ejemplo un FEC podría estar formado por todos los paquetes destinados a una cierta a red de destino. Pero también una FEC puede incluir solo los paquetes que pertenecen a una aplicación especifica con el mismo IP de origen y destino. Esta capacidad es sumamente importante para permitir la relación dual entre la necesidad de establecer tratamientos especiales a ciertos flujos de datos (Ej. QoS) y escalabilidad de la red cuando ésta es de dimensiones importantes. LDP La función básica del protocolo de distribución de etiquetas es que los LSR adyacentes sean consistentes en cuanto a que etiquetas usar para cada FEC. Esto es indispensable para una creación adecuada de los LSP. Un cambio en la configuración física de la red, la llegada de nuevos tipos de flujos de datos, o la voluntad del administrador de la misma de cambiar la forma en la que ciertos flujos deben ser tratados, genera nuevas relaciones Etiquetas-FECs, así como FEC-Próximo Nodo. Esto crea la necesidad de que los LSRs intercambien información en forma asidua sobre las etiquetas a ser usadas para cada FEC y cual es el LSR al que los paquetes de cada FEC deben ser enviados. En el caso que se opte por el esquema de distribución de etiquetas llamadas control-driven, una primera forma de distribuir esta información es usar los protocolos de ruteo existentes. Como se vio anteriormente para hacer posible el envío de paquetes entre LSRs es necesario tener tanto la relación Etiqueta-FEC como FEC-Próximo Nodo. Es claro que si la distribución de etiquetas se realiza como carga en los protocolos de ruteo, nunca faltara una de estas relaciones si la otra existe. Esta opción de distribución parece ideal ya que además simplifica la operación, y parece eliminar la necesidad de crear un protocolo independiente que se encargue de la distribución de etiquetas, pero se vera a continuación que esta forma de distribución tiene algunos inconvenientes insalvables. El primer inconveniente es que existen protocolos de ruteo que manejan información que no permite crear relaciones entre FEC-Siguiente Nodo. Por ejemplo OSPF no intercambia información suficiente para establecer dichas relaciones. En cambio otros protocolos como BGP y PIM si son adecuados. Sin embargo aun los protocolos adecuados para distribución de etiquetas, deben ser extendidos. Esto implica la modificación de los mensajes a ser utilizados y esto los torna incompatibles hacia atrás. Para evitar estos problemas mencionados IETF creo un protocolo especial de distribución de Etiquetas e información de FECs. Este protocolo es llamado LDP. LPD está formado por los siguientes mensajes: Mensajes de descubrimiento (sobre la presencia de los LSR vecinos), Mensajes de sesión (establecimiento, manutención y finalización de sesiones), Avisos (creación cambio y eliminación de mapeos de FECs) y Mensajes de Notificación (información y señalización de errores). Un resumen de los distintos esquemas usados para el intercambio de etiquetas entre los LSR es: LDP: Usado para mapear direcciones IP a etiquetas. RSVP, CR-LDP: usados en casos que se quiere realizar ingeniería de tráfico, y reservación de recursos. PIM (Protocol Independient Multicast): Usado para intercambio de etiquetas multicast. BGP: Usado para VPNs. 7.II-B Etiquetas 7.II-B.1 Introducción Una etiqueta es una entidad corta, de largo fijo. La misma no tiene porque hacer referencia a ninguna información de la red. Una vez que un paquete es identificado como perteneciente a una FEC al mismo se le asigna una etiqueta. Cada LSR examina la etiqueta de los paquetes entrantes y así identifica cual es el siguiente nodo que corresponde a ese paquete. Las etiquetas solo tienen valor local, es decir entre dos LSR vecinos, cuando un paquete sale de un LSR lleva una etiqueta que será cambiada en el siguiente salto. Cada LSR puede manejar etiquetas únicas para todo el LSR o únicas por interfase. Para aclarar ideas se establece una analogía entre una red y un sistema vial. Se puede ver en la Fig 7.17, que se le indica a todo coche que está usando el carril #1 de la Avenida A, que debe girar a la derecha y seguir por el carril #2 de la Avenida B. En esta analogía algunos de los paquetes que pertenecen a un flujo de datos (Avenida A) están identificados con la etiqueta (carril #1), y al llegar al LSR (lugar de cambio de camino) solo en base a esta Etiqueta se le indica como llegar a su Siguiente Nodo (Avenida B) y que etiqueta debe llevar para ser identificado (carril #2). La asignación de etiquetas puede estar basada en: destino, QoS (Quality of Service), ingeniería de tráfico, VPNs, etc. El formato genérico de las etiquetas se muestra en la Fig MPLS se creo para funcionar sobre múltiples capas de enlace. Actualmente hay especificaciones para ATM, Frame Relay, PPP y Ethernet.

74 73 Fig Analogía Red, sistema Vial ser únicas por LSR o únicas por interfase. Se usa un stack de etiquetas (tipo LIFO) de manera de permitir varios niveles de FECs, lo que ayuda como se menciona anteriormente a manejar flujos de datos de diferentes jerarquías. Las decisiones de reenvío tomadas por los LSR se basan siempre en la etiqueta superior del stack. Desde el punto de vista de la selección de caminos se permite que el Ruteo sea Nodo a Nodo (Hop by Hop) así como Ruteo Explícito. La creación de etiquetas puede ser Manejada por Control (Control Driven) o Manejada por Datos (Data Driven), pero es conveniente la utilización del sistema Control Driven. Finalmente se establece métodos para evitar así como detectar la formación de loops. La Etiqueta puede estar contenida en el encabezado de la capa 2 (ATM VCI/VPI o Frame Relay DLCI) o en un encabezado de relleno (shim header) colocado entre el encabezado de capa 2 y el de capa 3 (PPP y Ethernet y demás protocolos de capa 2 usan este formato). Fig Formato de Etiquetas Se estudia ahora los distintos campos del encabezado de relleno: EXP.: es el campo de CoS (Class of Service). Fue llamado Experimental, porque en el momento de estandarizar el encabezado, todavía no estaba 100% definido que seria usado para CoS. Stack: Las jerarquías en MPLS son manejadas colocando etiquetas unas sobre otras en un stack. Este campo es usado para indicar la ultima etiqueta del stack, es decir el nivel de jerarquía inferior. TTL: este campo (Time To Live) tiene dos posibles configuraciones. La primera es emular exactamente el funcionamiento que el mismo tiene en IP, es decir al entrar en la red MPLS el campo de IP es copiado a este campo, luego es decrementado en cada nodo que atraviesa y al salir de la red MPLS es copiado en su par de IP. La segunda opción es hacer la red MPLS transparente a herramientas como el trace y esto se logra copiando el TTL desde IP al ingreso y volviendo a colocarlo en el paquete IP al salir de la red MPLS pero sin decrementarlo. La arquitectura de MPLS usa asignación Downstream (lo que quiere decir en el sentido inverso del flujo de datos) de etiquetas. Se admite la distribución bajo demanda así como la distribución no solicitada de las mismas. Las etiquetas pueden 7.II-B.2 Creación de Etiquetas (Control Driven vs. Data Driven) Los LSRs crean o destruyen etiquetas como resultado de ciertos eventos. Estos eventos disparadores de la creación de etiquetas pueden ser resultado de la llegada de paquetes que necesitan ser reenviados así como resultado de llegada de información de control (ruteo). (Ej. actualización de rutas de OSPF, mensaje JOIN/PUNE de PIM y un mensaje de reserva de recursos de RSVP). Cuando la creación o destrucción de etiquetas y sus relaciones con FEC son generadas por paquetes, se les llama creación Manejada por Datos (Data driven). Cuando la creación o destrucción de las mismas son disparadas como consecuencia de información de control, se les llama creación Manejada por Control (Control Driven). Hay un rango muy variado de formas de crear etiquetas en ambos modos. Por ejemplo en el modo de creación Manejada por Datos, un LSR puede crear las etiquetas y sus relaciones con las FEC tan pronto como el primer paquete de un flujo de datos llega al LSR, o puede esperar hasta ver una cantidad importante de paquetes de ese flujo que le determine al LSR la necesidad de crea una relación Etiqueta-FEC. La elección de una u otra forma puede tener un impacto importante en la performance, escalabilidad o robustez de la red. Se analizaran las consecuencias sobre cada uno de estos parámetros: 7.II-B.2.a Performance: Si se crean etiquetas para cada flujo de datos de cada aplicación y estos son de muy larga duración el costo en tiempo de crear un camino conmutado es amortizado por la duración del mismo. El problema es que es sabido que hay una cantidad de flujos que envuelven una pequeña cantidad de paquetes. Es posible sin mucho esfuerzo generar algoritmos sencillos de detección de flujos del estilo: generar etiquetas para flujos que tengan una cantidad mayor a N paquetes. La operación normal será utilizar el reenvío convencional de IP para todos los paquetes que no estén contenidos en esta especificación. Lo difícil es dimensionar N y el problema atrás de esto es que un dimensionamiento de N hacia cualquiera de los dos extremos acarrea un problema en la performance de la red. Analicemos la situación de determinar un N pequeño, entonces se comenzarán a crear mucho caminos conmutados, pero esto además de problemas de escalabilidad para manejarlos implica un problema mayor: el tiempo requerido y los recursos destinados por la red para formarlos.

75 74 CAPÍTULO 7. PROTOCOLOS DE TRANSPORTE Si por el contrario se dimensiona un N muy grande todos los paquetes de todos los flujos (de cantidades de paquetes menores que N) hasta el paquete N-1 serán reenviados usando el protocolo de reenvío convencional de IP, el cual se sabe es mucho menos eficiente que cuando se reenvían por caminos establecidos (de lo contrario porque generarse la molestia de crear los caminos conmutados?), por lo tanto se obtendrá una performance menor a la ideal. El problema de dimensionar N está agravado por la poca información que se tiene del estado de diferentes redes dado la renuencia de sus administradores a compartir sus análisis de tráfico interno. Por otro lado un caso que afecta la performance sobre todo cuando se usa creación de etiquetas Manejada por Control es cuando nuevos nodos son agregados a la red. Estos cambios en la topología de la misma, generan normalmente nuevos caminos para llegar de un lado a otro, y esto genera un retardo hasta que los protocolos de ruteo o el LDP intercambian la información necesaria para establecer los nuevos LSP más convenientes. Durante este tiempo los routers probablemente tengan que seguir usando los caminos anteriores o recurrir al reenvío de datos por el sistema tradicional de IP. De todos modos este impacto es bastante menor que el estudiado anteriormente ya que en general los cambios de topologías se dan con conocimiento previo del administrador de la red (salvo en los casos de fallas para los cuales siempre hay que tener LSP alternativos establecidos). 7.II-B.2.b Escalabilidad: Una forma de aproximarse a los problemas de escalabilidad es estudiando cuantas etiquetas necesitan ser asignadas en distintos escenarios. Se puede ver sin mucho esfuerzo que si se utiliza la creación de etiquetas Manejada por Datos y se elige en forma incorrecta el algoritmo de detección de flujos se incrementa la cantidad de etiquetas creadas. Un ejemplo real mostrado en la Ref. [26] muestra que al aumentar el numero de paquetes analizados antes de considerar la asignación de etiquetas es beneficioso. Esto se debe a que al aumentar N, la mejora en la escalabilidad causada por el descenso de etiquetas asignadas, es más significativo que el detrimento de la performance causado por el aumento de paquetes a ser reenviados por IP tradicional. Al usar creación de etiquetas Manejada por Control la escalabilidad en lugar de estar relacionada con la naturaleza del tráfico está más determinada por la topología y el diseño de la red. Esto lo hace más visible para el administrador y por ende más fácil de controlar. 7.II-B.2.c Robustez: La robustez de una red está relacionada a que tan sensible es la performance y la escalabilidad de la misma a cambios en que se puedan dar en la red. Por lo visto anteriormente es fácil ver que los cambios en el comportamiento de los flujos de datos son mucho menos predecibles que los cambios en la información de control. Como ejemplo, se supone la creación de una nueva aplicación de Internet que tienen un gran numero de flujos muy cortos. Esto repentinamente incrementaría la cantidad de datos que deben usar el sistema de reenvío tradicional de IP y por ende una degradación de la performance de la red. Este es solo un ejemplo, pero se pueden pensar otros, en los que cambios de comportamiento de los usuarios pueden cambiar el análisis de tráfico para el cual fueron diseñados los protocolos de detección de flujos. En cambio es difícil que cambios radicales se den en cortos períodos de tiempo en lo que tiene que ver con información de ruteo. Solo un cambio radical en la forma en que la red está hecha como la inclusión de nodos de gran ancho de banda de redes móviles, podría causar tales cambios en el esquema de creación de etiquetas Manejada por Control y seguramente este cambio pueda ser previsto por el administrador de la red. Como conclusión la creación de etiquetas Manejadas por Control es lo más recomendables para redes de gran envergadura. 7.II-B.3 Distribución de Etiquetas 7.II-B.3.a Distribución bajo demanda: 1) El LSR1 reconoce al LSR2 como su siguiente nodo para una FEC determinada. 2) Le solicita al LSR2 una etiqueta a ser usada para el FEC correspondiente. 3) Si el LSR2 reconoce la FEC por la que recibió la solicitud y tiene un siguiente nodo para ésta, crea una relación FEC-Etiqueta y envía ésta como respuesta al LSR1 Ver Fig II-B.3.b Distribución no solicitada: 1) El LSR2 y el LSR1 saben que tienen una adyacencia de LDP (LSR2 está más cerca del destino del flujos de datos) 2) El LSR2 descubre un Siguiente Nodo para una FEC particular. Entonces genera una etiqueta para esa FEC y le comunica la misma al LSR1 3) EL LSR1 inserta esa relación FEC-Etiqueta en su tabla de reenvío 4) Si el LSR2 es el Siguiente Nodo de esa FEC el LSR1 puede usar la etiqueta que recibió. Ver Fig II-B.4 Control de Etiquetas 7.II-B.4.a Modo de Distribución Ordenada: En este modo de control de distribución de etiquetas las relaciones Etiquetas-FEC son generadas únicamente por los LSR de egreso (LER) de cada FEC. A partir de ahí las etiquetas se propagan ordenadamente en sentido contrario al flujo de datos (de egreso a ingreso). De esta forma solo el LSR que es el next hop aguas arriba de una determinada FEC puede enviar una etiqueta para ser asociada a esa FEC. 7.II-B.4.b Modo de Distribución Independiente: En este modo de control de distribución de etiquetas cada LSR decide en forma independiente sobre cuando y como generar relaciones Etiqueta-FEC. Una vez generadas y apenas se reconoce el próximo nodo le comunica las mismas. Esto quiere decir que las etiquetas se propagan desde cualquier

76 75 Fig Métodos de retención de Etiquetas 7.II-B.5.b Modo Liberal: En este modo se conservan aquellas relaciones Etiqueta-FEC recibidas desde LSRs que no son el siguiente nodo para dicha FEC. Este modo permite una adaptación rápida al cambio de topología en la red. Ver Fig7.20 Fig Distribución de etiquetas punto de partida hacia el nodo de egreso. Comparación: Se puede ver que con el Modo Independiente cada router toma su propia decisión sobre como repartir los paquetes entrantes en las distintas FEC. El problema que se puede dar es que su LSR vecino tome una decisión diferente, lo que resultaría en la imposibilidad de generar LSP para algunas FECs. Si bien esto se puede evitar configurando routers vecinos para que no pase, la posibilidad existe. Estos problemas no se pueden generar en el Modo Ordenado. también este ultimo modo tiene ventajas importantes en la prevención de la formación de loops, mientras que el Modo Independiente necesita de software de señalización extra para detectar y evitar la formación de los mismos. En contraposición al uso del Modo Ordenado, está el problema de retardo que hay hasta la creación del LSP. Esto se debe a que las relaciones Etiquetas-FEC se deben propagar a lo largo de toda la red antes que quede establecido el LSP, durante este tiempo de establecimiento los paquetes en tránsito deben ser descartados o ruteados de acuerdo al modo tradicional, lo cual es perjudicial a la performance de la red. Entonces se ve que uno de los principales beneficios del Modo Independiente es el rápido restablecimiento frente a cambios de topología de la red. 7.II-C Ruteo 7.II-C.1 Ruteo Nodo a Nodo En el camino hacia el destino B, hay que preguntar paso a paso cual es el camino a tomar para llegar a B. Características: Los caminos se generan sin un orden especifico. En la eventualidad de una falla, el sistema puede auto restaurarse pero el tiempo de recuperación es dependiente del protocolo de ruteo. Los protocolos existentes están desarrollados para ruteo en base a direcciones IP y no a otros parámetros de servicio. Es muy difícil de desarrollar ingeniería de tráfico o brindar una QoS adecuada de esta forma. 7.II-C.2 Ruteo Explícito El paquete acarrea una etiqueta, que es equivalente a tener una lista de por cuales LSRs pasar para llegar hasta B. La etiqueta funciona como lista, aunque en la realidad la lista está distribuida en los diferentes LSR. Ver Fig II-B.5 Retención de Etiquetas Está definida la forma en que se trataran las relaciones Etiqueta-FEC que se reciban de LSRs que no sean el siguiente nodo para una FEC dada. Se definen dos modos alternativos. 7.II-B.5.a Modo Conservativo: En este modo se descartan todas aquellas relaciones Etiqueta-FEC recibidas desde LSRs que no son el siguiente Nodo para dicha FEC. Fig Ruteo Explícito ER LSP Características: Se genera un camino de origen a destino. Normalmente necesita una creación manual de caminos.

77 76 CAPÍTULO 7. PROTOCOLOS DE TRANSPORTE Los LSPs pueden ser clasificados y en caso de falla se pasa de un LSP a otro en tiempos muy cortos. Hay flexibilidad en el ruteo, está permitido la creación en función de QoS o de cierta política de ruteo y no solo en función del camino más corto. Es sumamente adecuado para generar ingeniería de tráfico. Comparación de Ruteo explícito de MPLS con el ruteo estándar de IP: La naturaleza de protocolo no orientado a conexión de IP hace que en caso de querer explicitar una ruta toda la información de ésta deba estar contenida en el cabezal del paquete. Este procedimiento es llamado Source Routing. Caminos largos incrementan el tamaño del cabezal de los paquetes y los hacen de largo variable, esto además de incrementar el overhead hace más dificultoso y lento el procesamiento de los paquetes en cada nodo. Source routing no se ha adoptado por la mayoría de las redes IP debido a que es bastante impráctico. MPLS habilita el ruteo explícito ya que tiene capacidades de protocolo orientado a conexión. Esto se realiza sin modificar el tamaño de las etiquetas las cuales se mantienen pequeñas y de largo independiente del largo del camino. Desventajas del ruteo explícito de MPLS: Hay propuestas dos opciones de señalización como estándar, CR-LDP y RSVP extendido: 1) CR-LDP= LDP + Ruta Explícita 2) RSVP ext= RSVP + Ruta explícita + extensiones de Escalabilidad El inconveniente de tener estandarizadas dos opciones es que el mercado finalmente terminara imponiendo una de ellas y esto generara que todo aquel que haya trabajado en la otra deba cambiarla. 7.II-D Funcionamiento MPLS Los siguientes pasos son realizados cuando un paquete atraviesa una red MPLS: 1) Creación de etiquetas y distribución de las mismas. 2) Creación de la tabla Etiquetas-FEC en cada LSR 3) Creación del LSP 4) Insertar etiquetas en el paquete / Búsqueda en la tabla 5) Reenvío de paquetes Ver Tabla 7.II y Fig II-E Ingeniería de Tráfico La ingeniería de tráfico es un proceso que tiende a mejorar la utilización de la red en general, tratando de manejar el tráfico en forma uniforme o diferencial. Un resultado importante que se trata de lograr es eludir congestiones en cualquier punto de la red. Cabe notar que esto no implica mover todos los paquetes por el camino más corto sino que buscar los caminos menos congestionados para los flujos de datos preferenciales. Fig Ejemplo de funcionamiento MPLS O generar ciertos caminos para flujos con características especiales. Esto precisamente es lo que se llama Ruteo Restringido (CR de su sigla en ingles Constrained Route) 7.II-E.1 CR (Constrained Route) La principal diferencia entre el ruteo convencional IP y el ruteo CR es que los algoritmos de ruteo IP buscan caminos que optimicen alguna medida escalar (ej. minimizar la cantidad de nodos), mientras que el ruteo CR exige además no violar cierto grupo de restricciones impuestas en ningún tramo de la ruta. Estas restricciones pueden especificar parámetros como ancho de banda, retardo, latencia y QoS. De esta manera se puede especificar exactamente el tipo de nodos por los que debe pasar el flujo de datos así como parámetros de tratamiento en cada nodo. Como ejemplo el protocolo SPF (Shortest Path First) utiliza un algoritmo de comparación de distancias entre los nodos. De este modo en base a una métrica definida para establecer la distancia se decide que nodos pertenecen al camino que se elegirá como SPF. La ampliación de este protocolo a CSPF (Constrained Shortest Path First) exige que antes de evaluar la métrica entre 2 nodos se verifique si ese enlace cumple las restricciones mínimas impuestas por el administrador (ej. Ancho de banda mínimo =x). Si el enlace entre esos nodos no las cumple, el mismo ni siquiera será evaluado, para saber si puede pertenecer o no al camino más corto. Esto que se ha mencionado permite tener otra conclusión sobre que protocolos pueden o no ser ampliados para operar junto con las restricciones. Es claro que para que el protocolo pueda verificar las restricciones (Ej. ancho de banda mínimo) el protocolo de ruteo a usar debe ser capaz de tener información de estado del enlace. Es por esto que protocolos como OSPF y IS-IS pueden ser usados mientras que otros como RIP no, ya que estos la única información que manejan de los enlaces es si su estado es activo o inactivo. Una vez determinado el camino conveniente de acuerdo a la distancia y las restricciones de cada flujo, es necesario asegurarse de que todos los paquetes pertenecientes a ese flujo sean enviados a través de él. Es aquí donde MPLS juega un papel importante ya que lo único necesario para lograr esto es establecer un LSP y luego de esto el solo hecho de etiquetar los paquetes lo estarán incluyendo en un ruteo explícito.

78 77 TABLA 7.II FUNCIONAMIENTO DE MPLS Es por esto que en MPLS la ingeniería de tráfico está estrechamente ligada con el ruteo explícito. Hay dos modos de generar ruteo explícito con MPLS, CR- LDP y RSVP mejorado (TE-RSVP). Se hará aquí una brevísima descripción de cómo cada uno de estos protocolos genera el LSP, por una descripción más detallada ver Ref.[26] 7.II-E.1.a TE-RSVP: Es RSVP extendido para permitir ingeniería de tráfico mediante la asignación de etiquetas y especificación de ruteo explícito. Maneja un nuevo objeto llamado ERO (Explicit Route Object). Este objeto es transportado dentro del mensaje PATH del RSVP y contiene una secuencia ordenada de nodos que especifica la ruta que los paquetes deben seguir. Como ejemplo se ve a continuación como se genera la ruta de acuerdo a la Fig Suponga que de acuerdo a los protocolos CR-SPF se determino que se quiere establecer una ruta explícita que parta del LSR1 y pase por los siguientes nodos: LSR2, LSR6, LSR7, LSR4. Entonces el LSR1 crea un ERO que contiene la secuencia de los 4 nodos (como ejemplo el ERO puede contener la IP v4 de cada uno de los LSR). El LSR1 luego crea un mensaje RSVP PATH que incluye el ERO y también un objeto LABEL REQUEST. Después de construido el mensaje el LSR1 examina el primer nodo del ERO y encuentra el enlace que lo une con este, luego envía el mensaje a través de ese link. Cuando el LSR2 recibe el mensaje PATH y ve que en ese mensaje el primer nodo del ERO busca el siguiente nodo y envía otro mensaje RSVP PATH con un nuevo ERO donde figuran los nodos restantes (LSR6, LSR7, LSR4) y que también incluye un objeto LABEL REQUEST. Este procedimiento se repite en todos los nodos intermedios hasta que un mensaje que contiene un solo LSR en el objeto ERO llega al nodo final del LSP (LSR4). En este momento el LSR4 crea un mensaje RSVP RESV y lo envía al LSR7. Este mensaje incluye entre otras cosas un objeto LABEL que indica al LSR 7 que etiqueta usar para el LSP que se está creando. Este paso propaga mensajes RESV con las etiquetas correspondientes por el camino inverso al que llevo los mensajes de RSVP PATH desde el LSR1 al LSR4. En este momento el LSP ha sido establecido de acuerdo a una ruta explícita. Notar que además de establecer el camino, se pudo haber establecido parámetros de QoS del LSP usando otros objetos dentro de los mensajes RSVP. 7.II-E.1.b CR-LDP: Es una extensión de LDP para manejar especificación de ruteo explícito y reserva de recursos en los nodos. Para establecer un LSP de acuerdo a una ruta explícita CR-LDP incluye un objeto nuevo. La estructura de este objeto es prácticamente igual a la del ERO. El

79 78 CAPÍTULO 7. PROTOCOLOS DE TRANSPORTE requerir alguna de estas clases según el tipo de servicios que requieran de la red. Guaranteed Service tiene un costo, ya que requiere que cada flujo que la este usando sea enrutado por separado y con su ancho de banda mínimo reservado, lo que resulta en una mala utilización de los recursos de la red. Controlled Load no tiene esos problemas ya que lo que el servicio que recibe es el comparado al que recibiría solo si estuviera en una red dimensionada para esa aplicación y sin ningún otro tipo de carga. Para esto la red se asegura simplemente de encolar y mover los paquetes de los otros flujos de manera que no degraden la performance del primero. Fig Creación de LSP usando TE-RSVP procedimiento para crear el LSP es exactamente igual al explicado para RSVP. Es más, el mismo ejemplo puede ser usado aquí con solo cambiar los mensajes RSVP PATH y RSVP RESV por LABEL REQUEST y LABEL MAPPING respectivamente. Cabe agregar que CR-LDP también permite configurar parámetros de QoS en todos los nodos del LSP a medida que lo va creando. Entonces, cual es la diferencia entre usar TE-RSVP y CR-LDP? La diferencia entre ambos protocolos técnicamente se pueden dividir en mecanismos de señalización, escalabilidad y modelos de QoS. Se presenta aquí una tabla comparativa de ambos protocolos. Ver Tab. 7.III. 7.II-F Calidad de Servicio QoS Lo primero que corresponde aclarar es que la QoS que ofrece MPLS no es esencialmente diferente a la ofrecida en IP. La implementación en MPLS de las mismas funciones de QoS de IP tiene algunas ventajas, sobre todo referidas a eficiencia y a la posibilidad de implementarlas sobre una gama más amplia de plataformas. Hay dos modelos para implementar QoS en IP y los mismos son Integrated Services (Int-Serv) y Differenciated Services (Diff-Serv). 7.II-F.1 Integrated Services Normalmente es considerado como un sinónimo de RSVP aunque no es así. Integrated Services es el nombre de la arquitectura de QoS creada por el IETF. Parte de lo generado por el grupo de trabajo del IETF fueron las especificaciones de varias Clases de Servicio (CoS) creadas para satisfacer las necesidades de varios tipos de aplicaciones. Este mismo grupo definió cómo el protocolo de señalización RSVP podría ser usado para hacer los pedidos de QoS usando las Clases de Servicio mencionadas. En Int-Serv cada aplicación puede especificar que tipo y cantidad de tráfico inyectará en la red y el nivel de QoS que le gustaría obtener para el mismo. La especificación de tráfico se conoce como Tspec y el pedido de cierta QoS como Rspec. Las clases de servicio definidas por el grupo Int-Serv son: Guarateed Service (servicio garantido) y Controlled load (carga controlada). La primera intenta cumplir los requerimientos de aplicaciones que necesita una garantía estricta de ancho de banda y delay. Las aplicaciones pueden optar por RSVP al ser usado para señalizar los pedidos y reservaciones de Int-Serv debe encargarse de dos cosas: 1) Clasificación de los flujos reconociendo cuales necesitan que parámetros de QoS. Esta información incluye IP de origen y destino y puerto UDP. 2) Especificación de tráfico y sus parámetros de QoS, para esto usa Tspec y Rspec. Esto es decirle a cada router como reconocer (en función de las IP de origen destino y puertos UDP) los paquetes de cada flujo y con que parámetros de QoS tratarlos. Finalmente RSVP debe encargarse de tener toda esta información actualizada, ya que como se mencionó anteriormente RSVP es un protocolo soft state, lo que quiere decir que toda la información debe actualizarse continuamente, porque en caso de no ser así, luego de un time out se entiende que hay que darla de baja. Es decir que todas las reservaciones generadas en un router con respecto a un flujo, son dadas de baja si después de cierto tiempo este no recibe nuevamente los mensajes de PATH y RESV correspondientes. 7.II-F.2 Differenciated Services Este otro modelo creado por el IETF que elude la necesidad de mantener estados de reservaciones para cada micro-flujo, ya que esto se torna en un problema de escalabilidad en redes IP grandes. En lugar de reservar recursos de la red por aplicaciones Diff-Serv divide los flujos de la misma en clases y reserva recursos en base a dichas clases de flujos. Al definir pocas clases de tráfico, la información de la clase a la que pertenece el paquete puede estar incluida en el propio paquete. De este modo no es necesario un protocolo de señalización como RSVP en Int-Serv para decirle a cada router que flujo necesita que tratamiento. La marca en el paquete es llamada DSCP (Differenciated Services Code Point). Este está contenido en un campo de 6 bits en el encabezado IP. Cuando un Router recibe un paquete marcado con cierto DSCP el primero sabe como debe ser tratado el paquete desde el punto de vista de QoS. Formalmente lo que el router hace es comparar el campo de 6 bits con su tabla de PHB (Per Hop Behavior) en la que se indica que tratamiento dar al paquete. Quien se encarga de la asignación de los DSCP es el equipo terminal. Por ejemplo un host que quiere establecer una llamada telefónica seteará el DSCP de acuerdo a los requerimientos de esta.

80 79 TABLA 7.III COMPARACIÓN RSVP VS. LDP 7.II-F.3 MPLS y RSVP La primer meta de MPLS para manejar RSVP es habilitar a los LSR (los cuales clasifican paquetes en función de Etiquetas y no de IPs) a identificar los paquetes que pertenecen a flujos que reservaron QoS. Es decir generar una FEC para los flujos que tengan reservaciones RSVP. Para esto se usa el mismo objeto mencionado en ingeniería de tráfico (LABEL) de modo que este objeto es incluido en los mensajes RESV. De este modo los mensajes RESV usando el objeto LABEL establecen un LSP y además el resto de la información de estos mensajes permiten a los LSR asociar los recursos de QoS asociados a cada LSP. En resumen se ejecutan todas las funciones normales asociadas a Int-Serv de un router corriendo RSVP y además se establece una etiqueta a ser usada por los paquetes pertenecientes al flujo específico. A partir de ese momento solo el LSR de entrada (y no todos los routers) debe analizar (mirando todo el encabezado IP) que paquetes pertenecen a cada flujo de los

81 80 CAPÍTULO 7. PROTOCOLOS DE TRANSPORTE que tienen parámetros de QoS reservada. Esto hace a MPLS RSVP más eficiente. Finalmente otra ventaja es que MPLS define otro objeto RSVP que se incluye en el mensaje PATH y es el objeto LABEL REQUEST. Este objeto cumple dos funciones. Primero es usado para comunicarle al LSR del final del camino que envíe de retorno un mensaje RESV para establecer un LSP. Segundo ese LSP pude ser establecido para cualquier grupo de paquetes y no solo cada micro flujo IP, este objeto tiene un campo que permite definir LSP a ser usados por un protocolo especifico de una capa superior, lo que habilitaría a crear LSP que transportarán paquetes IPX, Ipv4, Ipv6, etc. 7.II-F.4 MPLS y Diff-Serv Nuevamente como el DSCP está incluido en el encabezado IP y los LSR no examinan dichos encabezados debe establecerse una forma en la que MPLS permita establecer vínculos entre PHB y Etiquetas. Hay dos métodos propuestos para establece esto: 1) Usar el campo Exp. del encabezado de la etiqueta. El inconveniente de este método es que dicho campo solo tiene 3 bits mientras que diff-serv maneja 6 bits. Es claro que este método solo permite diferenciar 8 clases de QoS mientras que Diff-Serv prevee 64. Este método se conoce como E-LSP 2) La segunda opción es establecer LSP con diferentes etiquetas según la QoS que se quiera dar. En este caso se genera una asociación entre la tabla PHB y la Etiqueta Es claro entonces que los protocolos de distribución de etiquetas a ser utilizados deben incluir la posibilidad de establecer relaciones Etiquetas-FEC y Relaciones Etiquetas-PHB. Este método se llama L-LSP. En la tabla 7.IV se comparan los modos E-LSP y L-LSP. 7.II-G MPLS y ATM Ya se mencionaron en este documento varias desventajas de utilizar IP sobre redes ATM, algunas de las cuales son que la nube ATM es invisible al ruteo de capa 3, que para hacer posible el ruteo IP sobre la nube ATM es necesario establecer una malla de VCs entre todos los nodos ATM con los problemas que esto además causa al generarse un cambio de topología. Todo estos problemas pueden ser eliminados (o al menos reducidos) al aplicar MPLS sobre redes ATM. Hay varios modelos en que redes ATM y MPLS puede coexistir y operar. Aquí se listan como: ATM controlado por Etiquetas. Naves en la Noche Túnel sobre ATM 7.II-G.1 ATM controlado por Etiquetas. Esta técnica combina el reenvío simple y rápido de celdas ATM con el ruteo de la capa de red de IP y el control de TCP. Fig ATM controlado por Etiquetas Usa el hardware ATM para hacer Label Switching y reemplaza el Soft the ATM por IP/MPLS. Ver Fig Desde la perspectiva de ATM, MPLS puede ser visto como otro plano de control que solo se ocupa del tráfico y ruteo IP. Podría decirse que es otra forma de crear un VC en ATM, con la diferencia que MPLS le llama un LSP. La diferencia fundamental reside en el hecho que MPLS no utiliza direcciones ATM, ni ruteo ATM, donde los protocolos del ATM Forum ya no se usan y en su lugar usar LDP. En general MPLS es utilizado para crear y distribuir relaciones FEC-Etiquetas de modo que el tráfico IP pueda ser reenviado en forma más eficiente. El trabajo de este ATM-LSR es mucho menor porque un ATM-LSR solo crea la ruta con los nodos adyacentes es decir que cada LSR no conoce al LSR al otro lado del VC. En la capa ATM la etiquetas (VCI, VPI) asociadas con un VC son cambiadas en cada switch ATM y por esto no es posible utilizarlas para identificar un VC en los mensajes de mapeo de etiquetas intercambiado entre los LSRs. Cuando un flujo es mapeado a un VC, es necesario asociar un identificador especial, el VCID (Virtual Connection Identifier). De este modo el flujo queda asociado al VC en su pasaje a través del los switches ATM. A partir de ese identificador MPLS puede identificar el flujo al lo largo de todo el camino ya que el VCID es el mismo en ambos extremos del VC. Por más detalles ver Ref. [27]. 7.II-G.2 Naves en la Noche Un LSR de MPLS es capaz de proveer servicios de reenvío para LSPs de MPLS, ATM VCs, y posiblemente paquetes IP. Algunos puertos serán configurados para MPLS y otros para ATM Los recursos de los Switches estarán bajo el control de MPLS y ATM al mismo tiempo, pero en forma separada. Esto es lo que da el nombre de Naves en la Noche porque ambas coexisten, pero sin que una deba enterarse de la existencia de la otra. Ver Fig Para usar esta forma de trabajo hay que ocuparse de definir los espacios que cada sistema utilizará. Entre otros hay que cuidar configuraciones de administración de tráfico, reservas de ancho de banda, Control de admisión, encolado, y capacidad de procesamiento. Esta forma de funcionamiento es muy importante cuando se comienza a migrar una red ATM en una MPLS.

82 81 TABLA 7.IV COMPARACIÓN E-LSP L-LSP Fig Método Naves en la noche 7.II-G.3 Túnel sobre ATM Una función que es única en MPLS es la capacidad de controlar el camino completo de un paquete sin tener que especificar todos los routers intermedios. Esta facilidad es útil no solo cuando se usa sobre switches ATM sino en forma más general. Esto se logra creando túneles sobre los routers/switches intermedios. Para ilustrar el funcionamiento se considerará la topología de la Fig Primero se creara un LSP1 a través de los LER1, LER2, LER3 y LER4. Esto se logra configurando LER1 para que su destino sea el LER2 y así sucesivamente. De todos modos para que el LER1 llegue al LER2 este debe pasar sus datos a través de varios LSRs (en teste caso LSR1, LSR2, LSR3). Para esto se crea un segundo LSP2 el cual en efecto es un túnel entre el LER1 y LER2. La etiqueta que se usa en este LSP2 son distintas de las usadas en el LSP1. Exactamente lo mismo pasa entre los LER3 y LER4 con sus respectivos LSRs los cuales crean el LSP3. Para lograr esto se utiliza el concepto de Stack de Etiquetas para transportar un paquete por más de un segmento de la red. Cuando el paquete es transportado por el LSP1, LSP2 y LSP3 debe tener 2 etiquetas todo el tiempo. En el primer segmento tendrá las etiquetas del LSP1 y el LSP2 y en el segundo segmento, las del LSP1 y LSP3. En el momento que el paquete sale del primer segmento El LER1 retira la etiqueta del LSP2 y al ser recibido por el LER3 este introduce la etiqueta del LSP3. Finalmente el LER4 removerá las 2 etiquetas antes de entregar el paquete al destino. Fig Túnel MPLS 7.II-G.4 ATM MERGE Una ventaja interesante del uso de MPLS sobre ATM es la que se conoce como ATM MERGE, indica la posibilidad que brinda MPLS de unir varios flujos, VCs o VPs que tienen un tramo en común en un solo LSP. Esto permite obtener una escalabilidad mejor a la de ATM al poder determinar más niveles de Jerarquías. Fig II-H MPLS y VPNS Se vera aquí porque el modelo MPLS de VPN es mucho más fácil de administrar para un proveedor que el modelo de VPN usando (IP, frame relay o ATM). En el modelo tradicional las VPN son manejadas por los clientes o por los proveedores. En el primer caso el cliente genera la VPN sobre sus equipos usando simplemente enlaces de los ISP para interconectarlos. Estos enlaces pueden ser punto a punto, frame relay, ATM o túneles sobre Internet. Cualquiera de las opciones implica

83 82 CAPÍTULO 7. PROTOCOLOS DE TRANSPORTE Fig ATM Merge una experiencia por parte del cliente en los diversos sistemas usados, administración de backbones (ATM o Frame Relay), o protocolos de IP bastante específicos como NAT, o IPSEC, etc. Si la VPN es suministrada por el proveedor y por ende administrada por él, empiezan a aparecer problemas de escalabilidad frente a la posibilidad de afrontar un numero muy grande de VPNs sobre clientes que a su vez tienen un numero importante de nodos en su VPN. Estos problemas son similares a los ya discutidos en el apartado de ruteo y tienen que ver con las enormes mallas a ser mantenidas en capa 2 y la dificultad de estas a adaptarse a cambios de topologías. MPLS brinda una solución que alivia la carga del proveedor que debe brindar una cantidad importante de VPNs. La solución usa cuatro funcionalidades clave: 1) Uso de modelo de equipo par. 2) Distribución limitadas de información de ruteo. 3) Tablas de reenvío múltiples. 4) Uso de direcciones VPN-IP. La razón por la que se le llama par al modelo es porque el router del cliente (CE) solo dialoga con su par en la red del proveedor (PE) y no como en el modelo tradicional donde los CE dialogan entre si, utilizando la red del proveedor como transporte. Este modelo facilita la escalabilidad de la red, ya que ahora el CE solo debe conocer el (o los) routers del proveedor que actúan como su par, y este numero no se incrementa si el cliente agrega nuevos nodos a su VPN. La Distribución restringida de información de ruteo es la que permite crear y mantener la VPN. Esto se debe a que los flujos de datos son ruteados a lugares donde exista la información de ruteo para ellos. Por esto restringir la información de ruteo, restringe los flujos de datos. Para restringir esta información se utiliza la facilidad de Comunidades que tiene el protocolo BGP y que permite asignarle a cada ruta creada una comunidad a la que pertenece, esto resultara en que dicha ruta solo será anunciada dentro de la comunidad a la que pertenece. La restricción de información de ruteo es claramente necesaria, pero no suficiente ya que un ruter de borde de el proveedor (PE) actúa como par de varios CE de diferentes clientes que están conectados a él pero pertenecen a distintas VPNs. Si este router tuviera una sola tabla de ruteo entonces en ella debería estar la información de todas las rutas de todas las VPNs lo que es contradictorio con que la información de las rutas se mantenga restringida a cada VPN. Es por esto que los PE deben manejar Múltiples Tablas de Reenvío. Por lo tanto habrá dos grupos de rutas que tendrán acceso a una tabla de Reenvío especifica y esos son, a) las rutas que provienen de routers directamente conectados a el PE y que pertenecen a esa VPN y b) las rutas que pertenecen a la Comunidad de rutas de esa VPN. Este doble filtro mantiene la información de ruteo (y por lo tanto los flujos de datos) restringida a cada VPN. El modelo propuesto, supone usar BGP para la distribución de la información de ruteo, pero BGP asume algunas cosas que no son ciertas en el dominio de las VPNs. Una de ellas es que para BGP las direcciones IP son únicas, mientras que en el dominio de las VPNs se usan direcciones IP privadas las cuales pueden ser usadas en múltiples VPNs. La forma de resolver esto es creando un nuevo tipo de direcciones de red llamadas VPN-IP las cuales serán únicas. Estas direcciones se crean concatenando un campo de largo fijo llamado Distintivo de Ruta con la dirección IP. Luego hay que estructurar el Distintivo de Ruta de modo que no se repita. Desde el punto de vista BGP, las direcciones VPN-IP son tratadas como direcciones IP normales. Cuando los paquetes salen del PE hacia el CE las direcciones VPN-IP son cambiadas nuevamente por las direcciones IP. Resumiendo, las Comunidades de BGP se usan para restringir la conectividad a las rutas de un cliente (una VPN), mientras que las direcciones VPN-IP son usadas para no confundir direcciones IP que se repiten en las distintas VPNs. Finalmente, se sabe que las direcciones VPN-IP solo son informadas en los protocolos de ruteo, y las mismas no están en el cabezal de cada paquete IP, por lo tanto ellas no pueden ser usadas directamente para efectuar el reenvío del paquete. Es aquí donde comienza el papel importante de MPLS. Para hacer posible el reenvío de los paquetes a través de rutas expresadas en términos de direcciones VPN-IP se usa MPLS, debido a que MPLS permite desacoplar la información usada para el reenvío del paquete (la Etiqueta) de la información que se encuentra en el cabezal del paquete. Sencillamente se pueden crear relaciones entre LSPs y rutas VPN-IP y luego reenviar normalmente los paquetes por MPLS a través del LSP. Se puede ver que el router encargado de poner la etiqueta es el PE y como se vio este mismo router es el que posee el Distintivo de Ruta, por lo cual la tarea de separar los flujos en función de VPN-IP se realiza en ese equipo. El funcionamiento se podría resumir como: cuando el PE recibe un flujo de datos nuevo, utiliza la interfase de entrada para identificar a que VPN pertenece el flujo, de este modo identifica que tabla de ruteo (o en términos MPLS Forwarding Information Base) utilizar. Luego el PE comienza un IP lookup normal en esa FIB, con el resultado de esa búsqueda el PE encuentra la Etiqueta a ser utilizada para el reenvío de ese flujo. Cabe notar que al usar MPLS para el reenvío, todas las ventajas de escalabilidad que se han discutido en otras sesiones son validas aquí, de modo que los equipos del proveedor no se verán sobrecargados por tener que manejar las rutas de demasiadas VPN. Ver Fig

84 83 Permite usar técnicas de administración de tráfico y QoS a través del ruteo. Facilita la escalabilidad de la red al introducir el Stack de Etiquetas y permite administrar la misma a diferentes niveles de granularidad. Permite ser aplicado tanto a redes de paquetes como de celdas ya que es independiente de los protocolos de capas inferiores y superiores. Elimina la necesidad que todos los routers manejen tablas completas de ruteo. Solo los routers de borde las requieren. Fig VPNs en MPLS Por más detalles sobre la escalabilidad y seguridad de las VPNs con MPLS ver Ref.[26]. 7.II-I Operación Multicast MPLS puede facilitar el transporte eficiente de paquetes multicast mapeando las múltiples direcciones de entrega de capa 3 a múltiples LSPs. Esto se logra generando un árbol donde a una etiqueta de entrada a se le asignan varias etiquetas de salida. Además permite aprovechar la buena performance y el bajo delay, esto es muy importante porque el tráfico multicast es completamente ignorante de la disponibilidad de capacidad en la red. En otras parlabas el tráfico multicast no puede reaccionar a la congestión como lo hacen las aplicaciones que pueden ser transportadas por TCP. En una red ATM se pueden usar los VCCs que preveen caminos de conmutación punto-multipunto. 7.II-J Resumen 24 MPLS brinda un reenvío simplificado de paquetes basado en un distintivo corto y de largo fijo llamado Etiqueta. Una cualidad importante es que separa la parte de ruteo de la parte de reenvío de paquetes en redes IP. El comienzo de MPLS fue basado en la existencia de switches ATM de bajo costo Facilita la evolución de técnicas de ruteo, al crear un sistema de reenvío fijo independiente del ruteo. MPLS facilita la integración de MPLS e IP permitiendo que los carriers que ya están instalados puedan reutilizar su infraestructura existente de ATM pero al mismo tiempo eliminando los problemas de escalabilidad a los que se veían enfrentados al configurar IP sobre ATM. Problemas estos relacionados con la necesidad de crear mallas con tantos enlaces como el cuadrado de los nodos a cubrir. 24 Varias de las figuras y conceptos aquí resumidos fueron tomados de [26], [27], [28], [29] y [30].

85 84 CAPÍTULO 7. PROTOCOLOS DE TRANSPORTE

86 Capítulo 8 Protocolos para servicios convergentes Resumen En este capítulo se estudian y analizan los protocolos utilizados para poder brindar los servicios que se ha optado por ofrecer. Entre estos se incluyen los protocolos para transporte y señalizacion de voz y multimedia, así como protocolos y tecnologías para transmisión de video y faxes, e interconexión con centrales tradicionales. V 5.2 Trabaja sobre un grupo de hasta 16 circuitos E1 y permite concentrar tráfico. Respeta un modelo de capas de acuerdo a la Fig I V 5.X PROTOCOLOS DE INTEGRACIÓN RED DE ACCESO PAQUETES - CENTRALES TRADICIONALES LOS protocolos V 5.x 25 se usan para la conexión de redes de Acceso AN (Access Network) a centrales locales LE (Local Exchange). Esto es necesario en caso de equipos que no tienen interfases en común, como ser equipos de diferentes proveedores, o equipos de redes diferentes. También es útil para fines de concentración de circuitos de acceso. Es por tanto usado para las siguientes formas de acceso: Telefonía tradicional POTS. ISDN BRA ISDN PRA Cualquier otro medio análogo o digital de conexión no permanente o sin señalización fuera de banda. V 5.1 El protocolo V5.1 opera sin concentración de tráfico, sobre un solo circuito E1. La interfase V5 incluye canales separados para tráfico, señalización y control ver Fig Fig Canales en elnace V V5 está definido en las recomendaciones ITU-T G.964 (V5.1) y G.965 (V5.2), y en los estándares ETSI ETS (V5.1) y ETS (V5.2). Fig Modelo de capas de V5.x. En la capa 2 el LAP (Link Access Procedure) indica la estructura de los frames en los que serán encapsulados las funciones (mensajes) de la interfase V5 en los enlaces punto a punto. A nivel de capa 3 y para soportar una asignación dinámica del tráfico y de este modo soportar función de concentradores, V5.2 utiliza varios protocolos. Estos protocolos manejan el procesamiento de la llamada, el uso de circuitos y canales. Cada uno de estos protocolos se le denomina enlace de datos. Enlaces de datos de V5.2: Link control Transporta la información para el control de enlace de cada E1 individualmente. Tiene los siguientes campos: Layer 3 address: Identifica la entidad que está transmitiendo o debe recibir el mensaje. Message Type: Identifica la función del mensaje. Este mensaje puede ser Link control o Link Control Ack. BCC Un protocolo de control de conexiones. Le da los medios a la central (LE) para requerir a la 85

87 86 CAPÍTULO 8. PROTOCOLOS PARA SERVICIOS CONVERGENTES AN que establezca (o termine) un circuito entre un puerto de usuario de la AN y un time slot de la interfase V5. Esto permite la concetración en la interfase V5, porque la conexión entre los usuarios de la AN y la LE se establecen dinámicamente. Algunos mensajes que maneja este protocolo son: Allocation, Allocation Complete, Allocation Rejected, De-Allocation, De-Allocation Complete, etc. PSTN Cuando el acceso es análogo, la señalización de la PSTN (LE) es convertida en mensajes V 5.2 y eso es lo que se traslada al AN y viceversa. El protocolo asociado se encarga principalmente de generar el camino de la llamada, de levantarlo al terminar ésta y resolver colisiones en la interfase V5. Lo que se hace es informar el estado de la línea analógica a través de la interfase V5. Los mensajes de este protocolo son: Establish, Establish Ack, Signal, Signal Ack, Status, Status Enquiry, Disconnect, Disconnect complete, Protocol Parameter Control Identifica las entidades de capa 3 y su correspondencia en la interfase V5.2 entre múltiples E1 Protection Un protocolo de protección, que opera en 2 enlaces separados por razones de seguridad. Este administra la conmutación de llamadas en caso de fallas del enlace que están usando. Esto es necesario debido a que la falla de el canal BCC, o de Control afectaría a muchos circuitos de voz. ISDN Para accesos ISDN (u otros digitales) se define un protocolo para el intercambio de mensajes de control de llamadas con la Central PSTN. Si no hay circuitos ISDN, el enlace ISDN está ausente, y si no hay circuitos analógicos, en enlace PSTN está ausente. Información adicional sobre V 5.x puede ser encontrada en: [31] y [32]. 8.II MGCP 8.II-A Características generales Este protocolo asume una arquitectura donde la inteligencia del control de llamadas esta fuera de los gateways y es manejada por un elemento de control externo comúnmente conocido como Call Agent. MGCP 26 asume que ese elemento de control externo o Call Agents, estará sincronizado con todos los otros para enviar comandos y respuestas coherentes a los gateways que el controla. A su vez, no especifica mecanismos para re-sincronizar los Call Agents, y prevé comportamientos inconsistentes si el sincronismo falla. En esencia, MGCP es un protocolo maestro/esclavo, donde los gateways deben ejecutar los comandos enviados por los Call Agents. 26 RFC II-B Arquitectura MGCP asume un modelo de conexión donde las construcciones básicas son puntos de terminación (endpoints) y conexiones. Los endpoints son fuentes y/o terminaciones de datos que pueden ser físicas o virtuales. Ejemplos de endpoints físicos pueden ser: Una interfase en un gateway que termina una troncal conectada a la PSTN. Una interfase en un gateway que termina POTS analógicos a los que se conectan teléfonos, key systems, etc. Un ejemplo de endpoint virtual, es un fuente de audio proveniente por ej. de un servidor de Anuncios. Las Conexiones pueden ser tanto punto a punto, como punto-multipunto. Una conexión es una asociación entre dos o más endpoints con el propósito de transmitir datos entre estos. Las Conexiones pueden ser establecidas sobre muchos tipos de redes portadoras, por ej: Transmisión de audio utilizando RTP y UDP sobre redes IP. Transmisióón de paquetes de audio utilizando AAL2 (u otra capa de aplicación) sobre redes ATM. Transmisión sobre conexiones internas, (por ejemplo dentro de un gateway). El establecimiento de sesiones se negocia y realiza utilizando SDP. Este protocolo se basa las RFCs 2705 y 2705bis, por más detalles se podrá consultar en las mismas. 8.III H.248/MEGACO 8.III-A Descripción y evolución Entre todos los protocolos de comunicación emergentes Megaco/H.248 aparece como una opción compatible y complementaria para el control de los gateways ofreciendo ventajas respecto a otros protocolos existentes. Como ya se ha mencionado, Megaco/H.248 es un protocolo de control de Media Gateways diseñado para lograr el objetivo de descomponer los Gateways y lograr escalabilidad y flexibilidad, bajando así el costo global de la solución. Este tipo de gateways separan la inteligencia de la llamada, del procesamiento y transmisión de paquetes. Usando Megaco/H.248, los Controladores de Media Gateways (MGCs) controlan los Media Gateways (MGs) para ir creando caminos multimedia a través de una red distribuida. Como se puede ver en la Fig. 8.3, el MGC trabaja con el MG de la misma forma que lo hace el procesador central de una central digital y el dispositivo conmutador de ésta. El modelo de conexión y la estructura de comandos son simples, flexibles y potentes en su diseño, proporcionando ventajas como por ej., reducción de la sobrecarga del

88 87 Fig Arquitectura de MEGACO/H.248. Fig Comparación entre un conmutador tradicional y un Softswitch. La capa de MG implementa las conexiones multimedia desde y hacia la red de paquetes (IP o ATM), interactua con esas conexiones a través de señales y eventos, y controla las funciones de gateway como las interfases de usuario. Esta capa no tiene ningún conocimiento de las funciones a nivel de llamada, y simplemente actúa como esclavo. encabezado, reducción de complejidad y la posibilidad de trabajar con un amplio rango de aplicaciones. Asimismo, Megaco/H.248 define totalmente y en forma clara los mecanismos de extensión del protocolo que permitan la innovación. Megaco/H.248 se puede aplicar sobre cualquier tipo de red, incluyendo tanto las basadas en IP, como las que utilizan ATM. Megaco/H.248 es la evolución de MGCP, y si bien MGCP es el más utilizado hoy en día, la tendencia de la industria es hacia la convergencia utilizando estándares abiertos Megaco/H.248, SIP, y H.323. Mientras MGCP ofrece un efectivo modelo para pasar voz de las PSTN (SS7 principalmente) hacia las redes de paquetes (principalmente IP), Megaco/H.248 ofrece un modelo más flexible y abstracto que permite utilizar en forma independiente cualquier tipo de red convergente (IP, ATM, Frame Relay, y la misma PSTN) para un muy amplio rango de aplicaciones. 8.III-B Arquitectura La Fig. 8.4, muestra que la arquitectura de este protocolo esta basada en: Capa de Media gateway control (MGC), Capa de Media gateway (MG), y el protocolo Megaco/H.248 en si mismo. La capa de MGC contiene toda la inteligencia del control de llamada, e implementa las funciones a nivel de llamada, como ser transferencia, conferencia, reenvío, espera, etc. Esta capa también implementa los protocolos para la interacción con otros MGCs o entidades terminales, administra las funciones y cualquier interacción con la señalización. El protocolo Megaco/H.248 deriva el control maestro/esclavo de los MGCs sobre los MGs. Provee control de conexión, control de dispositivos y configuración de dispositivos. Debido a que Megaco/H.248 está separado y es independiente del protocolo de control de llamada (por ej., SIP o H.323), se pueden usar diferentes sistemas a este nivel con un impacto en costo mínimo a nivel de la capa control de gateways. 8.III-C Principales características de Megaco/H.248 Megaco/H.248 utiliza un modelo conexión/recurso simple pero potente, para describir entidades lógicas u objetos en los Media Gateways que pueden ser controlados por los Controladores Media Gateways (MGC). Se basa fundamentalmente en dos conceptos clave, como: Terminación y Contexto. Las terminaciones son entidades lógicas que representan conexiones multimedia hacia/desde la red de paquetes. Estas identifican flujos multimedia o recursos, implementan señales o generan eventos, tienen propiedades y mantienen estadísticas. Otra característica, es que pueden ser permanentes o transitorias. Todas las señales, eventos, propiedades y estadísticas están definidas en paquetes, los que a su vez, están asociados con terminaciones individuales. Un contexto es una asociación entre una colección de terminaciones. La Fig. 8.5 muestra una descripción gráfica de estos conceptos. Este diagrama muestra solo dos de los posibles ejemplos. En este diagrama el asterisco representa la asociación lógica de

89 88 CAPÍTULO 8. PROTOCOLOS PARA SERVICIOS CONVERGENTES mínimas, de forma de obtener mejor interoperabilidad y relación complejidad/costo. Para negociar y establecer todas las sesiones multimedia, Megaco/H.248 utiliza SDP. Por más información ver [33], [34], [11] y [35] 8.III-D Ejemplo de funcionamiento A continuación se muestra parte de un ejemplo de flujo de una llamada utilizando MEGACO tomado de la RFC3015 [35]. 1. El MG1 se registra con el MGC utilizando el comando ServiceChange. Fig Contextos y Terminaciones. 2. El MGC envía la respuesta terminaciones implicadas en un contexto. Por su parte, la estructura de comandos de Megaco/H.248, también es muy simple, potente y flexible. Utiliza solamente 7 comandos: Add, Subtract, Modify, Move, Notify, AuditValue/AuditCapabilities y ServiceChange, y todos operan sobre las terminaciones de la misma forma. Está permitida la introducción de un nivel de evento/señal, como por ejemplo con eventos disparadores que produzcan acciones reflejo por parte del MG. Los comandos entre los MGC y los MG son agrupados en transacciones utilizando reglas de construcción. Esto trae como consecuencia inmediata una significativa reducción de overhead. Los comandos utilizan descriptores para agrupar datos de elementos relacionados, lo que ayuda notoriamente a encontrar a quien pertenecen los datos. Solamente los descriptores que se necesitan para una operación particular son enviados junto con los comandos, reduciendo aquí también el overhead introducido. El primer mecanismo de extensión que presenta Megaco/H.248, es a través de los paquetes. Así, nuevos paquetes definen nuevos comportamientos en las terminaciones, vía propiedades, eventos, señales y estadísticas adicionales. Los paquetes estándar están bien definidos, y se especifica en el estándar, la forma en la que se deben definir los nuevos paquetes. En Megaco/H.248, los perfiles definen aplicaciones en los MG. Esto incluye, organización y requisitos para la terminación de los paquetes, selecciones específicas de elementos optativos (como transporte y codificación), y cualquier otra definición de conducta requerida para la aplicación. Los perfiles son acuerdos a nivel de aplicación entre los MGC y los MG que especifican capacidades 3. El MGC envía el comando Modify, programando una terminación en contexto nulo. Le asigna el ID de terminación (terminationid) A4444, el ID de flujo (streamid) 1, y el ID de pedidos (requestid) en el descriptor de eventos El mid es el identificador del que envía ese mensaje. 4. El MG1 acepta el comando Modify. 5. Un intercambio similar ocurre entre el MG2 y el MGC, resultando en una terminación libre A5555. A continuación se ilustran las transacciones desde el MGC y el MG1 que llevan a la terminación A4444 a través de la recolección de dígitos a invitar una conexión a la terminación en el MG2. 6. El MG1 detecta el evento offhook desde el Usuario1 y lo reporta al MGC vía el comando Notify. 7. El MG1 envía acuse de recibo del comando Notify. 8. El MGC Modifica la terminación para emitir tono de discado y examinar los dígitos de acuerdo con el plan de numeración. 9. El MG1 envía acuse de recibo del comando Modify. 10. Los dígitos son acumulados por MG1 a medida que son discado por el Usuario1. El tono de discado es interrumpido en el momento que se detecta el primer dígito. Cuando el numero discado está de acuerdo con el plan de discado programado para A4444 se envía otro comando Notify al MGC conteniendo la información. 11. El MGC envía acuse de recibo del comando Modify. 12. El controlador analiza los dígitos y determina que es necesario establecer una conexión entre MG1 y MG2. Las terminaciones TDM (A4444) y la RTP (A4445) son agregadas

90 89 (comando Add) a un nuevo contexto en MG1. Se envían los posibles codecs a utilizar en orden de preferencia del MGC 13. MG1 acusa la nueva terminación y envía datos de dirección IP y puerto. También realiza la elección de codec a utilizar basado el las preferencias del MGC enviadas anteriormente. 14. El MGC asocia ahora la terminación A5555 en el MG2 con un nuevo contexto, y establece un flujo RTP (se asigna ID A5556). El MGC setea sonando (ring) en A MG2 acusa recibo, y envía su datos para establecer la conexión (IP y puerto UDP). 16. Se envían estos datos al MG Ahora estos dos gateways están conectados, y el usuario1 está escuchando el tono de sonando. Mientras tanto el MG2 espera que el Usuario2 acepte la llamada y que la llamada se establezca. El Usuario 2 acepta la llamada. 18. El MG2 notifica al MGC, esta hace lo mismo con MG1. MG1 cambia el estado para que pueda enviar y recibir, y corta el tono de sonando. Ahora la llamada está establecida (se establece el flujo RTP entre los MGs). El Usuario2 corta la comunicación. 19. Cuando el MGC recibe una señal de corte por parte de alguno de los MG, este corta la llamada. 20. El MGC envía a ambos MG las el comando Subtract para que corten la comunicación. Cada terminación tiene sus propias estadísticas que almacena. El MGC puede pedir aquí los datos de la llamada utilizando el comando Audit{Statistics}. Se pueden pedir la información de una o ambas terminaciones (hay que tener en cuenta que A5555 es una terminación física y A5556 es una terminación RTP). recomendación no especifica la interfaz de red, el medio físico ni el protocolo de transporte usado. Actualmente la mayoría de las soluciones adoptadas usan el stack TCP/IP como protocolo de transporte/red. 8.IV-B Codificación de la información multimedia H.323 soporta distintas codificaciones para la transmisión de audio y video. El tipo de codificación a usar es negociado por los clientes en el establecimiento de llamada a través del intercambio de capacidades con el protocolo H.245. Los codecs soportados actualmente son: Audio. G.711 PCM audio codec 56/64 kbps G.722 audio codec para 7 KHz a 48/56/64 kbps. G.723 speech codec para5.3 y 6.4 kbps. G.728 speech codec para 16 kbps. G.729 speech codec para 8/13 kbps. Video. H.261 video codec para >= 64kbps. H.263 video codec para < 64kbps. 8.IV-C Entidades en H.323 La recomendación define cuatro componentes en el sistema. Estos son Terminales, Gateways, Gatekeepers y MCU (Multipoint Control Units). Un diagrama de la arquitectura completa se muestra en la Fig El MGC setea ahora ambos MG para que estén listos al ocurrir una nueva llamada. Nota: Si se quiere dar servicio a equipos H.323/SIP, deberá existir un H.323 Gatekeeper/SIP proxy. En este caso el MGC actúa como terminal H.323/SIP en cuanto al establecimiento y control de la llamada, pero el flujo RTP es dirigido directamente al terminal de destino. 8.IV H.323 SISTEMA DE COMUNICACIONES MULTIMEDIA BASADA EN REDES DE PAQUETES. 8.IV-A Introducción H.323 es una recomendación del Grupo 16 de la ITU-T que especifica un sistema y sus protocolos para las comunicaciones multimedia sobre redes de conmutación de paquetes. Esta Fig Arquitectura de H IV-C.1 Terminales Los Terminales son los clientes que establecen comunicaciones bidireccionales con otras entidades H.323.

91 90 CAPÍTULO 8. PROTOCOLOS PARA SERVICIOS CONVERGENTES 8.IV-C.2 Gateways Los Gateways proveen un camino de conexión entre la red de paquetes y la red de circuitos. Los gateways implementan el establecimiento y control en ambas redes y traducen la señalización y procedimientos para posibilitar la comunicación. Algunos gateways también implementan la traducción entre distintos codecs usados en la red de paquetes y la red de circuitos (a esto se le llama transcoding). 8.IV-C.3 Gatekeepers Los Gatekeepers son opcionales en un sistema H.323. Implementan las siguientes funciones: traslación de nombres (de alias H323 o números telefónicos E.164 a direcciones de transporte). control de admisión control de ancho de banda administración de la zona. Los Gatekeepers también proveen soporte para funciones opcionales como ser: señalización de control de llamada, autorización de llamada, administración de ancho de banda y administración de llamadas. Cuando un Gatekeeper está presente en un sistema H.323, todos los demás tipos de clientes deben registrarse con el Gatekeeper y recibir la autorización antes de realizar una llamada. 8.IV-C.4 MCU s Los MCU dan soporte a conferencias entre tres o más clientes. Un MCU provee las funciones de control como ser la negociación entre terminales y la determinación de facilidades comunes para el procesamiento de audio y video. El procesador multipunto implementa el procesamiento de los media streams, mezclando y conmutando el audio y video entre los clientes. 8.IV-D Uso de Canales en H.323 El estándar H.323 usa el concepto de canales para estructurar el intercambio de información entre las entidades. Se definen los siguientes tipos de canales: 8.IV-D.1 Canal RAS Este canal provee un mecanismo de comunicación entre el cliente y el Gatekeeper. El protocolo RAS (Registro, Admisión, y Status) es definido en la recomendación H A través del canal RAS, un cliente se registra con el Gatekeeper y solicita el permiso para establecer una llamada con otro cliente. Si el permiso es concedido el Gatekeeper devuelve la dirección de transporte por el canal de señalización del cliente solicitante. En una red IP se usa UDP para la comunicación con el RAS, el RAS escucha en el puerto IV-D.2 Canal de señalización de llamada Este canal transporta la información para el control de llamada y control de servicios suplementarios. Es usado un protocolo similar al Q.931 especificado en el H y H.450.x. Cuando la llamada es establecida la dirección de transporte para el canal H.245 es informada por este canal. En una red IP se usa TCP para la señalización en el puerto A partir de la versión 3 del H.323 se puede optar por UDP/TCP. 8.IV-D.3 Canal de control H.245 Este canal transporta los mensajes H.245 para el control de la información multimedia y el intercambio de facilidades. Los canales lógicos para el transporte de información multimedia son abiertos a través de los canales H.245. En redes TCP/IP la asignación de puertos TCP es dinámica (como se mencionó en el punto anterior, se realiza a través del canal de señalización de llamada). 8.IV-D.4 Canales lógicos multimedia Estos canales transportan el audio, video y otra información multimedia. Cada tipo (video, audio) es transportado en un par de canales individuales, uno para cada dirección usando RTP (Media channels) y RTCP (en el H.245). Los canales multimedia son transportados sobre UDP, con asignación (negociación) dinámica de puertos. 8.IV-D.5 Canal de datos T.120 Canal de datos en la comunicación multimedia. Se usa el puerto 1503 del transporte TCP (ej Netmeeting). 8.IV-E Calidad de servicio en H.323 Los Gatekeepers proveen un conjunto de funciones de control y administración que incluyen la traslación de direcciones, el control de admisión, el control de ancho de banda y la administración de la zona. Algunas funciones opcionales son el control de señalización de llamada (en modo ruteado), la autorización de llamada, la administración de ancho de banda y el control de llamada. El control de admisión determina cuando la red cuenta con recursos suficientes para soportar la Calidad de Servicio requerida para una llamada, con este criterio acepta o rechaza las nuevas llamadas. Para realizar el control de admisión el protocolo debe manejar la administración de ancho de banda, la administración de llamada y el control de ancho de banda. Actualmente el H.323 no soporta reserva de recursos por si mismo sino que recomienda mecanismos externos para la reserva de recursos como ser el uso del protocolo RSVP (Resource Reservaton Protocol). A partir del H.323 v.3 se ofrecen algunos Servicios Diferenciados basados en la negociación de parámetros de calidad de servicio. Un terminal puede, en la inicialización de una llamada, solicitar uno de las tres clases de servicios definidas como: Servicio Garantizado, Servicio Controlado y Servicio No Especificado.

92 91 8.IV-F Prestaciones y características del H IV-F.1 Entrada de datos vía PhoneKeypad Desde las primeras versiones del H.323 se provee soporte para DTMF. En la última versión ratificada (4) se habilita una carga útil en un paquete RTP para la señalización DTMF junto con el soporte del intercambio de mensajes H.245 v7. H.323 usa el mismo protocolo para la señalización de control de llamada (Q.931) que ISDN para el establecimiento y la liberalización. Los servicios suplementarios H.450 usan la misma lógica que QSIG. 8.IV-F.2 Interoperabilidad con otros protocolos de señalización Para soportar los servicios tradicionales de telefonía la señalización de VoIP deben soportar el sistema de señalización SS7 de ISDN. Este sistema implementa señalización fuera de banda para soportar el establecimiento, billing, ruteo y funciones de intercambio de información de la PSTN. Existen dos especificaciones de señalización en SS7 para dos interfases distintas. Para la interfaz UNI (User to Network Interfaz) se usa Q.931. Para la interfaz NNI (Network to Network) se usa ISUP. H.323 usa una señalización similar a la Q.931 lo que hace más fácil la interoperabilidad con ISDN. Sin embargo los mensajes de establecimiento de llamada son solo un subconjunto de los mensajes usados en SS7/ISUP. Esto hace que no existan estándares para el mapeo de mensajes SS7/ISUP sobre una red H.323. La familia H.32x de recomendaciones ofrecen estándares para interoperar con otras redes de conmutación de circuitos, por ejemplo H.320 con ISDN y B-ISDN, H.324 con GSTN. Con estos estándares la interoperabilidad por medio de gateways está bien definida. 8.IV-F.3 Tunelizando protocolos de señalización de la PSTN sobre H.323 H.323 v.4 especifica los medios para realizar la tunelización de mensajes en cualquier mensaje H de control. Estos métodos permiten transportar señalizaciones no H.323 sobre redes H.323, como consecuencia pueden transportarse protocolos como el QSIG (Anexo M1) ISUP (Anexo M2) y DSS1 (Anexo M3). 8.IV-F.4 Codificación de los mensajes Los mensajes de señalización en H.323 están codificados en formato binario usando ASN.1 PER (Packet Encoding Rules). Para ser presentada a un usuario o para ser almacenada en un sistema esta sintaxis debe ser mapeada en alguna forma de presentación. Esto hace que la implementación y el debugging del protocolo se haga más difícil puesto que hay que usar herramientas para su análisis. 8.IV-F.5 Capacidades Optimizadas de la Red Los Gateways compatibles con H.323 v.4 pueden usarse como interfaz entre uno o más switches de la PSTN y asociarse a grupos de troncales o transportar información sobre los enlaces de señalización de llamada. Esto significa que se puede utilizar un gateway específico para cada tarea. Si un cliente elige enviar un fax la llamada puede ser enrutada a un gateway que solamente sabe enviar faxes en lugar de enviarla a un gateway que pueda manejar llamadas complejas de video. Las características definidas en el H.323 v.4 permiten a los clientes a través de mensajes H indicar que protocolos (fax, H.320, o T.120) desea utilizar durante el curso de una llamada. Si un cliente indica a un Gatekeeper los protocolos deseados el Gatekeeper puede intentar localizar a un gateway que pueda dar soporte para dichos protocolos. 8.IV-F.6 Accounting de llamadas Las siguientes facilidades pueden ser usadas para el accounting y el billing de llamadas en H.323. Autenticación de usuarios. Durante el setup de la llamada en los campos del H se provee capacidades de relativas al crédito. El cliente puede recibir información de el crédito o el débito desde el Gatekeeper antes y después del establecimiento de llamada. El Gatekeeper puede especificar las limitaciones de tiempo que tiene el cliente. El cliente puede liberar la llamada cuando finaliza el crédito. Un Gatekeeper puede enviar balances al cliente e indicar los limites de duración de llamada. El Gatekeeper puede indicar el tipo de billing (crédito o débito). El anexo G del H permite a los dominios administrativos realizar solicitudes a otros dominios de información de uso de recursos de una determinada llamada. 8.IV-F.7 Servicios de Identificación de llamadas Presentación y restricción del número de abonado llamante. Presentación y restricción de abonados conectados. Presentación y restricción del abonado llamado. Presentación y restricción del abonado ocupado. Etc. (Ver facilidades H.450.X) 8.IV-F.8 Seguridad y privacidad La recomendación H.235 define la autenticación. La autenticación se cumple agregando una firma en los mensajes del RAS y Q.931 con una secret key conocida por el cliente y el dispositivo central. H.235 v.2 define la encriptación de la información multimedia. Esto permite la prevención de los intrusos en los media streams RTP. 8.IV-F.9 Balanceo de carga y redundancia H.323 define una entidad llamada Gatekeeper Alternativo. Un Gatekeeper puede utilizar múltiples dispositivos físicos o lógicos como Gatekeepers alternativos. Cuando un Gatekeeper se sobrecarga puede balancear su carga redireccionando algunos clientes ya registrados hacia un Gatekeeper alternativo. La Fig. 8.7 muestra como al registrarse un cliente con un Gatekeeper, el Gatekeeper rechaza su solicitud pero agrega la dirección del Gatekeeper alternativo en el mensaje de rechazo.

93 92 CAPÍTULO 8. PROTOCOLOS PARA SERVICIOS CONVERGENTES 8.IV-F.14 Detección y corrección de errores H.323 v.3 especifica sus propias políticas de retransmisión ante la pérdida de paquetes para el soporte de TCP y UDP, mediante el uso de timers. Comienza señalizando en UDP y si supera un valor de retransmisiones se detiene la transmisión por UDP y se señaliza con TCP. Fig Gatekeeper alternativo 8.IV-F.10 Registro masivo de direcciones en un Gatekeeper Las versiones previas del H.323 no eran eficientes cuando un gateway o un MCU tenían que registrar un número alto de alias o direcciones en un Gatekeeper debido a las limitaciónes de tamaño de los paquetes UDP. Esta ineficiencia era causada por la limitación del tamaño de los paquetes UDP. En el H.323 v4 fue resuelto el problema mediante un mecanismo de registro aditivo. Cuando es usado este mecanismo el gateway o MCU se registra en un Gatekeeper enviando mensajes con la lista de los aliases en solicitudes RRQ correlativas hasta completar la lista de aliases disponible. 8.IV-F.11 Multiplexación de canales TCP Por defecto es usado TCP en H.323 para la señalización de llamada (H.225.0) y el control de llamada (H.245). TCP asegura la señalización sobre conexiones de baja calidad (como puede ser Internet). Sin embargo las conexiones TCP ocupan muchos recursos de CPU del sistema. Usando la multiplexación de mensajes Q.931 sobre una misma conexión TCP se ahorra recursos y se mejora la performance del sistema. El canal H de señalización transporta mensajes de control que mediante el valor de referencia de llamada (CRV) permite que estos mensajes sean de varias llamadas concurrentes. 8.IV-F.12 Tiempos de Setup más eficientes Desde la versión 2 del H.323 el RTT (Round Trip Time) del establecimiento de llamada ha sido mejorado. En el H.323 versión 4 el setup de llamada puede realizarse junto con el establecimiento de la sesión H.245 vía túnel en paralelo, por lo cual los tiempos de conexión bajaron aún más. Esto significa que se puede establecer una llamada de audio en dos direcciones, intercambiando las facilidades de los clientes en 3 mensajes bajando significativamente el tiempo de señalización. El protocolo abre conexiones TCP y UDP en paralelo y si el UDP falla continúa con el establecimiento por TCP. En caso de que no falle el UDP existe un mecanismo para cerrar la sesión TCP. 8.IV-F.13 Señalización no orientada a conexión El Anexo E (definido en H.323 versión 3) es un protocolo genérico que implementa el intercambio de mensajes sobre UDP. UDP puede ser usado en lugar de TCP para transportar los mensajes Q IV-F.15 Detección de loops Cuando la red crece en tamaño el número de Gatekeepers involucrados en un establecimiento de llamada aumenta y puede producirse un loop en el establecimiento. Para evitar esto los mensajes de establecimiento tienen un campo de PathValue que indica la cantidad máxima de Gatekeepers por los cuales puede pasar el mensaje de señalización. Si un loop ocurre no se detiene el mensaje hasta que no se alcanza el valor de este campo. Siendo crítica la elección de este valor. 8.IV-F.16 Tolerancia a fallas Además de que el Gatekeeper puede indicarle al terminal durante el registro Gatekeepers alternativos, que pueden ser usados en caso de fallas; los clientes pueden indicar una dirección de transporte de backup, alternativa o redundante. Esto permite que un cliente tenga una interfaz secundaria u otro cliente de backup. 8.IV-G Flujo de llamada H.323 A continuación se presenta un diagrama donde puede observarse el flujo de llamada entre dos clientes H.323, con la presencia de un Gatekeeper (en modalidad de llamada no ruteada). 1 El terminal A se registra ante el Gatekeeper (cuando por ejemplo se conecta el equipo). Aquí el GK registra el alias y los recursos de transporte que va a usar ese cliente. 2 El Gatekeeper (GK) confirma el registro. 3-4 ídem terminal B. 5 El terminal A quiere iniciar una comunicación con B para esto envía un mensaje al GK para obtener la ubicación (dirección de transporte de B) indicando el alias, número E.164 o URL H El GK responde al terminal A con un mensaje que contiene la dirección de transporte de B. 7-8 Setup-Proceeding-Alerting del H.225 entre A y B 27. A recibe el Alerting y se manifiesta al usuario por ejemplo en forma de tono de libre Mensajes de admisión de llamada entre el GK y el terminal B. De esta forma B solicita permiso para establecer la llamada. 27 Esto podría hacerse a través del GK en modalidad de llamada ruteada.

94 93 8.V SIP - SESSION INITIATION PROTOCOL 8.V-A Introducción Este protocolo de detalla en la RFC , y fue diseñado par crear, modificar y terminar sesiones multimedia con uno o más participantes. Estas sesiones incluyen conferencias multimedia y llamadas telefónicas sobre Internet o sobre una red IP. El objetivo de SIP es determinar que puertos y que direcciones IP se utilizarán durante la conferencia. Si bien el protocolo no transporta datos de la conferencia, existen mecanismos para enviar sobre la señalización fotografías, business card y páginas web utilizando estos paquetes de señalización. SIP no es un protocolo de transporte y se vale por esto del RTP para el transporte de los media streams, SIP usa un mecanismo descriptivo de las sesiones para que los participantes acepten una serie de capacidades multimedia compatibles entre ellos. Fig Flujo de llamada H.323 con GK. Clientes Netmeeting y GNU-GK. 11 Mensaje Connect del H.225 desde B hacia A. B levanta el tubo 12-13,15-16 Intercambio de facilidades entre A y B. Aquí se intercambian las capacidades de codificación de los distintos DSP s de audio y video además de disponibilidad de canales de datos. Los clientes indican que tipo de esquemas de codificación pueden enviar, recibir y enviar-recibir. La otra parte tiene elege uno de estos esquemas. A continuación se muestra el mensaje de B hacia A 14,17,18 Determinación del Master y Slave: se utiliza este mecanismo para resolver en caso de solicitar ambos clientes los mismos recursos, este mecanismo se describe en el protocolo H.245. Ambos endopoints envían un mensaje de MasterSlaveDetermination conteniendo un número entre 0 y (224-1). si ta >tb entonces A es el master si ta-tb>224/2, en otro caso A es el slave. En el ejemplo no se muestra el mensaje MasterSlaveDetermination desde B hacia A. El master tiene prioridad sobre los recursos solicitados Apertura de canales de audio y video. Se intercambian las solicitudes de apertura de los canales de audio y video indicando la codificación a usar así como también las direcciones de transporte de cada uno Fin de conferencia (liberación de llamada). SIP soporta las siguientes facilidades de llamada: Facilidades tradicionales como ser hold, transferencia, desvío, llamada en espera, etc. Servicios suplementarios como ser call park y call pickup, call completion on busy subscriber e identificación de llamadas. Control por un tercero: Es la habilidad que tiene un abonado de establecer una llamada entre otros dos abonados sin participar necesariamente en esta llamada. Esta funcionalidad es útil en muchos escenarios como ser: servicios de secretarias, pre atendedor de llamadas, servicios de operadora, etc. 8.V-B Funciones de SIP Traslación de nombres e información de ubicación. Asegura el establecimiento de la llamada. Para que no dependa la localización ni de la dirección IP ni la MAC del cliente (permite la movilidad del cliente). Establecimiento de llamada. Determinación de la disponibilidad del usuario en participar en la conferencia (estado del usuario). Determinación de las funcionalidades de usuario. Determinación de los tipos multimedia (y parámetros) a usar. Esta transacción puede, por ejemplo, determinar el uso o no de la transmisión de video durante la conferencia. Administración de llamada por parte de los participantes. Los participantes de la conferencia pueden agregar a otros, dejar la llamada en hold, transferirla, etc. Los clientes pueden, con una programación sencilla, iniciar una llamada enviando una imagen del que llama, responder a una llamada con una página web (con información de contacto actualizada por ejemplo) o redirigirla automáticamente hacia un asistente u otra localización. Cambio de facilidades de llamada durante la conferencia. Un usuario puede realizar cambios durante la llamada, por ejemplo puede decidir comenzar a transmitir video. Puede ser necesario también el cambio en las facilidades 28 anteriormente RFC2543bis

95 94 CAPÍTULO 8. PROTOCOLOS PARA SERVICIOS CONVERGENTES para permitir la inclusión en la conferencia de otros participantes. 8.V-C Mensajes SIP Los mensajes SIP son similares a los mensajes del protocolo HTTP, la centena indica el tipo de mensaje. 1xx buscando, sonando (ringing), encolando, etc. 2xx exitoso. 3xx redireccionando. 4xx problemas del cliente. 5xx fallas del servidor. 6xx ocupado, rechazado, no disponible en ningún lugar. 8.V-D Flujo de llamada SIP es usado para establecer, modificar y terminar sesiones multimedia. Sin embargo el protocolo únicamente maneja la comunicación entre el abonado de origen y destino, el direccionamiento y la ubicación de usuarios. Es necesario un intercambio de facilidades de la sesión multimedia con mensajes SIP de consulta y respuesta, para esto es usado el protocolo SDP (Session Description Protocol) conjuntamente con SIP para implementar todas las funciones de señalización de llamada en la telefonía IP. El abonado que origina la llamada usa un mensaje OPTION para conocer las capacidades del destino o simplemente envía una descripción SDP en un mensaje SIP de INVITE con una oferta de capacidades multimedia ordenadas por preferencia. El destino a su ves basándose en estas capacidades responde con otra descripción multimedia, también ordenada A groso modo SIP es equivalente al RAS y al Q.931- (H.225) en H.323 y SDP es equivalente al H.245. INVITE User A User B INVITE sip:userb@there.com SIP/2.0 Via: SIP/2.0/UDP here.com:5060; branch=z9hg4bk74bf9 Max-Forwards: 70 From: BigGuy <sip:usera@here.com> ;tag=9fxced76sl To: LittleGuy <sip:userb@there.com> Call-ID: @here.com CSeq: 1 INVITE Contact: <sip:usera@ > Content-Type: application/sdp Content-Length: Aquí va la descripción de las sesiones multimedia (ver sección 8.VI).... Ringing User B User A SIP/ Ringing Via: SIP/2.0/UDP here.com:5060 ;branch=z9hg4bk74bf9 ;received= From: BigGuy <sip:usera@here.com> ;tag=9fxced76sl To: LittleGuy <sip:userb@there.com> ;tag= Call-ID: @here.com CSeq: 1 INVITE Content-Length: OK User B User A SIP/ OK Via: SIP/2.0/UDP here.com:5060 ;branch=z9hg4bk74bf9 ;received= From: BigGuy <sip:usera@here.com> ;tag=9fxced76sl To: LittleGuy <sip:userb@there.com> ;tag= Call-ID: @here.com CSeq: 1 INVITE Contact: <sip:userb@ > Content-Type: application/sdp Content-Length: 147 ACK User A User B ACK sip:userb@there.com SIP/2.0 Via: SIP/2.0/UDP here.com:5060; branch=z9hg4bk74bf9 Max-Forwards: 70 From: BigGuy <sip:usera@here.com>; tag=9fxced76sl To: LittleGuy <sip:userb@there.com>; tag= Call-ID: @here.com CSeq: 1 ACK Content-Length: 0 BYE User B User A BYE sip:usera@ SIP/2.0 Via: SIP/2.0/UDP there.com:5060 ;branch=z9hg4bknashds7 Max-Forwards: 70 From: LittleGuy <sip:userb@there.com> ;tag= To: BigGuy <sip:usera@here.com> ;tag=9fxced76sl Call-ID: @here.com CSeq: 1 BYE Content-Length: OK User A User B SIP/ OK Via: SIP/2.0/UDP there.com:5060 ;branch=z9hg4bknashds7 ;received= From: LittleGuy <sip:userb@there.com> ;tag= To: BigGuy <sip:usera@here.com> ;tag=9fxced76sl Call-ID: @here.com CSeq: 1 BYE Content-Length: 0 8.V-E Direccionamiento SIP Las direcciones SIP se definen como SIP Uniform Resource Locators (SIP-URLs), los cuales son de la forma sip: user@host.domain. Fig Flujo de una llamada entre dos endpoints. Mensajes SIP intercambiados: 8.V-F Componentes del protocolo Existen dos entidades en el protocolo, el Agente de Usuario y el Servidor de Red SIP.

96 95 El Agente de Usuario tiene incorporado un elemento cliente (UAC-User Agent Client) y un elemento servidor, el Agente de Usuario Servidor (UAS-User Agent Server). El cliente inicia la llamada y el elemento servidor atiende la llamada. Esto permite llamadas punto a punto con un protocolo de comunicación Cliente-Servidor. La principal función de los Servidores de Red es proveer la resolución de nombres y ubicación de los clientes. El cliente conoce únicamente una dirección SIP o un alias que puede ser una dirección de o un número telefónico. Mediante el uso de uno o varios servidores el cliente obtiene la información del nombre de host o dirección IP del destino. Existen tres tipos de Servidores de Red, un servidor de re-direccionamiento, un servidor Proxy y un servidor de Registro. Una llamada SIP básica no necesita de ningún servidor pero algunas de las facilidades más potentes dependen de ellos. Comparativamente el Agente de Usuario SIP es equivalente a un terminal H.323 y un Servidor de Red SIP es equivalente a un Gatekeeper H.323. El Agente de Usuario Cliente SIP (UAC) efectúa una solicitud (request), el servidor proxy SIP actúa como un agente para determinar la ubicación del destino y el Agente de Usuario Servidor SIP (UAS) acepta la llamada. Una invitación SIP consiste en dos mensajes INVITE seguida de un ACK. El mensaje INVITE contiene la descripción de la sesión que informa a la parte llamada que tipo de información multimedia puede aceptar y donde quiere que se la envíen. 8.V-G Servidores de Registro: Los servidores de Registro se definen como aquellos que aceptan las solicitud REGISTER y ubican la información recibida en estas solicitudes en el servicio de localización para el dominio que manejan. Las solicitudes REGISTER son generadas por los clientes de manera de establecer o remover un entrada que mapea su dirección SIP con la dirección donde debe ser contactado. Esta solicitud también puede ser usada para obtener la direccións actual de contacto de una determinada dirección SIP. Estos servidores procesan las solicitudes REGISTER de un conjunto específico de dominios. El servicio de localización es una abstracción de una base de datos. Este servicio puede correr en un equipo remoto que puede ser contactado usando un protocolo como LDAP, RADIUS, etc. El estándard de SIP deja esto para que sea implementado. Algunas implementaciones ubican el servidor y el servicio en el mismo equipo. Un servidor de registro puede autenticar también las solicitudes de REGISTER entrantes. Fig Proceso de registro. Formato de Mensaje. Solicitud del usuario. REGISTER sip:polonio0 SIP/2.0 Via: SIP/2.0/UDP :12345 From: <sip:polonio0@polonio0>; tag=acb0fbf7-2cc b-44da57b8c27f To: <sip:polonio0@polonio0> Call-ID: 30e d eae6ce5@ CSeq: 1 REGISTER Contact: <sip: :12345>; methods= INVITE, MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK User-Agent: Windows RTC/1.0 Expires: 1200 Event: registration Allow-Events: presence Content-Length: 0 Respuesta del servidor. SIP/ OK Via: SIP/2.0/UDP :12345 From: <sip:polonio0@polonio0>; tag=acb0fbf7-2cc b-44da57b8c27f To: <sip:polonio0@polonio0>;tag= Call-ID: 30e d eae6ce5@ CSeq: 1 REGISTER Contact: <sip: :12345>; methods= INVITE, MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK ;expires=1200 Content-Length: 0 8.V-H Servidores de Re-dirección Los servidores de re-dirección procesan los mensajes IN- VITE y responden con respuestas 3xx (de redirección) enviando de vuelta el SIP-URL alternativo donde es localizable el destinatario para que la fuente pueda contactarlo directamente. Por lo general son usadas las respuestas 301 y 302. El redireccionamiento permite a los servidores poner información de ruteo en las respuestas a los clientes. Luego de ayudar a localizar el destino quedan fuera del loop establecido para el envío de los mensajes. Los servidores de redireccionamiento conocen solamente el estado de las transacciones individuales que ellos manejan y no son conscientes del estado de las llamadas. Por esta razón los servidores de redireccionamiento son elementos de simple diseño y esto le permite a SIP ser altamente escalable y de gran performance. Los servidores de redireccionamiento son usados como balanceadores de carga (por su capacidad de enviar información de ruteo).

97 96 CAPÍTULO 8. PROTOCOLOS PARA SERVICIOS CONVERGENTES Respuesta Significado 300 Opciones Múltiples La dirección en la solicitud fue resuelta con múltiples opciones, con sus correspondientes ubicaciones. El usuario puede seleccionar una de estas. Esta respuesta es apropiada si el destino puede ser localizado en distintas ubicaciones y el servidor no puede o prefiere no hacer de proxy para el originador. Las siguientes 2 respuestas también pueden tener varias direcciones de contacto pero la diferencia es que son más específicas las razones del direccionamiento. 301 Trasladado Permanentemente El usuario no puede ser localizado más en esta dirección especificada en el URL de la solicitud (dirección de destino) y el cliente debe repetir la solicitud con la nueva dirección expresada en el campo de Contacto del encabezado. 302 Trasladado Temporalmente El usuario está temporalmente disponible en una dirección(s) diferente(s). El tiempo de validez de esa dirección puede estar expresado en el encabezado de Contacto. 305 Usar Proxy La dirección de destino solicitada debe ser accedida a través del proxy especificado en el campo de Contacto. 380 Servicio Alternativo La llamada no fue exitosa pero es posible servicios alternativos. Los servicios alternativos se describen en el cuerpo del mensaje de la respuesta. El uso de esta respuesta no está definido aún por el SIP y se reserva para uso futuro. TABLA 8.I RESPUESTAS DE LOS SERVIDORES DE RE-DIRECCIÓN. Estos servidores proxy pueden ubicarse según su propósito en distintos lugares de la red. La especificación SIP define dos tipos de servidores proxy, Stateless y Stateful: a) Stateless proxy: Fig Redirección de la petición. Es posible también solicitar la autenticación del usuario usando una respuesta de tipo 407 (ver más adelante). 8.V-I Servidores Proxy El estándar SIP define a los proxies como los elementos que pueden rutear las solicitudes SIP hacia los agentes de usuarios servidores (UAS) y las respuestas SIP hacia los Agentes Clientes de Usuarios (UAC). Las solicitudes podrían atravesar varios proxies en su camino al UAS, cada proxy tomará sus decisiones de ruteo y modificará la solicitud antes de reenviarla hacia el próximo elemento. Las respuestas pasarán por este mismo conjunto de proxies en orden inversa. Los proxies pueden verse como un router a nivel del protocolo SIP que reenvía las solicitudes y respuestas SIP, sin embargo los proxies SIP usan una lógica para el ruteo que es por lo general más sofisticada que un simple forwarding de paquetes basándose en una tabla. El estándar SIP permite a los proxies implementar acciones como ser validación de usuarios, bifurcación de solicitudes, resolución de direcciones, cancelación de llamadas pendientes, recordar la ruta o olvidar la ruta y detección y manejo de loops de señalización. Simplemente toma un mensaje y lo reenvía (forwarder). Cuando estos servidores reciben una solicitud la procesa de forma similar a como la haría un servidor stateful pero lo hace sin salvar ninguna información de la transacción. Esto significa que una ves que se reenvía el mensaje el servidor olvida toda la información manejada por ese mensaje. Como no puede recordar la información de los mensajes reenviados estos proxies deben manejar un algoritmo de ruteo que copie siempre el mismo mensaje en el mismo destino para evitar que la retransmisión de ACK, por ejemplo, sea ruteada hacia un Agente de Usuario distinto del que retornaron las respuestas. El hecho de no guardar información sobre las transacciones permite que tenga mayor performance pero trae algunas consecuencias, a saber: No puede asociar las respuestas con las peticiones reenviadas, con la consecuencia de no saber si la transacción fue exitosa. No puede asociar retransmisiones de peticiones con las peticiones y respuestas de las instancias anteriores de esos mensajes, puesto que procesa una retransmisión como si fuera la primer copia del mensaje recibido. Si el mensaje se pierde el proxy no puede retransmitirlo dejando para los agentes de usuarios o stateful proxies el trabajo. Debido a la alta performance y su capacidad de manejar altos throughputs estos tipos de proxies son a menudo usados en el core de las redes de los carriers

98 97 y proveedores de servicios. También a menudo son usados como balanceadores de carga. b) Stateful proxy: Este tipo de servidores procesan transacciones en lugar de mensajes individuales. El proxy maneja dos tipos de transacciones, transacciones de servidores para recibir las solicitudes y enviar de regreso respuestas, y transacciones de clientes para enviar solicitudes y recibir respuestas. Una solicitud entrante es procesada por el servidor de transacciones y reenviada hacia delante por uno o más clientes de transacciones (para hacer el forking, por ejemplo). Una respuesta es procesada por el cliente de transacciones correspondiente y reenviada hacia atrás por el servidor de transacciones. El proxy maneja la asociación entre los clientes y servidores de transacciones y el estado de ellas. 8.V-I.1 Validación de solicitudes Antes de rutear una solicitud un servidor de red SIP necesita validar la solicitud para asegurarse de continuar el procesamiento del mensaje. El mensaje tiene que pasar por los siguientes chequeos de validación: Chequeo sintáctico. Solamente de los campos que procesa el servidor. Chequeo del tipo de URI (por ejemplo ftp en ftp:company.com). En caso de no soportar ese tipo de URI devolverá un mensaje. Chequeo del campo MAX-FORWARDS. Similar al TTL de algunos protocolos, si el valor está en cero retorna un mensaje 483 (demasiados saltos). Cada proxy que maneja el mensaje debe decrementar este campo en uno. Este chequeo previene los loops y es obligatorio. Detección de loops. El proxy puede optar por ejecutar un algoritmo de detección de loops en la lista Via contenida en el mensaje. Si el proxy identifica una condición de loop, el rechaza el mensaje con una respuesta 482 (loop detectado). Este chequeo es opcional puesto que la detección de loops está asegurada por la obligatoriedad de chequear el campo MAX-FORWARDS. Fig El stateful proxy está al tanto del estado de las transacciones y de la historia del mensaje y puede por lo tanto implementar un procesamiento más inteligente de los mensajes que recibe, por ejemplo puede identificar retransmisiones y reenviarlas solamente si es necesario. También puede generar el mismo retransmisiones en caso de pérdida de mensajes. Además puede procesar las solicitudes CANCEL y generararlas de la manera que se necesiten. También pueden implementar la bifurcación de mensajes, útil, por ejemplo, para casos en que el destino tenga varias ubicaciones posibles. Sin embargo este tipo de servidores tiene las siguientes desventajas: Mayor consumo de memoria. Esto también limita la capacidad de llamadas concurrentes. Disminución del throughput. El consumo de ciclos de CPU por un mensaje aumenta por el manejo de transacciones, máquinas de estado, timers, asociación de clientes y servidores, etc. Mayor complejidad de la implementación. Aumento de la complejidad del Stack del SIP. Este tipo de proxies requiere ciertas funciones que los agentes de usuario no necesitan principalmente para las capas de transporte y transacciones. Esto requiere mayor modularidad en el Stack. Fig Loop Ilegal Campo PROXY-REQUIRE. El cliente puede indicar extensiones del protocolo SIP en este campo. El proxy debe inspeccionar este campo y verificar que soporta todas las extensiones listadas. Autenticación. Si el servidor determina que debe autenticar al originador del mensaje, antes tiene que asegurarse de que el mensaje contenga las credenciales para autenticarlo. Si el mensaje no contiene credenciales o fallan las credenciales al autenticarlo el proxy retorna un mensaje 407 conteniendo un desafío. 8.V-I.2 Resolución de nombres. Una ves que el proxy valido la solicitud entrante y decide reenviarla debe determinar el destino al cual debe reenviarse el mensaje con anterioridad. El proxy realiza dos tipos de resolución de nombres. Determina primero la dirección SIP del destino de un conjunto que tiene mapeados de alguna forma, por ejemplo si el destino tiene múltiples direcciones o aliases. La dirección puede estar predefinida en la solicitud y simplemente el proxy la reenvía. Si la dirección no está

99 98 CAPÍTULO 8. PROTOCOLOS PARA SERVICIOS CONVERGENTES especificada en el destino puede ser determinada por el proxy accediendo a un servicio de ubicación actualizado por el servidor de registro SIP, leyendo una base de datos, consultando a otro servidor, o substituyendo la dirección de destino usando algún algoritmo. Determina la dirección de transporte correspondiente a esa dirección SIP de la forma protocolo de transporte, dirección ip, puerto. Fig Flujo de mensajes INVITE-200-ACK 8.V-I.3 Reenvío de mensajes de los servidores proxy stateful. Los flujos de mensajes que se muestran en Fig. 8.14, Fig.8.15, Fig y Fig. 8.17, muestran la forma en que este tipo de servidores proxy reenvían los distintos tipos de mensajes. Solicitudes que no son de INVITACIÓN: En el caso de las solicitudes que no son de INVITE, como ser BYE y REGISTER, el proxy reenvía solicitudes y respuestas a medida que estas llegan. Las solicitudes retransmitidas no son reenviadas por el proxy, aunque el proxy si puede retransmitir solicitudes basándose en sus propios timers de retransmisión. Las respuestas retransmitidas si son reenviadas por el proxy. 8.V-I.5 Solicitudes de INVITE ACK-200 Las respuestas de tipo 2xx a una solicitud de INVITE son un caso especial. Para robustecer el establecimiento de llamada el protocolo obliga a que las retransmisiones de los mensajes 200 y los ACK de los mismos sean manejadas end-to-end en lugar de hop-by-hop. Esto significa que luego de recibir una respuesta 2xx el proxy reenvía el mensaje y posiblemente todas las retransmisiones que le sigan en una forma stateless no generando ningún ACK ni modificando el estado de sus transacciones. Solamente el Agente de Usuario del originador (A) tiene permitido confirmar (ACK) las respuestas 2xx. Si alguno de estos mensajes 2xx o ACK se pierden es responsabilidad del UA (B en este caso) de retransmitir el mensaje 2xx hasta recibir el ACK. Este procedimiento asegura que la llamada está establecida solo si ambos Agentes de Usuarios finalizaron el handshake. Fig Flujo de mensajes para solicitudes que no son de invitación 8.V-I.4 Solicitudes de INVITE-ACK no 2xx Cuando el proxy procesa una solicitud de INVITE el proxy responde con un mensaje de tipo 100 (intentando) para evitar las retransmisiones. Todas las respuestas recibidas de tipo 1xx son reenviadas hacia el hop previo. Si el proxy no recibe una respuesta 100 del hop siguiente puede retransmitir la solicitud INVITE. Fig Flujo de mensajes INVITE NO-2xx-ACK 8.V-I.6 Mensajes de CANCEL El stateful proxy puede generar solicitudes de CANCEL para cualquier solicitud pendiente de INVITE que haya reenviado previamente. El proxy al recibir una solicitud de CANCEL debe primero intentar asociarla al contexto de una solicitud de INVITE existente y cancelar cualquier transacción pendiente asociada a ese INVITE. Si no se localiza ese contexto el proxy debe reenviar en modo stateless la solicitud CANCEL puesto que debe también haber reenviado en este modo (stateless) la solicitud INVITE. 8.V-I.7 Registro de ruteo Este mecanismo permite a los proxies SIP requerir que todas las futuras solicitudes que pertenezcan al dialogo actual sigan la misma ruta de señalización (pasando por él). El proxy hace esto poniendo un encabezado (header) en las solicitudes iniciales de establecimiento (soportadas INVITE y SUSCRIBE). Los UAS y UAC construyen una lista de ruteo basada en este header y envían cada solicitud posterior con la lista de ruteo como un conjunto de headers de ruteo. Un proxy que no registre el ruteo luego de un mensaje INVITE no debe esperar recibir ningúna de las siguientes solicitudes, incluyendo los ACK. Similarmente un proxy que no registre el ruteo luego de una solicitud de REQUEST no debe esperar ver ninguno de los mensajes NOTIFY que le

100 99 Post procedimiento de información de ruteo. Reescritura de header con registro de rutas en las respuestas (por ejemplo cuando el proxy rutea entre dos dominios distintos). Pérdida de ruteo. Fig siguen. Cancelación 8.V-I.8 Proxy de pérdida de ruteo Un proxy de perdida de ruteo (también conocido como el router de pérdida) se diseña para que siga los procedimientos definidos para registrar el ruteo en la RFC2543bis-08 y siguientes. Este procedimiento permite al proxy introducir más saltos en la lista de ruteo independientemente del destino final del mensaje. Esto habilita al proxy a rutear los mensajes a través de un conjunto pre-definido de proxies antes de alcanzar su destino final. Estos routers fueron agregados a la especificación SIP debido a los requerimientos de los estándares de la tercera generación inalámbrica (3G), como el 3GPP, de manera de soportar ruteo inteligente de mensajes. 8.V-I.9 Recursión en respuestas 3xx Un proxy luego de recibir una respuesta 3xx (Redirección) puede agregar la información de la dirección de contacto provista en la respuesta 3xx como destino y generar una nueva copia de la solicitud hacia ese nuevo destino. Este proceso es llamado recursión en respuestas 3xx. El proxy puede realizar este mecanismo solamente si el URI de la solicitud original indica una dirección que pertenece al dominio del cual es responsable el proxy. Ver Fig Fig Flujo de mensajes de ruteo. Las excepciones a estos casos se presentan cuando el proxy actúa como proxy de salida o frente a una pérdida de ruteo. Los proxies por lo general registran la ruta solo en las solicitudes que establecen un diálogo como ser INVITE y SUSCRIBE. Sin embargo el proxy puede agregar un header con el registro de ruta en cualquier solicitud SIP. Los agentes SIP no cambian sus listas de rutas si los headers no provienen de solicitudes iniciales de INVITE o SUSCRIBE, por esta razón no se recomienda que los proxies pongan estos headers en otro tipo de solicitudes ya que agregarían overhead y tiempo de procesamiento sin ningún resultado. El uso selectivo de este mecanismo es importante ya que permite a los servidores mantenerse en la ruta de algunos diálogos de interés y dar soporte solo en el establecimiento a otros proxies quitándose luego del loop y no desaprovechando recursos en diálogos que no son de su interés. Un proxy que registra la ruta es requerido para implementar las siguientes funciones. Pre procesamiento de información de ruteo. Fig Recursión en respuestas 3xx. 8.V-I.10 Bifurcación (forking) Luego de procesar una solicitud entrante y determinar el destino, el proxy puede elegir reenviar la solicitud a múltiples direcciones. Este proceso es llamado forking y el proxy que lo soporta es llamado forking proxy. Esto permite implementar facilidades como: búsqueda simultánea de un usuario con múltiples dispositivos (teléfono de escritorio y celular, por ejemplo) o búsqueda de el primer agente disponible en un call center, o el reenvío si está ocupado. El proxy puede elegir realizar el fork de varias maneras:

101 100 CAPÍTULO 8. PROTOCOLOS PARA SERVICIOS CONVERGENTES En forma paralela, copiando las solicitudes en paralelo a múltiples destinos En forma secuencial, enviando las solicitudes y esperando por la respuesta de falla para enviar a la siguiente dirección. Una mezcla de ambos. 8.V-I.11 Autenticación Cuando un UAC envía una solicitud a un servidor proxy el proxy debe decidir si autenticar al originador o no antes de procesar la respuesta. El proxy puede enviar un desafío con una respuesta 407 (Proxy Authentication Required) con el header conteniendo el desafío. El cliente en este caso reenvía la solicitud con un header de autorización que provee las credenciales que coinciden con el desafío. El cliente también puede ahorrarse la respuesta del proxy y enviar directamente sus credenciales antes de que el proxy envíe un desafío, con esto se evitan retardos. Ambos mensajes (desafío y respuesta) usan criptografía para información como las contraseñas. La verificación del originador es útil para evitar robos de servicio así como para asegurarse de que algunos campos de mensaje no sean alterados por terceros (con el uso de la criptografía). Fig Bifurcación paralela Fig Autenticación. Fig Bifurcación secuencial. El forking paralelo es el más efectivo en tiempo para la búsqueda de un usuario, pero esto agrega complejidad al trabajo del proxy puesto que tiene que manejar múltiple transacciones concurrentes, recolectar múltiples respuestas y elegir la mejor respuesta para reenviarla hacia el originador. Esta decisión de la mejor respuesta es en base a un algoritmo provisto en el estándar SIP. Algunas respuestas tienen preferencia sobre otras. Luego de recibir una respuesta 2xx (exitoso) o 6xx (fallo global) en una de las transacciones clientes el proxy cancela todas las solicitudes pendientes (con CANCEL) y reenvía la respuesta final. Con este tipo de forking el proxy puede tener que realizar agregación de desafíos si recibe múltiples respuestas 401 (Authentication Required) o 407 (Proxy Autenticación Required). El proxy recolectará todas los desafíos y los reenviará al originador. El forking paralelo también hará agregación de respuestas de redirección si se reciben múltiples respuestas 3xx. 8.V-I.12 Proxy de salida Un proxy de salida es un proxy que recibe las solicitudes independientemente de el destino del mensaje enviado. Los clientes pueden enviar todos los mensajes vía este proxy, típicamente los clientes son configurados con un proxy de salida, en forma manual o con protocolos automáticos. Estos proxies permiten la creación de clientes simples que no tengan que preocuparse por tomar decisiones de ruteo ni hacer consultas de DNS. Son especialmente importantes en dispositivos wireless que tienen capacidades limitadas pero pueden hacer roaming entre distintas redes. 8.V-I.13 Políticas Todas estas formas de manejar los mensajes definen una política de servidores. Esta política debe ser establecida por el proveedor de servicio o administradores. 8.VI SDP SESSION DESCRIPTION PROTOCOL

102 101 8.VI-A Introducción (RFC 2327). SDP es un protocolo para anunciar sesiones multimedia de tipo unicast o multicast comunicando las direcciones y herramientas necesarias para participar en las mismas. Este protocolo no incorpora un protocolo de transporte y puede ser usado con diferentes protocolos como ser SAP (Session Announcement Protocol), SIP, H.248, Real-Time Streaming Protocol, correo electrónico y HTTP, con extensiones MIME del tipo application/sdp, entre otros. Este protocolo sin embargo no está pensado para la negociación del contenido de las sesiones ni de la codificación multimedia a usar. SDP sirve a dos propósitos primarios: comunicar la existencia de una sesión y ser una forma de transportar información suficiente para permitir unirse y participar de la sesión. SDP transporta información de la sesión multimedia que incluye los siguientes ítems: El tipo de información multimedia (video, audio, etc) El protocolo de transporte usado (RTP/UDP/IP, H.320, etc) El formato de la información multimedia (H.261 video, MPEG video, etc) Direccionamiento multicast para la información multimedia o dirección remota para la información multimedia en un ambiente unicast. Direccionamiento de transporte para la información multimedia. Información de duración de sesiones,tiempo de inicio, repetición programada. Tipo de sesión, pública o privada con encriptación. Además, SDP admite punteros adicionales con formato URI (Universal Resources Identifiers) para incrementar la información acerca de la sesión. 8.VI-B Codificación SDP al igual que SIP es enteramente textual usando una conjunto de caracteres ISO con la codificación UTF- 8 (aunque también se soporta alternativamente ISO ). Para los campos de los mensajes y los nombres de los atributos se usa únicamente el subconjunto US-ASCII del UTF-8. 8.VI-C Especificación Una descripción de sesión SDP consiste en un número de líneas de texto de la forma <tipo>=<valor>. <tipo> es siempre un carácter y <valor> es un string de texto estructurado con formato dependiente del <tipo>. 8.VI-C.1 Pares <tipo>=<valor> Algunos opcionales (*) pero que deben aparecer en el orden establecido. 8.VI-C.2 Descripción de sesión v=(versión del protocolo) - <version> o=(dueño/creador e identificador de sesión) - <username><session id><version><network type><address type> s=(nombre de la sesión) - <session name> i=*(información de la sesión) - <session description> u=*(uri de descripción) - <URI> e=*(dirección de correo electrónico) -< address> p=*(número telefónico) -<phone number> c=*(información de la conexión) - <network type><address type><connection address> b=*(información de ancho de banda) - <modifier>: <bandwidth-value> z=*(ajustes para el uso horario) - <adjustment time><offset><adjustment time><offset>... k=*(llave de encriptado) - <method>:<encryption key> a=*(cero o más líneas de atributo de sesión) - <attribute>:<value> 8.VI-C.3 Descripción temporal t=(tiempos de inicio y finalización de la sesión) - <start time><stop time> r=*(cero o más tiempos de repetición) - <repeat interval><active duration><list of offsets from start-time> 8.VI-C.4 Descripción multimedia m=(tipo multimedia y dirección de transporte) - <media><port> / <number of ports><transport><fmt list> i=*(encabezamiento multimedia) - <string> c=*(información de conexión) b=*(información de ancho de banda) k=*(llave de encriptado) a=*(cero o más líneas de atributos multimedia) 8.VI-C.5 Ejemplo de descripción SDP v=0 o=laptop-toshiba 0 0 IN IP s=session c=in IP b=ct:1000 t=0 0 m=audio RTP/AVP a=rtpmap:97 red/8000 a=rtpmap:111 SIREN/16000 a=fmtp:111 bitrate=16000 a=rtpmap:112 G7221/16000 a=fmtp:112 bitrate=24000 a=rtpmap:6 DVI4/16000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:4 G723/8000 a=rtpmap:5 DVI4/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp: VII VOZ Y MULTIMEDIA SOBRE ATM 8.VII-A Transportando la voz sobre redes ATM. El ATM Forum en su documento Voice and Telephony Over ATM to the Desktop [36] especifica las condiciones que hacen posible la implementación de servicios de voz y telefonía en redes B-ISDN así como también la interoperabilidad entre terminales B-ISDN y N-ISDN. Este organismo especifica además en los documentos [37] y [38] dos métodos para emular el loop de abonado usando ATM. Estos servicios de emulación de loop (LES), junto con las tecnologías de acceso xdsl permiten brindar servicios de voz a operadores entrantes con el uso del unbundling del par de cobre.

103 102 CAPÍTULO 8. PROTOCOLOS PARA SERVICIOS CONVERGENTES 8.VII-A.1 Servicio de Emulación de Circuitos (CES-DBCES) - Troncales ATM usando AAL 1. El Servicio de Emulación de Circuitos (CES-Circuit Emulation Service) está definido en el ATM Forum y es un servicio estable y confiable para soportar el tráfico CBR, como por ejemplo tramas E1/T1 sobre redes ATM. El Servicio de Emulación de Circuitos con Ancho de Banda Dinámico (DBCES) es una mejora del CES y permite manejar capacidades menores a una E1/T1 (nx64kbps) en las conexiones ATM. Esta emulación permite transportar canales individuales entre troncales de PBXs identificando cada time slot. Además permite la utilización de la señalización por canal asociado (CAS) para cada canal. DBCES se define por lo tanto como un servicio estructurado de emulación de circuitos. Como se muestra en la Fig. 8.23, la red de banda angosta se conecta a la red ATM mediante un dispositivo que implementa la función de InterWorking (IWF) del CES. Fig Servicio de emulación de circuitos (CES) 8.VII-A.1.a Función de InterWorking CES-DBCES: La Función de InterWorking CES hace posible la interconexión de dispositivos no ATM entre sí o entre dispositivos ATM con otros dispositivos no ATM (N-ISDN por ejemplo). 8.VII-A.1.b Interfases físicas del dispositivo IWF: Las interfases entre el dispositivo IWF y la red de banda angosta en el caso de usar señalización N-ISDN (fuera de banda) es la PRI ISDN definida en el I.431. Para la señalización CAS la interfaz es una E1 G.703 o DS1 definida en la sección 3 del ANSI/TIA/EIA-464-B. La interfase entre el IWF y la red ATM puede ser cualquiera de las interfases definidas por el ATM Forum o en las recomendacións para la interfase UNI de la serie ITU-T I.432.x. 8.VII-A.1.c Señalización: Se requieren varios niveles de señalización: entre la red de banda angosta y el IWF; entre IWF s (IWF-IWF) y entre el IWF y la red ATM. Señalización en la interfase de banda angosta La señalización usada en la interfase entre la red de banda angosta y el IWF es la definida en la Q.931 o PSS1 en el caso de N-ISDN. La norma G.704 define la estructura del frame para los bits de la CAS de una E1 y DS1. La señalización CAS de una E1 y DS1. La señalización CAS para una DS1 es: E&M para la señalización de supervisión y DTMF para la señalización del direccionamiento como se especifica en la sección 4.2 de la ANSI/TIA/EIA-464-B. Señalización IWF-IWF Los protocolos de señalización entre IWF pueden ser algunos de los listados a continuación pero deben ser iguales a los usados en la interfaz de banda angosta. DSS1 ISDN (Anexo D, Q.931) PSS1 en el punto de referencia Q para la PINX-QSIG (Transit Private Integrated Network Exchange). Señalización por canal asociado (E&M con DTMF de acuerdo a la ANSI/TIA/EIA-464-B). Señalización con la red ATM La señalización ATM es usada entre el IWF y la red ATM para establecer: SVC s para la señalización IWF-IWF (solo en el caso de N-ISDN). SVC s para los canales de 64kbps por la red ATM. En la Fig se muestran las funcionalidades de la IWF, estas pueden resumirse en: Terminación de señalización, extrae e inserta la señalización desde y hacia la red de banda angosta. En el caso de señalización fuera de banda el IWF termina la señalización y transporta todos los mensajes de banda angosta en una conexión establecida al efecto con el dispositivo IWF remoto usando los servicios de la SAAL y AAL5. Para la seńalización CAS se utiliza el mismo circuito virtual ATM que transporta la voz. Manejo de llamada, para implementar los mensajes de setup y release desde el equipo de banda angosta conectado incluyendo la selección del destino para cada llamada. Switcheo, para permitir la combinación de canales del lado de la red de banda angosta y sus correspondientes posiciones en canales del lado de la red ATM y viceversa. Multiplexado, para combinar los canales de múltiples fuentes desde el lado de la red de banda angosta hacia los troncales ATM. Mapeo y adaptación, para insertar los canales de 64kbps en las posiciones asignadas en el VCC de acuerdo al ATM Forum [39] Administración de los VCC para asignar y liberar los VCCs a PBX s distantes. La función CES es noestructurada ya que no se encarga de identificar canales individuales dentro de una trama. La capa AAL1 provee las siguientes funciones para la capa superior: manejo del jitter, recuperación e indicación del temporizado, sincronismo e indicación de pérdidas de celdas. 8.VII-A.1.d Temporización: Los servicios DS1/E1 y Nx64 kbps (estructurados) requieren una sincronización del circuito como se recomienda en la ITU I Para soportar la recuperación del reloj por el equipo de usuario conectado al equipamiento se debe cumplir: Para servicios de DS1 la interfase de servicio del IWF provee un reloj de MHz. Para servicios de E1 la interfase de servicio del IWF provee un reloj de 2048 MHz. Estos requerimientos asumen que el IWF provee el reloj por la interfase CES misma, no habla de la provisión del reloj por una interfase física distinta.

104 103 Fig Funcionalidad de la Función de InterWorking CES Para los servicios no estructurados el reloj puede ser provisto por el IWF (modo síncrono) a través de su interfase CES o de una fuente externa que lo distribuye por toda la red (modo asíncrono). 8.VII-A.1.e Capa de Adaptación ATM AAL: Para el transportar la señalización IWF-IWF de modo que soporte señalización N-ISDN (fuera de banda) se usa AAL 5. En el plano de usuario, se usa AAL 1 especificada en la recomendación I AAL1 tiene la capacidad de delinear bloques de tamaño fijo de datos, cada bloque con un número entero de octetos. Esto es usado para transportar múltiples DS0 s organizados en bloques. Si el tamaño de un bloque es un octeto, simplemente se alínea el octeto AAL con el payload ATM de la celda. Para un tamaño mayor AAL1 provee un mecanismo de punteros para indicar el comienzo de una estructura de bloque, este mecanismo se describe en la recomendación I Esta estuctura se resume como sigue: N-ISDN Para permitir la codificación de canales múltiples N- ISDN sin transporte de señalización se crea un bloque con N octetos uno por cada canal de 64kbps agrupándolos en secuencia como se muestra en la Fig Fig Ejemplo del formato de la estructura para 3x64kbps CAS Para el soporte de CAS la estructura del bloque AAL1 se especifica en la sección [39], el número de 24 o 31 canales de los sistemas DS1 o E1 no se aplican. El número de canales por VCC es limitado a 128. La información de la voz y los tonos DTMF son transportados sobre el payload del bloque AAL 1. La señalización CAS se transporta en la porción de señalización del bloque AAL 1 como se muestra en la Fig Fig Ejemplo del formato de la estructura Multiframe para DS1/E1 con CAS para 3x64kbps 8.VII-A.2 Emulación de loop de abonado usando AAL 2 8.VII-A.2.a Breve descripción de AAL2: El protocolo AAL2 tiene dos sublayers mostradas en la fig 8.27: Service specific convergence sublayer (SSCS) Common part sublayer (CPS) Fig Estructura del protocolo AAL2 La sublayer SSCS codifica los distintos flujos de información para el transporte sobre una única conexión ATM. Estos flujos pueden provenir de canales de voz codificados, descriptores de inserción de silencios, dígitos de marcado o fax. La SSCS puede proveer también control de errores en información crítica (por ejemplo en señalización CAS y en los dígitos de marcación) usando un CRC de 10 bits. Estas celdas se las llama celdas AAL2 tipo 3. La SSCS segmenta la información que es pasada desde las capas superiores en un número de unidades de datos, luego las pasa a la subcapa CPS para su transmisión. El largo máximo de estas unidades es 45 o 64 bytes. La sublayer CPS es responsable del transporte end-to-end. Esta sublayer posibilita la multiplexación de paquetes de voz de largo variable en un único VCC ATM. Como desventaja se agrega un overhead adicional de tres bytes por cada paquete de datos. Campos del CPS. En la Fig puede observarse el formato y los distintos campos del paquete CPS. A continuación se describe el campo Start Field de la celda ATM y los campos del paquete CPS.

105 104 CAPÍTULO 8. PROTOCOLOS PARA SERVICIOS CONVERGENTES Start field. - Se compone por campo de Offset que es un puntero de seis bits a la posición del primer paquete CPS. CID (Channel ID). - Identifica al usuario final, El CID usa el valor 1 para intercambiar procedimientos de gestión de la capa, como ser negociación del establecimiento de canales. El CID hace posible la multiplexación de hasta 248 canales de usuarios. Si, por ejemplo, se usan 8 E1 s que terminan en un Media Gateway, se usan 240 valores del CID. Algunos valores del CID no son usados. LI (Length Indicator). - Identifica el largo del paquete CPS. UUI (User-to-User Indication) - Provee dos funciones. Conducir información específica en forma transparente entre dos puntos (por ejemplo entre entidades CPS o SSCS) y distinguir entre los diferentes usuarios, como entidades SSCS y usuarios de capa de gestión. HEC (Header Error Control). - Permite el descarte del resto del paquete CPS hasta el próximo Start field. Esto resulta en una mejor eficiencia ya que no todos los canales de voz residentes en ese VCC ATM son afectados por los errores. Fig Estructura del paquete CPS 8.VII-A.2.b Introducción a loop de abonado sobre AAL2: Los troncales ATM usando AAL 2 y categorías de servicios tipo VBR proveen un mecanismo eficiente de transporte del tráfico de voz y otros con características similares a éste entre dos funciones de InterWorking (IWF). Esto permite como se muestra en la fig interconectar dos troncales no-atm a travéz de la red ATM. Este servicio soporta la distribución de servicios de voz desde la PSTN hacia los equipos de abonado con enlaces ATM como los provistos con las líneas xdsl, enlaces wireless, FTTH, etc. El IWF puede soportar uno o más estándares de esquemas de codificación para la voz, supresión de silencios y CNG (Comfort Noise Generation) en el abonado de destino. En el modelo de referencia solo se muestra las entidades de voz pero el equipamiento que provee la función de InterWorking de abonado (Customer Premises InterWorking Function - CP-IWF) puede proveer también una interfaz de datos (p.e. Ethernet) hacia el abonado. El tráfico originado por este tipo de interfases puede ser transportado por ejemplo sobre AAL 5 u otra AAL apropiada sobre la misma interfase ATM usada para el tráfico de la voz. Fig Modelo de referencia, emulación de loop de abonado usando AAL 2 El nodo de servicio mostrado en la Fig puede representar un switch de PSTN clase 5, PBX, etc. La capa de aplicación AAL2 transporta la voz o video paquetizado usando VBR y sus funciones incluyen el multiplexado y la indicación de la pérdida o los errores en los paquetes. La opción de AAL2 con VBR ofrece un mejor servicio puesto que soporta la compresión de la voz, detección y supresión de silencios y detección y liberación de canales inactivos. Este tipo de conexión soporta señalización CAS y por canal común (CCS). Existen dos formas de armar enlaces usando AAL2: 1) Troncal switcheada: la señal proveniente de la red de banda angosta es analizada y ruteada en un canal AAL2 por un VCC armado entre IWF s, de forma similar se rutean las llamadas salientes de la red ATM. 2) Troncal no-switcheada: La señal proveniente de la red de banda estrecha es siempre transportada sobre el mismo canal AAL 2 y VCC. Los circuitos virtuales ATM entre el CP-IWF y el CO-IWF (Central Office InterWorking Function) pueden ser SVC s, PVC s o SPVC s y pueden transportar: tráfico y señalización CAS usando AAL2, llevando la señalización CAS sobre el mismo canal AAL2 que el tráfico asociado. tráfico y señalización CCS usando AAL2, donde la señalización CCS para el control de los servicios de banda angosta se transporta en un canal AAL2 específico con el mismo VCC ATM que el tráfico asociado. 8.VII-A.2.c Arquitectura del servicio: En la Fig se muestra de que forma son soportados los servicios por las distintas partes del stack de protocolos ATM. Funcionalidad del CO-IWF Dependiendo de la configuración, un CO-IWF implementa un subconjunto de las siguientes funciones: Función de conmutación, para permitir que canales individuales desde la interfaz de nodo de servicio (Service Node Interface - SNI) pueda conectarse a cualquier canal inividual AAL 2.

106 105 Fig Protocolos ATM para el soporte de los distintos servicios. InterWorking de señalización, para recibir la señalización desde el SNI e insertarla en las interfases ATM. Manejo de llamadas, para interpretar el establecimiento y liberación de llamadas desde el nodo de servicios y el equipo de abonado y controlar la conexión de canales del SNI hacia canales AAL2. Funciones SSCS (Service Specific Convergence Sublayer) de usuario, incluyendo codecs de voz para la compresión, canceladores de eco y moduladores/demoduladores para FAX. Funciones AAL2 SSCS, para dar formato a la información de usuario en paquetes que serán transportados por las conexiones AAL2. Funciones AAL2 CPS (Common Part Sublayer), para multiplexar las conexiones AAL2 en celdas ATM. Gestión de VCC s ATM, para asignar y liberar, según la demanda, recursos de VCC s ATM hacia los CP-IWF s distantes para soportar las necesidades de tráfico. Gestión de canales AAL2, para asignar y liberar canales AAL2 hacia los CP-IWF s distantes para soportar las necesidades de tráfico. Funciones SAAL (Signaling ATM Adaptation Layer) para soportar la señalización UNI ATM para el establecimiento de SVC s bajo demanda. Interfaz de gestión para permitir la administración de funcionalidades de telefonía en los CP-IWF s distantes de forma remota desde el CO-IWF por ejemplo. Funcionalidad del CP-IWF Dependiendo de la configuración, un CP-IWF implementa un subconjunto de las siguientes funciones: Interfases de capa física para aplicaciones de telefonía, como POTS analógicos, BRI ISDN o DS1/E1 canalizados. InterWorking de señalización, para recibir la señalización desde la interfase de banda angosta e insertarla en las interfases ATM. Funciones SSCS (Service Specific Convergence Sublayer) de usuario, incluyendo codecs de voz para la compresión, canceladores de eco y moduladores/demoduladores para FAX. Funciones AAL2 SSCS, para dar formato a la información de usuario en paquetes que serán transportados por las conexiones AAL2. Funciones AAL2 CPS (Common Part Sublayer), para multiplexar las conexiones AAL2 en celdas ATM. Gestión de VCC s ATM, para asignar y liberar, según la demanda, recursos de VCC s ATM hacia los CO-IWF s distantes para soportar las necesidades de tráfico. Gestión de canales AAL2, para asignar y liberar canales AAL2 hacia los CO-IWF s distantes para soportar las necesidades de tráfico. Funciones SAAL (Signaling ATM Adaptation Layer) para soportar la señalización UNI ATM para el establecimiento de SVC s bajo demanda. Interfaz de gestión para permitir la administración de funcionalidades de telefonía desde el CO-IWF. Interfases soportadas La especificación [38] identifica las interfases soportadas del lado del usuario en el CP-IWF y las interfases ATM en el CP-IWF y CO-IWF. No especifica la interfase entre el CO-IWF y el nodo de servicios ya que se entiende que el protocolo que opera entre IWF s debe dar soporte genérico para la distribución de servicios de banda angosta hacia el abonado (parte de usuario del CP-IWF) independientemente de esta interfase. Las interfases de servicios hacia redes de conmutación de circuitos podrían ser, por ejemplo, las definidas en las especificaciones Telcordia GR-303, Telcordia TR-008, ETSI V5.1 (ITU-T G.964) y ETSI 5.2 (ITU-T G.965). Interfases ATM del CO-IWF La interfase entre el CO-IWF y la red ATM debe ser una de las definidas en el ATM Forum, por la serie de recomendaciones UNI ITU-T I.432.x o una de las siguientes: ATM over ADSL de acuerdo al DSL Forum TR-017. Otra interfase para SDSL, HFC o wireless dependiente de la aplicación como por ejemplo ITU-T SHDSL (G.991.2, Single-pair High Speed Digital Suscriber Line) ANSI HDSL2 (High bit rate Digital Subscriber Line - 2nd. Generation (HDSL2)) ETSI SDSL (Symmetric Single-pair High Speed Digital Suscriber Line). Capa de Adaptación Un CO-IWF utiliza la capa AAL2 definida en el I También puede utilizar AAL5 (para soportar SAAL) que se define en la I Capa de señalización. Si el CO-IWF establece SVC s entonces la señalización utilizada estará de acuerdo con la UNI 4.0 (af-sig ) del ATM Forum, PNNI 1.0 (af-pnni ), AINI 1.0 (af-cs ) o ITU-T Q.2931.

107 106 CAPÍTULO 8. PROTOCOLOS PARA SERVICIOS CONVERGENTES Interfases de usuario del CP-IWF. El CP-IWF debe soportar las interfases apropiadas para conectar el equipamiento telefónico. Estas interfases incluyen interfases para aparatos analógicos, BRI ISDN, y E1/DS1. Las especificaciones para estas interfases incluyen: Interfase analógica para telefonía de acuerdo a la ANSI T1.401, ANSI T1.405, ANSI T1.409, Telcordia TR- NWT o estandard nacional equivalente. Basic Rate ISDN (BRI) de acuerdo a la ITU-T I.430, Telcordia TR-NWT , ETSI ETS o estándar nacional equivalente. Interfases ATM del CP-WIF. Las interfases CP-WIF con la red ATM soportadas son las mismas que en el caso del CO-IWF. 8.VII-A.2.d Facilidades soportadas: A continuación se listan algunas de las facilidades soportadas por el CO-IWF y CP-IWF, para el servicio de emulación de loop sobre AAL2. Comunicación entre IWF s Un CP-IWF y un CO-IWF se conectan a través de un VCC ATM. Los VCC s pueden ser PVC s, SVC s, o SPVC s. Dentro de ese VCC se utiliza AAL2 para transportar tráfico de portadora, CAS, CCS y otros tipos de tráfico de los planos de control y gestión. VCC s transportando canales AAL2 para el servicio de emulación de loops Un VCC ATM puede contener el tráfico de una o más líneas analógicas o BRI ISDN. La señalización de supervisión para líneas analógicas es transportada como CAS en el mismo canal AAL2 que el tráfico de transporte o en un canal AAL2 separado como CCS. Para un VCC dado estos métodos son exclusivos. El tráfico ISDN BRI es transportado como 2B+D por canales AAL2 separados para cada canal B y D, más detalles de esto puede encontrarse en la sección 5 de [38]. Señalización entre el CO-IWF y el CP-IWF para telefonía analógica La señalización de control entre el CO-IWF y el CP-IWF puede ser transportada en forma de CAS o CCS sobre AAL2. En ambos casos la información es transportada sobre el mismo VCC que contiene los canales AAL2 para el transporte de datos de voz. La señalización analógica de las interfases POTS del CP-IWF es convertida por el CP-IWF. Los estados de las líneas analógicas son mapeados en palabras de código ABCD y transportadas vía CAS como se define en el Anexo L del I Los streams multimedia son mapeados según los Anexos A-I del I.366.2, si el CP-IWF usa un codec que no soporta el transporte transparente de tonos DTMF por el canal de datos, los tonos son mapeados a dígitos y transportados usando el servicio definido en el Anexo K de la I En las Figs y 8.32 se muestran los modelos de referencias de los protocolos con CAS y CCS para el CP-IWF con telefonía analógica. Señalización entre el CO-IWF y el CP-IWF para BRI ISDN El modelo de referencia es mostrado en la Fig. 8.33, el transporte de los streams multimedia entre el CP-IWF y el CO-IWF con el uso opcional de DTMF se realiza de la misma forma que en telefonía analógica. La señalización DSS1 no se termina en el CP-IWF sino que el CP-IWF la reenvía desde Fig Modelo de referencia del protocolo para el CP-IWF con telefonía analógica usando CAS sobre AAL2. Fig Modelo de referencia del protocolo para el CP-IWF con telefonía analógica usando CCS sobre AAL2. el canal D a través del VCC AAL2 usando el servicio de Detección de Transmisión y Error especificado en la I Fig Modelo de referencia del protocolo para el CP-IWF con ISDN BRI con el relay de DSS1 sobre AAL2. Selección y cambio de la codificación Los IWF s soportan al menos un perfil de codificación, cada uno de estos perfiles puede tener varias entradas. Estas entradas especifican el algoritmo usado y la forma de empaquetar la información de los streams multimedia. Antes de establecer la llamada los IWF s deben conocer el perfil a usar. La información de los distintos perfiles puede obtenerse en la I (ver tabla 8.II) Supresión de canales inactivos La supresión de canales inactivos es controlada por el CO-

108 107 Id. Descripción del perfil 0 No usado 1-6 Reservado para el af-vtoa PCM-64, ADPCM-32, 44 octetos por paquete, sin supresión de silencios- 8 PCM-64, 44 octetos por paquete, sin supresión de silencios 9 PCM-64, 44 octetos por paquete, con supresión de silencios 10 PCM-64 y ADPCM-32,44 octetos por paquete, con supresión de silencios 11 PCM-64 y ADPCM-32,40 octetos por paquete, con supresión de silencios 12 PCM-64 y ADPCM-32,40 octetos por paquete, sin supresión de silencios 11 Reservado para asignaciones futuras TABLA 8.II PERFILES DE CODIFICACIÓN PREDEFINIDOS POR EL ATM FORUM IWF activando y desactivando los canales AAL2 usando los procedimientos establecidos en la sección o de [38]. Para determinar el estado inactivo de una llamada el CO- IWF puede monitorear el canal D ISDN o los canales CAS, CCS detectando el establecimiento y liberación de llamadas. Otra forma de hacer esto es determinando alguna condición de inactividad en la información, esta condición podría ser, por ejemplo, un patrón de datos. El Anexo A del documento af-vtoa-oo85 contiene notas informativas al respecto. Detección y supresión de silencios Cuando son usados esquemas de codificación que no manejan la supresión de silencios en forma nativa, el IWF puede monitorear la actividad y determinar cuando existe un período de silencio, suprimiendo la transmisión durante esos intervalos y transmitiendo la información necesaria para regenerar en el destino el ruido de background necesario. La I contiene los procedimientos para asegurar el mantenimiento de la sincronización durante estos intervalos de silencio. Cancelación de eco y delay El delay end-to-end es introducido por varios factores como: Paquetización. Algoritmos de compresión. Tiempo de propagación. Conmutación de celdas ATM en la red. Encolamiento en nodos de la red ATM. Delay introducido por buffers para evitar el jitter. El DSL Forum WT-043 sugiere que el delay en un sentido introducido por el canal de audio al implementar LES-AAL2 con un acceso DSL sea del orden de los ms. Esto excede claramente el límite superior establecido en el ANSI T1.508 para el acceso en redes digitales sin cancelación de eco, por lo que la cancelación de eco se hace necesaria. Las recomendaciones ITU-T G.131, G.114, G.165, G168 y otras contienen referencias sobre el tema. El IWF puede soportar la cancelación de eco pero no está establecido en la especificación [38]. Transporte de datos en banda base Algunos de los esquemas de codificación (perfiles) no soportan el paso de señales provenientes de módems en banda vocal. Para permitir esto el IWF puede implementar varios métodos listados a continuación: Cambio de perfil de codificación. Detección de tonos o tonos usados en la negociación de fax, módem y llamadas de terminales. Monitoreo de información de facsímile e implementación de los procesos de demodulación y modulación descritos en el Anexo M del I Luego de la finalización de la actividad de datos en banda vocal el IWF puede retomar su esquema de codificación anterior. 8.VII-A.3 Control de VCC s AAL2 y Canales Cuando se crea un VCC AAL2 ciertas características deben ser acordadas. A continuación se describen algunos parámetros (características) que deben especificarse en el proceso de provitioning. 8.VII-A.3.a Identificación de aplicación (AppId): Este identificador especifica la combinación de protocolos a usar entre IWF s como por ejemplo CAS, señalización PSTN 29, DSS1 BRI, CCS, etc. Estos valores están especificados por el ATM Forum, en la sección 4 de [38] y los códigos correspondientes (que en definitiva será el valor del identificador) están especificados en la sección 5 del documento ATM Forum Well-known Addresses and Assigned Codes disponible en el sitio web del mismo. El valor del AppId de un VCC determinará el stack de protocolos usados sobre el VCC, como se muestra en las Figs. 8.31, 8.32 y VII-A.3.b Tipo de SSCS (Service Specific Convergence Sublayer): El tipo de SSCS que se aplica en cada canal varía según el uso del mismo. Los canales que se utilizan para transportar los streams multimedia (POTS o canales B ISDN) usan el SSCS definido en la I.366.2, los canales usados para el control y gestión (CCS, ISDN D, ELCP, LES-EOC) deben usar el definido en la I VII-A.3.c Valores por defecto de los parámetros SSCS: Un determinado VCC puede tener canales que soportan distintos tipos de SSCS. Cada tipo debe tener asociado un valor de SSCS. Estos valores son aplicados por defecto para cada canal AAL2 del VCC en ausencia de señalización o provitioning para los canales AAL2. 8.VII-A.3.d Valor del CPS (Common Part Sublayer) AAL2: Los parámetros que deben ser aceptados son: máximo número de CID s (Identificador de canal AAL2) que pueden ser activados. máximo largo de paquete. Provisión de PVC s En el proceso de provitioning de un PVC AAL2 se especifican las siguientes características. AppId Valores por defecto de los parámetros SSCS para cada tipo SSCS. 29 la señalización PSTN se refiere al uso de señalización V5 definida en el ETSI EN

109 108 CAPÍTULO 8. PROTOCOLOS PARA SERVICIOS CONVERGENTES AAL = AAL2. Valor del CPS 8.VII-A.3.e Señalización de SVC s: Si es usado un SVC para establecer la conexión ATM entre el CP-IWF y el CO- IWF, se utilizan las características del VCC listadas en la provisión de PVC s salvo el valor por defecto del SSCS. 8.VII-A.3.f Asignación de canales AAL2: Valores del CID. En la tabla 8.III se muestran los valores del parámtro CID en el caso de no usar ELCP, estas asignaciones pueden ser sobrescritas por una acción del sistema de management o provitioning, Los valores del 1 a 7 no son asignables (reserva del I.363.2). Valor CID del Propósito 8 CCS y ELCP 9 LES-EOC Reservados uso futuro Canales POTS Canales D ISDN BRI Canales B ISDN BRI Reservados para uso específico de los fabricantes TABLA 8.III ASIGNACIÓN ESTÁTICA DEL CID La tabla 8.IV muestra la forma de derivar el valor del CID a partir del tipo de canal y número de puerto del CP-IWF. Tipo de canal POTS Canal D ISDN Canal B#1 ISDN Canal B#2 ISDN Valor del CID 15 + N de puerto N de puerto BRI * N de puerto BRI * N de puerto BRI TABLA 8.IV DERIVANDO EL CID CON EL TIPO DE CANAL Y PUERTO DEL CP-IWF En caso de usar ELCP se utiliza un mensaje de ALLOCATION para asignar el número de CID. En este caso no se utilizan los valores del 1 al VII-A.4 Señalización de banda angosta POTS 8.VII-A.4.a LES usando CAS entre CP-IWF y CO-IWF: Señalización del estado de línea Para señalizar el estado de la línea, como ser el on-hook, offhook, idle y ringing se mapean estos estados en palabras de código ABCD. Los procedimientos para el transporte de las palabras se establecen en el Anexo L de la I El mapeo de los estados de la línea analógica y las palabras ABCD se especifican en las tablas 12-3 a 12-6 de la recomendación Telcordia GR-303-CORE. Marcación por tonos Como se mencionó anteriormente, si el codec usado no tiene previsto el transporte de tonos DTMF, se codifican estos tonos para el transporte en paquetes de tipo 3 entre IWF s de acuerdo a los procedimientos establecidos en el Anexo K de la I Marcación por pulsos La marcación por pulsos es soportada por la mediante señalización CAS usando transmisión de paquetes de tipo 3 para transportar los cambios de estados entre el on-hook y off-hook. 8.VII-A.4.b LES usando CCS entre CP-IWF y CO-IWF: Señalización del estado de línea Los IWF s que soportan CCS usan el protocolo PSTN definido en la ETSI EN sección 13 para el transporte de señales de estado de línea. Se utiliza la dirección de capa 3 para identificar el puerto del CP-IWF al cual se refiere el mensaje. Señalización del estado de línea Esto ser implementa de la misma forma que en CAS. Marcación por pulsos El protocolo PSTN soporta la transmisión de pulsos. Se define en la sección de la norma mencionada anteriormente. 8.VII-A.4.c Transmisión de datos en banda vocal: Cuando es necesario la transmisión de datos en la banda vocal, por ejemplo, cuando se envía el número de abonado con tonos DTMF se debe cambiar el codec utilizado -si este no soporta ese tipo de transmisión-. 8.VII-A.5 Señalización de banda angosta ISDN Cada canal B y D son transportados en un canal independiente AAL2 del mismo VCC ATM. El protocolo que opera sobre el canal D es el Digital Signaling System number 1 DSS1. El IWF transportan los mensajes DSS1 de capa 2 (Q.921) en forma transparente usando la subcapa Service Specific Transmission Error Detection-SSTED encima de la subcapa Segmentation and Reassembly Service Specific Common Sublayer SSSAR como se especifica en la recomendación ITU-T I Esto se conoce como el relay de mensajes DSS1. 8.VII-A.6 Control de la emulación de loop Los CP-IWF s y CO-IWF s pueden activar los canales y los puertos mediante el protocolo ELCP- Emulated Loop Control Protocol. Los mensajes del ELCP son transportados por un canal AAL2 de señalización común que se le asigna el CID=8. Los mensajes están basados en los tipos definidos en la ETSI EN y En la Fig se muestra el modelo de señalización ELCP. Los canales pueden ser asignados y liberados tanto por el CO-IWF como por el CP-IWF. Los puertos, tanto de POTS como de ISDN, pueden ser activados y desactivados a travéz del canal de señalización por el CO-IWF. Los IWF s que no soporten ELCP implementan otro tipo de procedimiento para activar y desactivar los canales y puertos. Cuando un CO-IWF determina que un canal debe ser activado comienza a transmitir por ese canal e inicializa un timer. Si el timer se vence el CO-IWF deja de transmitir por ese canal, si el CO-IWF detecta paquetes provenientes del CP-IWF en ese canal detiene el timer y considera el canal activo. El CP-IWF monitorea todos los canales en busca de paquetes provenientes del CO-IWF, si detecta algún paquete en determinado canal inicializa un timer. Cada vez

110 109 multiplexar 48 muestras de voz. Para reducir el tiempo de paquetización cada celda puede transportar menos que 48 muestras. Esto puede especificarse tanto en AAL1 como en AAL2. Llenado de celdas adaptativo: Se implementa un análisis del estatus de la red para determinar el delay de cada canal. Basado en esto se determina si el canal de voz llena completamente o parcialmente una celda. Celdas compuestas: Para minimizar el delay de paquetización y hacer uso eficiente de la capacidad disponible, pueden agruparse varios canales de voz en una celda. Dicha celda se compone de varios canales individuales que llevan su propio mini-encabezado antes de su carga útil; este encabezado contiene toda la información necesaria para procesar este canal. Esto mejora la eficiencia pero requiere funciones más complicadas para el switching y para el armado y desmontado de cada celda. Fig Modelo de señalización ELCP. que recibe un paquete se fija si el timer no está vencido y lo re-inicializa. Si el timer expira se considera desactivado el canal. Los tiemers son del orden de 300 ms y los paquetes de información pueden contener voz, datos en banda vocal, descriptores de inserción de silencios o fax. Para activar y desactivar los puertos se utiliza un canal llamado LES Embedded Operations Channel que se describe en la sección 6 de [38]. Este canal (CID=9) permite el transporte de elementos de protocolo de capa superiores en el payload. 8.VII-A.7 Comparación de los métodos de transporte Se comparan en la tabla 8.V en terminos de ventajas y desventajas los tres métodos. 8.VII-B QoS de la voz en ATM Los datos que contienen voz son generados en intervalos regulares y deben ser transmitidos en tiempo real y en forma contínua en las dos direcciones sin un delay o distorsión apreciable. La QoS para la voz define cuanto ancho de banda se debe asignar a cada aplicación o usuario y un set de parámetros de performance requeridos. Los parámetros de calidad de servicio usados para la voz sobre ATM son: Cell Transfer Delay (CTD) Cell Delay Variation (CTD) 8.VII-B.1 Cell Transfer Delay (CTD) El CTD mide el tiempo, en promedio, de transmisión de una celda desde su origen hacia su destino sobre un circuito virtual ATM. Con un delay mayor a 30 ms. se hace necesario la incorporación de canceladores de eco en la nueva red, esto amplía la tolerancia hasta los 150 ms. Existen varios métodos para minimizar el delay y controlar así el eco: Celdas parcialmente llenas: Una celda ATM transporta 48 bytes de datos de usuario y por lo tanto puede 8.VII-B.2 Cell Delay Variation (CDV) El CDV es la diferencia entre el CTD de una celda en particular y el delay esperado. Como las celdas pasan a través de la red, ocurren variaciones en el momento de arribo de la misma por la variación de los retardos de encolamiento, de switching y de propagación. De forma de reducir el efecto para los usuarios finales el delay no debe variar demasiado. Para esto se manejan buffers cuyo tamaño debe ser diseñado para no tener una variación muy grande del delay ni tampoco en delay end-to-end muy grande. 8.VII-C Video sobre ATM El método más difundido para el transporte de video sobre ATM usa MPEG2 como estándard para la compersión (aunque se están comenzando a analizar otros métodos como MPEG 4). El uso incluye desde la videoconferencia hasta el video on demand. Estos servicios tienen distintos requerimientos en términos de transmisión (como el bit rate, delay end to end, jitter), topología (punto a punto, multicast, broadcast) y calidad (frame rate, resolución, profundidad de color). 8.VII-C.1 Compresión de video digital Los requerimientos de ancho de banda del video digital pueden llegar a sobrepasar los 100 Mbps por lo que se hace necesaria la compresión del mismo. En la tabla 8.VI se muestran distintos formatos usados para servicios audiovisuales, el ancho de banda usado antes y después de la compresión y la técnica de compresión usada. La forma más sencilla de reducir el volumen de tráfico necesario es seleccionando un resolución espacial (cantidad de líneas por cantidad de columnas ), temporal (cantidad de frames por segundo) y resolución de color lo que implica el sub-muestreo de la señal de video e impacta directamente sobre la tasa de bits necesaria. Un resumen de los formatos más usados se muestran en la tabla 8.VII.

111 110 CAPÍTULO 8. PROTOCOLOS PARA SERVICIOS CONVERGENTES Método de transporte Técnica Ventajas Desventajas CES [AAL1] Emulación de full E1/T1 1) Simple de implementar y desarrollar. 2) Adecuada para le transporte de una full E1/T1 con mínimo delay. 1) Mayor ancho de banda por overhead (12 % más que el circuito original). 2) Los PVC s quedan activos aún durante los períodos de silencio. 3) No tiene ganancia estadística. DBCES [AAL1] Variable Channel Emulation (nx64kbps) 1) Establecimiento de E1/T1 fraccionales. 2) Identificación de canales individuales permitiendo que varios circuitos compartan el mismo link. 1) Requerimientos de mayor ancho de banda. 2) Delay adicional en el establecimiento de los circuitos nx64kbps. 3) No es posible usar señalización fuera de banda VBR [AAL2] Trunking VBR switcheado o noswitcheado 1) Uso eficiente del ancho de banda con VBR. 2) Compresión de la voz. 3) Supresión de silencios. 4) Liberación y eliminación de los canales no activos. 5) Múltiples canales con ancho de banda variable en una conexión única ATM. 6) Multiplexación estadística. 1) No tiene interoperabilidad con algunas aplicaciones. 2) No es útil cuando se transportan datos de módems en banda base. TABLA 8.V COMPARACIÓN DE LOS DISTINTOS MÉTODOS DE TRANSPORTE Parámetro SQCIF QCIF CIF 4CIF 16CIF CIF-NTSC CIF PAL/SECAM Pixel/Línea Lineas/Imagen Formato de color YCbCr Color subsambpling 4:1:1 4:2:0 Resolución de color 8 bits/pixel Resolución temporal Bit rate RAW (Mbps) TABLA 8.VII FORMATOS DE VIDEO DIGITAL USADOS POR MPEG1, MPEG2 MPEG4, H.261 Y H VII-C.2 Calidad de servicio y MPEG2 Los parámetros vistos en secciones anteriores de QoS en ATM incluyen el CTD (end to end Cell Transfer Delay), la variación de este delay CDV (Cell Delay Variation), la tasa de errores de bit BER (Bit Error Rate) y el nivel de pérdida de celdas CLR (Cell Lose Ratio). La transmisión de video MPEG2 sobre ATM usa una alta tasa de transmisión, necesita un mínimo delay, no tolera variaciones del mismo y requiere baja tasa de errores. 8.VII-C.2.a VBR vs CBR: Como la información contenida en un video difiere de un cuadro a otro la tasa de bits de salida del codificador MPEG2 varia en el tiempo, como consecuencia el bit-rate obtenido es naturalmente de tipo VBR. Para permitir la transmisión de video sobre redes basadas en circuitos, los codecs deben dar salidas de tasas constantes de datos, esto se logra agregando un buffer de salida en el codificador. Para controlar este buffer se realimenta información hacia el codificador, que varia su compresión según el uso del buffer. El video CBR agrega un delay en el sistema que se combina con otras fuentes de delay para aumentar el parámetro CTD por el agregado del buffer. Además produce una calidad variable del video por el control de realimentación y hace que el codificador sea más costoso. En contraposición el uso de video VBR asegura una calidad constante de los cuadros durante toda la sesión con un delay más bajo. Por lo que el modo VBR es el más apropiado para comunicaciones en tiempo real y tiene menores costos. El uso de VBR deja, también, la posibilidad del re-uso por parte de otras fuentes del ancho de banda disponible en los períodos de baja actividad. El uso de una realimentación de los distintos parámetros de estado de la red hacia el codificador MPEG2 hace posible que los mismos modulen la tasa de bits ajustando sus parámetros internos incluyendo la calidad, frame rate y resolución. Esto hace posible definir diferentes modos de transmisión dependiendo de la respuesta del codificador a la realimentación de dichos parámetros: [40] Unconstrained VBR (U-VBR): El codificador de video opera con independencia de la interfaz con la red ATM (UNI) operando con una cuantización constante. Shaped VBR (S-VBR): El buffer es conectado a la UNI pero no al codificador. En este caso el codificador produce un flujo como el de U-VBR pero se le da forma a la salida

112 111 Servicio Formato Tasa sin compresión Tasa con compresión Estándar Videotel. móvil SQCIF 4.4 Mbps 5 a 64 kbps MPEG4, H.263 Videotel. QCIF Mbps 32 a 64 kbps H.261, H.263 Videoconf. CIF Mbps 112 kbps H.261 Calidad VCR (DVI, SIF Mbps 1.5 Mbps MPEG1 CDI) Calidad digital de TV (DVD) HDTV Super HD Video Quality ITU-R BT Mbps 3 a 6 Mbps MPEG2 SMPTE 506 Mbps 25 a 35 MPEG 2 240M Mbps SHD > 6 Gbps > 100 Mbps MPEG2 TABLA 8.VI REQUERIMIENTOS DE TASA DE BITS PARA VARIOS SERVICIOS AUDIOVISUALES antes de la transmisión. No se afecta la calidad pero se agrega un delay. Constrained VBR (C-VBR): El codificador conoce el estado del buffer y también las restricciones de la UNI. Por lo tanto el codificador puede modular su salida maximizando la calidad del video de acuerdo a esto. Aquí es afectado el contenido del stream de video pero los ajustes los realiza el codificador directamente, quien se encargará de cambiar la tasa de bits con el menor impacto en la calidad. Feedback VBR (F-VBR): El codificador recibe información adicional del estado de la red, como por ejemplo períodos de congestión o baja carga, esto posibilita que el codificador ajuste la tasa de bits para cambiarla según el estado de la red. 8.VII-C.2.b Efectios del BER: El efecto del los errores de bit en un stream de video MPEG2 dependen del lugar -en la jerarquía de la estructura de datos- que ocurran. Estos errores pueden conducir a propagar errores temporales o espaciales en el stream. Antes de que estos errores se pasen a la aplicación pasarán por la AAL respectiva. Por esto el efecto depende de que protocolo AAL se esté usando. Si la AAL soporta Forward Error Correction - FEC (AAL1 y AAL2) la tolerancia a errores es mayor. Si solo se detectan los errores (AAL5) y se descarta la PDU entera el error puede aumentar, dependiendo del tamaño usado de PDU. En la tabla 8.VIII se muestra la tolerancia a errores con y sin corrección en la capa AAL para algunos servicios de distribución de video. 8.VII-C.2.c Efectos del delay y jitter: Los factores que contribuyen al delay en la transmisión de video son los siguientes: Delay decodificación y decodificación. Reordenación de cuadros en los extremos. Buffers de codificación y decodificación. Servicio Videotel. móvil Tasa de datos 64 kbps - 2 Mbps H.261 Videotel. 2 Mbps VBR MPEG2 Videoconf. 5 Mbps VBR MPEG2 Calidad 1.5 VCR Mbps Calidad 10 Mbps digital de VBR TV MPEG2 Studio TV quality 15 Mbps CBR MPEG2 HDTV Mbps VBR MPEG2 BER con detección BER con FEC CLR con detección CLR con FEC x10 6 3x x x x10 8 4x10 9 5x10 6 4x x x10 6 6X X10 8 2X10 9 4X10 9 2x x x x x10 7 TABLA 8.VIII BER Y CLR PARA VARIOS SERVICIOS AUDIOVISUALES Delays de paquetización y bufferizado de interfases entre la red y el codificador. Delays de la red incluyendo serialización, propagación y procesamiento. En la tabla 8.IX se muestra la tolerancia al delay de distintos servicios audiovisuales. Servicio Tasa de datos Delay Jitter Videotel. 64 kbps - 2 Mbps ms 130 ms móvil H.261 Videotel. 2 Mbps VBR 300 ms - MPEG2 Videoconf. 5 Mbps VBR 300 ms - MPEG2 Calidad 1.5Mbps 5 seg 6.5 ms VCR Calidad 10 Mbps VBR 1 seg. 1ms digital de MPEG2 TV Studio TV 15 Mbps CBR 1 seg. 1ms quality MPEG2 HDTV Mbps 1 seg. 0.8 ms VBR MPEG2 TABLA 8.IX TOLERANCIA AL DELAY Y JITTER PARA VARIOS SERVICIOS AUDIOVISUALES Si el servicio es en un sentido existe flexibilidad en el delay end to end (CTD). Es aceptado un delay de varios segundos entre la solicitud del usuario y el comienzo de la visualización del video. Este delay de presentación existe puesto que hay que almacenar información para comenzar la decodificación.

113 112 CAPÍTULO 8. PROTOCOLOS PARA SERVICIOS CONVERGENTES Si el servicio es bi direccional el CTD es un factor importante en la presentación del video en tiempo real, aquí se aplica la recomendación G.114 que indica que un delay menor a 150 ms es aceptable y uno mayor a 400 ms inaceptable. El delay de codificación en MPEG2 es mayor, por lo general, que el introducido en la paquetización y otros delays de la red. Este delay puede ser del orden de 160 ms en la fuente de transmisión. En el destino se tiene la misma latencia pero existen técnicas en el standard MPEG2 para minimizarla que recomiendan el reordenamiento de los cuadros antes de ser transmitidos logrando delays del orden de 30 ms. Esta latencia claramente es demasiado alta para servicios en tiempo real. Sin embargo existen técnicas que, a costa de un mayor ancho de banda, que logran bajar este delay y mantener la calidad del video [41] El jitter puede tener un impacto importante en la calidad del video. En MPEG2 un alto jitter puede causar la pérdida de sincronización de los relojes del codificador y decodificador manifestándose en distorsiones de color, pérdida de sincronización de audio y video y en casos extremos congelamiento o ausencia de video debido a overflows o vaciamiento de buffers. De acuerdo a algunos estudios el efecto predominante es la distorsión de color. Existen dos caminos para controlar el jitter, o limitando las variaciones del delay con bufferizado y shaping de tráfico, o absorbiendo esas variaciones en el sistema (capa AAL o sistema MPEG2). La capa de adaptación AAL1 es dedicada a video CBR e introduce demasiado overhead además, el timestamp (SRTS) provisto por AAL1 es redundante con el clock provisto en MPEG2 por lo que no es apropiada para la transmisión de video VBR en tiempo real. La capa AAL2 tiene el problema de que el tamaño máximo de la PDU es de 64 bytes lo que la hace inapropiada para transmitir los paquetes TS MPEG2 de 188 bytes. Por esto el protocolo AAL5 es la mejor opción puesto que tiene un bajo overhead y permite transmitir paquetes de largo variable y ha sido adoptada por el ATM Forum [42] para el diseño de sistemas audiovisuales. Sin embargo AAL5 tiene capacidades limitadas y debe ser mejorada con la introducción de un mecanismo de FEC en la capa SSCS, remoción de jitter y multiplexado de flujos de datos. 8.VIII STREAMING DE VIDEO SOBRE IP USANDO ADSL 8.VIII-A Introducción La transmisión de video sobre accesos ADSL es posible usando distintas técnicas de compresión como se explicó en la sección 8.VII-C. En la tabla 8.X se muestran alguno de los esquemas de codificación usados junto con la calidad del video y el número de canales posibles en simultáneo por abonado. La codificación más conveniente es MPEG 4 por tener una mejor relación calidad-ancho debanda y permitir por lo tanto la distribución de un mayor número de canales en simultáneo. El mapeo de los streams de video MPEG 4 sobre RTP/UDP/IP se especifica en la RFC 3016 [43]. CODEC Tipo de Servicio MPEG 1 MPEG 2 MPEG 4 Calidad VCR Calidad DVD Calidad VCR o DVD Formato A.B. por canal SIF 352x Mbps 4 720x486 4 Mbps 1 352x x486 TABLA 8.X hasta 1 Mbps 6 POSIBLES ESQUEMAS DE CODIFICACIÓN PARA VOADSL 8.VIII-A.1 Arquitectura Fig Arquitectura de video sobre IP Cantidad de canales En la Fig se muestra un diagrama con la arquitectura del sistema de Streaming de video. Los componentes del sistema son: Acondicionador de la señal: Se encarga de codificar las señales de las distintas fuentes, separar los canales y crear un stream multicast para cada canal. Existen dos posibilidades para la distribución del stream de video desde el punto central de distribución hacia los distintos nodos de acceso. Por un lado es posible usar la red de transporte desde el sitio central hacia los equipos de acceso en cada nodo de distribución. Esto trae como desventaja el uso de un gran ancho de banda de transporte para los streams de video (dependiente de la cantidad de canales y de la codificación) y la necesidad de controlar internamente la QoS en la red de tranporte para que no varie la calidad en las distintas zonas. Como ventajas de este método están los menores puntos de fallos y la facilidad de implementación. Por otro lado es posible distribuir este stream de video por una red independiente de la de transporte (por ejemplo via satélite) hacia los distintos nodos. Dependiendo de la topología de la red puede ser beneficioso el uso de IP multicast en el transporte y en el acceso. Para el manejo de IP multicast sobre redes IP se utiliza del protocolo IGMP (Internet Group Management Protocol) definido en la RFC 2236 (v2) [44] y RFC 3376 (v3) [45] para informar los grupos activos y permitir a

114 113 los usuarios unirse y abandonar dichos grupos. Servidor de video: Se utiliza para proveer Near VoD o VoD, es necesario para esto un servidor con una gran base de datos de películas. Servidor de aplicaciones: Utilizado para proveer servicios web, almacenar publicidar y nuevos servicios. Software de management y de administración de servicios: El software de management permite configurar la guía de canales y manejar la información de clientes. Este servidor interactua con el equipo de abonado (STB) para proveer los siguientes tipos de funcionalidades: Información de canales. Guía de programación interactiva. Paquetes de canales. Información de facturación. Almacenamiento de preferencias de canales y de favoritos. Manejos de usuarios y contraseñas. Control infantil. Pay per View Guia de películas. Set-Top-Box: Del lado del usuario, el STB se encarga de decodificar el stream de datos y alimentar al TV mediante una interfaz analógica. Tambien maneja la información de los canales, despliega la guía interactiva y es usado para cambiar de canales como un receptor convencional. Del lado de la red el STB maneja los mensajes de union y liberación del IGMP y envía reportes del subscriptor hacia la red. Cuando el STB se enciende ejecuta un proceso de inicialización. Durante este proceso baja información del sistema de gestión. Esta información incluye la guía de canales y las correspondencias entre los canales y los grupos multicast. Cuando el usuario cambia de canal el STB notifica a la red que no necesita más ese stream y que que necesita unirse a otro grupo. Cuando recibe el nuevo stream lo decodifica y lo envía en forma de video analógico hacia la TV. Switches de borde y DSLAM s: El manejo de IP multicast puede ser manejado por el DSLAM (si soporta servicios IP e IGMP) o el switch de distribución, estos switches debe manejar también QoS. 8.VIII-A.2 Manejo de usuarios Algunas implementaciónes del sistema [46] realiza la autenticación del servicio mediante el ingreso en una página web de un usuario y contraseña. El servidor web autentifica a el usuario (contra un servidor de AAA) y descarga su perfil re-dirigiéndolo a otra página web que contiene los servicios disponibles, por ejemplo una lista de canales a los cuales puede acceder. Cuando el usuario selecciona un canal el sistema interactúa con el servidor que presta el servicio o se une al stream multicast adecuado para desplegar el canal solicitado. 8.VIII-A.3 Equipamiento Existe una gran variedad de equipamiento, desde equipos profesionales a PC s con placas especializadas de I/O que efectúan las tareas de coompresión/descompresión por hardware o software. Del lado del cliente, la mayoría de los equipos son cajas negras que corren un Sistema Operativo y tienen placas con salida analógica para la TV. La descompresión del stream de video la realizan algunas en hardware y otras en software. También existen equipos que permiten almacenar programas y para esto tienen también medios de almacenamiento integrados. La tendencia es a brindar un equipo que funcione como consola de entretenimientos y que incluya las funcionalidades de STB además de permitir la navegación por Internet, la lectura de correo electrónico y el uso de juegos on line. En las tablas 8.XI y 8.XII se resumen algunos de los Set Top Boxes y Servidores de streaming junto con sus características principales. 8.IX FAX SOBRE IP USANDO T.38 La transmisión de fax sobre una red telefónica tradicional está especificado por el ITU en su recomendación T.30 [47]. Una de las razones de su popularidad es la notificación del envío y la información recibida junto con el fax (número telefónico del remitente, fecha y hora de envío), otra razón es que la transmisión no puede ser facilmente interceptada. La ITU-T en su estándard T.38 [48] especifica cómo se transporta las señales de fax sobre IP. 8.IX-.4 Introducción al T.38 Esta recomendación define como se transfiere un fax en tiempo real entre gateways de fax y/o entre maquinas de fax en una red IP. El transporte de señales puede realizarse sobre TCP o UDP. La confiabilidad en UDP es alcanzada mediante el uso de mecanismos de control del protocolo (FEC o redundancia de paquetes). La recomendación no especifica métodos de conexión entre terminales por lo que asume que la conexión entre los dos equipos ya está establecida (como lo está entre equipos de fax convencionales). No se incluyen en esta recomendación por lo tanto el direccionamiento, identificación, autenticación y creación de conexiones. Los equipos de fax también deben haber acordado el protocolo de transporte a usar (TCP o UDP) y el tipo de control de error que van a realizar en el caso de seleccionar UDP. Los mecanismos de direccionamiento, autenticación, establecimiento de sesiones, etc son provistos por otros protocolos como H.323 en su Anexo D, SIP o MEGACO/H.248. El manejo de FoIP en MGs, que son controlados por Megaco/H.248 es descrito en el T.38 Apéndice III y es soportado por el H.248 según se define en el Anexo F [49] del H.248.

115 114 CAPÍTULO 8. PROTOCOLOS PARA SERVICIOS CONVERGENTES Modelo Decoder Codecs Video Broadband Comunications Broadband Magic Host Pro Coventive libra II ALLwell.tv STB3036N Sigma EM847x Sigma EM840x TVIA CyberPRO 5005 MPEG1,2,4 y Divx MPEG1,2,4 MPEG1,2,4 PS/TS RTSP MPEG1,2,4 CPU/RAM x86 333MHz /64 MB SDRAM X86 400MHz /64 MB SDRAM VIA C3/400 Mhz /64 MB SDRAM GeodeTM GX Mhz fanless /256 MB SDRAM Interfase de red Ethernet 10/100 Ethernet 10/100 Ethernet 10/100 Ethernet 10/100 TABLA 8.XI Audio output 2ch RCA Jack stereo 2ch RCA 2ch RCA Video output SO Otros Compuesto y S-Video PAL NTSC Compuesto y S-video, SVGA NTSC Compuesto y S- video PAL NTSC Compuesto y S-video, SVGA MODELOS DE STB SET-TOP-BOXES Y SUS CARACTERÍSTICAS Linux USB 1.1, llave USB, Browser y player incluido, HD op. Windows o Linux Linux Windows o Linux Teclado inalámbrico, modem, puerto serial, game y paralelo, USB, HD 4.3 GB. Lector de smart card, mic, audio, USB, HD op. Lector de Smart Card, flash disk, floppy, serial, paralelo, USB, mouse y teclado PS/2, mic, audio jack. Modelo Codecs Interfaces de red Optibase MGW 5100 MPEG1,2,4, Transcode MPEG2, MPEG4 Ethernet 100/1000 OC-3/STM- 1 Entone 5220 MPEG 2 Gig ethernet OC3-OC12 Tipo de Streaming ftp, Unicast, Multicast MPEG2 ov IP TS Management Características Storage Video input SNMP XML, HP OpenView SNMP HP OpenView Web TABLA 8.XII Rackeable, chasis con 17 slots con tarjetas de servicio e I/0 Rackeable 5U DOS MODELOS DE SERVIDORES DE STREAMING Y SUS CARACTERÍSTICAS 720 GB max ultra SCSI Tarjetas de video analógico y digital No captura video, el fabricante tiene otros productos para este fin

116 Capítulo 9 Transporte y Conmutación Resumen En este capítulo se realiza el diseño de la red de transporte y conmutación. Se comienza estudiando el volumen de tráfico necesario para soportar los servicios de voz y datos proyectados para los tres primeros años; luego se estudian las distintas tecnologías y formas de implementación (contratación,tendido propio, etc) para la capa física de esta red discutiendo la conveniencia de cada una. Posteriormente se estudian las formas de distribución del reloj hacia los distintos nodos de la red, dando pautas básicas para el diseño de la red de sincronismo. Se describe brevemente la necesidad de un sistema de provisionamiento de servicios para luego concentrarse en la arquitectura y diseño de la red de transporte. Finalmente se describen las características de distintos equipos relevados. SI se considera al sistema telefónico tradicional, se puede encontrar una distinción clara entre las etapas de conmutación y transporte. Por un lado los equipos de conmutación de circuitos, resultantes en la mayoría de los casos de combinar conmutadores S y T, y por otro los equipos encargados de enlazar las centrales (esto es habilitar circuitos entre estas), que realizan todo lo concerniente al transporte entre distintos puntos de la red. Sin embargo, esto está muy distante de lo que actualmente se plantea para las llamadas redes convergentes. Estas se basan principalmente en paquetes o celdas (con la capacidad de simular circuitos), y por consiguiente tienen mecanismos de conmutación de circuitos virtuales resultantes de conmutar paquetes de acuerdo un conjunto de reglas previamente establecidas. Para entender y asimilar estos conceptos, habrá que estudiar los mecanismos que se utilizan para generar circuitos virtuales entre origen y destino, así como las restricciones y necesidades de los mismos para funcionar correctamente. Lo que si se puede apreciar de antemano, es que ahora no es tan fácil realizar la distinción entre las etapas de conmutación y transporte como para el caso de telefonía clásica, es más, la mayoría de los trabajos realizados al respecto tratan estas etapas como una sola. Es por esto que se realizaran en este entregable todas las tareas relacionadas con ambas en lugar de tratarlas por separado como se esperaba a priori, y se hará referencia a cualquiera de ellas en forma indistinta como red de transporte (distinguiéndolas solo cuando sea necesario). 9.I ESTIMACIÓN DE TRÁFICO PARA DATOS Y TELEFONÍA En esta sección se estima el tráfico que generarán los abonados de cada central o zona. 9.I-A Tráfico de datos Para la estimación del tráfico de datos generado en cada zona se comienza tomando para cada una la fracción de clientes residenciales y empresariales de datos basándose en los valores calculados en 3.III. Tomando como hipótesis requerimientos de ancho de banda promedio, de 256kbps y 512kbps, para los tipos residencial y empresarial respectivamente se estima el ancho de banda que requerirá cada zona. Estos valores de ancho de banda incluyen acceso a Internet para los clientes residenciales y accesos a Internet más redes privadas para los empresariales. Es favorable, desde el punto de vista económico, manejar algún grado de sobreasignación en los nodos donde se contrate transporte sobre redes existentes. Se podría comenzar el primer año sin sobreasignación o con una sobreasignación pequeña y evaluar el comportamiento de los usuarios para planificar ampliaciones futuras. La política seguida por los proveedores habitualmente es aumentar el ancho de banda de sus enlaces a medida que el tráfico o los clientes lo requieren. En las tablas 9.I, 9.II y 9.III se muestran las estimaciones de ancho de banda para los primeros tres años sin realizar sobreasignaciones. Central Clientes datos Fracción Residencial A.B. Mbps Aguada Athahualpa Buceo Carrasco Centenario Centro Ciudad Vieja Cordón Malvín Palacio Parque Rodó Pocitos Punta Carretas TABLA 9.I ANCHO DE BANDA DATOS PARA EL PRIMER AÑO 115

117 116 CAPÍTULO 9. TRANSPORTE Y CONMUTACIÓN Central Clientes datos Fracción Residencial A.B. Mbps Aguada Athahualpa Buceo Carrasco Centenario Centro Cerrito Ciudad Vieja Colón Cordón Euskalerría Ituzaingó Malvín P. Carretas Palacio Parque Rodó Paso Molino Pocitos Sayago Unión TABLA 9.II ANCHO DE BANDA DATOS PARA EL SEGUNDO AÑO 9.I-B Cálculo del teletráfico 9.I-B.1 Hipótesis para el cálculo de teletráfico Para realizar el cálculo de teletráfico [50] se formulan, para la red bajo estudio, las siguientes hipótesis: Modelado de la red como un sistema de pérdida puro. El orígen y terminación de las llamadas es aleatorio siguiendo una distribución de Poisson, con duración de llamada exponencial negativa. Hipótesis de equilibrioestadístico. La probabilidad de pérdida de llamada (por congestión) bajo las condiciones anteriores está dada por la primera fórmula de Erlang, dada por la ecuación 1 P = A N N!. N i=0 Ai i! Donde: P=probabilidad de pérdida. A=número de arribos por unidad de tiempo. N=número total de canales. Considerando el Anuario Estadístico 2001 de la UIT [51], los últimos datos correspondientes a Uruguay (1999) indican: Líneas Activas Tráfico cursado 3719 millones de cómputos. Considerando un promedio de 1 cómputo cada 3 minutos se obtiene una estimación de los minutos de tráfico promedio por línea. Minutos anuales de tráfico por línea (1) Central Clientes datos Fracción Residencial A.B. Mbps Aguada Atahualpa Buceo Carrasco Centenario Centro Cerrito Cerro Ciudad Vieja Colón Cordón Euskalerría Ituzaingó Lezica Malvín Manga S P. Carretas P. de la Arena Palacio Parque Rodó Paso Molino Pocitos S.Vázquez Sayago Unión TABLA 9.III ANCHO DE BANDA DATOS PARA EL TERCER AÑO Este valor equivale a Erlangs de tráfico promedio por línea (valor medio anual de tráfico para todo el país). Según [24], valores típicos de volúmen de tráfico para distintos perfiles de abonados son: Abonado residencial erlang Abonado empresarial erlang Central privada erlang Según [52] en el mercado estadounidense los valores típicos en la busy hour son de erlangs y 0.11 erlangs por línea residencial y empresarial respectivamente. Mientras que en África del Sur los valores típicos son de 0.04 y 0.08 erlangs respectivamente. Como no se cuenta con datos actualizados de Uruguay y tampoco datos de tráfico de Montevideo se asignan valores de 0,03 0,05 y 0,07 erlangs por abonado en los distintos nodos (para la Busy Hour), teniendo en cuenta el nivel socio-económico de la población y la característica Empresarial de la zona. Esta asignación se muestra en la tabla 9.IV. Con estos valores de tráfico se elabora la proyección para los primeros tres años del volumen de tráfico y la cantidad de líneas troncales necesarias para una probabilidad de pérdida de 1%. Luego teniendo en cuenta el tipo de codificación a usar se estimará el Ancho de Banda de transporte necesario para manejar la demanda de voz.

118 117 Central Erlangs/ abonado Aguada 0.05 Athahualpa 0.05 Buceo 0.05 Carrasco 0.07 Centenario 0.05 Centro 0.07 Cerrito 0.03 Cerro 0.03 Ciudad Vieja 0.07 Colón 0.03 Cordón 0.05 Euskalerría 0.03 Ituzaingó 0.03 Lezica 0.03 Malvín 0.05 Manga S P. Carretas 0.05 P. de la Arena 0.03 Palacio 0.05 Parque Rodó 0.05 Paso Molino 0.05 Pocitos 0.05 S.Vázquez 0.03 Sayago 0.03 Unión 0.03 TABLA 9.IV ERLANGS POR ABONADO PARA LAS DISTINTAS CENTRALES 9.I-B.2 Estimación de los circuitos de voz necesarios por central para los tres primeros años La cantidad de circuitos de voz necesarios para atender la demanda de cada año se calcula a partir de la cantidad de abonados proyectada en 3.III, y la estimación de tráfico de la sección 9.I-B.1. A partir de estos datos, y aplicando la fórmula de Erlang 30, se obtienen las tablas 9.V, 9.VI y 9.VII que indican la cantidad de circuitos de voz necesarios en cada uno de los tres primeros años. Se en cuenta para el cálculo de los circuitos el peor caso que ocurre cuando todo el tráfico del nodo es saliente (no se genera tráfico local). Este resultado es independiente del modelo de red que se elija posteriormente ya sea una red enteramente convergente o híbrida. 9.I-B.3 Calidad de la voz La calidad de la voz está subjetivamente descrita por su MOS (Mean Opinion Score), como puede observarse en la tabla 9.VIII, el cual es principalmente depende del tipo de codificación y del transporte usado. El valor de 4.2 corresponde a una calidad de línea telefónica. Para poder enviar voz sobre una línea digital debe ser previamente codificada. El método tradicional usado por las compañías telefónicas es el PCM (Pulse Code Modulation) estandarizado por la ITU-T como G.711 que utiliza un canal digital de 64kbps por cada canal de voz. Existen otros métodos 30 Debido a que no se contaban con tablas para valores altos de tráfico, se implementáron dos algoritmos para aplicar, en su forma recurrente, la fórmula de Erlang, ver apéndice F Valor Calidad de voz Nivel de distorsión 5 Excelente Imperceptible 4 Bueno Perceptible 3 Aceptable Perceptible, un poco molesto 2 Pobre Molesto, entendible 1 Insatisfactorio Molesto, inaceptable TABLA 9.VIII MEAN OPINION SCORE que logran mayores compresiones y que, junto con la VAD 31, compresión de encabezados, etc, logran un ahorro sustancial del ancho de banda por canal permitiendo el uso de redes existentes, diseñadas en un principio para la transmisión de datos, para el transporte de voz. Este ahorro de ancho de banda ayuda a la integración de servicios de voz y datos sobre una misma red. En la tabla 9.IX se muestran algunos esquemas de codificación usados en la actualidad. En esta tabla se indica, para cada CODEC, la tasa de datos 32, el Mean Opinion Score (MOS) para la voz, el delay introducido (latencia) necesario para implementar la compresión y la complejidad de dicho algoritmo. Los dispositivos de usuario digitalizan previamente la señal vocal en PCM y luego pasan esas muestras por el algoritmo de compresión para luego paquetizar las muestras y enviarlas por el enlace de datos. Codec Tasa de Datos (kbps) Calidad de voz (MOS) Delay (ms) Complejidad (MIPS) G.711 PCM G.726 ADPCM G.726 ADPCM G.723 MPMLQ ACELP 5.3, G.728 LD-CELP G.729 CS-ACELP G.729a CS-ACELP GSM RPE-LPC I-B.4 Delay TABLA 9.IX DISTINTOS CODECS USADOS PARA LA VOZ Un parámetro que puede afectar significativamente la calidad de una conversación es el delay extremo a extremo. La ITU en su norma G.114 define los distintos rangos de este parámetro junto con su efecto en la transmisión. Esto se refleja en la tabla 9.XI. La ITU recomienda que para una conversación de voz el 31 VAD Voice Activity Detection: este mecanismo permite detectar la presencia de la voz y suprimir el envío de datos durante los silencios que se presentan durante la conversación. Estadísticamente, la duración de los silencios puede equivaler a más del 50% de la llamada. Cuando se utiliza VAD, por lo general también se utiliza el CGN Confortable Noise Generation, esta técnica establece que, durante los silencios, se debe genera un ruido ambiente en el destino para simular lo que sucede durante una conversación normal, y evitar que la supresión de silencios sea molesta para el usuario. 32 Es la tasa pura de la codificación, no incluye headers de protocolos para la transmisión.

119 118 CAPÍTULO 9. TRANSPORTE Y CONMUTACIÓN Central Clientes solo voz Clientes de voz y datos Total clientes de voz Erlang / abonado Volumen de tráfico (Er) Aguada Athahualpa Buceo Carrasco Centenario Centro Ciudad Vieja Cordón Malvín Palacio Parque Rodó Pocitos Punta Carretas TABLA 9.V CANTIDAD DE CIRCUITOS NECESARIOS PARA LAS DISTINTAS CENTRALES DEL AÑO 1 Circuitos de voz Central Clientes solo voz Clientes de voz y datos Total clientes de voz Erlang / abonado Volumen de tráfico (Er) Aguada Athahualpa Buceo Carrasco Centenario Centro Cerrito Ciudad Vieja Colón Cordón Euskalerría Ituzaingó Malvín P. Carretas Palacio Parque Rodó Paso Molino Pocitos Sayago Unión TABLA 9.VI CANTIDAD DE CIRCUITOS NECESARIOS PARA LAS DISTINTAS CENTRALES DEL AÑO 2 Circuitos de voz Codec Tasa de Datos (kbps) Calidad de voz (MOS) G.711 PCM G.726 ADPCM G.728 LD-CELP a 5 G.729 CS-ACELP G.729 x 2 encodings G.729 x 3 encodings G.729a CS-ACELP G MP-MLQ G ACELP TABLA 9.X Delay de la compresión (ms) DISTINTOS CODECS USADOS PARA LA VOZ SEGÚN [53] Retardo en un sentido Efecto Aceptable para la mayoría de las aplicaciones de usuario Aceptable, pero debe tenerse cuidado en el impacto que pueda provocar el delay a las aplicaciones. sobre 400 Inaceptable para procesos generales de planificación de una red, sin embargo es reconocido que en algunos casos excepcionales este límite será excedido. TABLA 9.XI DISTINTOS RETARDOS Y SU EFECTO (ITU-T G.114) retardo en un sentido no supere los 150 ms. Esta recomendaciones consideran que el eco está controlado lo que supone el uso de canceladores/supresores de eco cuando el delay en un sentido excede los 25 ms. Esto último se especifica en la recomendación G.131. Estas recomendaciones están orientadas a administradores nacionales de telecomunicaciones y por lo tanto son más exigentes que lo aplicable a redes de voz privadas. Según [53] en redes privadas de voz es razonable tener 200 ms de

120 119 Central Clientes solo voz Clientes de voz y datos Total clientes de voz Erlang / abonado Volumen de tráfico (Er) Aguada Atahualpa Buceo Carrasco Centenario Centro Cerrito Cerro Ciudad Vieja Colón Cordón Euskalerría Ituzaingó Lezica Malvín Manga S P. Carretas P. de la Arena Palacio Parque Rodó Paso Molino Pocitos S.Vázquez Sayago Unión TABLA 9.VII CANTIDAD DE CIRCUITOS NECESARIOS PARA LAS DISTINTAS CENTRALES DEL AÑO 3 Circuitos de voz delay con un máximo de 250 ms siempre y cuando estén bien controlados las fuentes del delay. El efecto del delay define la calidad del servicio, en la tabla 9.XII se muestran lineamientos para la definición de servicios de voz. Tipo de llamada MOS Delay (ms) Servicios de alta calidad Local Internacional Servicios de baja calidad Local Internacional TABLA 9.XII RETARDOS TÍPICOS DE SERVICIOS DE VOZ. Existen dos tipos de delay [53], el delay fijo y el delay variable. Los delays fijos son sumados directamente al delay total del enlace. Los delays variables (o jitter) son causados por los delays producidos en los buffers de salida de equipo de abonado hacia la red y de otros efectos no controlados en la red. Estos delays son manejados por un buffer llamado de de-jitter en el equipo receptor. Las fuentes de los delays fijos y variables en una red son identificadas en la Fig. 9.1 Delay de procesamiento de codecs (χ n ). Es el tiempo que le toma al DSP (Digital Signal Processor) comprimir el bloque de muestras PCM. Este delay depende del tipo de codificación y de la velocidad del procesador. Por ejemplo un codec que utiliza un algoritmo ACELP (Algebraic Code Excited Linear Prediction) trabaja analizando 10 ms de muestras PCM y luego comprimiéndolas. El tiempo (según [53]) de compresión para un algoritmo CS-ACELP (Conjugate Structure - ACELP) puede tomar desde 2.5 ms a 10 ms. dependiendo de la carga del procesador DSP. El tiempo de descompresión es aproximadamente el 10% de el de compresión para cada bloque. Sin embargo como pueden haber múltiples muestras (codificadas) en cada frame, el tiempo de descompresión es proporcional también al número de muestras por frame. Por lo general cuando se utiliza G.729 se ponen 2 o 3 bloques (de 10 ms de muestras PCM) en cada frame mientras que al usar G se utiliza un único bloque. Estos resultados se muestran en la tabla 9.XIII. CODEC Tasa de datos Bloque PCM usado Delay mín CODEC Delay máx CODEC G.726 ADPCM 32 Kbps 10 ms 2.5 ms 10 ms G.729A CS ACELP 8.0 Kbps 10 ms 2.5 ms 10 ms G MP MLQ 6.3 Kbps 30 ms 5 ms 20 ms G MP ACELP 5.3 Kbps 30 ms 5 ms 20 ms TABLA 9.XIII DELAY DE LOS DISTINTOS ALGORITMOS DE COMPRESIÓN Algoritmos de compresión como el G.729 y el G necesitan el conocimiento de parte del bloque N+1 para poder reproducir el bloque N. Esto introduce un delay adicional llamado delay algorítmico que tiene como efecto

121 120 CAPÍTULO 9. TRANSPORTE Y CONMUTACIÓN Fig Fuentes del delayfuncionamiento del buffer de de-jitter. el incremento del largo del bloque de compresión según se detalla a continuación: Delay algorítmico para el G.726 es 0 ms. Delay algorítmico para el G.729 es 5 ms. Delay algorítmico para el G es 7.5 ms. Todos estos delays son sumados en el siguiente ejemplo para el CODEC G.729 Tiempo de compresión por bloque 10 ms. Tiempo de descompresión por bloque x3 bloques 33 3 ms. Delay algorítmico 5 ms. Esto suma un total de 18 ms. de delay de codificación Delay de paquetización (π n ) El delay de paquetización es el tiempo que toma el llenado del payload de un paquete con una conversación codificada y comprimida. Este delay es función del tamaño del bloque requerido por el CODEC de voz y el número de bloques por frame. En la tabla 9.XIV se muestra para distintos CODECS y tamaños de payloads los delays de paquetización: A medida que se va codificando se va paquetizando, por CODEC Vel. Kbps Payload Bytes Delay ms Payload Bytes Delay ms G.711 PCM G.726 ADPCM G.729A CS ACELP G MP MLQ G MP ACELP TABLA 9.XIV DELAY DE PAQUETIZACIÓN lo que ambos valores se suman. Como ejemplo, para el algoritmo CS-ACELP el tiempo de paquetización de Se asume que el tamaño del payload será de 30 ms. lo que equivale a 30 bytes por la compresión 8:1 ms (equivalente a tres bloques) se suma al de codificación de 10 ms (peor caso) para enviar el bloque de voz comprimida. Delay de serialización (σ n ) El delay de serialización depende del tamaño del paquete enviado y de la velocidad de la línea. Así, como ejemplo, se calcula en 2 el delay de serialización de una celda ATM (53 bytes) sobre una línea E1 (2048 kbps). P = 53bytes 8bits/byte 2048Kbits/s = 0.207ms. (2) Delay de encolamiento (β n ) Luego que se construye el payload, se agrega un encabezado y el frame se encola para la transmisión sobre la conexión de red. Puesto que la voz debería tener prioridad absoluta en los equipos, un frame de voz debería esperar solamente por un frame de datos que ya está en proceso de transmisión o por otros frames de voz que estén delante de él. Esencialmente el frame de voz espera por el tiempo equivalente a la serialización de cualquier frame precedente en la cola de salida. El delay de encolamiento es variable y depende de la velocidad de la conexión y el estado de la cola. Por ejemplo si la línea es de 128 kbps y existe un paquete de datos de 1500 bytes encolado (asumimos que se envió medio paquete) y otro paquete de voz de 48 bytes ya está esperando y llega otro paquete de voz, el tiempo total del delay de encolamiento es de ms* ms = 49.9 ms. 34. Debe tenerse en cuenta entonces para el cálculo de este delay la cantidad de líneas a usar en cada dispositivo, la prioridad asignada a los paquetes de voz y la fragmentación usada para los paquetes de datos. Delay de conmutación y de la red (ω n ). Este delay es introducido por la red publica/privada que interconecta los dos abonados. Este es el delay más difícil de identificar y tiene componentes fijos y componentes variables. En general los delays fijos provienen de los 34 Par evitar esta magnitud de delays de encolamiento se fragmentan los paquetes de datos antes de enviarlos por la conexión de red.

122 121 delays de propagación de la red. Si el backbone está interconectado con F.O. este delay es despreciable ya que los retardos típicos de una fibra monomodo son de 0.75 ns por kilómetro a temperatura ambiente (25 C). Por lo general se utiliza para estimar este delay de propagación el valor de 6 µs por kilómetro (G.114) aunque algunos factores como equipamiento intermedio de multiplexación, links de microondas y otros factores pueden crear excepciones a esto. El delay variable proviene del encolamiento en los switches intermedios. Si la red es privada es posible medir o estimar este delay. Los delays típicos de una red frame relay en Estados Unidos son de 40 ms para los retardos fijos y 25 ms para los retardos variables [53] sumando un total de 65 ms. Delay introducido por el buffer de De-Jitter ( n ). Puesto que la voz es un servicio de tasa constante deben eliminarse todo el jitter proveniente de los delays variables antes de entregar la voz al decodificador. La elección de este buffer es crítica y el valor inicial óptimo para este buffer es igual al total del delay variable de la conexión. Por lo general se configura un valor inicial y otro final equivalente a 1.5 o 2 veces este valor. En la Fig. 9.2 se muestra la operación del buffer de de-jitter. interleaving. Este retardo corresponde al medido entre el punto de referencia V en el extremo de la estación central (V-C) y el punto de referencia T en el extremo distante (T-R). El Modelo de referencia es mostrado en la Fig Fig Modelo de referencia ADSL Ejemplo de cálculo del delay Para este ejemplo se considera el codec G.729 y una línea ADSL de 384 kbps de velocidad en el downstream y 128 kbps de velocidad en el upstream. Se calcula el delay total de un circuito de voz indicado en la Fig Fig Fuentes del delay Si por ejemplo se utiliza un valor de 40 ms, la primera muestra recibida se mantiene por 40 ms antes de ser presentada. Si el siguiente paquete demora a lo sumo 40 ms no se pierde continuidad en la voz, si demora más de 40 ms el buffer de de-jitter se vaciará y el siguiente paquete será mantenido por 40 ms más antes de ser presentado provocando un salto en la voz de alrededor de 40 ms. VoDSL delay ADSL tiene dos modos de transmisión, el llamado fast path y el interleaved path. La recomendación ITU G especifica que el delay en el modo fast path no debe exceder los 2 ms. mientras que el delay del interleaved path, en un sentido, no debe superar a lo establecido en la ecuación 3. donde: t d = 4 + S S D 4 t d es el delay de transmisión en ms sobre el link. S es la cantidad de símbolos DMT por palabra de código (1, 2,4, 8, 16). D es la profundidad del interleaving (1, 2, 4, 8, 16, 32 o 64). El ADSL usando el interleaved path varía su delay entre los 4.25 ms a los ms dependiendo del tipo de (3) Fig Consideraciones: Topología para el ejemplo de cálculo de delay Duración de muestra 30 ms. Tamaño de paquete 30 bytes. Utiliza VoIP. Tamaño de encabezados RTP/UDP/IP 40 bytes sin compresión y 5 bytes con compresión usando la compresión de encabezados de CISCO [54]. El delay de conmutación de los DSLAM s se incluye dentro de un delay estimado de 10 ms para toda la red. Se desprecia el delay de transmisión dependiente de la distancia. Se utiliza IP sobre AAL5 (RFC 2684 ex 1483), por esto hay que tener en cuenta el Trailer de 8 bytes del protocolo (usando el método de VC Multiplexing). Se fragmentan los paquetes de datos a un tamaño de 256 bytes.

123 122 CAPÍTULO 9. TRANSPORTE Y CONMUTACIÓN Se toma en cuenta un delay extra al de serialización de 4 ms. en cada acceso ADSL. El delay del codec incluye los delays de decodificación χ 2 y el delay del algorítmico. Para calcular el delay de encolamiento se considera que pueden estar activos 3 canales de voz en forma simultánea. Tomando en cuenta estas consideraciones se tiene un tamaño de paquete para el payload de la celda ATM de = 43 bytes, quedando 5 bytes de relleno para completar la celda como se muestra en la Fig Fig Celda ATM/AAL5 con payload de VoIP Con estos datos se elabora la tabla 9.XV Tipo de delay Fijo (ms) Variable (ms) Delay del Codec, χ 1 18 Delay de Paquetización, π 1 30 Delay de Serialización (128 kbps) σ Encolamiento, buffering, β Delay de Serialización (2 Mbps) σ Delay acceso ADSL τ 1 4 Delay de la red 5 5 Delay del buffer de De-jitter 1 30 Encolamiento, buffering, β 2 1 Delay de Serialización (2 Mbps) σ Delay de Serialización (128 kbps) σ Delay acceso ADSL τ 2 4 Total TABLA 9.XV DELAYS FIJOS Y VARIABLES PARA EL EJEMPLO El delay introducido estará entonces entre los ms y los ms lo que cumple con los requisitos establecidos en la G.114 de la ITU-T. una etiqueta para el tráfico IP. Por esta razón se utilizará el paquete RTP/UDP/IP para el cálculo de el ancho de banda necesario para un canal de voz. La estructura del paquete IP se muestra en la Fig A este paquete se le agrega la etiqueta MPLS. Fig Paquete de VoIP En la tabla 9.XVI se muestra el ancho de banda necesario para los tres tipos de CODECS mencionados sin compresión y utilizando la compresión utilizada por CISCO que reduce a 5 bytes todo el encabezado RTP/UDP/IP [54]. CODEC Voice payload Tasa datos de Tasa con compresión G bytes 19.7 kbps 10.4 kbps G MP MLQ 24 bytes 17.8 kbps 8.67 kbps G ACELP 20 bytes 16.9 kbps 7.7 kbps TABLA 9.XVI ANCHO DE BANDA POR CANAL DE VOIP A continuación se muestra el cálculo para el CODEC G ACELP, para el resto de los CODECS se opera de forma similar: Consideraciones: Tamaño de paquete = 4 bytes (Etiqueta MPLS) + 40 bytes (Encabezados RTP+UDP+IP) + 20 bytes (Payload voz) = 64 bytes. Cantidad de paquetes por segundo = 5.3 kbps / (20 bytes * 8 bits/byte) = 33 pps. Ancho de banda de la llamada = 64 bytes * 8 bits/byte * 33 pps = 16.9 kbps Tamaño de paquete con compresión de encabezados = 29 bytes Ancho de banda de llamada con compresión = 29 bytes * 8 bits/byte * 33 pps = 7.7 kbps. 9.I-B.5 Ancho de banda necesario por canal de voz El ancho de banda necesario en cada caso dependerá del codec a usar así como también del retardo requerido. Esto depende de la cantidad de canales de voz enviados en cada circuito (en caso de usar ATM) y del tamaño del paquete usado. A continuación se realizan los cálculos de requerimientos de ancho de banda por canal vocal para tres distintos tipos de CODECS de los habitualmente usados por los operadores de telefonía IP, G.729, G723.1 MP-MLQ y G ACELP. VoIP en redes MPLS. En el acceso y hasta los switches ATM/MPLS el tráfico IP viaja encapsulado en celdas ATM. Luego en el switch de borde se realiza el InterNetworking ATM/MPLS y se agrega No se tuvo en cuenta el uso de VAD en el cálculo individual del ancho de banda. Algunas implementaciones propietarias de fabricantes utilizan un overhead adicional. Un ejemplo de esto es la implementación de CISCO que al utilizar multilink PPP agrega un overhead adicional de 6 bytes al paquete. VoATM El uso de voz sobre AAL1, como se vió en la sección 8.VII, es ineficiente frente al uso de voz sobre AAL2. La celda AAL1 tiene 47 octetos de payload mientras que cada frame de voz transportado sobre AAL2 tiene 3 octetos de encabezado como se muestra en la Fig Tres bytes son usados por la capa CPS (Common Part Sublayer) y uno por el campo de comienzo. Los campos correspondientes al CPS incluyen el identificador de canal CID (Channel Identifier)

124 123 que identifica unívocamente hasta 248 canales dentro de una PDU AAL2, y el LI (Lenght Indicator) que indica el largo del payload asociado a cada canal, el UUI (User to User Indication) responsable de enlazar servicios o grupos de servicios con la capa SSCS (Service Specific Convergence Sublayer) y el HEC (Header Error Control). Varios de estos encabezados CPS pueden ser incluidos en una PDU AAL2 para multiplexar varios canales de voz, como se muestra en la Fig. 9.8, disminuyendo el overhead introducido. La desventaja que presenta la multiplexación de muchos canales de voz en una PDU AAL2 -si bien disminuye el overheades el delay introducido en el llenado. Fig Estructura de la celda AAL2 En la tabla 9.XVII se muestra el ancho de banda necesario para los tres tipos de CODECS mencionados. Ancho de banda de la llamada = 53 bytes * 8 bits/byte * 33 pps = kbps 3 x G MP MLQ Celda ATM1 = 5 bytes (Encabezado ATM) + 1 byte (Start field) + 3 bytes (Encabezado CPS1) + 24 bytes (Payload voz 1) + 3 bytes (Encabezado CPS2) + 17 bytes (Payload voz 2) = 53 bytes. Celda ATM2 = 5 bytes (Encabezado ATM) + 1 byte (Start field) + 7 bytes (Payload voz 2) + 3 bytes (Encabezado CPS3) + 24 bytes (Payload voz 3) +13 bytes (relleno) = 53 bytes. Cantidad de celdas por segundo = 2 x 6.3 kbps / (24 bytes * 8 bits/byte) = cps. Ancho de banda de 3 canales de voz = 53 bytes * 8 bits/byte * cps = kbps Ancho de banda de llamada = 9.2 kbps. Fig Variantes en el llenado de celdas ATM AAL2 CODEC Voice payload Tasa datos G bytes kbps G MP MLQ 24 bytes kbps G ACELP 20 bytes 14 kbps TABLA 9.XVII ANCHO DE BANDA POR CANAL USANDO VOATM de 9.I-B.6 Dimensionamiento de enlaces de acceso al backbone A partir de lo calculado en las secciones anteriores (9.I-A y 9.I-B) se dimensionan las capacidades necesarias de acceso al backbone. VoIP vs VoATM: Algunas compañias han desarrollado redes de VoATM pero con mayores costos que las redes de VoIP, conectando los gateways de VoATM a centrales convencionales. Estos gateways terminan actuando como terminales remotos concentrando la inteligencia en la central convencional. Esto determina que la convergencia esté presente solo en el acceso y no en toda la red a diferencia de las implementaciones de VoIP. 9.I-B.7 Conclusión Para la estimación del ancho de banda se tiene en cuenta el uso de VoIP, MPLS como protocolo de transporte y G.729 CS ACELP como CODEC para la compresión de la voz. 35. A continuación se muestra el cálculo para el CODEC G.729 y G MP MLQ (usando 3 canales de voz por PDU AAL2). G.729: Tamaño de paquete (celda ATM) = 5 bytes (Encabezado ATM) + 1 byte (Start field) + 3 bytes (Encabezado CPS) + 30 bytes (Payload voz) + 15 bytes (relleno) = 53 bytes. Cantidad de celdas por segundo = 8.0 kbps / (30 bytes * 8 bits/byte) = 33.3 cps. A partir de los datos del número de canales se obtiene el ancho de banda de voz (y el ancho de banda total) por nodo para los tres primeros años. Esto se muestra en las tablas 9.XVIII, 9.XIX y 9.XX. Es posible lograr una disminución promedio del 35% en el ancho de banda en las troncales con el uso de VAD [54]. 35 Se utilizará este, codec pese a que el G.723 MP MLQ tiene una mejor relación MOS/ancho de banda, ya que según lo relevado es soportado ampliamente por operadores de larga distancia internacional de VoIP.

125 124 CAPÍTULO 9. TRANSPORTE Y CONMUTACIÓN Central Ancho de banda datos Mbps. Ancho banda Mbps. de voz Total Mbps. Aguada Athahualpa Buceo Carrasco Centenario Centro Ciudad Vieja Cordón Malvín Palacio Parque Rodó Pocitos Punta Carretas TABLA 9.XVIII ANCHO DE BANDA ESTIMADO PARA LOS DISTINTOS NODOS EN EL AÑO 1 Central Ancho de banda datos Mbps. Ancho banda Mbps. de voz Total Mbps. Aguada Athahualpa Buceo Carrasco Centenario Centro Cerrito Ciudad Vieja Colón Cordón Euskalerría Ituzaingó Malvín P. Carretas Palacio Parque Rodó Paso Molino Pocitos Sayago Unión TABLA 9.XIX ANCHO DE BANDA ESTIMADO PARA LOS DISTINTOS NODOS EN EL AÑO 2 9.II TRANSPORTE FÍSICO Hoy en día existen varias opciones para interconectar los nodos del backbone de transporte, pero lo más usado son los enlaces de radio o fibra. Otra opción posible es rentar capacidad de transporte al operador incumbente usando redes existentes (ATM, DWDM, MPLS, SDH, IP, etc) 9.II-A Radio Esta solución consiste en interconectar los nodos usando radioenlaces que pueden variar su capacidad -dependiendo de la tecnología y producto- desde los 2Mbps o menos hasta una o varias STM-1 (155 Mbps). A continuación se listan las ventajas y desventajas de la solución por radio. VENTAJAS La solución se puede implementar con infraestructura propia Central Ancho de banda datos Mbps. Ancho banda Mbps. de voz Total Mbps. Aguada Atahualpa Buceo Carrasco Centenario Centro Cerrito Cerro Ciudad Vieja Colón Cordón Euskalerría Ituzaingó Lezica Malvín Manga S P. Carretas P. de la Arena Palacio Parque Rodó Paso Molino Pocitos S.Vázquez Sayago Unión TABLA 9.XX ANCHO DE BANDA ESTIMADO PARA LOS DISTINTOS NODOS EN EL AÑO 3 Control total del backbone, menor dependencia del operador incumbente. Rapidez de la implementación. Obra civil de poco porte -dependiendo de envergadura de las torres a construir- comparado con el tendido de fibra o cable de otras opciones. Posibilidad del re-uso de la infraestructura para brindar acceso o backup de accesos. DESVENTAJAS Problemas ante factores climáticos. Gastos asociados a las licencias de frecuencias. Costos de radiobases y equipos de transmisión. Mayor complejidad en el diseńo. Necesidad de alquiler de azoteas o espacio en mástiles existentes. Infraestructura adicional que se suma a el equipamiento en coubicación. 9.II-B Fibra Óptica Existen al menos dos posibilidades para la implementación del transporte por fibra óptica. La primera es el alquiler de la misma ya sea por pelo de fibra oscura o de una o varias longitudes de onda dentro de un enlace DWDM. Estas soluciones permiten brindar enlaces de alta capacidad de hasta 10 Gbps por longitud de onda (o por pelo de fibra sin utilizar DWDM). La segunda opción es el tendido propio de fibra. A continuación se listan las ventajas y desventajas de la solución por fibra en cada caso.

126 125 9.II-B.1 Fibra rentada VENTAJAS Ancho de banda ilimitado. Inmunidad a interferencias y factores climáticos. Control total del backbone, poca dependencia del operador incumbente. Rapidez de la implementación. No es necesario realizar obra civil. Instalación de equipos de backbone en coubicación junto con los de accesos. Cobertura. En Montevideo el operador incumbente llega con fibra a todas las centrales donde existen nodos de la nueva red. DESVENTAJAS La legislación no contempla esta posibilidad y el operador incumbente tiende a evitar el alquiler de este recurso Necesidad de auditar los enlaces. Contratos muy detallados para contemplar aspectos de QoS, seguridad, etc. 9.II-B.2 Fibra propia VENTAJAS Ancho de banda ilimitado. Posibilidad de crecer en ancho de banda utilizando el mismo medio. Inmunidad a interferencias y factores climáticos. La legislación contempla esta posibilidad. Control total del backbone, no hay dependencia del operador incumbente. Instalación de equipos de backbone en coubicación junto con los de accesos. DESVENTAJAS Es necesario realizar obra civil. Altos constos iniciales y mayor riesgo. Mayores tiempos para la implementación. 9.II-C Transporte rentado Esta solución se implementa utilizando la red de transporte del otro operador. Se acuerda con este la capacidad y QoS del enlace, y se utliiza el mismo si preocuparse de la ruta fisica. VENTAJAS Posibilidad de crecer en ancho de banda utilizando el mismo medio. De acuerdo a la capacidad ofrecida por el proveedor. Inmunidad a interferencias y factores climáticos. Independencia de la capa física de la red. La legislación contempla esta posibilidad. Menores costos de operación y mantenimiento. Instalación de equipos de backbone en coubicación junto con los de accesos. Redundancia intrínseca. Suponiendo que el proveedor la tenga. DESVENTAJAS Necesidad de adaptarse a un protocolo manejado por el proveedor. Necesidad de auditar los enlaces. Contratos muy detallados para contemplar aspectos de QoS, seguridad, etc. Menor flexibilidad a la hora de brindar servicios en zonas no atendidas por el incumbente. 9.II-D Conclusiones Al momento de elegir el transporte propiamente dicho de la red, se deberán tener en cuenta no solo los aspectos técnicos de la solución, sino que también factores económicos y de crecimiento que dependen del plan de negocios. En el caso de estudio, la utilización del unbundling en el loop de abonado hace que la primer opción (Radio) no sea tan conveniente, ya que al no usar equipos inalámbricos en el acceso la inversión de la radiobase e infraestructura asociada se suma al costo del unbundling. En otro escenario donde si se pueda aprovechar la infraestructura de torres, radiobases, etc. para dar el acceso, posiblemente esta opción tendría un peso mayor. La opción de tendido de fibra propia no parece apropiada para una red con la dimensión y las posibilidades de crecimiento como la que aquí se plantea de acuerdo a lo visto en el capítulo 3. Esto deja como opciones convenientes rentar pelos de fibra (o longitudes de onda de enlaces DWDM) o rentar capacidad en el backbone del operador incumbente. En este proyecto se usaran ambas opciones justificando en cada caso la elección tomada. 9.III-A Descripción 9.III RED DE SINCRONIZACIÓN El propósito del plan de sincronización para la red es lograr maximizar su confiabilidad y disponibilidad. Para ello se establece una red de sincronización, que distribuye y controla la temporización a través de toda la red. Esta red es en realidad una capa más sobre la red existente ya que utiliza los mismos enlaces de transporte que unen sus componentes (nodos). Existen objetivos de performance a verificar y cumplir concernientes al deslizamiento como se especifica en la norma EIA/TIA-594 Private Digital Network Synchronization. Los objetivos de la red de sincronización son objetivos globales de la red. Estos objetivos incluyen ítemes como el porcentaje de segundos sin error, la cantidad máxima de minutos de caídas al mes por circuito, el promedio mensual de minutos de caída de circuitos, etc. Tener una buena sincronización implica mantener en el receptor, que se encuentra al final de uno/varios enlaces, la misma frecuencia de reloj que en el transmisor. Debido a la complejidad de las topologías de redes existentes, esto requiere mantener la misma frecuencia de reloj en todos los nodos de la red. Si las frecuencias son ligeramente diferentes en los buffers de datos pueden producirse sobrecargas o vaciamientos (overflows, underflows) que producen deslizamientos de tramas, errores de bits, y posibles pérdidas de frames.

127 126 CAPÍTULO 9. TRANSPORTE Y CONMUTACIÓN 9.III-B Deslizamiento de tramas En un sistema TDM el receptor almacena algunos frames en sus buffers temporales para compensar cualquier deslizamiento de fase en el flujo de bits proveniente del receptor con el flujo interno de bits que maneja. Este deslizamiento es causado por el jitter y es introducido por el transporte o por diferencias en la frecuencia de los relojes del transmisor y el receptor. Si el transmisor envía datos a una tasa mayor de bits que el reloj del receptor, el buffer de recepción puede desbordarse causando que se descarte el frame. Si por el contrario la tasa es menor el buffer se vaciará causando una repetición del frame. Ambos eventos son llamados deslizamiento de tramas y resulta en errores de bit. Si estos deslizamientos hacen que otros elementos aguas abajo en la red realicen procesos de re-sincronización los errores de bit pueden ocurrir en ráfagas cortas. Esto hace que sean difíciles de localizar. En la tabla 9.XXI se muestra un ejemplo de los efectos de deslizamiento según la estabilidad del reloj usado [55]. En la tabla 9.XXII el posible impacto en los distintos servicios del desplazamiento de tramas[55]. Las fuentes de reloj se clasifican por su calidad o nivel Stratum donde el nivel 1 representa la mejor calidad posible. Por ejemplo el oscilador de los procesadores es una fuente Stratum 4 [56], mientras que el oscilador del modulo de reloj en un equipo tiene nivel Stratum 3. Calidad del Clock Posible deslizamiento con la referencia Desajustado Normal Stratum 2 Sin deslizamientos en 5 Inapreciable días Stratum deslizamientos por Un deslizamiento por día hora Stratum slips por hora 100 deslizamientos/día TABLA 9.XXI DESLIZAMIENTOS EN FUNCIÓN DE LA CALIDAD DEL RELOJ Tipo de servicios Texto encriptado Datos Fax Video Datos en banda base Voz Impacto Reenvío de clave de encriptación Pérdida y/o reenvío de datos Borrado de líneas de fax, posible pérdida de llamada Congelamiento de imágen por algunos segundos, ruido en el audio Errores en la transmisión hasta por 2 segundos, posible pérdida de llamada Posibles clicks en la conversación TABLA 9.XXII IMPACTO DEL DESLIZAMIENTO DE UN FRAME EN LA CALIDAD DE DISTINTOS SERVICIOS. 9.III-C Desajustes de sincronización que causan deslizamientos de tramas. Las fuentes de referencia para la sincronización tienen una frecuencia ligeramente desigual. Falla en el equipamiento de un elemento de la red de donde se extrae el sincronismo. Loops de sincronización, producidos por dos extremos de un enlace extrayendo el sincronismo entre sí. Esta condición inestable conduce a una pérdida de sincronización. Jitters de gran tamaño causados por problemas intermitentes en el camino de transporte. Reestructuras en la red que interrumpen o cambian el recorrido de un flujo de datos. Variaciones de temperatura a lo largo del camino de transporte, con más efecto sobre líneas de cobre que sobre fibras ópticas. Ajustes de punteros en tramas SONET/SDH en el camino de transmisión. El efecto de la mayoría de estos problemas puede minimizarse con el uso de un reloj en cada nodo de la red llamado BITS (Building Integrated Timing Supply). Este reloj provee la temporización para todo el nodo. Este reloj puede ser un master como un oscilador de cesio o un GPS o un oscilador corregido por GPS; o puede ser un reloj slave enganchado con una E1 de buena estabilidad. En cualquier caso la salida de este reloj se distribuye por todos los elementos de la red (muxes, Switches, PBX, DACS, etc). 9.III-D Items a tener en cuenta en el momento del diseño Se tienen que estudiar los recorridos de los enlaces para evitar loops de sincronismo en caso de caídas. Deben evitarse las cascadas de más de 4 nodos Debe evitarse tomar una referencia de una tributaria SONET/SDH por los cambios de fase producidos por ajuste de punteros. Todos los nodos de tránsito deben tener una referencia de backup y la conmutación a esta referencia debe ser automático. Los backups deben llegar al nodo por un enlace distinto al que utiliza la referencia principal. Los nodos que no reciben un reloj de backup deben tener un reloj interno para usar como backup en caso de caída de la fuente principal. Al menos dos relojes de la red deben ser referencias primarias y deben ser relojes GPS o relojes stratum 2 o mejores provistos por PSTN. Los relojes Masters deben ser capaces de usar como referencias un GPS o una E1 desde otros nodos de la red. Si la referencia es una E1 deben tener la posibilidad de un backup por GPS o por otra E1 desde otro nodo de la red. Si el que provee la referencia no especifica ni controla el nivel stratum de la interfaz, esta referencia debe ser usada solo para conexiones punto a punto y no para distribuir en la red. Cualquier sincronismo recibido desde el carrier o otra red debe ser aislado con un reloj stratum 2 o 3 en el punto de entrada si es posible.

128 127 Fig Topología de la red de sincronismo 9.III-E Topología de la red de sincronización La red de sincronización se configura como una capa más de la red de comunicaciones existente. Los relojes Master se instalan en los nodos principales de la red y pueden ser relojes basados en osciladores GPS, con un reloj de referencia interno, o relojes atómicos o referencias de buena calidad derivadas de la PSTN. El reloj luego se distribuye a los nodos esclavos a través de los enlaces como se indica en el ejemplo de la Fig En caso de caída de uno de los relojes principales los nodos esclavos y el nodo principal afectado toman el sincronismo del Master que continúa activo. Los nodos principales o los esclavos pueden tener una referencia extra como segundo backup. 9.IV-A Introducción 9.IV ARQUITECTURA Se presentan aquí las dos arquitecturas más adecuadas, para la red a diseñar. Las opciones son: Red Híbrida y Red Convergente (NGN). Se hará una primera descripción global (pre diseño) apenas suficiente para compararlas desde el punto de vista técnico, de servicios y también de costos de instalación. A partir de esta comparación se decide la opción a implementar y para la misma se presentara la arquitectura detallada. 9.IV-B Red Híbrida 9.IV-B.1 Descripción Esta red se basa en usar elementos convergentes en el acceso y en el transporte, pero mantener la conmutación de las llamadas de voz en centrales de tipo tradicional. Se presenta aquí un diagrama básico en Fig IV-B.2 Ventajas La principal ventaja de este modelo es la fácil implementación ya que se trata de tecnología bien conocida y usada tradicionalmente por los operadores telefónicos. También es un modelo muy usado por operadores entrantes, que dan servicios de telefonía en sub-zonas de grandes metrópolis, ya que estos operadores suelen comprar centrales que han sido reemplazadas (por alguna más nueva o de mayor capacidad) Fig Arquitectura de red Hibrida por otros operadores de mayor envergadura. Aprovechando los bajos costos de estas centrales y el unbundling, estos operadores consiguen una rápida penetración al mercado con un costo reducido. 9.IV-B.3 Desventajas Un operador multiservicio puede estar orientado (por su plan de negocios) a ser un proveedor de servicios de valor agregado (servicios innovadores). En este caso esta arquitectura no es adecuada debido a la limitación implícita de dar servicios que necesiten la convergencia entre voz y datos. También hay servicios como la Portabilidad de numeros que son de más sencilla implementación en redes completamente convergentes. Otra desventaja de esta arquitectura es la adaptación que se debe hacer de los flujos de voz desde codecs tipo CELP que se usan en el acceso (para maximizar el aprovechamiento del mismo y del transporte) a TDM ley A, que es lo que la central podrá conmutar. Cuando dos abonados de esta red hablan entre ellos el problema se agrava ya que habrá una doble conversión (al entrar y salir de la central). Es sabido que la doble conversión degrada bastante el MOS de la llamada, además de introducir retardos muy importantes como se estudio en la sección 9.I. 9.IV-B.4 Pre Diseño En caso de optar por esta arquitectura, lo más adecuado es tener al menos dos centrales de tipo tradicional, por razones de redundancia de equipos y locativa. Por la misma razón también seria necesario replicar los Trunk Gateways. Estas centrales deben manejar V5.2 para la comunicación con el Trunk Gateway, que en este caso actúa como concentrador de abonados. Un esquema que resume los protocolos de señalización utilizados en este caso se muestra en la Fig El esquema análogo para los protocolos de voz se puede ver en la Fig. 9.12

129 128 CAPÍTULO 9. TRANSPORTE Y CONMUTACIÓN Fig Protocolos de señalización en red híbridas. Fig Pre diseño red Hibrida Fig Protocolos para transporte de una llamada de voz. Dado que manejan voz y señalización tradicional (TDM, G.711, SS7 36 ) serán usadas como equipo de Interconexión con la PSTN 37. Es recomendable por lo tanto, que estén ubicadas lo más cerca posible de los puntos de interconexión (POI) con la red del operador incumbente (ANTEL). Notar que según [57] estos puntos deben ser en centrales CTI (si se quiere tener acceso a todos los abonados de la PSTN del país) y en centrales Tándem (si se quiere tener acceso a todos los abonados de la PSTN de Montevideo). Se eligen entonces, como punto de interconexión las centrales Unión y Aguada ya que ambas son a la vez Tándem y CTI en la jerarquía de ANTEL. Los edificios donde estén estos equipos serán denominados NOC1 y NOC2 ya que también se utilizarán como centros de operación de la red. De este modo la red quedaría estructurada como lo muestra la Fig IV-C Red Convergente 9.IV-C.1 Descripción En este caso todas las funciones de la red son implementadas por equipos de NGN. A todos los niveles (acceso, transporte, conmutación) se tendrán paquetes/celdas con información de diverso tipo. Estos paquetes/celdas serán tratados en forma diferencial de acuerdo a al contenido de lo que transporten. Se respetara la arquitectura NGN de acuerdo a lo que se describe en 5. En la Fig se presenta un diagrama básico misma. 9.IV-C.2 Ventajas Permiten implementar servicio de redes de nueva generación que usufructúan la convergencia de voz, video y datos. Esto 36 Si bien la legislación Argentina estipula R2, el convenio de Interconexión de ANTEL exige señalización SS7 ISUP 37 También para interconexión con MSCs de redes celulares. Fig Arquitectura de red Convergente pone al operador que los utilice en una posición privilegiada desde el punto de vista de la flexibilidad de los servicios que puede ofrecer. En las zonas en las que se dará servicio se llegara con transporte propio, entonces para llamadas locales nunca se dará el caso de doble conversión (CELP-PCM / PCM-CELP) y por lo tanto se tendrá un MOS adecuado en todas las llamadas. 9.IV-C.3 Desventajas Es una tecnología muy poco extendida, si bien todo apunta que es la tecnología de los próximos años, hasta ahora solo ha sido implementadas por operadores de telefonía internacional o a nivel de prueba por operadores tradicionales. Esto se debe entre otros factores a que tanto equipos como protocolos no cuentan con la confianza de los operadores. Los equipos NGN son aun costosos aunque se espera que los precios disminuyan rápidamente a medida que se comiencen a implementar redes de este tipo.

130 129 9.IV-C.4 Pre Diseño En cada una de las centrales de ANTEL cuya planta externa cubre las zonas en las que se darán servicio cada año según la sección 6.V, se contrata coubicación y se conecta ahí un DSLAM que interconecte los IADs con el anillo de transporte. Además de esto se seleccionan edificios cercanos a las dos centrales de ANTEL en las cuales se tendrán los POI con dicho operador. En estos edificios se ubican los NOC de la red, teniendo así redundancia locativa (además de la de equipos). La ubicación de los NOCs seguirá lo mismo criterios descritos en el pre diseño de la Red Híbrida. En cada uno de estos NOCs, se instalan: Softswitch Signaling Gateway Voice Gateways Equipos de acceso a Internet Equipos para interconexión con otros proveedores de datos. Equipos de OAM Estos NOCs tendrán esencialmente tres puntos de interconexión: Interconexión con operador telefónico Interconexión/es con proveedor/es de acceso a Internet Interconexión con el transporte. De este modo la red quedaría estructurada como lo muestra la Fig V-A Introducción 9.V DISEÑO En las secciones anteriores se han estudiado las distintas tecnologías, protocolos y equipos que son normalmente empleados en redes de estas características. En consecuencia se está en condición de diseñar la red más adecuada a los objetivos planteados en la especificación de este proyecto. 9.V-B Acceso El diseño de la red de acceso fue hecho en el capítulo 6. Se ponen aquí los resultados obtenidos, con el fin de dejar plasmado el diseño completo de la red. El acceso de los usuarios será a través de ADSL, que se dará haciendo unbundling físico sobre la planta externa del operador incumbente (ANTEL). Los equipos de cliente (CPE) serán IADs que manejen: VoIP. G.729. Manejo de QoS. Interfases de datos. Interfases de voz (POTS). En cada una de las centrales de ANTEL en las que se tendrá presencia cada año (según sección 6.V) se contratará coubicación y ahí se instalaran los siguientes equipos: DSLAM. Es recomendable que estos equipos puedan manejar IP/MPLS, de este modo los DSLAM usaran PVCs ATM para comunicarse con los IADs y MPLS para comunicarse con el transporte. Si no manejan MPLS, el LER tendrá que ser capaz de hacer InterNetworking ATM-MPLS (como se muestra en la figura 9.16), lo que hace necesario además implementar un PVC desde el DSLAM hasta el LER. Router de borde (LER). Este equipo forma parte del Transporte, por lo que se dan más detalles más adelante en la sección correspondiente. 9.V-C Transporte y Conmutación 9.V-C.1 Descripción La red de transporte tendrá una topología de Doble estrella, como se puede ver en la Fig Esta estructurada en Borde y Núcleo. Fig IV-D Conclusión Pre diseño red Convergente Debido a las razones expuestas aquí, pensando en la característica de red multiservicio que se diseña, desde un punto de vista técnico lo más adecuado es desarrollar una red convergente. No obstante, es casi seguro que la decisión dependa intrínsecamente de factores económicos. Se desarrolla aquí la opción convergente suponiendo que el plan de negocios es favorable a esta. Se usa MPLS como protocolo de transporte. La elección de la tecnología MPLS en lugar de ATM toma en cuenta las siguientes ventajas de MPLS: Manejo de múltiples protocolos (independencia de capa 2). Manejo de QoS independientemente del protocolo. Implementación robusta y escalable de VPN s Facilidad en la OAM y provisioning de servicios. Mejor ingeniería de tráfico, tratamiento diferencial de flujos de datos. ATM tiene como ventaja que es una tecnología madura probada en redes durante años en todo el mundo, por lo que

131 130 CAPÍTULO 9. TRANSPORTE Y CONMUTACIÓN Fig Interworking MPLS en acceso ADSL. Fig Topología de la red. muchos operadores ya instalados extienden sus redes con esta tecnología. En el caso de estudio y por tratarse de una red a implementarse desde cero, la elección de MPLS apuesta a la convergencia de servicios y al manejo eficiente del protocolo IP predominante en las redes actuales. 9.V-C.2 Núcleo Los routers (LSR según MPLS) ubicados en los NOCs formaran el Núcleo de la red. Estos estarán a su vez conectados entre si con una fibra oscura rentada. 9.V-C.3 Borde En cada una de las centrales donde se tendrá coubicación, un router interconectará el DSLAM con el Núcleo. En conjunto estos router forman el Borde de la red de transporte (LER según MPLS). Desde cada router de borde habrá un enlace a uno de

132 131 los NOC de la red y un respaldo hacia el otro NOC para contingencias en caso de: 1) Falla del LSR de uno de los NOC (o ruptura de la fibra que los une). Frente a esto todos los LERs pasaran automáticamente a depender de el otro NOC, utilizando el enlace de respaldo como lo muestra la Fig Uno activo y respaldo automático operado por el monitoreo de esta red. Los dos activos. Algunos puntos del contrato son vitales y deben estar claramente establecidos. Por ejemplo: Disponibilidad de los enlaces. Forma en que se manejara el doble enlace. Tiempo máximo de instalación y de ampliación de los mismos. Fig Topología frente a falla del NOC o la Fibra. 2) Si falla alguno de los enlaces contratados, el enlace de respaldo hacia el otro NOC pasara a ser activo, como lo muestra la Fig V-D Sincronización Para la sincronización de la red se instalan en cada NOC relojes GPS, uno activo y otro de backup. La sincronización se hace necesaria en el enlace entre ambos NOC s, como referencia para los gateways de interconexión con el incumbente y para una futura extensión del backbone propio. Los equipos remotos (DSLAM s y LER s) que utilizan transporte rentado tomarán el reloj de la interfaz conectada directamente con el carrier, eventualmente podrían tomar el reloj directamente desde la PSTN mediante una E1. En la Fig se muestra un diagrama de la distribución del reloj. Fig Topología de la red frente a fallas de un enlace. Si bien, lo más recomendado es que el transporte se de sobre enlaces propios, el costo de enterrar fibra óptica a todos los puntos de borde es extremadamente caro para la cantidad de clientes servidos en cada punto (como se vio en 9.I). Debido a esto los enlaces, serán contratados a un proveedor. Se contratará en función del tráfico necesario en cada punto, calculado en 9.VII. La forma de funcionamiento de la redundancia de los dos enlaces de cada LER depende de lo que se pueda establecer en el contrato con el proveedor. Como ejemplo podrían funcionar como: Uno activo y un respaldo automático operado por el proveedor. Fig Topología de la red de sincronismo 9.V-E Provisionamiento Los Equipos de OAM se encargan de la administración, provisión de servicios y monitoreo de todos los componentes de la red. Se preverá que todos los equipos tengan CORBA 38 como interfase común con este propósito. De este modo se podrá unificar toda la gestión en un único sistema de provisioning. 38 Ver Apéndice E

133 132 CAPÍTULO 9. TRANSPORTE Y CONMUTACIÓN Se puede prever, que el sistema de provisioning este vinculado con el sistema informático usado para las demás funciones de la empresa que gestione la red. De este modo el alta administrativa de un servicio podría generar los eventos necesarios para que la red automaticamente provea el servicio al usuario. Sistemas de interfases entre los distintos softwares, se hacen mas necesarios a medida que aumenta el tamaño de la red. Debido al número de clientes previstos para el inicio de la red que se está diseñando, estas interfases no son estrictamente necesarias, pudiendo proveerse los servicios desde una interfaz hombre maquina. De todos modos la elección del conjunto de software es de una complejidad tal que ha sido dejada fuera del alcance de este proyecto. 9.V-F Servicios 9.V-F.1 Telefonía Los accesos empresariales serán accesos ruteados convencionales con direcciones IP fijas. Redes privadas Se instrumentarán creando VPNs MPLS entre los equipos del cliente como se describe en 7.II-H. El mecanismo de implementación de estas depende del equipo DSLAM que se utilice. El caso más sencillo es cuando el DSLAM tiene servicios MPLS ya que las VPNs comienzan en el propio DSLAM. En caso de DSLAMs ATM será necesario además implementar un PVC desde el IAD hasta el LER para cada VPN. Servidores de streaming-media, webhosting Estos servicios solo implican agregar servidores con las aplicaciones especificas. Telefonía local Se pueden distinguir 2 casos: Entre abonados de la misma red. Los IADs de cada abonado estarán registrados en el Softswitch mediante H.248. Al iniciar una llamada el equipo de abonado A consultara al Softswitch la dirección de transporte del abonado B y establecerá una sesión RTP con este. Hacia abonados del incumbente. En este caso al establece la consulta al Softswitch este lo redireccionará a el Trunk Gateway correspondiente. Al mismo tiempo el Softswitch utilizando su función de Signaling gateway negocia (usando SS7) con la PSTN el canal a tomar y el destino de la llamada. El mecanismo análogo es utilizado para las llamadas entrantes. Telefonía Internacional El procedimiento es análogo al de la telefonía local, usando cualquiera de los casos descritos dependiendo de la tecnología que utilice el operador internacional. Soluciones de telefonía empresarial, redes privadas de Voz y servicios IN La flexibilidad de las redes convergentes permite la implementación de cualquier servicio de voz con la sola inclusión de la función en el Aplication Server. 9.V-F.2 Datos Acceso a Internet Se usarán accesos de PPPoE para abonados residenciales. Los usuarios iniciaran una sesión PPPoE (PPP over Ethernet) con el BRAS (Broadband RAS) el cual previa autentificación (vía servidor AAA) bajará la información al IAD para habilitar el acceso a Internet (dirección IP, ruta por defecto y servidores DNS). 9.V-F.3 Video El servicio de video no estuvo contemplado en el cálculo de tráfico ni en la arquitectura, ya que luego de los estudios realizados de la zona, se puede deducir que éste no será incluido en el plan de negocio. No obstante la distribución de Video se puede realizar según lo explicado en 8.VIII. 9.V-G Soporte e Infraestructura de servicios Aquí se describe el hardware y protocolos necesarios para dar los servicios mencionados anteriormente. En cada NOC se deben instalar equipos con las siguientes funcionalidades: Softswitch, Trunk Gateways, Signaling Gateway, Servidores de Aplicaciones, Equipos de Operación, Administración y Mantenimiento (OAM) 39, H.323 Gatekeeper y SIP proxy 40. El Softswitch usará H.248 para establecimiento y control de llamadas entre IADs y/o Trunk Gateways. Además este se encargara de todas las funciones conmutación de llamadas, IN 41 y accounting. El Trunk Gateway, provee la interfaz de llamadas entre la PSTN y la NGN. El Signaling Gateway es el encargado de mapear la señalización SS7 desde y hacia la PSTN en SIGTRAN desde y hacia el Softswitch. En la Fig se muestra un diagrama con los protocolos involucrados tanto a nivel de señalizacioón como de VoIP. Los Servidores de Aplicaciones dan soporte a servicios diferentes a los soportados por el Softswitch. Haciendo uso 39 Varias de estas funcionalidades suelen estar integradas en un solo hardware (ver sección 9.VI-B.1). 40 Opcionales en caso de dar servicios que utilicen H.323 o SIP 41 ej.: reenvío de llamadas, llamada en espera, teleconferencia, etc.

134 133 Fig Protocolos utilizados para el establecimiento de llamadas en redes convergentes utilizando VoIP. de la convergencia la gama de servicios que se pueden implementar es extremadamente amplia 42. Además permite la creación de nuevos servicios usando lenguajes estándar como XML. El H.323 Gatekeeper y el SIP proxy serán usados para dar servicio a aplicaciones especiales (ej.: telefonía desde el PCs, video conferencia, mensajería, etc) que no trabajen con H Algunos ejemplos representativos pueden ser: Call Centers (inclusive distribuidos), facilidades Web to Speach, Fax to Mail, etc.

135 134 CAPÍTULO 9. TRANSPORTE Y CONMUTACIÓN 9.VI-A Introducción 9.VI EQUIPOS La elección de equipos es la etapa final en el proyecto de Ingeniería de una red. Este proceso normalmente consta de varios pasos. Si bien estos pasos tienen un orden a seguir, varios de ellos pueden producir la vuelta atrás en el proceso para cambiar alguna de las decisiones tomada en pasos anteriores. Se darán algunos ejemplos sobre esto más adelante. Etapas en la elección de equipos A- Relevamiento de equipos disponibles en el mercado. B- Verificación de compatilidad con otros equipos. C- Comparación técnica. D- Comparación de costos. E- Elección final. 9.VI-B Elección de equipos En esta parte se aplicaran los pasos detallados anteriormente a nuestro el diseño específico. 9.VI-B.1 Relevamiento de equipos disponibles en el mercado Con el surgimiento de la idea de redes NGN y las perspectivas que se tenían sobre finales de la década del 90, sobre el desarrollo que se produciría en el área de las telecomunicaciones, surgieron muchos proveedores de equipos para NGNs así como los clásicos proveedores clásicos abrieron sus áreas de desarrollo hacia este lado. Este crecimiento acelerado de desarrolladores de equipos para NGN, se ha producido con cierto desorden, y si bien están claras las distintas funciones que deben existir en una NGN, el equipo en el que se implementan y el nombre de dicho equipo cambia con cada proveedor. Como ejemplo, mientras que la mayoría de los proveedores tienen la función de Voice Gateway y Trunk Gateway en un mismo equipo que suelen llamar Media Gateway, Cisco tiene estas funciones separadas en lo que ellos llaman MGX (Voice Gateway) y PGW (Trunk Gateway). También hay proveedores que integran funciones de Softswitch y Media Gateway en un solo Hardware. Otro punto a tener en cuenta es que todos los proveedores tienen varios modelos de equipos con las mismas funcionalidades y estos varían esencialmente en la capacidad de los mismos. Por ejemplo la cantidad de interfases que soportan o la capacidad de el modulo de conmutación. Se ha decidido tomar la decisión en función de las prestaciones del equipo y luego verificar cual de los modelos es el requerido de acuerdo a las previsiones de tráfico que se tienen. Lo aquí comentado dificulta una comparación sencilla entre los diferentes equipos desde el punto de vista de sus funcionalidades. De todos modos se presentan aquí tablas en las cuales se resume la información de las hojas de datos de equipos de los distintos proveedores 43. Estas tablas están organizadas de 43 Las tablas han sido elaboradas a partir de las referencias: [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [68], [69], [70], [71], [72], [73], [74], [75], [76], [77], [78], [79], [80], [81], [82], [83], [84], [85], [86], [87], [88], [89], [90], [91] forma que permitan comparar los distintos equipos en función de las características que se requieran de los mismos. Hoja comparativa de Media Gateways ver Tabla 9.XXIII Hoja comparativa de Softswitches ver Tabla 9.XXIV Hoja comparativa de Switches de Backbone ver Tablas 9.XXV, 9.XXVI, 9.XXVIIy 9.XXVIII 9.VI-B.2 Verificación de compatilidad con otros equipos. Hay que verificar que protocolos habla cada equipo y a través de que interfases lo puede hacer, luego comparar estas con las que hablan los demás equipos que se interconectarán a este. En el diseño de cada una de las partes de la red se hicieron estudios de equipos y medios físicos a ser usados. Por ejemplo al diseñar la red de acceso se estudiaron los equipos existentes y se eligieron un grupo de ellos que cumplen con los requerimientos funcionales necesarios. Por otro lado al llegar a esta etapa debido a la diversidad de protocolos existentes para cada función de la red, 44 será necesario decidir los protocolos a ser usados, en las distintas capas de la misma. Los equipos que se seleccionen en esta etapa deben ser compatibles con los de acceso y en caso de no ser posible, habría que volver a elegir equipos de acceso que lo sean. Una restricción mayor es la compatibilidad con las tecnologías/equipos que usan los proveedores con los que habrá que interconectar la red (ej. el proveedor incumbente). Normalmente esto está normalizado en el reglamento de inteconexión, donde se suele listar un grupo de interfases/protocolos disponibles a la interconexión. De no ser así habrá que negociarlo directamente con el operador. Compatibilidad entre equipos. De acuerdo a lo que se vio en 9.V los equipos deben cumplir las siguientes especificaciones: Protocolo de transporte. El elegido es IP/MPLS, por lo cual todos los equipos del Núcleo de red (LER, LSR, Softswitch, Trunk Gateway, Signaling Gateway, etc.) tienen que tener esta capacidad. Voz. Se manejará con VoIP, usando CODEC CELP G.729, por lo cual tanto los IADs, como el Trunk gateway tiene que ser capaces de manejarlos. Señalización. Hacia la PSTN de acuerdo a [57] debe señalizarce SS7 ISUP. Esto determina que el Signaling gateway tiene que soportar SS7 ISUP y además el Softswitch debe manejar SIGTRAN. El establecimiento y control de llamadas (comunicaciones multimedia) entre los equipos NGN se hará mediante H.248 (MEGACO). Por lo cual Softswitch y Media Gateway, IADs, Trunk Gateway y Aplication Servers deben hablar H Transporte (IP, AMT, MPLS, etc), protocolos para voz sobre paquetes (ej.: AAL2 sobre ATM, VoIP), Señalización entre los diferentes equipos (ej.: SS7, R2, MGCP, H.248/MEGACO, H.323, SIP, etc.)

136 135 Sincronización. Se tomara la referencia de tiempo desde un reloj externo. Por lo cual los equipos tendrán que tener entrada de reloj externo. Confiabilidad. Categoría Carrier Class. Redundancia en componentes críticos. Disponibilidad de tanto de hardware como de software. Resumiendo, los requerimientos para los diferentes equipos de la red son: LER: MPLS (optimizado par función de LER), Capacidad de Voz, ATM-IP InterNetworking, Interfase acordad para el enlace de transporte, Redundancia en componentes críticos. LSR: MPLS (optimizado para función de LSR), capacidad de Voz, Interfase de Fibra óptica además de la acordada para enlace de transporte. Capacidad de conmutar 1.6 Gbps según lo estableció en 9.I, Redundancia en componentes críticos. Softswitches: MPLS o IP, H.248, SIGTRAN, Capacidad de conmutación acorde a 9.I, entrada de reloj externo, Redundancia en componentes críticos y opcionalmente H.323 y SIP. Trunk Gateways: MPLS o IP, H.248, CODEC CELP G.729, G.711 ley A, VoIP, Interfases E1, entrada de reloj externo, Redundancia en componentes críticos y opcionalmente H.323 y SIP. Signaling Gateways: MPLS o IP, SIGTRAN, SS7 ISUP,Entrada de reloj externo, Redundancia en componentes críticos. Aplication Servers: MPLS o IP, CORBA, XML. OAM: MPLS o IP, CORBA. 9.VI-B.3 Comparación técnica Las hojas de datos de los equipos suelen tener distinto grado de detalle, por lo que puede ser necesario entrar en contacto con los proveedores de los mismo para tener un panorama completo antes de hacer la comparación. En este proyecto, esta etapa se vio limitada ya que los proveedores de equipos no suelen dar detalles de los mismos a menos que se trate de de una compañía, es decir de un cliente real. Esto fue discutido durante la etapa de especificación del proyecto, ya que se sabía que sería difícil conseguir más datos de los que están publicados. También es necesario tener en cuenta las pruebas de campo que cada equipo ha tenido, o si ha sido integrado en otras redes que ya están dando servicio. Este punto es necesario sobre todo con equipos de NGNs debido a la explosión de fabricantes de estos equipos y el poco nivel de implementación que han tenido estas redes hasta el momento. 9.VI-B.4 Comparación de costos. Este dato no se puede dejar de lado porque todo proyecto de ingeniería va atado a un plan de negocios. Este punto fue excluido del actual proyecto en su especificación inicial debido a la ausencia de un plan de negocios, que acompañe al mismo. También se hubieran tenido dificultades para conseguir precios reales (que son muy diferentes de los de lista) debido a la situación comentada en la sección anterior (9.VI-B.3). 9.VI-B.5 Elección final. Basados en los requerimientos, comparaciones técnicas y de costos hay que decidir los equipos a usar en cada parte de la red. Debido a las limitaciones de este proyecto discutidas anteriormente solo se mencionaran aquí algunos ejemplos (tomados de las tablas 9.XXIII a 9.XXVIII) que cumplan los requerimientos, sin tener en cuenta aspectos económicos o diferencias técnicas que no sean explícitas en las hojas de datos publicadas. LER: Cisco MGX 8250/8230 Lucent PacketStar PSAX 4500 Marconi ASX LSR: Alcatel 7470 MSP Marconi ASX Softswitches: Cisco BTS CopperComm Softswitch GNP Continuant Softswitch Alcatel 5000 Trunk Gateways: Alcatel 7670 Rapid 5 Networks RCP 700 Aplication Servers: No se especifica ya que generalmente son implementados por software instalado sobre servidores estándar. OAM: La elección del sistema de provisioning está fuera de las especificaciones de este proyecto.

137 136 CAPÍTULO 9. TRANSPORTE Y CONMUTACIÓN TABLA 9.XXIII COMPARATIVO DE VOICE/TRUNK GATEWAYS

138 137 TABLA 9.XXIV COMPARATIVO DE SOFTSWITCHES

139 138 CAPÍTULO 9. TRANSPORTE Y CONMUTACIÓN TABLA 9.XXV COMPARATIVO DE SWITCHES DE BACKBONE (PARTE I)

140 139 TABLA 9.XXVI COMPARATIVO DE SWITCHES DE BACKBONE (PARTE II)

141 140 CAPÍTULO 9. TRANSPORTE Y CONMUTACIÓN TABLA 9.XXVII COMPARATIVO DE SWITCHES DE BACKBONE (PARTE III)

142 141 TABLA 9.XXVIII COMPARATIVO DE SWITCHES DE BACKBONE (PARTE IV)

143 142 CAPÍTULO 9. TRANSPORTE Y CONMUTACIÓN

144 Capítulo 10 Diseño Resumen Se hace aquí un resumen del diseño y de la metodología utilizada para llegar al mismo. También se incluyen una breve descripción de la forma de implementar algunos de los servicios mas comunes. 10.I METODOLOGÍA PARA DISEÑO DE UNA RED El diseño de una red es un proceso que involucra una serie de pasos. Si bien parte de ellos deben respetar un orden de precedencia, otros pueden ser realizados en paralelo, e incluso algunos procesos necesitan ser realimentados por etapas posteriores. Se propone aquí una metodología que sirva de guía para afrontar el diseño de una red. A continucación se listan las etapas mas importantes del proceso. La relación entre las mismas se muestra en la Fig Estudio del marco regulatorio, legislación, proveedores existentes, frecuencias disponibles, posibilidades del uso de infraestructura existente. Relevamiento de las zonas de interés incluyendo: Cantidad de abonados, condición socioeconómica, posibilidades de crecimiento. Oferta de servicios de otros proveedores. Datos de tráfico telefónico. División en zonas con características similares (condición socioeconómica, densidad de habitantes, ofertas de servicios por otros proveedores, posibilidades de crecimiento, etc). Estimación de clientes a corto, mediano y largo plazo. Crecimiento y demanda futura de servicios. Elaboración del plan de negocios. Cálculo de requerimientos de tráfico/ancho de banda para satisfacer la proyección según el plan de negocios. Estudio de distintas tecnologías de acceso y elección de la misma. Estudio de distintas tecnologías de transporte y conmutación y elección de la misma. Estudio de sistemas de Provisión, Gestión y Contabilidad de servicios, elección del mismo. Evaluación de proveedores y equipamiento. Diseño y elección de equipamiento: Topología y estructura de la red. Ruteo y dimensionamiento de enlaces. Backup y contingencias. 10.II EJEMPLOS DE IMPLEMENTACIÓN DE SERVICIOS 10.II-A Telefonía Se instala un equipo IAD en el Cliente con la cantidad de canales y tipo de interfaces requeridas. Este equipo es configurado a nivel de IP y VoIP (direccionamiento IP, alias VoIP o numeración E.164, servidores de VoIP, fragmentación, priorización, QoS, etc). A nivel de ATM se establece un circuito virtual permanente (PVC) para este cliente (VPI/VCI); este PVC tendrá alcance local entre el DSLAM correspondiente y el LER. A nivel de MPLS se lo integra a una determinada VPN de voz 45. En la Fig se muestra un esquema de la topología mencionada. Fig II-B Internet Posible implementación de VoIP Para este tipo de Cliente se instala un equipo IAD o BRIDGE o ROUTER según el tipo de servicio a implementar. A nivel de ATM se establece el circuito virtual permanente (PVC) hasta el LER. Si es un cliente PPPoE (RFC 2516) la trama ethernet viajará encapsulada sobre MPLS hasta el BRAS correspondiente. A travéz de este BRAS obtendrá - previa autorización- el acceso a Internet. Si es un cliente que utilize direccionamiento estático se lo hace pertenecer a una VPN que termine en un GW de Internet destinado al servicio contratado. En la figura 10.3 se muestra la topología mencionada. 45 Si este es un cliente de voz y datos, se debe evaluar la conveniencia o no de establecer un nuevo PVC para los datos 143

145 144 CAPÍTULO 10. DISEÑO Fig Metodología de diseño propuesta.

146 145 Acceso: Luego de estudiar varias tecnologías se opto por ADSL haciendo unbundling físico del par de cobre del incumbente. Para esto se ubica en cada central del incumbente (donde se tenga presencia) equipos DSLAM y routers de borde en condición de coubicación. En el lado del abonado se instalan distintos equipos IADs de acuerdo a los servicios requeridos por cada cliente. Fig Posible implementación de accesos a Internet PPPoE y con direccionamiento estático 10.II-C VPNs Para establecer una red privada se instala en todos los sitios que pertenecerán a la VPN un equipo IAD, ROUTER o BRIDGE dependiendo de los servicios a brindar. Se establecen los PVC s ATM hacia los LER s correspondientes y se configuran los LER s involucrados para incluir todos los sitios en una VPN. Los posibles mecanismos para crear estas VPN s pueden verse en la sección 7.II. En la figura 10.4 se muestra la topología mencionada. Transporte y Conmutación: El transporte será fundamentalmente rentado, distinguiéndose la interconexión entre los NOCs donde lo que se renta es únicamente el medio físico (fibra óptica). El protocolo de trasporte elegido para el núcleo de la red es MPLS. Al optarse por una red NGN los elementos de conmutación son softswitches y Gateways, los cuales usaran los como protocolo principal H.248 aunque también podrán manejar H.323 y SIP. Estos equipos estarán duplicados en los NOCs, que se ubican en las inmediaciones de los POI con el incumbente. La señalización de esta interconexión será SS7 ISUP. Sincronización: El sincronismo tendrá como fuente principal dos relojes GPS ubicados en los NOCs. Los DSLAM s y routers de borde de la red, pueden derivan el reloj de la interfase por donde reciben los datos, por una referencia externa de reloj o por una E1 conectada a la PSTN, además de estas fuentes poseen una referencia interna. En el caso de estudio, puesto que el transporte será, rentado el clock será extraído del proveedor de transporte o de la PSTN. Operación y Mantenimiento: Se preverá que todos los equipos tengan CORBA como interfase común con este propósito. De este modo se podrá unificar toda la gestión en un único sistema de provisioning. Fig Posible implementación de VPN s 10.II-D Otros En caso de que el cliente requiera de otros servicios como enlaces punto a punto, emulación de circuitos, VLAN s, etc; se debe proveer de un equipo CPE con las interfaces adecuadas y configurar a nivel de MPLS la priorización y calidad de servicio necesaria. 10.III RESUMEN DEL DISÑO FINAL Para diseñar se separo la red en dos partes diferenciadas, Acceso y Transporte/Conmutacion. También se estudió, aunque con menor detalle, la sincronización y la Operacion/Mantenimiento.

147 Apendice A Comportamiento estadístico de los usuarios ESTE estudio se realiza con el propósito de plantear un escenario lo mas detallado posible de los requerimientos de los usuarios que tendrá la red a diseñar. Es así que en conjunto con el estudio demográfico de la zona de Montevideo y los niveles socioeconómicos de las misma, el comportamiento estadístico de los usuarios dará una idea mas acabada de que quieren, necesitan o se puede ofrecer a los posibles consumidores de servicios de telecomunicaciones en Montevideo. Se investiga entonces, sobre el comportamiento estadístico de los montevideanos y uruguayos, pero también de otras partes del mundo que podrían relacionarse por las características socioeconómicas de alguna de las sub-zonas definidas. Cabe aclarar que la gran mayoría de la información sobre este tema no se encuentra disponible en forma gratuita por lo que este estudio se ve opacado. Algunos datos relevantes de Montevideo y Uruguay PBI per capita 6036 dólares americanos (2000). Penetración de servicios Telefónicos Nro. Total de abonados de ANTEL en Montevideo (2001) Cantidad de habitantes en Montevideo (2001) Con lo cual se obtienen 39 teléfonos cada 100 habitantes en Montevideo. (2001). Penetración de Internet en Uruguay Servidores de Internet en Uruguay cada 100 habitantes 1.71 (2001) PC en Uruguay cada 100 habitantes 9.12 (1999) Índice de penetración de Internet en Uruguay 13 Hogares con T.V en Uruguay cada 100 habitantes 97 (1998) Fuentes : [92], [93], [94], [95]. Datos de Estados Unidos Estos datos son tenidos en cuenta como una cota superior, alcanzable en la zona que (por su nivel socioeconómico y densidad de población) se estima estará el mercado mas fuerte. Fuente: [96]. Datos de países pertenecientes a la OECD Se presentan aquí datos pertenecientes a la Organización para la Cooperación y Desarrollo Económico (OECD), formada por: Australia, Estado Unidos, México, Japón, Corea, y la mayoría de los países Europeos. Servicio Gasto (U$S) Penetración en los hogares (USA) Telefonía Local % Larga Distancia % TV Cable % Servicios telefónicos avanzados % Acceso a Internet % Paquetes premium de TV cable % Telefonía celular % TABLA A.I CONSUMO MEDIO MENSUAL (1998). En estos países los acceso de banda ancha están incrementando a un ritmo muy alto pasando de 3.1 millones de suscriptores a fines de 1999 a 22 millones para junio de La tecnología de mayor incremento ha sido la DSL. En la Fig. A.1 se presentan los datos correspondientes: Fig. A.1. Millones de usuarios con acceso de banda ancha. Se adjunta también aquí, un panorama de la penetración de tecnologías de Banda Ancha en los países de la OECD, ver Tab. A.II. Red de Televisión para abonados El mercado de la televisión para abonados tiene dos modelos bien diferenciados. Por un lado el modelo americano, también implementado en Latinoamérica donde hay un pago fijo por un paquete básico y luego pagos extras por paquetes premium y el modelo europeo donde no hay paquetes básicos y casi todos los programas se venden en la modalidad de pay per view. No se disponen de datos estadísticos de Europa y estados 146

148 147 unidos en cuanto a penetración de servicios de televisión de abonados. Estudio comparativo de penetración de telecomunicaciones e Internet en Latinoamerica País Teledensidad. Líneas c/100 hab. [92] Densidad de PC s c/100 hab. [93] Uruguay Argentina Brasil Chile Costa Rica México Puerto Rico Venezuela TABLA A.III Penetración de Internet.usuarios c/100 hab.[97] PENETRACIÓN DE TELECOMUNICACIONES EN LATINOAMERICA. Fuentes: [92], [93], [97]. En las Figs. A.2, A.3 y A.4 se muestran estos datos en forma gráfica. Fig. A.4. Densidad de PC s. Accesos a Internet a nivel mundial En la Tab. A.IV se presenta la penetración de Internet para algunos países significativos. Nro. de Internautas (millones) Estados Unidos % Japón 9.75 Inglaterra % Alemania % Canadá 6.49 Australia 4.36 Francia % Suecia % Italia % Taiwan 2.12 Corea 2.04 España % Holanda % China 1.58 Finlandia 1.57 TABLA A.IV ACCESOS A INTERNET A NIVEL MUNDIAL. Porcentaje de Hogares Fuente: [98]. Fig. A.2. Teledensidad. Fig. A.3. Penetración de Internet.