Converfim Modulo4

Módulo 4
Normalización de la
convergencia de
redes fijas e Internet
Módulo 4
Normalización de la convergencia de redes fijas e Internet
1. Introducción
En este capítulo se afronta uno de los mayores problemas que tiene la convergencia de
redes de fijo a móvil, siendo éste la estandarización de los servicios, de las redes, de los
terminales, etc. Para ello han existido, existen y existirán diversos organismos, comités
técnicos, grupos de trabajo, etc., cuyo único fin es el mencionado: alcanzar un consenso
para la estandarización. Dentro de estos organismos o comités se encuentra TISPAN
(Telecoms & Internet converged Services & Protocols for Advanced Networks),
perteneciente al ETSI (European Telecommunication Standards Institute, Instituto Europeo
de Estandarización de Telecomunicaciones).
Después del trabajo realizado por el 3GPP creando el protocolo SIP para IMS, TISPAN y
3GPP están ahora trabajando juntos para definir un núcleo tanto para redes inalámbricas y
cableadas. En este capítulo se analizará el trabajo que está realizando TISPAN, y sobre
todo su propuesta de redes de nueva generación (NGN, Next Generation Network). Es
imposible abarcar todas las estandarizaciones que se están llevando a cabo, e incluso
incorporar el último estándar, porque quizás se está publicando en el momento de leer estas
líneas. En este capítulo se tratará de dar una visión lo más amplia posible, pero evitando
perder el sentido de este capítulo. La información se puede complementar
exhaustivamente con los documentos adicionales que se adjuntan, así como con los
enlaces recomendados.
La novedad de los temas tratados en este curso conlleva el uso de un lenguaje bastante
técnico, repleto de siglas y de términos en inglés. La traducción de muchos términos puede
generar la pérdida del significado original de los mismos, o del concepto que se desea
transmitir. Desde este momento indicar, que no queda más remedio que usar muchos
términos tal cual se definieron, ya que es lo que se manejará en cualquier entorno en el que
se traten estos temas. Poca gente conoce lo que es el Sistema Global de Comunicaciones
Móviles, pero sin duda, cualquiera que esté leyendo este documento tiene (o quizás ha
tenido) un teléfono móvil GSM (Global System for Mobile communications). Con este
sencillo ejemplo se está justificando la aparición de ciertos anglicismos o siglas en los
párrafos siguientes.
1.1. ¿Qué es TISPAN?

En 2003, para ofrecer sinergias nuevas en el enfoque de ETSI respecto de la normalización
de NGN, se combinó el trabajo del Proyecto ETSI de armonización de protocolos entre
redes de telecomunicaciones e Internet (EP TIPHON™) y del comité técnico ETSI de
servicios y protocolos para redes avanzadas (SPAN) con un nuevo comité: Servicios y
protocolos combinados de Internet y telecomunicaciones para redes avanzadas. Se cerraron
TIPHON y SPAN y comenzó su andadura TISPAN.
TISPAN es una rama de estandarización de ETSI, especializada en la convergencia de

redes fijas e Internet. Tiene como primordial objetivo asegurar que los usuarios conectados
a las redes basadas en IP puedan comunicarse con usuarios en redes tradicionales de
circuitos tales como: PSTN, ISDN y GSM.
2/15
Módulo 4
TISPAN es el responsable de todos los detalles de estandarización (o normalización) para el

presente y futuro de las redes combinadas incluyendo las redes NGN, contemplando
aspectos de: servicios, arquitectura, protocolo, estudios de calidad del servicio (QoS),
estudios relacionados con la seguridad, aspectos de movilidad dentro de redes fijas,
utilizando tecnologías existentes y emergentes.
Entre las competencias principales de TISPAN se encuentra la definición de aspectos

generales de redes y servicios para todas las redes centrales y de acceso cableado, tanto
para redes nuevas como para las existentes. De igual manera define medios para proveer
servicios públicos de comunicación en entornos heterogéneos mediante la definición de un
medio genérico de creación de servicios que sea independiente de cualquier tecnología
específica de red subyacente y de si es red de circuitos o de paquetes. TISPAN se enfoca
en la entrega del mismo nivel de calidad y conectividad global de los nuevos servicios IP y
NGN que el que se recibe de la red de telefonía pública conmutada de hoy.
Esta tendencia de ALL IP (todo IP) tiene el potencial para proporcionar un nuevo modelo de
negocio para los operadores de redes fijas y móviles. El acceso independiente con IMS será
la clave para la convergencia fijo-móvil, reduciendo los costes de instalación y de
mantenimiento, permitiendo que nuevos servicios sean desarrollados y desplegados
rápidamente para satisfacer nuevas demandas del mercado.
La Figura 1 muestra el concepto de la convergencia de las redes mediante la actuación de

IMS. IMS es un sistema totalmente independiente del acceso, lo que permite un escenario
de desarrollo de servicios sobre IP y servicios Multimedia para usuarios conectados a través
de ADSL, WLAN, WIMAX, GPRS, UMTS, o cualquier otro acceso, lo cual posibilita la
convergencia, con el consiguiente beneficio para Operadores (nuevos servicios y sinergias
en las inversiones) y Usuarios (facilidad de uso y acceso al mismo servicios desde cualquier
terminal).
Figura 1. Esquema de la convergencia de tecnologías.
3/15
Módulo 4
La versión 1 (Release 1) de las NGN fue lanzada por TISPAN en diciembre de 2005,
proporcionando un estándar robusto y abierto que la industria puede utilizar como base
fiable para el desarrollo e implementación de los sistemas de la primera generación de las
NGN.
Actualmente se está trabajando en la Release 2, con el objetivo de mejorar la movilidad, los

nuevos servicios, la distribución de contenidos con una seguridad mejorada, así como la
gestión de la red.
TISPAN se estructura como un solo comité técnico, con competencias centrales, existiendo
ocho Grupos de Trabajo (Working Groups, WG) y Equipos de Proyecto. Los grupos de
trabajo tienen las responsabilidades específicas, competencias técnicas, y un programa de
actividades para alcanzar la consecución de los objetivos. Los equipos del proyecto son los
responsables de conducir el trabajo, estableciendo las temporizaciones y objetivos. Aunque
más adelante se tratarán los grupos de trabajo, de forma esquemática se muestra la
estructura de TISPAN en la Figura 2.
Figura 2. Estructura de TISPAN.
Descripción de las competencias centrales de TISPAN
• La definición de la red general y aspectos del servicio para las redes cableadas,
nuevas y existentes, así como los núcleos de dichas redes.
4/15
Módulo 4
• Definición del nivel de servicio entre las tradicionales redes de conmutación de

circuitos (SCN) - especialmente aquellas servidas por PSTN, ISDN o PLMN- y las
redes de nueva generación emergentes.
• Definición de los métodos para proporcionar servicios públicos de comunicación en
entornos heterogéneos, así como la creación de servicios independientes de
cualquier tecnología de red (conmutada o basada en paquetes).
• Definición de las capacidades del transporte de información, requerimientos de
señalización, diseño del protocolo, y las especificaciones de test asociadas.
• TISPAN tiene la experiencia y conocimiento en materias de consistencia entre redes
públicas y corporativas, fijas o móviles, asegurando que los estándares tengan en
cuenta los requerimientos reguladores, la seguridad, la interceptación legal de
comunicaciones, comunicaciones de emergencia, la calidad de servicio, facturación,
movilidad, los requerimientos del proveedor de servicio y la gestión de las redes de
telecomunicaciones.
• TISPAN debe proporcionar los mismos niveles de calidad y de conectividad global
en las redes de nueva generación y en los servicios IP, tal como se ofrecen
actualmente con las redes conmutadas de telefonía.
• Se debe garantizar el mantenimiento de los estándares vigentes.
Cooperación con otros organismos
Como es lógico, TISPAN no trabaja solo, sino que tiene en cuenta la cooperación con otros
organismos, tanto dentro como fuera de ETSI, para conseguir los objetivos de la
convergencia. A continuación se mencionan algunos de ellos:
• Provisión de las guías generales de actuación para otros cuerpos técnicos del ETSI
para asegurar el acercamiento al desarrollo de los estándares para redes públicas
incluyendo los requerimientos de las redes privadas.
• Cuerpo técnico primario para coordinar la posición del ETSI para los grupos de
studio de la IUT (especialmente los grupos de estudio 2, 4, 7, 11, 13, 16, 17).
• Cuerpo técnico primario para intermediar y colaborar apropiadamente con los
equipos de proyecto del CEPT/ECC.
• Intermediación y colaboración con la Unión Europea a través del OCG ECN&S
aplicando las directives correspondientes.
• Coordinar las posiciones de la ETSI en los aspectos de red en IETF.
• Mantenimiento de buenas relaciones con otros comités implicados, incluyendo: ITU-
T, 3GPP, IETF, ITU-R, ATM Forum, DSL Forum, Eurescom, MPLS Forum, MSF,
ETNO, ICANN y sus organizaciones de apoyo.
5/15
Módulo 4
1.2. Reflexiones sobre la necesidad de la convergencia

Nota: Extraído del congreso “Convergencia de medios”, Mayo de 2002.
La evolución tecnológica de los últimos años da lugar a que no se asocien de forma

indisoluble servicios y tecnologías. Esto supone que se debe plantear la neutralidad
tecnológica como necesaria para el correcto desarrollo de redes y servicios. Para ello la
regulación debe hacerse eco de la situación y crear un marco adecuado para alcanzar un
mercado lo suficientemente desarrollado. Se tendrá así una situación con una cadena de
valor diferente, con distintos tipos de operadores y éstos compitiendo en igualdad de
condiciones, con el consiguiente beneficio para los usuarios
Se está dando un doble fenómeno. Por un lado, la convergencia tecnológica que permite
que se presten servicios mediante varios soportes basados en distintas tecnologías y por
otro lado la convergencia que se está dando entre las distintas Tecnologías de la
Información y las Comunicaciones, como consecuencia de la digitalización.
La importancia de la digitalización se basa en varias razones:
1. Permite manejar de forma única toda clase de fuentes de información.
2. Permite una mayor flexibilidad y libertad en la incorporación de nuevos servicios.
3. Es más efectivo almacenar, procesar y, en general, manejar la información en formato

digital.
La importancia de la digitalización reside también en ser uno de los factores explicativos del
proceso de cambio que está teniendo lugar en lo que se refiere al desarrollo de la Sociedad
de la Información. Esto es así, ya que al permitir el tratamiento homogéneo de las señales,
ofrece también la posibilidad de utilizar los diferentes soportes (telefonía, cable, satélite,
televisión, móvil) para proporcionar acceso a toda clase de aplicaciones.
Esto nos lleva, por ejemplo, a la existencia de una convergencia de los terminales que hasta
hace poco no se daba. Así, ya no deberían contemplarse como plataformas destinadas a
distintos servicios terminales como la televisión y el ordenador personal, sino como
terminales genéricos o plataformas de usuario que permiten el acceso a los mismos
servicios.
Si echamos la vista atrás y contemplamos la situación de las telecomunicaciones hace

escasos años, podemos contemplar un panorama que en la situación actual nos resulta
sencillamente obsoleto. Ese panorama nos muestra escasos servicios de
telecomunicaciones prestados de manera indisoluble mediante una serie concreta de
tecnologías y redes.
Este “empaquetamiento” era el natural en una situación tecnológica que no ofrecía más
posibilidades que la utilizada para llegar a los usuarios y prestar los servicios. De esta forma,
la prestación de servicios estaba íntimamente ligada a la existencia de una determinada
6/15
Módulo 4
infraestructura y eran dos conceptos inseparables: la red que daba soporte físico y el
servicio de telecomunicaciones, ambos prestados por un mismo operador.
La evolución tecnológica ha traído consigo un paisaje muy diferente. Existe en la actualidad

una variedad de infraestructuras cuya manifestación más paradigmática está en las distintas
posibilidades existentes en cuanto al acceso.
Nos encontramos así, con el hecho de que los usuarios pueden disfrutar de una serie de
servicios independientemente de la tecnología que los soporte, como consecuencia de la
existencia de una serie de alternativas tecnológicas en lo que a las infraestructuras se
refiere, sobre las que se pueden prestar servicios de telecomunicaciones.
Pero la cuestión es, ¿Cómo nos afecta la convergencia?
Fundamentalmente a través de la convergencia en servicios, de manera que deja de tener

importancia la tecnología con que se presta un determinado servicio. Por ejemplo:
• Voz: mediante telefonía fija, telefonía móvil, telefonía sobre IP, redes de cable.
• Acceso a datos: a través del par de cobre, ADSL, redes de cable o televisión digital.
• Televisión: a través de redes de cable, radiodifusión analógica y digital terrenal o vía
satélite.
Por tanto, tenemos que acostumbrarnos a no identificar un determinado servicio o tipo de

negocio con una infraestructura o tecnología determinada, lo cual está íntimamente
relacionado también con la nueva estructura de la cadena de valor.
Con este panorama, debemos plantearnos la neutralidad tecnológica y las plataformas

tecnológicas móvil) para proporcionar acceso a toda clase de aplicaciones abiertas como
una necesidad para el correcto funcionamiento del mercado y un adecuado desarrollo de las
redes y servicios. Esto supone que también debemos afrontar un reto regulatorio.
La convergencia de los sectores de telecomunicaciones, medios de comunicación y

tecnologías de la información supone que todos los servicios y las redes de transmisión
deben estar sometidos a un único marco regulador.
Consideraciones a tener en cuenta desde la administración.
Desde la Administración, en el momento de abordar las necesidades regulatorias derivadas

de la convergencia, debe plantearse el tratamiento de las siguientes cuestiones:
• La estandarización.
La estandarización es necesaria como elemento que garantice la interoperabilidad de los

equipos. Conseguir estándares comunes a nivel mundial como ha ocurrido con GSM y
UMTS suponen una garantía de éxito y un aval de seguridad para las iniciativas
empresariales.
7/15
Módulo 4
• Los posibles escenarios de evolución de la convergencia tecnológica.
Hasta ahora sólo estamos imaginando el futuro en función de lo que suponemos serán las
ventajas de estos avances tecnológicos. Sin embargo, tenemos que plantearnos que entre
los posibles escenarios de evolución de la convergencia tecnológica, también puede llegar a
darse un estancamiento.
• Evitar la brecha digital.
La posibilidad de disponer de múltiples tecnologías con las que prestar los servicios, supone
una ventaja a la hora de plantearse la modalidad más adecuada a utilizar para llegar a los
ciudadanos. Además de la reducción de precios y costes que puede implicar la oferta
múltiple, los ciudadanos tendrán la posibilidad de no verse marginados en su acceso a la
Sociedad de la Información por la separación entre operadores de redes y operadores de
servicios, y la existencia de múltiples plataformas de usuario con las que acceder a distintas
prestaciones, que permitirán que las ventajas de la convergencia hagan que la brecha digital
vaya dejando de ser un obstáculo que pudiera llegar a marginar a determinados ciudadanos.
• El impulso de la banda ancha.
Desde la Administración se ha de impulsar sin titubeos el despliegue de aquellas

infraestructuras que permitan acceder a los servicios de la Sociedad de la Información con
anchos de banda adecuados.
Es una apuesta clara, para cuya consecución se deben tomar en consideración todas las
posibilidades tecnológicas, no descartando a priori ninguna de ellas.
• Impulsar la neutralidad tecnológica.
Es un hecho que paulatinamente van apareciendo distintas tecnologías que ofrecen

capacidades de transmisión adecuadas, lo cual hace que el esfuerzo regulatorio deba tener
en cuenta la necesaria neutralidad tecnológica, puesto que la convergencia produce un gran
abanico de posibilidades.
• Conseguir una situación de competencia efectiva.
Para lograr una mayor capacidad de elección y calidad en los servicios recibidos por parte
de los usuarios es necesario poner todos los medios a nuestro alcance para que el
desarrollo del mercado nos lleve a una auténtica competencia efectiva. Es la situación ideal,
y a ella contribuyen sin duda las nuevas expectativas que la evolución tecnológica depara.
Reflexión final
No se puede dudar de la importancia y beneficios de la convergencia para el desarrollo

económico. Pero la convergencia en cuanto que innovación supone la introducción de
nuevos productos, procesos y estructuras organizativas. Se diferencia del mero cambio
8/15
Módulo 4
tecnológico por incluir además cambios no exclusivamente tecnológicos y supone, en

definitiva, la difusión de la tecnología existente en cada momento.
La innovación tecnológica, el desarrollo tecnológico y la inversión, son factores cruciales

para la generación de riqueza. Es en este punto en el que debe hacerse notar con más
fuerza el papel de la Administración, en promover la existencia de las necesarias
condiciones (en cuanto a infraestructuras, fiscalidad, etc.) que permitan a las empresas
prestar servicios y a los usuarios hacer uso de los mismos.
Nos encontramos en un momento en el que las nuevas tecnologías de la información y las

comunicaciones son fundamentales para propiciar un profundo cambio social y juegan un
papel de gran importancia en el desarrollo socioeconómico de los países.
El carácter horizontal de las TIC está facilitando además que se produzcan a su vez,
muchos cambios en el proceso de innovación que, indudablemente, constituyen una ayuda
para conseguir que otros sectores económicos sean más innovadores.
La difusión e inversión en TIC ofrece un mayor potencial de crecimiento y mayores

beneficios, fundamentalmente cuando se combina con factores organizativos adicionales
(constituyendo así una auténtica innovación) tales como nuevas estrategias, nuevos
procesos de negocio, nuevas estructuras organizativas y mejores capacidades de los
trabajadores.
Así, las TIC son dinamizadoras de la economía con la virtud de que sus efectos alcanzan a
todos los grupos sociales.
1.3. Organismos vinculados a la estandarización

Ya ha sido expuesta anteriormente la necesidad de la estandarización, de forma que se
garantice la interoperabilidad de los equipos y los sistemas.
Diversos organismos y foros de estandarización están trabajando en aspectos relacionados

con la movilidad en las telecomunicaciones [Ref 1]. Organizaciones históricamente
conocidas por sus normas para comunicaciones no móviles, como IEEE o IETF, o de nuevo
cuño, como OMA, se unen a entidades tradicionalmente ligadas a la estandarización de las
tecnologías móviles, como ETSI y su proyecto 3GPP. Los distintos grupos colaboran,
desarrollando cada uno la parte del sistema que es su especialidad. Por ejemplo, el servicio
PoC sobre redes UMTS o GSM se basa en documentos de 3GPP, OMA e IETF.
En este apartado se resume sucintamente la actividad de de estandarización de algunos de

los grupos de normalización, desde el punto de vista de la evolución de las redes móviles
actuales y su confluencia con las redes fijas de datos y con otros tipos de accesos
inalámbricos, para llegar finalmente al organismo que más nos compete en este módulo, el
comité TISPAN de ETSI.
9/15
Módulo 4
Este barrido por los diferentes organismos ayudará al lector a tener una idea de las
actividades actuales en lo que a normalización y estandarización se refiere dentro del campo
de las comunicaciones.
3GPP
3GPP (3rd Generation Partnership Project) se encarga de la estandarización del sistema

móvil 3G. No tiene entidad legal siendo un proyecto común de diferentes socios. Entre sus
integrantes se encuentra la ETSI en Europa, ATIS en EEUU, ARIB y TTC en Japón, TTA en
Corea y CCSA en China.
La estandarización en 3GPP ha sido un proceso gradual, con continuas revisiones y

evoluciones, de manera que cada cierto tiempo se ha generado una nueva versión, estándar
o más conocido como release. La Figura 3 [Ref 1] muestra la evolución temporal y los hitos
fundamentales, desde la primera versión de la norma GSM (Fase 1).
Figura 3. Evolución de la estandarización GSM/UMTS.
En la Release 5 se presentó IMS (IP Multimedia Subsystem) y HSDPA (High Speed

Downlink Packet Access), estudiado ya en el capítulo anterior.
OMA
OMA (Open Mobile Alliance) es un organismo de estandarización creado en junio de 2002,

orientado a estandarizar servicios y aplicaciones móviles de manera independiente a la
tecnología de transporte y acceso. Participan los principales operadores móviles, fabricantes
de equipos de red y terminales, proveedores de servicios y contenidos, y compañías de
tecnologías de la información de todo el mundo. OMA consolida e integra diversos grupos:
WAP Forum, Location Interoperability Forum (LIF), SyncML Initiative, MMS-IOP (Multimedia
Messaging Interoperability Process), Wireless Village, Mobile Gaming Interoperability Forum
(MGIF) y el Mobile Wireless Internet Forum (MWIF).
El objetivo último y principal de OMA es garantizar la interoperabilidad extremo a extremo de

los servicios móviles, para lo cual OMA se centra en la especificación de una arquitectura de
10/15
Módulo 4
servicios con interfaces abiertas e independiente de la tecnología de redes móviles y sus

plataformas.
Para proporcionar esta interoperabilidad extremo a extremo, OMA se basa en los principios
siguientes:
• Proporcionar productos y servicios basados en estándares abiertos.
• Disponer de una arquitectura y unas tecnologías que posibiliten servicios

independientes del sistema operativo, de las tecnologías de acceso y de las
plataformas de red.
• Disponer de una capa de aplicación independiente de las capas de transporte.
• Proporcionar una interoperabilidad de servicios de manera transparente al usuario,

pudiendo emplear diferentes tecnologías y modos de acceso.
OMA dedica considerables esfuerzos a especificar pruebas de interoperabilidad extremo a

extremo y promueve eventos de pruebas de las tecnologías que desarrolla.
3GPP2
De forma similar a como se estableció 3GPP (3rd Generation Partnership Project) para la
estandarización de GSM y UMTS, la estandarización de los sistemas cdma2000 se realiza a
través de un proyecto de colaboración, sin entidad legal, que han establecido cinco
organismos de estandarización:
• ARIB, Association of Radio Industries and Businesses (Japón).
• CCSA, China Communications Standards Association (China).
• TIA, Telecommunications Industry Association (EE.UU.).
• TTA, Telecommunications Technology Association (Corea).
• TTC, Telecommunications Technology Committee (Japón).
También cuenta con dos representantes del mercado: The CDMA Development Group
(CDG) y el IPv6 Forum.
El trabajo de preparación de las especificaciones técnicas se divide entre cuatro TSGs

(Technical Specification Groups):
• TSG-A (Access Network Interfaces).
• TSG-C (cdma2000).
11/15
Módulo 4
• TSG-S (Services and Systems Aspects).
• TSG-X (Core Networks).
3GPP2 ha ido produciendo distintas versiones de las distintas modalidades del estándar
(1xRTT, 3xRTT, 1xEV-DO y 1xEV-DV), que están disponibles para su descarga gratuita en
el portal del proyecto (www.3gpp2.org).
IEEE 802
El IEEE 802 LAN/MAN Standards Committee desarrolla estándares para redes de área local
(LAN) y metropolitana (MAN), fundamentalmente para las capas más bajas del modelo OSI.
Los más conocidos son la familia 802.3 (Ethernet), Token Ring, y, más recientemente,
Wireless LAN. IEEE se organiza en grupos de trabajo (WGs) y sus miembros son personas
individuales, no compañías.
El estándar 802.11 ha dado pie a la explosión de las redes de área local inalámbricas,
denominadas comúnmente WLAN o WiFi. La Figura 4 recoge las revisiones fundamentales
del estándar 802.11. La variante 802.11a, en la banda de frecuencia de 5 GHz, no ha
alcanzado la misma popularidad al utilizar una banda que en algunas regiones no esta
liberada.
Figura 4. Revisiones más relevantes del IEEE 802.11
12/15
Módulo 4
IETF
IETF (Internet Engineering Task Force) se define como un grupo de individuos dedicados a
la evolución de las tecnologías de Internet. No tiene miembros ni cuotas, cualquier persona
puede participar en sus reuniones. El producto de IETF son estándares, denominados RFC
(Request For Comments), que recogen especificaciones relacionadas con Internet. Por
ejemplo, IP, TCP, SMTP, PPP y ARP aparecieron como RFCs. De ellos, los denominados
Internet Standards forman el subgrupo de documentos esenciales para el funcionamiento de
Internet.
Actualmente, la orientación hacia arquitecturas “todo IP” (ALL IP) a que se tiende en el
mundo de la telefonía móvil trae consigo la reutilización de protocolos IETF.
En particular, SIP (Session Initiation Protocol) es la base del subsistema IP multimedia (IMS)
de 3GPP. Además, existen casi cien referencias a RFCs o internetdrafts en las
especificaciones 3GPP, entre las que destacan las siguientes:
• Diameter. Es un protocolo que proporciona un marco de autenticación, autorización y

registro de uso (Authentication, Authorization and Accounting, AAA) para
aplicaciones de acceso a redes, movilidad en redes IP y roaming. Diameter es
compatible con Radius. Se compone de una especificación base más una serie de
especificaciones dependientes de la aplicación. Diameter se utilizará en las redes
móviles 3GPP para autenticación en IMS, charging de IMS prepago e interacción con
WLAN.
• SIP (Session Initiation Protocol). Es un protocolo de señalización de la capa de

aplicación que permite crear y gestionar sesiones con uno o más participantes. Estas
sesiones pueden ser llamadas de voz, multimedia, streaming, etc. SIP se basa en los
nodos denominados servidores proxy para enrutar, gestionar la autenticación y
autorización, y proveer los servicios. En 3GPP, SIP se ha adaptado ligeramente y es
la base del subsistema IMS. Además del protocolo básico, múltiples RFCs e internet-
drafts de IETF que extienden las funcionalidades de SIP se utilizan en 3GPP,
principalmente para los servicios de presencia IMS.
• EAP (Extensible Authentication Protocol). Define un marco de autenticación

directamente sobre capas de enlace, WLAN por ejemplo, sin necesitar IP. Diameter
se implementa sobre EAP para permitir la autenticación en una red 3GPP a través de
un acceso WLAN.
13/15
Módulo 4
UIT
La UIT (Unión Internacional de Telecomunicaciones) forma parte de la red de

organizaciones internacionales de las Naciones Unidas. Establecida en 1865 para facilitar el
desarrollo internacional del telégrafo, su funcionamiento se basa en la cooperación entre el
sector privado y los estados. Sus miembros son gobiernos, organismos reguladores,
fabricantes y operadores.
Las comunicaciones móviles de tercera generación reciben en la UIT el nombre de IMT-

2000. Las actividades de la UIT en IMT-2000 abarcan la normalización internacional, que
incluye el espectro de radiofrecuencias y la especificación de la red de acceso radio y
troncal, la tarificación y facturación, y los estudios sobre aspectos de reglamentación y
política. IMT-2000 cubre tanto comunicaciones móviles terrestres como por satélite.
Desde el punto de vista del acceso, IMT-2000 es un intento de armonización a escala

mundial, con el resultado de una familia de sistemas de acceso radio. El proyecto IMT-2000
fue un importante acicate para el desarrollo de sistemas 3G, ya que diferentes organismos
de estandarización regionales enviaron a la UIT propuestas que luego fueron desarrolladas
en detalle en los distintos foros, como se muestra en la Figura 5.
Figura 5. Propuestas 3G dentro del proyecto IMT-2000.
Dentro de la UIT, los accesos radio IMT-2000 se normalizan en la recomendación UIT

M.1457. Aprobada en el año 2000, la UIT ha producido sucesivas revisiones para incluir la
funcionalidad que los foros de estandarización han añadido a sus especificaciones. La
M.1457 no especifica los accesos radio en detalle, esto sería imposible en un solo
documento. En su lugar proporciona una lista de referencias a las especificaciones
originales
14/15
Módulo 4
ETSI
El Instituto Europeo de Estándares de Telecomunicación (ETSI, European

Telecommunications Standards Institute) es una organización independiente y oficialmente
responsable en Europa de la estandarización en los campos de las tecnologías de la
información y las comunicaciones; sus miembros son fabricantes, operadores y
administraciones de todo el mundo. Los desarrollos sobre radiocomunicaciones en ETSI
incluyen éxitos como DECT, TETRA y GSM, responsabilidad este último durante varios años
del comité SMG para finalmente pasar el testigo al proyecto 3GPP del que ETSI es socio.
TISPAN, como ya se ha comentado anteriormente, es el grupo de ETSI dedicado a la

estandarización de servicios y redes fijas, en particular en lo que se refiere a la evolución de
redes de circuitos a redes de paquetes. Además, TISPAN es responsable de la
convergencia de redes en ETSI y es el grupo que centraliza el trabajo en NGN (Next
Generation Networks).
Una de las tecnologías estudiadas para las NGN es el subsistema IMS estandarizado por
3GPP. IMS tiene como requisito en 3GPP la independencia de la red de transporte; es decir,
un operador podría ofrecer servicios a sus suscriptores independientemente de cómo estos
hayan obtenido su acceso a una red IP (UMTS, WLAN o línea fija). Un sistema diseñado de
esta forma es atractivo para los operadores de red fija, y TISPAN y 3GPP han comenzado a
analizar los aspectos prácticos de la teórica viabilidad del IMS 3GPP para este entorno.
Algunos de los aspectos que necesitan clarificarse son las diferentes definiciones de las
clases de servicio entre las redes fijas y móviles, la necesidad de la tarjeta SIM o
equivalente, los codecs o el soporte a IPv4. La colaboración entre IETF y 3GPP, las redes
fijas y las móviles, se repite ahora con TISPAN.
15/15
Módulo 4
2. Grupos de trabajo de TISPAN

2.1. Estructura de TISPAN
TISPAN está estructurado como un solo comité técnico, con competencias centrales bajo las
cuales existen Grupos de Trabajo (Working Groups) y Equipos de Proyectos (Project
Teams) tal como se refleja en la Figura 6.
8 Grupos
Proyectos
de trabajo
WG1. Servicios
(EMergency TELecommunication)
DTM (Dynamic asynchronous

Telecom Equipment Identity
OSA (Open Service Access)

WG2. Arquitectura
Tispan_NGN
Transfert Mode)
WG3. Protocolos
WG4. Numeración y
EMTEL
F-MMS
encaminamiento
WG5. Calidad del
servicio
WG6. Test
WG7. Seguridad
WG8. Gestión de red
Figura 6. Estructura de TISPAN.
Los grupos de trabajo son: WG1 (Servicios), WG2 (Arquitectura), WG3 (Protocolos), WG4
(Numeración, Direccionamiento y Encaminamiento), WG5 (Calidad de Servicio), WG6
(Test), WG7 (Seguridad) y WG8 (Gestión de red). Los Grupos de Trabajo tienen
responsabilidades centrales específicas, competencias técnicas y un programa de
actividades para reunir sus objetivos.
Aunque hay varios proyectos en curso, el más relevante es la definición de las redes de
nueva generación, NGN. Las NGN serán estudiadas en detalle más adelante.
17/33
Módulo 4
2.2. Grupos de trabajo

A continuación se describen las funciones más relevantes de los grupos de trabajo antes
indicados. Para ello, por cada grupo se definen sus responsabilidades y sus actividades.
También se indica si mantienen colaboración con otros comités.
2.2.1. WG1: Servicios
Responsabilidades
• Dirigir los estudios que llevan a realizables la nueva generación de servicios y

aplicaciones (desde la perspectiva del usuario);
• La coordinación y preparación de las descripciones del servicio para las NGN,

incluyendo:
o Los servicios de tiempo real inter-personales
o El video (bajo demanda, streaming, uni-transmisión, múltiple transmisión),
o Los datos (Almacenamiento, procesos) y mensajes
o Multimedia y comunicación de grupo
o Diferentes segmentos de mercado y comunidades.
• Identificación de los requisitos genéricos funcionales de las NGN para apoyar el

funcionamiento de servicio
• La coordinación y preparación de descripciones de intercambio para el servicio con

otras redes fijas (PSTN, ISDN, etc.) y con redes móviles teniendo en cuenta los
requisitos para la provisión del servicio
• Coordinación de las áreas de trabajo descritas dentro de ETSI y las relaciones con
comités externos;
• Proporcionar apoyo a otros comités técnicos del ETSI, con contribuciones a ITU-T
(como ejemplo: SG 2; SG 12, SG 16)
Actividades
• Estandarización de las descripciones de servicio desde la perspectiva del usuario,

para las redes bajo la responsablidad de los servicios NGN.
18/33
Módulo 4
• Preparar las descripciones de interrelación para el servicio de intercambio entre las

distintas redes.
Colaboración con otros organismos
• Dentro del ETSI: TC AT and TC HF, EP TETRA
• Dentro del 3GPP (en particular SA TSG)
• Con ITU-T SG2 (servicios), SG12 (Aspectos de la calidad del servicio), SG 16

(Proyecto Mediacom 2004)
• Con las actividades relacionadas del IETF
2.2.2. WG2: Arquitectura
Responsabilidades
• Inteligencia de la red, Movilidad universal personal y de terminales, arquitecturas de

NGN y requisitos funcionales y arquitecturas para el entorno del hogar; definición y
uso de una arquitectura funcional global. Hay que tener en cuenta que el 3GPP es el
responsable de la movilidad de terminales, siendo por tanto necesaria la cooperación
con el mismo.
• Actividades de desarrollo de normas relacionadas con la arquitectura de red y su

evolución, incluyendo interrelaciones y aspectos IP en el servicio, transporte y
control.
• Estudios en las funciones, y los puntos de la referencia requeridos para la

interrelación entre la nueva arquitectura de red emergente y las redes heredadas (IN
/ ISDN / PSTN).
• Definición y análisis de Entidades Funcionales, Sucesiones del Mensaje y Elementos

de Información.
• Responsabilidad para la extensión del Meta-protocolo de TIPHON
• Estudios de los requisitos funcionales de los proveedores del servicio para acceder a
las redes de PTNOs, para el cumplimiento de las directivas de la Unión Europea de
acceso a redes especiales; incluyendo los interfaces funcionales de las APIs para el
servicio a terceras partes.
19/33
Módulo 4
• Estudios en el campo de los sistemas de movilidad de tercera generación (ej.: IMT-

2000 y UMTS) incluyendo las interrelaciones con las redes IP existentes y
emergentes
Actividades
• Estudio de la evolución de las arquitecturas de red motivadas por las NGN, los
nuevos requerimientos del mercado y la consideración de las nuevas tecnologías.
• Definir el impacto de las interfaces ya estandarizadas
• Identificación de la necesidad de puntos de referencia e interfaces estandarizadas
• Identificación de las capacidades funcionales requeridas para desarrollar un servicio

independiente de la arquitectura, así como la definición de una terminología
apropiada, incluyendo ejemplos de flujo de información (Message Sequence Charts).
• Análisis y comparación de los requerimientos de protocolo, secuencias de mensajes

y definición de los elementos de información y de los Meta-procolos.
• Proporcionar una arquitectura para los entornos de las NGN, suportando:
o Los servicios multimedia de nueva generación, los múltiples flujos de datos y

los puntos finales.
o Interacción e integración con redes de acceso IP.
o Otros aspectos como las redes domésticas, UMTS, IPCablecom, etc.
• Definición de arquitecturas funcionales inteligentes, teniendo en cuenta los

desarrollos relacionados en estándares para redes fijas y móviles ((UMTS, H.248,
H.323, MSF, ISC…) para habilitar la convergencia.
• Desarrollo de requerimientos en áreas de trabajo, incluyendo: arquitectura del

trabajo, seguridad, acceso a servicios abiertos, garantía de la calidad, mecanismos
de red, y aspectos de red para la movilidad de personas y terminales.
• Definición de los requisitos de control del servicio, incluyendo OSA APIs
• Estudio del impacto de la interrelación entre diferentes tipos de red que están
evolucionando independientemente. Identificar la necesidad de entidades funcionales
y de los puntos de referencia para soportar nuevas interfaces y protocolos.
• Estudios de la introducción y evolución de estrategias para la inteligencia en redes.
• Especificación de requerimientos adicionales incluyendo los parámetros de carga y

las técnicas de encaminamiento para la interrelación entre servicios y redes.
20/33
Módulo 4
• Cooperación con otros cuerpos de estandarización con actividades en áreas

relacionadas, incluyendo: 3GPP SA; ETSI TC LI; ETSI TC AT; ERM; ITU-T SG11,
ITU-T SG13, ITU-T SSG-IMT2000, ITU-T SG16; ITU-T SG9; grupos relevantes del
IETF (ej: PINT, SPIRITS, MIDCOM, IP-Sec, etc.), MSF.
2.2.3. WG3: Protocolos
Responsabilidades
• Definir todos los aspectos relacionados con los protocolos: definición de protocolo,
requerimientos, mapeado, perfiles, análisis de otros protocolos desarrollados por
otros comités, extensión de protocolos y especificaciones de interrelación.
Actividades
• Adaptación de los protocolos de final a final (end to end) y las extensiones para
redes, incluyendo: SIP , SIP-T, BICC, PSTN/ISDN etc.
• Adaptación y estandarización de los protocolos del control de recursos para redes

(núcleo, acceso y terminales), incluyendo los protocolos MEGACO / H.248, etc.
• Adaptación y estandarización de los protocolos de control de portadora para redes

(núcleo, acceso y terminales), incluyendo MPLS, H.245, etc.
• Estandarización e interrelación para el servicio de control de protocolos, incluyendo,

pero sin limitar, la especificación de APIs, mapeado en el nivel de servicio de APIs
para los accesos a servicios abiertos.
• Estandarización de los protocolos de los modos de transferencia, incluyendo pero no

limitado a: DTM, etc.
• Estandarización de los protocolos de transporte entre nodos, incluyendo:
o Adaptación y estandarización del transporte de la señalización fiable,

incluyendo SCTP, etc.
o Estandarización de los mecanismos de transporte en el nivel de usuario
• Consideración y estandarización de los aspectos de seguridad relacionados a la

señalización y los protocolos de transporte de usuario.
21/33
Módulo 4
• Consideración del impacto de los protocolos:
o en NAT (Network Address Translation) y ENUM (Enhancement of Numbering

and Naming) en el contexto del acceso y seguridad de redes para terminales
y firewalls.
o Para direcciones de red y las políticas de interpretación de nombres
o Para los requerimientos legales
o Para proveer el nivel adecuado de calidad del servicio
• Evolución de las redes ISDN/PSTN para la interoperabilidad de los servicios de

redes fijas y móviles.
• Mantenimiento de protocolos existentes desarrollados por TISPAN, TIPHON, SPAN,

SPS, NA, BTC, etc.
• Cooperación con otros comités del ETSI y otros comités de estandarización en áreas
relacionadas, como por ejemplo: ITU-T SG9, SG11, SG16, ANSI, IETF, MSG, MSF,
3GPP.
2.2.4. WG4: Numeración y encaminamiento
Responsabilidades
• Realización de estudios en numeración, nombres, direccionamiento y

encaminamiento.
• Coordinación de las áreas de trabajo del ETSI y proporcionar apoyo para las
contribuciones al ITU-T SG2.
• Direccionamiento y traducción de nombres.
• Representación del ETSI en el ENF (European Numbering Forum).
• Colaboración con ERO (the European Radio Office) en los aspectos de numeración,
nombres y direccionamiento europeos.
• Representación del ETSI en el comité directivo del ETNS.
22/33
Módulo 4
• Todos los comités relevantes del ETSI, ETO, ENF y ITU-T SG2.
2.2.5. WG5: Calidad del servicio (QoS)
Responsabilidades
• Conducir estudios en los siguientes campos:
o Parámetros de la calidad del servicio, objetivos y métodos de medida.
o Determinación de los requerimientos de los protocolos necesarios para

asignar y gestionar los recursos de red para cumplir los objetivos de calidad
del servicio.
o Coordinación con otros comités relacionados del ETSI
Actividades
• Aplicaciones usuario-usuario en la capa de aplicación.
• Parámetros de la calidad del servicio y objetivos asociados para los componentes de

los servicios multimedia, así como su aislamiento y combinación.
• Los requerimientos de funcionamiento de los terminales dirigidos a soportar los

servicios multimedia.
• Métodos de medida para identificar los parámetros de la calidad del servicio.
• Cooperación y coordinación con otros comités del ETSI, 3GPP, ITU-T (en particular
SGs 2, 4, 11, 12, 13 & 16) e IETF.
23/33
Módulo 4
2.2.6. WG6: Test
Responsabilidades
• Dirección y coordinación del desarrollo de especificaciones de test para la telefonía

de nueva generación.
• Proporcionar especificaciones de test y perfiles para las especificaciones aprobadas

por TISPAN.
• Mantenimiento de las especificaciones de test existentes
• Seguimiento a nivel mundial de las actividades de interoperabilidad, testado y

certificación de interés para TISPAN
Actividades
• Elaboración de tests de conformidad para las especificaciones de TISPAN
• Asistencia a otros grupos de trabajo de TISPAN para el desarrollo de

especificaciones.
• Elaborar las especificaciones de test de interoperabilidad entre los protocolos de

TISPAN, y otros con los que pudiera operar.
• Mantenimiento de los tests de especificación de TISPAN según se requiera.
• Proporcionar realimentación y un enlace estrecho con otros grupos de trabajo de

TISPAN, especialmente con el de protocolos.
• Promover las actividades de test en entornos de certificación.
Cooperación con otros comités de estandarización trabajando en áreas similares o

relacionadas, tal como: MTS, 3GPP, ITU, ECMA, IETF, etc.
24/33
Módulo 4
2.2.7. WG7: Seguridad
Responsabilidades
• Conducir estudios que lideren los objetivos en seguridad.
• Gestión y coordinación de desarrollos de las especificaciones de seguridad para la

telefonía de nueva generación y las comunicaciones multimedia.
• Investigación de los servicios de seguridad y los mecanismos requeridos para

proporcionar dichos servicios en Internet.
• Desarrollo de análisis de seguridad para los protocolos candidatos y los elementos

de la red para ser usados en la NGN.
• Seguimiento a nivel mundial de las actividades de seguridad de interés para TISPAN
Actividades
Las actividades más relevantes que ha asumido este grupo se detallan a continuación:
• Determinar y documentar los objetivos y prioridades para la seguridad de TISPAN

teniendo en cuenta las necesidades y aspiraciones de los usuarios, operadores,
reguladores y fabricantes.
• Acomodar, en cuanto sea posible, las regulaciones regionales, fundamentalmente las

relacionadas con datos personales y la privacidad.
• Detallar los requerimientos de seguridad que TISPAN incluye para usuarios y

servicios, facturación, contabilidad, mantenimiento, y control del fraude.
• Detallar los requerimientos de seguridad que TISPAN incluye para los elementos
físicos, incluyendo el acceso a red, el núcleo de red; sus interfaces y el legado de
redes y terminales.
• Definir una arquitectura de seguridad para TISPAN que concuerde con la

arquitectura del sistema.
• Generar especificaciones para:
25/33
Módulo 4
o Todos los elementos de seguridad del sistema.
o Las operaciones y la gestión de la seguridad de los elementos.
o Cualquier algoritmo criptográfico necesitado para la seguridad de los

elementos.
• Asegurar la disponibilidad de algoritmos criptográficos para las especificaciones

comunes.
• Definir cómo las especificaciones para la seguridad de los elementos son integradas
en los accesos a red, en el núcleo de red, en los terminales y otras especificaciones
relevantes producidas por las NGN, y asistir en las tareas de integración.
• Detallar los requerimientos para la intercepción legal en TISPAN, y producir todas las
especificaciones necesarias para alcanzar esos requerimientos. Este trabajo se hará
en concordancia con otros comités técnicos.
• Producir guías del uso de los elementos de seguridad de TISPAN, así como de las
limitaciones, y las implicaciones que son proporcionadas.
Adicionalmente, los servicios de seguridad y los mecanismos para proporcionar servicios

sobre Internet continuarán siendo investigados. También se investigará los mecanismos de
seguridad para las redes de interés. A título de ejemplo:
• Aplicaciones sobre Internet
• Aplicaciones sobre redes IP privadas
• Redes ATM
• Ethernet
• ISDN/PSTN sobre ATM
• ISDN/PSTN sobre IP
• ISDN/PSTN sobre SDH
• Redes MPLS
• SDH y SDH de nueva generación
Es importante tener en cuenta que la seguridad para redes abiertas y la interoperabilidad es

un desafío. La protección de la privacidad del usuario es un aspecto muy significativo
también. Soluciones para la protección de la información como el número de teléfono en
PSTN/ISDN no son trasladables fácilmente, por ejemplo, a redes abiertas basadas en el
protocolo SIP, donde participantes “no fiables” pueden directamente recibir la señalización
SIP.
26/33
Módulo 4
Enlaces podrían ser establecidos con los siguientes comités: 3GPP TSG SA3, ETSI SAGE, ETSI
OCG Security, ETSI TC LI; además de otros, según se requiera.
2.2.8. WG8: Gestión de red
Responsabilidades
• Desarrollo de una aproximación consistente a la gestión de las telecomunicaciones

entre todas las disciplinas y tecnologías dentro de las actividades de estandarización
del ETSI.
• Gestión de todos los tipos de equipos de telecomunicación, redes y servicios.
Actividades
• Analizar las necesidades de la gestión de las redes de telecomunicación; definir y

producir estándares y especificaciones según se requiera para los servicios,
tecnologías y participantes.
• Prevenir la duplicación de esfuerzos y de conflictos, concentrando la gestión de las

telecomunicaciones en un grupo.
• Proporcionar tecnología orientada a proyectos del Comité Técnico, teniendo en

cuenta las necesidades de gestión de red de forma oportuna.
• Usar los recursos disponibles de gestión de las telecomunicaciones.
• Animar al intercambio de expertos en esta materia entre este grupo y otros proyectos
dentro de TISPAN.
Entre los mismos destacan: ITU-T SG4, ITU-T SG15, 3GPP, ECMA TC32, ANSI T1M1,
IETF, TeleManagement Forum, EURESCOM y ATM Forum.
27/33
Módulo 4
3. Redes de NGN. El concepto.

Las redes de nueva generación (NGN) se pueden considerar como el camino a seguir para
alcanzar la convergencia, siendo IMS la clave para el éxito de estas redes [Ref 2]. En este
apartado se realiza una introducción general al concepto de las NGN, exponiendo las
características fundamentales de IMS. Respecto a IMS, con el objetivo de que este apartado
sea auto-contenido, se repetirán algunos conceptos ya estudiados en el módulo anterior,
aunque de una forma más divulgativa. En el capítulo siguiente se realizará una descripción
más detallada de la propuesta que TISPAN hace para las NGN.
Automatización, digitalización, RDSI, conmutación de paquetes, integración voz y datos, IP,

nueva generación de redes, IMS, convergencia... la evolución de los servicios y de las
tecnologías de las telecomunicaciones ha sido habitualmente señalizada por uno o varios
términos, acrónimos, que sintetizan bien en términos sociales y en el de las claves técnicas
las diferentes etapas de esta evolución.
Las aproximaciones que con frecuencia se hacen de estos conceptos o de sus factores
técnicos claves, tanto en su impacto social como incluso en su más pura consideración
técnica son a veces dispares o al menos se mueven dentro de una gran gama de matices en
sus fases iniciales. Estas aproximaciones finalmente tienden a alinearse en torno a los
conceptos que poco a poco terminan decantándose desde unos marketings cada vez más
agresivos.
Si hay en estos días unos términos que definen el momento, la situación actual del entorno
de las telecomunicaciones son NGN: la siguiente generación de redes; e IMS: Internet
Multimedia Subsystem.
Existen distintas aproximaciones más o menos certeras, más o menos interesadas del
concepto NGN. Toda la industria, todos los operadores tienen referencias, y habitualmente
las mejores, en NGN...
NGN no es sino un modelo de arquitectura de redes de referencia que debe permitir

desarrollar toda la gama de servicios IP multimedia de nueva generación (comunicaciones
VoIP nueva generación, videocomunicación, mensajerías integradas multimedia, integración
con servicios IPTV, domótica, etc...) así como la evolución, migración en términos mas o
menos de sustitución o emulación de los actuales servicios de telecomunicación.
Como probablemente se sabe este modelo de referencia puede sintetizarse en el siguiente

decálogo de puntos:
• Arquitectura de red horizontal basada en una división diáfana de los planos de

transporte, control y aplicación
• El plano de transporte estará basado en tecnología de conmutación de paquetes

IP/MPLS
28/34
Módulo 4
• Interfaces abiertos y protocolos estándares
• Migración de las redes actuales a NGN
• Definición, provisión y acceso a los servicios independiente de la tecnología de la

red (Decoupling Access and Services)
• Soporte de servicios de diferente naturaleza: real time/ non real time, streaming,
servicios multimedia (voz, video, texto )
• Calidad de servicios garantizada extremo a extremo
• Seguridad
• Movilidad generalizada
La materialización de este concepto y la visibilidad de las tecnologías que permiten su

soporte, progresivamente disponibles desde hace algunos años, dependen
fundamentalmente de la situación y estrategia de cada operador en cada mercado.
Quizás se pueda simplificar y establecer dos grandes marcos de actuación, en estos años,
en torno al concepto de NGN:
• En mercados en expansión, en crecimiento en servicios básicos de

telecomunicación, donde se “simulan” o “emulan” redes y servicios tradicionalmente
de circuitos optimizando el escenario técnico-económico hasta ahora habitual
mediante el uso de NGN-SoftSwitches, transporte IP e interfaces de banda estrecha /
banda ancha para el soporte de servicios de voz.
• En mercados consolidados en términos de servicios fijos – móviles donde la

búsqueda de sinergias, eficiencias entre ambos mundos y la banda ancha y los
nuevos servicios IP multimedia hacen que NGN e IMS, (Internet Multimedia
Subsystem, conjunto de elementos funcionales que configuran el plano de
control de este modelo de referencia) adquieran un papel fundamental como ejes
del desarrollo de la convergencia.
De forma clara el desarrollo de los conceptos NGN e IMS, en este último marco de
actuación, debería permitir pasar de un modelo de redes verticales, específicas por gama de
servicios, a un modelo horizontal de red unificada soporte de toda la gama de servicios
multimedia imaginable. Debería permitir el desarrollo de un modelo convergente de redes y
servicios en torno al cual se consoliden los modelos de negocio de los Operadores Únicos
Integrados. La Figura 7 muestra el modelo de las NGNs, en el que se ubican las distintas
tecnologías y servicios.
29/34
Módulo 4
Figura 7. Modelo de NGN.
El por qué “NGN-IMS” pueda ser el conductor del desarrollo de la convergencia requiere un
repaso también de aspectos claves:
• Se denomina IMS “IP Multimedia Subsistema”, al subsistema de control, acceso y

ejecución de servicios común y estándar para todas las aplicaciones en el modelo de
arquitectura de nueva generación, capa de control de una red de nueva generación.
• IMS permite controlar de forma centralizada y deslocalizada el diálogo con los

terminales de los clientes para la prestación de cualquiera de los servicios (voz,
datos, video, etc.) que estos requieran.
El modelo IMS se basa en tres ejes fundamentales que pueden asegurar su éxito:
1. Uso de las tecnologías de la información, se adoptan los protocolos del

mundo Internet SIP (HTTP, etc...), se integran las comunicaciones personales
(voz, mensajería, etc...) con las aplicaciones IT. Se aprovecha así la mayor
capacidad y flexibilidad de estos protocolos para la prestación de todo tipo de
servicios multimedia y desarrollo de nuevas aplicaciones.
2. Se requiere sólo conectividad IP del cliente y por tanto inherentemente

supone la convergencia de accesos fijos y móviles definiéndose IMS como
“agnóstico” al tipo de acceso, siempre que éste sea banda ancha.
30/34
Módulo 4
3. Movilidad generalizada, movilidad entre diferentes accesos de un mismo

operador incluyendo el mantenimiento de las comunicaciones en itinerancia,
la movilidad entre redes (deslocalización) y movilidad del cliente y sus
aplicaciones entre diferentes terminales (móvil, PDA, PC, etc.). Se hereda
además los valores de control de movilidad, localización y accesibilidad
propios de las redes móviles.
Sin duda el grado de expectativa generado por IMS en el sector de las telecomunicaciones
parece responder a la visión del cambio que en general puede suponer en la mayor parte de
los mercados y operadores, visión que se soporta en una simbiosis de valores para el
operador y para el cliente:
• Para el operador: el cliente está suscrito al dominio del operador que controla bajo
perfiles de suscripción el acceso de éste a cualquier aplicación (SIM-Dominio-
Operador) esté o no en su red. Se traslada el concepto de dominio de aplicación
(ISP) al concepto de operador de Telco. Se potencia así la visión del cliente de
operador = servicio frente a operador = red / acceso.
Al potenciarse esta relación el operador fortalece su posición frente a terceros

(incluidos ISPs) que quieran acceder a sus clientes finales ofertando a éstos la
posibilidad de acceso a clientes, y/o a las capacidades de servicios de su red.
• Para el cliente: movilidad, localización y accesibilidad garantizada, acceso a los

mismos servicios siempre bajo la mejor opción de conexión (Always Best connected)
en función de preferencias de usuario, coste o de ancho de banda requerido,
tarificación simple y flexible que le permita control de gasto y dotando a estas
comunicaciones de valores propios como QoS, seguridad, fiabilidad y alta
disponibilidad de las redes Telcos.
Parece así que IMS es la pieza clave, ya que debe ser el CATALIZADOR de la
convergencia:
• IMS no es una red, no ofrece servicios finales, es el embrión a partir del cual se
definen:
o las identidades de usuario (dominio)
o los requerimientos a los diferentes tipo de acceso para su control común
o los requerimientos a los terminales y clientes SIP para su convergencia
o los habilitadores o capacitadores de servicios comunes a los servicios
o el diseño de los servicios finales
o las interfaces de los diferentes elementos de red para los sistemas y

herramientas de explotación técnico-comercial
31/34
Módulo 4
La Figura 8 muestra algunos de los subniveles de IMS.
Figura 8. Niveles de IMS.
Existen dos posibles estrategias usando IMS en torno al concepto de convergencia de redes
y servicios de fijos y móviles, que caracterizarían a un operador integrado:
• IMSs interoperables: mera interconexión entre las capas de control, IMS´s, de dos
redes que acompañada de unas metodologías de trabajo comunes/compatibles
podrían maximizar las sinergias y la oferta de algunos servicios convergentes a
futuro.
• IMS único: una infraestructura final común en torno a un único plano de control,
“IMS único” existiendo unicidad tanto en usuarios como en servicios (usuario de
Operador Único y Servicio del Operador Único, sin distinción de acceso). Inicialmente
esta red única sería el soporte de los nuevos servicios convergentes, durante la
evolución coexistirá con funciones e infraestructuras propias de las redes de partida
para la sostenibilidad de los servicios actuales con enfoque de migración final hacia
esta red única objetivo.
¿Qué garantiza IMS único?
• La disponibilidad de todas las aplicaciones desde cualquier tipo de acceso fijo/móvil.
• Sistema de Tarificación común y flexible para todos los servicios.
32/34
Módulo 4
• Presencia única.
• Gestión de Grupos único.
• Servicios de lista de contacto en red.
• Gestión de Usuario única.
• Gestión de los servicios única.
• Directorio Único.
• Gestión de identidad Única.
• Sistema de Identificación y autorización único. (SIM card based solution).
La Figura 9 muestra la estructura de IMS único.
Figura 9. Estructura de IMS único.
33/34
Módulo 4
IMSs interoperables.
No garantizan, en principio, el desarrollo de este tipo de servicios, o funcionalidades al no

contemplarse en los estándares las interoperabilidades entre los habilitadores de servicio
(presencia, localización, etc...) ni entre capas de servicios de dos redes basadas en IMS.
Adicionalmente la experiencia ha puesto de manifiesto las dificultades en el desarrollo de

soluciones e infraestructuras soporte de servicios sobre redes distintas en un marco de
ausencia de estandarización
Aunque sobre ambos modelos sería posible teóricamente un conjunto de sistemas y

herramientas unificado la experiencia ha puesto de manifiesto que dos redes, bases de
servicios y clientes separados conducen a sistemas, herramientas, y procesos también
separados. Parece que la situación anterior se maximiza cuando el punto de partida está
condicionado por dos negocios consolidados y separados.
Con los argumentos anteriores sobre estos conceptos claves, NGN, IMS e IMS único,
parece justificado decir que la NGN es efectivamente un trayecto “hacia la convergencia” y
que estamos ante una nueva situación apasionante de evolución tecnológica, que ha de
permitir la convergencia progresiva de los servicios finales de los clientes, fijos-móviles-
nómadas…, de las redes, de los sistemas y herramientas y previsiblemente de los negocios.
En esta situación parece también claro que cobrará especial relevancia la figura del
Operador Único Integrado así como la posición del Regulador en cada mercado ante una
nueva gama de servicios, fijos-móviles-nómadas multimedia que poco a poco deben ir
sustituyendo a los actuales. Solo quedará por resolver el marco temporal de los
acontecimientos que parece, en principio, más condicionado por las situaciones de los
negocios y de la regulación en cada mercado que por las evoluciones tecnológicas.
34/34
Módulo 4
4. Arquitectura de red NGN propuesta por TISPAN

Fuente [Ref 3].
4.1. Introducción
La evolución hacia un modelo de red "todo IP" ("all IP") permite a un operador la integración
de todos los flujos de datos correspondientes a diferentes servicios en una única red troncal,
con IP como protocolo de red, abandonando el modelo de redes diferenciadas para cada
servicio. Pero para la integración completa de todos los servicios en una única red falta algo
más, pues la prestación de un servicio no consiste únicamente en el transporte de flujos de
información.
También se ha de contemplar la señalización asociada a estos servicios. Por tanto, para

integrar en una misma red troncal todos los servicios de una oferta integrada de voz, vídeo y
datos, es preciso dotar a ese núcleo de red de un conjunto de elementos que permita un
control de dichos servicios.
Por ello, para que sea posible el despliegue de una oferta de servicios integrada sobre un
núcleo de red único se han de definir todos los elementos necesarios en dos planos
distintos: el de transporte, que se corresponde con los actuales núcleos de red IP/MPLS,
que permiten la transmisión extremo a extremo de flujos de datos de diversa naturaleza, y
un segundo plano que permita el control del establecimiento, mantenimiento y liberación de
los flujos de datos correspondientes a los diversos servicios de una oferta integrada.
Hay mucho por hacer, especialmente en el plano de control, para lograr un objetivo tan
ambicioso, pero también se ha avanzado mucho en los últimos años, de forma que hoy ya si
que es viable la integración de varios servicios en un único núcleo de red.
El 3GPP (3rd Generation Partnership Project), dentro del marco del ETSI, ha estandarizado
el IMS (IP Multimedia Subsystem) para los servicios móviles de tercera generación. Este
subsistema define un conjunto de elementos de control para proporcionar servicios de
comunicaciones multimedia personales, que pueden incluir mensajería, presencia,
intercambio de documentos, streaming de vídeo, etc., en combinación con las clásicas
llamadas y videollamadas por conmutación de circuitos de voz en un entorno "all IP".
El grupo TISPAN del ETSI, partiendo de las necesidades de los operadores de acceso fijo
de banda ancha, se ha propuesto un objetivo ambicioso como es el de definir un marco que
permita ofrecer en un entorno all IP todo tipo de servicios, y no sólo los contemplados en
3GPP. Para ello, partiendo de un modelo de red en el que reaprovecha el subsistema IMS
del 3GPP para los servicios telefónicos multimedia, y aprovechando el elevado grado de
madurez alcanzado por 3GPP (release 7), se plantea definir los elementos necesarios para
el control y transporte de los flujos de datos correspondientes a todo tipo de servicios sobre
un backbone IP único.
35/78
Módulo 4
4.2. Arquitectura NGN
El propósito de TISPAN es el desarrollo de las especificaciones para que una red de nueva
generación disponga de las capacidades necesarias para poder desplegar un amplio
catálogo de servicios multimedia. Para ello, este tipo de redes ha de disponer de las
capacidades necesarias para poder seguir ofreciendo los servicios básicos convencionales,
como el servicio telefónico básico y el acceso básico RDSI, la interconexión con otros
operadores, así como nuevos servicios multimedia.
Como se puede observar en la Figura 10, en la arquitectura NGN contemplada por el grupo
TISPAN se incluyen todo tipo de servicios, y no sólo la telefonía multimedia. También se
incluye el acceso al servicio telefónico básico mediante terminales convencionales, así como
los servicios de TV interactiva: distribución de canales de TV, pago por visión (Pay Per View,
PPV) y vídeo bajo demanda (Video on Demand, VoD).
Figura 10. Arquitectura NGN del grupo TISPAN del ETSI.

Como ya se ha indicado, el modelo de red NGN propugna la integración de todos los
servicios de un operador integrado de comunicaciones sobre un mismo núcleo de red
IP/MPLS. Dentro de ese modelo se contemplan los seis subsistemas que aparecen en la
figura anterior y cuya función se resume a continuación. Cada uno de los subsistemas
incluye un conjunto de entidades funcionales así como las interfaces entre estas entidades.
36/78
Módulo 4
Los subsistemas se agrupan según los dos planos indicados anteriormente, por tanto se
puede hablar de dos grupos de subsistemas:
• El grupo de subsistemas del plano de transporte. Este plano es el encargado de

proporcionar conectividad IP a los flujos de datos establecidos entre los usuarios, así
como entre éstos y los usuarios conectados a otras redes. Por eso, el plano de
transporte comprende las redes de acceso y el núcleo de red. Y, además, el plano de
transporte incorpora los subsistemas NASS y RACS, que se encargan de ocultar al
plano de servicio las tecnologías de transporte empleadas en el acceso y en el
núcleo de red por debajo de la capa IP. En este sentido:
o El subsistema NASS (Network Attachment SubSystem) es el encargado de

todo lo relativo a la autenticación de línea y usuario, y autoconfiguración de
equipamiento del cliente. Este subsistema intercambia información relativa a
los perfiles de usuario con los subsistemas del plano de servicio.
o El subsistema RACS (Resource and Admission Control Subsystem) es el

encargado de proporcionar los recursos en el plano de transporte (acceso y
núcleo de red) para la transmisión de los flujos correspondientes a los
servicios demandados por los usuarios, para lo cual intercambia información
con los subsistemas del plano de servicio, y actúa sobre las plataformas del
plano de transporte, los equipos de red integrantes del núcleo IP/MPLS.
• El grupo de subsistemas del plano de servicio. Este plano está formado por todos los
subsistemas que permiten el control de las sesiones correspondientes a los
diferentes servicios contratados por un usuario. Integran este plano los subsistemas
IMS, PES, el subsistema de streaming (Streaming Subsystem) y el subsistema de
difusión de contenidos (Content Broadcasting Subsystem). Pero además de estos
cuatro subsistemas, el plano de servicio incluye otros elementos como las
aplicaciones, y componentes comunes empleados por varios subsistemas como
pueden ser las bases de datos con los perfiles de usuarios o con información para el
encaminamiento de los flujos de información.
Esta subdivisión del plano de servicio en dos niveles, por un lado los subsistemas de
control de los servicios, y por otro las aplicaciones, con unas interfaces claramente
definidas, permite la evolución independiente de cada una de ellas y facilitan la
introducción en la red de nuevos servicios de valor añadido. En este sentido:
o El subsistema IMS (IP Multimedia Subsystem) permite la simulación de

servicios de voz para usuarios con accesos nativos sobre IP (teléfonos IP y
softphones). Es el único de los subsistemas del modelo con una
estandarización más o menos cerrada, ya que se ha copiado del modelo IMS
del 3GPP.
o El subsistema PES (PSTN/ISDN Emulation Subsystem) se utiliza para la

emulación de los servicios que ofrece hoy la PSTN y la RDSI. Este
subsistema permitirá en un futuro la sustitución de las centrales de acceso
(clase 5) y de tránsito (clase 4) de la PSTN. Este subsistema está en una fase
inicial de normalización.
37/78
Módulo 4
o El subsistema de streaming (Streaming Subsystem) es el encargado de los

servicios de streaming de vídeo basados en el protocolo RTSP (Real Time
Streaming Protocol). Un ejemplo de este tipo de servicios es el vídeo bajo
demanda (VoD). Este subsistema no ha sido tratado aún, dado que está fuera
del objetivo planteado para la release 1 de NGN.
o El subsistema de difusión de contenidos (Content Broadcasting Subsystem)

contempla otro tipo de servicios multimedia, cuyo control no tiene por qué
estar basado en RTSP. Dentro de esta categoría entran servicios como los de
distribución de canales de TV en formato digital o los servicios de pago por
visión (PPV). Y al igual que en el caso del subsistema anterior, este
subsistema no ha sido desarrollado ya que también está fuera de los
objetivos planteados para la release 1 de NGN.
Como el modelo NGN se basa en IP como protocolo de red y emplea protocolos basados en
IP tanto para la señalización de las aplicaciones como para la transmisión de la información
de usuario, soporta la migración hacia nuevas tecnologías de transporte, haciendo que tanto
el plano de transporte como el de servicios sean independientes de la tecnología
subyacente bajo el plano de transporte.
Como ya se ha comentado, el modelo NGN se centra en la integración de múltiples

servicios, incluyendo servicios multimedia, para aquellos usuarios con accesos fijos de
banda ancha. Pero hay dos puntos que permiten considerar al modelo NGN como una
solución válida para la integración de servicios de telefonía multimedia fija y móvil. Estos dos
puntos tienen en cuenta lo siguiente:
1. En el modelo NGN, para los servicios de telefonía multimedia de los usuarios con
accesos IP nativos como teléfonos IP o softphones a través de un acceso fijo de
banda ancha con ADSL, el bloque de control propuesto es el IMS, añadiendo las
modificaciones necesarias para que se puedan soportar los mismos servicios en
terminales diferentes a los móviles.
2. En las redes de nueva generación se contempla la interconexión con el dominio PS

(Packet Switched) del 3GPP, contemplando para ello la misma interfaz que con otras
redes de acceso, un IP Edge Node, que para los usuarios con accesos móviles se
corresponden con el GGSN. Por ello NGN contempla la 3GPP IPCAN (IP
Connectivity Access Network), y todas las interfaces entre el dominio PS del 3GPP y
el subsistema IMS se mantienen en el modelo NGN.
En cuanto a la movilidad, en la primera versión (release 1) del modelo se contempla una

movilidad limitada para aquellos usuarios con accesos fijos de banda ancha, de manera que:
• Se contempla la movilidad de usuarios, servicios y terminales. Para ello se han de

incluir mecanismos de gestión de la movilidad, en los que el subsistema NASS
desempeña un papel básico.
38/78
Módulo 4
• La movilidad se limita a la posibilidad de que un mismo usuario pueda acceder a

cualquiera de los servicios con cualquier tipo de terminal desde cualquier punto de
acceso a la red, incluidos puntos de acceso correspondientes a la red de acceso de
otro operador distinto a aquél con el que se tiene contratado el servicio. Esto es lo
que se define como nomadismo.
• Sólo se contempla la posibilidad de movilidad en la sesión, es decir, el

mantenimiento de una misma sesión cuando se cambia de punto de acceso a la red,
cuando la tecnología de acceso lo permita y cuando los puntos de acceso a la red
inicial y final se correspondan con una misma tecnología de acceso. Por tanto, en la
primera versión del modelo NGN únicamente se contempla el roaming. El handover o
movilidad en la sesión queda restringido al acceso móvil a través del dominio PS de
las redes 3G.
El hecho de que se pueda acceder a los servicios contratados haciendo uso de las redes de
acceso de terceros implica acuerdos entre operadores, similares a los acuerdos de roaming
internacional entre operadores de telefonía móvil. Por tanto, también se emplean los
conceptos de home domain o home network, el correspondiente al del operador con el que
se contrata el servicio, y visited domain o visited network, el correspondiente al operador que
proporciona el acceso. Cuando se accede a un servicio a través de la red de acceso de un
operador distinto a aquél con el que se ha contratado dicho servicio, el control de la sesión
corresponde básicamente al plano de servicio del home domain. Pero el flujo de datos
asociado a la sesión abierta por el usuario consume recursos de los planos de transporte del
home domain y del visited domain. Eso implica que las interfaces de los subsistemas del
plano de control con los subsistemas del plano de transporte, el NASS y el RACS, pueden
ser interfaces entre operadores.
A continuación se desarrolla cada uno de los subsistemas presentados, así como las
funciones de transferencia del plano de transporte, indicando su función, estado de
desarrollo e interfaces y protocolos con otros subsistemas. Pero, antes de esto, se comenta
otro aspecto importante para la definición de un modelo de red NGN que de verdad se
ajuste a las necesidades tanto de los operadores como de los usuarios, y también a las del
negocio y la regulación.
4.3. Modelo NGN y modelos de negocio
La tendencia hacia un modelo de red all IP ha permitido la entrada de nuevos actores en el

ámbito de los servicios de telecomunicación. Inspirados en los ISPs, que ofrecían servicios
en Internet accesibles a través de los backbone IP de diferentes operadores, han ido
apareciendo diferentes proveedores de servicios de diversa índole.
Esta realidad también ha de ser tenida en cuenta a la hora de estandarizar el modelo de red
NGN. Tal y como se muestra en la Figura 11, el modelo NGN puede ser aplicado en su
totalidad por un operador integrado. Pero este modelo también es compatible con otros
modelos de negocio en los que haya uno o varios operadores de acceso, operadores de red
troncal, y operadores de servicios (distintos operadores para servicios multimedia y servicios
39/78
Módulo 4
vocales, por ejemplo), apareciendo incluso la figura del "packager" o entidad que actúa
como intermediario entre el usuario final y diversos proveedores de acceso, red y servicios,
y que ofrece al usuario un paquete integrado de servicios elaborado a partir de lo que cada
uno de los operadores le aporta.
Un modelo de negocio desagregado y el nomadismo plantean nuevos retos. En este

sentido, y por citar algunos, se puede decir que:
• Algunas de las interfaces entre subsistemas, o entre entidades de un mismo

subsistema, van a ser interfaces entre operadores diferentes, por lo que es necesaria
una especificación muy precisa y detallada de estas interfaces.
• Es necesario un acuerdo sobre cómo elaborar una factura única a un cliente

integrando los registros de tarificación proporcionados por diferentes operadores,
cada uno de los cuales aporta una parte del paquete global de servicios contratado
por dicho cliente.
De hecho, la definición de un sistema genérico para la recogida de datos y registros de

tarificación está fuera de los objetivos contemplados en la release 1. En dicha release sólo
se contempla la recogida de datos y registros de tarificación por subsistema.
Figura 11. Cadenas de valor del modelo de negocio NGN.
40/78
Módulo 4
4.4. Plano de transporte: funciones de transferencia
En el modelo NGN, el plano de transporte es el que sustenta la transmisión de todos los

flujos, ya sean de señalización o de información de usuario. Por ello, todos los subsistemas
van a hacer uso de las capacidades de este plano.
Las especificaciones de TISPAN se modelan en forma de entidades funcionales (Functional

Entities, FE) que agrupan una serie de tareas y funciones que han de efectuar los elementos
de red. Sin embargo, estas FEs, que son entidades lógicas, no tienen por qué
implementarse necesariamente en un mismo elemento de red (físico). En el caso de que un
elemento de red implemente varias FEs al mismo tiempo, las interfaces entre dichas
entidades son internas y no tienen por qué seguir el estándar.
El plano de transporte de la NGN consiste en un conjunto de redes (acceso y troncal) que

proporcionan conectividad IP y dispone de mecanismos para proporcionar calidad de
servicio. Por el momento los estándares de TISPAN no especifican la versión de IP a utilizar,
y dejan abierta la posibilidad de emplear IPv4 o IPv6, o bien ambos esquemas de
direccionamiento IP, pero en este último caso se señalan las dificultades inherentes al
interfuncionamiento entre IPv4 e IPv6.
Desde el punto de vista topológico, y como ya se ha indicado, el plano de transporte de una

NGN consta de redes de acceso y red troncal. Cabe señalar una red más, la de cliente, pero
hay que indicar que el ámbito de la NGN llega hasta el R-MGF, el Residential-Media
Gateway Function, la pasarela que separa el equipamiento de cliente de la red de acceso.
NGN se plantea el soporte de redes de acceso, con tecnologías y capacidades diversas.

Eso sí, el único requisito es que han de proporcionar conectividad IP. Entre las redes de
acceso soportadas se encuentran:
• Las redes de acceso fijas de banda ancha, que incluyen:
o Acceso xDSL.
o Acceso óptico, tanto con topologías en estrella como redes ópticas pasivas
(BPON, EPON, GPON).
o Redes de cable.
o Accesos punto a punto en entornos corporativos.
o Gigabit Ethernet.
• Las wireless LAN.
• Los dominios de conmutación de paquetes (PS Domain) de redes 3GPP y 3GPP2,

es decir, acceso GPRS. NGN soporta cualquier tipo de IP Connectivity Access
Network (IP-CAN) de 3GPP y 3GPP2. Para ello NGN adopta los estándares relativos
al PS Domain del 3GPP y 3GPP2. En cambio, en NGN no se incluye el soporte de la
conmutación de circuitos (CS Domain) como red de acceso.
41/78
Módulo 4
Esto es lo que hace que el modelo NGN permita plantear la integración de servicios fijos y
móviles, siempre que la lógica de control de estos servicios se pueda efectuar mediante
aplicaciones soportadas por protocolos IP.
Desde el punto de vista funcional, el plano de transporte se puede subdividir en un subnivel

de control de transporte, y en unas funciones de transferencia (Transfer Functions) sobre las
cuales se sustenta el subnivel de control. El modelo sólo aborda las funciones de
transferencia con las que necesitan interactuar el subnivel de control de transporte o el nivel
de servicio.
El subnivel de control de transporte se divide a su vez en dos subsistemas, denominados:
1. Network Attachment Subsystem (NASS).

2. Resource and Admission Control Subsystem (RACS).
En la Figura 12 se muestra la subdivisión del plano de transporte de una red NGN, en el que
se muestran los subsistemas que lo integran, las funciones de transferencia, así como las
interfaces entre éstas y las entidades funcionales que componen los dos subsistemas del
plano de transporte.
Figura 12. Subdivisión del plano de transporte del modelo NGN.
42/78
Módulo 4
En esa misma figura se señala dónde pueden residir algunas de las funciones de
transferencia, referidas a plataformas empleadas normalmente en el backbone IP de un
operador que ofrece accesos fijos de banda ancha.
Cabe señalar la particularidad del Access Node, que en la figura anterior aparece en trazo
discontinuo, así como su interfaz con A-RACF. La razón es que, en principio, el DSLAM
(Digital Subscriber Line Access Multiplexer) es transparente a nivel IP, siendo el BRAS
(Broadband Remote Access Server) el IP Edge Node de la figura anterior, el primer
elemento de la red de acceso que encamina el tráfico ateniéndose a las direcciones IP (IP
aware), por lo que las políticas de calidad de servicio (Quality of Service o QoS) que
implementa el RACS sólo empiezan a aplicar a partir del IP Edge Node. Y esto es así en
muchas de las redes de acceso fijo de banda ancha. Pero no siempre va a ser así. De
hecho, ya hay DSLAMs que trabajan en capa IP, los DSLAMs IP, cuya interfaz agregada no
es una interfaz ATM o Ethernet, y sí una interfaz IP. En ese caso, cuando un usuario acceda
a través de un puerto de uno de estos DSLAMs, el propio DSLAM tendrá que implementar
las políticas de QoS que indique el A-RACF y deberá incorporar las funciones de
transferencia propias del IP Edge Node.
En cuanto a los tráficos correspondientes a las diferentes sesiones multimedia abiertas por
el usuario, se trata de flujos de bits generados por codecs de audio y vídeo, encapsulados
en paquetes IP, empleando para ello RTP. En el modelo NGN se establece que se deberán
contemplar los siguientes codecs:
• En los servicios de voz es obligatorio el uso de G.711 con retardos de 10

milisegundos (paquetes con un payload de 80 muestras). También se recomienda
AMR para servicios de telefonía móvil, así como G.729a para la interconexión con
redes VoIP.
• En los servicios de vídeo es obligatorio el uso de H.263 con perfil 0 y H.264.
En la Figura 12 se muestran las principales funciones de transferencia del modelo NGN. A

continuación se explica en qué consiste cada una de ellas, y en la medida de lo posible se
identifican con las funcionalidades que hoy en día incorporan las plataformas habitualmente
empleadas en los backbone IP de un operador de comunicaciones. Estas funciones son:
• La función BGF (Border Gateway Function)
Actúa como interfaz entre dos dominios de transporte IP, típicamente entre la red de
acceso y el núcleo de red, o bien como interfaz en la interconexión entre núcleos de red
de dos operadores diferentes. Algunas de las tareas encomendadas a un BGF son las
relativas a:
o Control del tráfico, mediante el filtrado del tráfico IP en función de los cinco
parámetros habituales en cualquier router: direcciones IP origen y destino,
protocolo y puertos origen y destino.
o Conformado de tráfico entrante y marcado de paquetes.
43/78
Módulo 4
o Asignación de recursos y reserva de ancho de banda en las interfaces de

salida del equipo.
o Antispoofing de direcciones IP.
o Traducción de direcciones y puertos (NAPT).
o Interfuncionamiento entre redes IPv4 e IPv6.
o NAT traversal.
o Ocultación de la topología.
o Métricas de uso. Como es, por ejemplo, el tráfico cursado en cada sentido,
expresado en términos de número de bytes y paquetes.
A su vez, dentro del núcleo de red se puede hablar de dos tipos de BGF, cada uno de los
cuales implementa un subconjunto de las funcionalidades de una BGF genérica, según sea
su situación en la red y la política del operador. Los dos tipos de BGF se denominan:
• Core BGF (C-BGF). Es una pasarela de tipo packet to packet gateway para tráfico de
media en el plano de usuario, que se sitúa entre la red de acceso y el núcleo de red,
ubicado en este último lado. Su función es la aplicación de políticas y la funcionalidad
de NAPT bajo el control del SPDF, una entidad lógica correspondiente al subsistema
RACS. El CBGF actúa sobre los flujos de paquetes asociados a cada sesión. Es una
función dinámica que puede bloquear flujos individuales y permitir el paso a flujos
autorizados conforme a lo que le indique el SPDF. Este último, por medio del
protocolo H.248, indica al C-BGF el tratamiento a aplicar a un flujo que se identifica
por medio de cinco parámetros: direcciones IP origen y destino, puertos origen y
destino y protocolo. Para cada flujo, la SPDF le puede indicar a la C-BGF que
aplique políticas que limiten la tasa de transferencia del flujo hasta un determinado
nivel.
Actualmente se están empleando para soportar esta funcionalidad las plataformas

denominadas SBC (Session Border Controller). Algunas de las plataformas de este
tipo disponibles hoy en el mercado soportan una parte significativa de las
funcionalidades propias de un BGF.
• Interconnection BGF (I-BGF). Es otro packet to packet gateway, pero situado en este
caso entre núcleos de red de operadores diferentes. Este tipo de BGF también se
puede implementar en la práctica por medio de un SBC.
En la red de acceso se sitúa un tipo de BGF con capacidades limitadas, denominado

Resource ControlEnforcement Function (RCEF). Éste aplica las políticas definidas por el
proveedor de acceso bajo el control del A-RACF (abre y cierra puertas permitiendo el paso
de flujos, marca los paquetes IP y aplica políticas de tráfico en sentido ascendente y
descendente), de manera que el RACS pueda asegurar los recursos en la red de acceso.
44/78
Módulo 4
Como se puede ver, entre las tareas de un BGF, es su responsabilidad la reserva de

recursos y la aplicación de políticas en el plano de transporte, bajo el control de un
subsistema externo, el RACS. Para mantener un modelo escalable similar al conseguido en
las redes IP tradicionales, estas funcionalidades han de limitarse a los extremos de la red o
a las fronteras entre dominios administrativos.
Hay que recordar que la red de acceso y el núcleo de red pueden ser responsabilidad de
operadores de red diferentes. De esa posibilidad se deriva la necesidad del C-BGF, como
frontera entre esas dos redes. En el caso de que un mismo operador controle la red de
acceso y el núcleo de red, la funcionalidad del C-BGF y el RCEF pueden residir en el mismo
equipo, por ejemplo en un BRAS encargado de atender accesos ADSL.
• La función L2TF (Layer 2 Termination Function)
Se encarga de la terminación del nivel de enlace a la entrada de la red de acceso. A

modo de ejemplo, en el caso de una red de acceso fijo de banda ancha basada en
tecnología xDSL, donde el tráfico se suele encapsular en celdas ATM, la funcionalidad
L2TF se correspondería:
o Bien con el servidor PPP del BRAS, cuando se emplea PPPoE (PPP over
Ethernet) para encapsular el tráfico IP sobre el flujo de celdas ATM que
proporciona el enlace xDSL.
o O bien con el desempaquetado de las tramas ethernet que efectúa el BRAS,

cuando el tráfico IP se encapsula sobre ATM según la RFC 2684 para su
envío sobre las conexiones virtuales ATM definidas en un enlace xDSL.
• La función ARF (Access Relay Function)
ARF es una función intermedia entre el equipo de usuario y el subsistema NASS. Recibe
peticiones desde el equipo de usuario y las reenvía a dicho subsistema, pudiendo añadir
información local. Por tanto, está implicado en el control de acceso (delegado en el
NASS) y la reserva de recursos (también a través del NASS y en relación con el RACS).
En el caso de una red xDSL con PPP y autenticación vía RADIUS, el ARF residiría en el
BRAS y se encargaría de la conversión entre las peticiones del cliente recibidas, por
ejemplo, vía PPP, y las peticiones que el cliente AAA del BRAS envía al servidor AAA.
Un ejemplo de configuración local añadido por el BRAS serían los atributos RADIUS
"NAS Port" y "NAS IP Address", que permiten la identificación de la conexión a través de
la cual está accediendo un usuario con una acceso ADSL.
• La función MGF (Media Gateway Function)
Proporciona la correspondencia entre flujos de media así como la transcodificación,

cuando sea necesaria, entre una red de transporte IP y una red conmutada de circuitos.
Existen tres tipos de MGF, denominados:
a. Residential MGF (R-MGF), situado en las instalaciones del cliente.
45/78
Módulo 4
b. Access MGF (A-MGF), que se sitúa en la red del operador, ya sea en la red de acceso
o el núcleo de red.
c. Trunking MGF (T-MGF), situado en la frontera entre la red IP y la PSTN/RDSI.
Los R-MGF y A-MGF proporcionan acceso a los servicios del subsistema PES. En cambio el
T-MGF puede ser empleado tanto por el subsistema PES como por el subsistema IMS.
Como ya se ha indicado, en el caso de que sea necesaria la transcodificación, son los MGFs
los encargados de efectuarla. Un ejemplo sería el caso de una llamada entre un teléfono
analógico convencional, atendido por un A-MGF, a un terminal móvil 2G de la PLMN. En ese
caso, el T-MGF que interconecta el núcleo de la red NGN con la red del operador GSM se
encargaría de la transcodificación, pasando los flujos RTP con codec G.711 a tramas TDM
con flujo AMR y viceversa.
• La función MRFP (Media Resource Function Processor)
Realiza funciones de procesamiento de recursos que van más allá de las proporcionadas
por la MGF, tales como soporte a conferencias multimedia, funcionalidades IVR, origen de
anuncios multimedia, etc.
• La función SGF (Signalling Gateway Function)
Se encarga de pasar la señalización de la PSTN o PLMN, que es SS7 y se transporta sobre

tramas TDM, a paquetes IP y viceversa. Para el transporte de señalización SS7 sobre IP se
puede emplear SIGTRAN (M2UA o bien M3UA), aunque en el modelo NGN la opción que se
está planteando es SIP-I.
4.5. NASS: Control de acceso y perfiles de usuario
El NASS es un subsistema ubicado en el plano de transporte del modelo NGN, por lo que
las facilidades que proporciona son empleadas por los subsistemas restantes ubicados en el
plano de servicio. El subsistema NASS proporciona las funcionalidades relativas a:
• La autenticación y autorización de accesos. Autenticación tanto implícita (por

ejemplo, autenticación de línea en una red de acceso xDSL, basada en la activación
del nivel de enlace de la conexión del usuario) como explícita (por ejemplo,
autenticación de usuario con credenciales).
• El registro y autoconfiguración del equipo de usuario. Como parte del registro, el

NASS le proporciona al equipo de usuario el punto de contacto del subsistema de
servicio (la dirección IP o el nombre de dominio del P-CSCF).
• La información para la contabilidad de los accesos y sesiones.
46/78
Módulo 4
• La información para la localización de los usuarios, especialmente en un contexto

caracterizado por la movilidad de los usuarios (nomadismo), incluyendo la posibilidad
de roaming, es decir, de accesos a través de redes de acceso de terceros. La
release 1 de NGN no soporta el handover ni la continuidad de sesiones entre redes
de acceso. Eso no impide la existencia de mecanismos de movilidad inherentes a la
red de acceso que sí soporten esa continuidad.
• La información necesaria para aplicar los perfiles de servicio correspondientes al

usuario final.
La Figura 13 muestra las relaciones entre las diferentes entidades que componen el
subsistema NASS.
Figura 13. Elementos que integran el NASS.
Este subsistema tiene un papel fundamental a la hora de ofrecer movilidad, que como ya se
ha indicado es uno de los objetivos contemplados en NGN. Se ha de posibilitar que un
mismo usuario en momentos diferentes pueda acceder a través de redes de distintos
operadores. Esto, en el caso del subsistema NASS, implica que bloques de este subsistema
puedan estar en redes de distintos operadores. En este sentido:
• Una parte de los componentes del NASS estarían en la red que proporciona el
acceso de banda ancha, y que por analogía con los términos acuñados en 3GPP
sería el visited domain.
• Y otra parte de los componentes estarían en la red del operador con el que el usuario
contrata el servicio (el home domain).
47/78
Módulo 4
En la Figura 14 se muestra cuál sería la ubicación de los diferentes elementos del

subsistema NASS cuando se produce el acceso a través de la red de acceso de un tercero.
En principio, en el subsistema NASS, los perfiles de usuario que se contemplan son los
correspondientes a las subscripciones de acceso y no a los servicios. Pero siempre hay una
relación con el servicio, cuya sesión es soportada por el acceso establecido.
Figura 14. Elementos del NASS con accesos a través de la red de un tercero.
Las entidades funcionales que componen el subsistema NASS son:
• La función NACF (Network Access Configuration Function)
Se encarga de la asignación de dirección IP al equipo de usuario. También

proporciona otros parámetros necesarios para los servicios demandados por el
usuario, como la dirección de los servidores DNS o del PCSCF.
Esta función en las redes actuales de banda ancha se ha venido proporcionando de

diversas formas. Por ejemplo, por el propio BRAS, en el caso de que la asignación
de direcciones IP se efectúe de manera local en éste, o bien, desde un servidor
RADIUS o DHCP, en el caso de que la gestión de direcciones IP se haga de forma
centralizada.
• La función AMF (Access Management Function)
48/78
Módulo 4
Esta entidad lógica traduce las peticiones de acceso a la red recibidas del
equipamiento de usuario y se las reenvía al NACF con objeto de obtener una
dirección IP e información de configuración. Además, a partir de la petición de
acceso procedente del equipamiento de cliente, el AMF envía esta petición del
usuario a la UAAF para iniciar el proceso de autenticación y de autorización (o
rechazo) del usuario. Este proceso permite la obtención de información relativa a la
configuración del usuario (por ejemplo, información de su servicio por defecto).
En el caso de usuarios con accesos fijos de banda ancha con PPPoE, el AMF con el
cliente AAA (típicamente RADIUS), a partir del perfil del usuario recibido vía PPP,
solicita a un servidor RADIUS la autenticación de dicho usuario.
• La función UAAF (User Access Authorization Function)
Se trata de la entidad lógica encargada de la autenticación y autorización del usuario

conforme a su perfil, que se encuentra almacenado en la PDBF. La UAAF se
encarga también de la recolección de información de tarificación. Esta entidad se
corresponde con un servidor AAA, ya sea RADIUS, como en las actuales redes de
acceso fijo de banda ancha, o Diameter.
En un escenario con roaming, el UAAF de la visited network puede comunicarse con

el UAAF de la home network para que éste consulte al PDBF de la home network del
usuario. Las respuestas recibidas del UAAF de la home network serían reenviadas al
AMF, actuando el UAAF de la red visitada como un Proxy AAA (véase la Figura 14).
• La función PDBF (Profile Data Base Function)
Es el repositorio donde se almacena el perfil del usuario a nivel de red. Este perfil
incluye información necesaria para la autenticación (username, password, etc.) así
como información de configuración, por ejemplo, el servicio por defecto.
En la release 1 de la NGN, la interfaz entre la PDBF y la UAAF no es objeto de

estandarización. Su comunicación se realizará mediante una interfaz no
estandarizada.
En las redes actuales de acceso fijo de banda ancha, la funcionalidad PDBF la

proporciona una base de datos o un servidor LDAP utilizados por el servidor
RADIUS.
• La función CLF (Connectivity session Location and repository Function)
Es el elemento del plano de transporte que mantiene información de estado sobre las
sesiones de acceso a la red establecidas (no las de servicio, pues éstas corresponden a
los subsistemas del plano de control). Como tal, permite establecer una relación entre
una dirección IP dada y una serie de parámetros asociados en cada momento a esa
dirección IP.
Entre esos parámetros almacenados en el CLF se encuentran los siguientes: "Logical

Access Id", "Address realm" (dominio), "Physical Access Id", usuario, información de
49/78
Módulo 4
localización, perfiles de QoS suscritos, etc. El CLF recibe esta información de la NACF,
la entidad lógica encargada de proporcionarle al usuario la dirección IP y otros
parámetros básicos de configuración, y del UAAF, el elemento que autentica al usuario.
Actualmente, en los servicios de banda ancha para usuarios con accesos fijos vía ADSL
basados en PPPoE, son los servidores de estado de los servidores RADIUS los que
proporcionan los parámetros que debe proporcionar el CLF. Estos servidores de estado
han demostrado ser uno de los factores limitadores más importantes en cuanto a las
prestaciones, en términos de sesiones de acceso establecidas por segundo, en este tipo
de redes, como por ejemplo se ha comprobado en la Plataforma de Selección de
Servicios de Banda Ancha (PSSBA) de Telefónica LATAM. El hecho de que el servidor
de estados tenga que mantener una información centralizada sobre todas las sesiones
establecidas dentro de un dominio administrativo lleva a estos problemas de
"escalabilidad".
Pero el estado de una sesión cambia dinámicamente. Si se pueden contratar servicios

dinámicamente, eso implica activaciones y desactivaciones de servicios, que a su vez
implican variaciones de los requerimientos de QoS asociados a un determinado acceso.
De ello se deriva la necesidad de una interacción entre los subsistemas RACS y NASS,
establecida entre el ARACF y el CLF respectivamente. Todo esto supone una mayor
carga para el servidor de estados de un servidor AAA, lo que puede plantear problemas
de prestaciones.
• La función CNGCF (Customer Network Gateway Configuration Function)
Esta función se encarga de la configuración adicional que necesita el equipamiento de

usuario, como por ejemplo, la del cortafuegos interno del CPE, el marcado de paquetes
IP para calidad de servicio, etc.
Esto se corresponde con el concepto de auto-configuration server definido por el DSL

Forum. En un futuro se contempla la posibilidad de que haya más de un operador
interviniendo en la configuración del equipo de usuario (operadores de red y proveedores
de multitud de servicios: servidores de contenidos, servicios domóticos, etc.). Esta
situación obliga a una estandarización de la interfaz de cada uno de los operadores con
el CPE. En el DSL Forum también se están ocupando de la estandarización del CPE y
sus interfaces.
De lo descrito anteriormente se puede concluir que la entidad lógica más novedosa de la

arquitectura NGN, en lo que se refiere al subsistema NASS, es el CLF. En las redes
tradicionales este elemento no se encuentra estandarizado, por lo que su funcionalidad se
incorpora actualmente mediante soluciones propietarias.
La mayor incertidumbre es saber cómo se va a abordar el problema de escalabilidad que

plantea el CLF. La principal característica del CLF que lleva a los problemas de
escalabilidad es su necesidad de mantener información de estado "centralizada" para un
elevado número de sesiones de usuario. Los problemas de escalabilidad se derivan de esta
necesidad de un acceso centralizado a la información, combinado con el requisito de alta
50/78
Módulo 4
disponibilidad exigible a una red NGN. Esa centralización de la información no tiene por qué
implicar una arquitectura centralizada, sino un punto de contacto único.
TISPAN por el momento no detalla cómo se podría implementar el CLF. De hecho, queda
por ver si llevará a cabo un diseño detallado del mismo, o si por el contrario, únicamente
serán estandarizadas dentro de este ámbito las interfaces del CLF con las demás entidades
de la NGN. Si TISPAN finalmente no entra en el diseño de la implementación del CLF, los
problemas de escalabilidad dependerían de nuevo de soluciones propietarias.
Otra consideración relativa al NASS es la ubicación de la entidad lógica AMF. En principio,

este elemento se puede situar en el IP Edge Node (BRAS). En los actuales servicios HSI
(High Speed Internet) sobre accesos ADSL, en la mayor parte de los casos, los operadores
trabajan con PPPoE sobre ATM, terminando el circuito virtual ATM en el BRAS. De este
modo el cliente AAA del BRAS tiene la información necesaria para poder identificar
unívocamente el acceso físico (par metálico) empleado por el usuario en su acceso. Si se va
a un escenario con movilidad en el que los access nodes, como pueden ser los DSLAMs,
trabajen con Ethernet en lugar de ATM, y si la funcionalidad AMF sigue residiendo en el IP
Edge Node, se pierde la referencia que permite identificar la línea física que está empleando
el usuario para acceder a sus servicios. Y de cara a requisitos legales, como puede ser la
interceptación legal de las comunicaciones o el acceso a los servicios de emergencia, éste
es un dato muy importante. En ese escenario podría plantearse que la funcionalidad AMF
residiese en el Access Node. Pero eso a su vez plantea nuevos retos: si el Access Node es
transparente en capa IP, como puede ser el caso de un DSLAM ATM o Ethernet, de alguna
manera hay que ligar la información del puerto físico a través del cual se accede, cosa que
sólo puede proporcionar el Access Node, y la dirección IP asignada al usuario, dato que en
principio suele obtenerse del IP Edge Node.
4.6. RACS: Control de admisión y recursos
Al igual que el subsistema anterior, el RACS también se sitúa en el plano de transporte, por
lo que las facilidades que proporciona también son empleadas por los subsistemas del plano
de servicio. El subsistema RACS, dentro del modelo NGN de TISPAN, engloba los
elementos encargados de aplicar políticas de control, reservar recursos y controlar la
admisión de flujos. Incluye también la activación y desactivación en las plataformas del
plano de transporte de funcionalidades como NAT o cortafuegos (firewall).
Es el encargado de proporcionar los recursos necesarios en el plano de transporte para las

diferentes sesiones de servicio establecidas por los usuarios. Por tanto, a partir de la
información proporcionada por los subsistemas del plano de servicio así como el NASS, los
elementos del RACS van a actuar sobre las plataformas de red para conseguir los recursos
necesarios. Para conseguirlo, en el caso de servicios multimedia en tiempo real (VoIP,
videoconferencia, VoD, juegos en línea, etc.), tiene que ser capaz de:
• Reservar los recursos necesarios para ofrecer los niveles de QoS contratados
(SLAs).
• Efectuar un control de admisión que garantice en todo momento la disponibilidad de
recursos para las sesiones establecidas.
51/78
Módulo 4
• Controlar las políticas a aplicar en las diferentes sesiones.
Como ya se ha indicado, el subsistema RACS ha de proporcionar los medios a los

operadores para que se puedan aplicar los controles de admisión y las políticas de servicio
asociadas a una oferta integrada de servicios, contemplando escenarios con movilidad en el
acceso, incluso entre redes de distintos operadores. Eso implica que este subsistema tiene
que ser agnóstico en cuanto a los servicios ofrecidos y ha de llevar un control sesión por
sesión. Para poder llevar a cabo estas funciones, se necesitan:
• Unos niveles de calidad o clases de QoS de referencia para cada tipo de servicio.
• Unas interfaces normalizadas con los restantes subsistemas del modelo NGN, tanto
del plano de transporte como del de servicio, así como las interfaces con el
equipamiento de red encargado de la transmisión de los flujos (routers, BRAS e
incluso plataformas como pueden ser DSLAMs cuando éstos agregan el tráfico en la
capa IP).
• Una arquitectura escalable para este subsistema.
En la primera versión de la arquitectura NGN de TISPAN se especifican algunos requisitos

generales para ofrecer QoS. La diferencia principal es que la estandarización del 3GPP no
impone ningún requisito de control de la variación del retardo o jitter.
Entre estos requisitos generales está la necesidad de que exista un mecanismo dinámico
para negociación de QoS entre proveedores de servicio y red de acceso basados en SLA
que permita que el mecanismo de QoS sea controlado por la aplicación.
También debería proporcionar soporte de al menos uno de los dos modelos para garantizar
el nivel de servicio: QoS garantizada o relativa, al igual que soporte de terminales, tanto con
señalización específica de QoS como sin ella. En este sentido:
• El modelo de calidad de servicio garantizada implica la prestación del servicio con

límites absolutos en algunos o en todos los parámetros de QoS, como tasa de
transferencia, latencia, variación del retardo (jitter) y pérdida de paquetes. Para
conseguirlo se hace un control de admisión y se obliga a tomar decisiones de control
de admisión en la red de acceso con políticas de control.
• El modelo de calidad de servicio relativa implica la diferenciación de clases de tráfico

(DiffServ) mediante distintas colas dedicadas a distintas clases de tráfico IP y
priorizando dichas colas en la red de acceso. El marcado del tráfico se hace en el IP
Edge Node.
La calidad de servicio que observa el usuario es siempre extremo a extremo, pero la QoS en
la red de acceso es considerada como el segmento crítico. La QoS se refiere únicamente al
segmento de acceso, mientras que en el núcleo de la red de transporte se consigue, por
ejemplo, mediante el sobredimensionado de la red. Esta distinción, además, permite que la
evolución de la implementación de QoS sea independiente en la red de acceso y el núcleo
de red.
52/78
Módulo 4
La provisión de QoS en los mecanismos NGN de TISPAN debería tener en cuenta

diferentes mecanismos de control de QoS correspondientes a las diferentes tecnologías y
posiblemente a los diferentes modelos de negocio, donde al menos se ha identificado tres
escenarios relativos a:
1. QoS con “proxy” y “policy-push”. El terminal de usuario no dispone de soporte

nativo de mecanismos de señalización de QoS. Se solicita un servicio
específico al gestor de aplicación que determina el nivel de QoS necesario
para el servicio demandado (como en una red xDSL).
2. QoS solicitada por el usuario con “policy-push”. El cliente puede solicitar sus
necesidades de QoS, y el equipamiento de cliente es capaz de enviar
solicitudes de QoS mediante señalización o protocolos de gestión para sus
propias necesidades de QoS, pero necesita autorización previa por parte de
un gestor de aplicación (como en la red móvil).
3. QoS solicitada por el usuario con “policy-pull”. El terminal del usuario es

capaz de enviar peticiones de QoS mediante señalización y protocolos de
gestión para sus propias necesidades y no necesita autorización previa.
En la práctica, la calidad de servicio que ofrece NGN sigue el modelo DiffServ en la red de
transporte, y por tanto, la funcionalidad del subsistema RACS se resume en la aplicación en
cada sesión de los mecanismos relativos a:
• Control de admisión. Este control se implementa en el segmento de acceso y

agregación. Se puede pensar en varios tipos de control de admisión, desde un
control estricto hasta un control trivial basado en la autorización únicamente.
• Reserva de recursos. Permite a la aplicación solicitar recursos de portadora en la red

de acceso, es decir, controlando los flujos de tráfico.
• Control de políticas basadas en servicios. El RACS autoriza recursos de QoS

indicados por los elementos del plano de control.
• Prestación de servicios a las funciones de aplicación (AF). Ofrece los servicios a los
AF (Application Function) de los subsistemas del plano de control que pueden
corresponder a operadores diferentes. Se establece un control de QoS basado
principalmente en un modelo DiffServ, de manera que los flujos de tráfico se tratan
en función de un comportamiento predefinido: se agrega el comportamiento de los
flujos en PHB (Per Hop Behaviour).
• Aplicación de PHB en los diferentes nodos. Esta aplicación se realiza tanto en la red
de acceso como en el núcleo, lo que en la práctica significa que, atendiendo a las
indicaciones recibidas desde el RACS, en cada nodo del plano de transporte:
o Se clasifica el tráfico IP mediante filtros definidos en función de la dirección IP

origen y destino, el puerto origen y destino, y el protocolo.
o Se distribuye el tráfico, una vez clasificado, en colas de transmisión.
53/78
Módulo 4
o Se gestionan las colas de transmisión, mediante la asignación de diferentes

anchos de banda y prioridades a cada cola.
o Pero eso sí, en cada nodo, el filtrado, el encolamiento del tráfico y los
mecanismos de reparto de ancho de banda dependerán de lo que permita la
solución tecnológica del fabricante del nodo.
Como se observa en la Figura 15, el subsistema de control de admisión y recursos (RACS)

está formado por unas entidades lógicas, como son:
Figura 15. Elementos integrantes del subsistema RACS.
• La función SPDF (Service-based Policy Decisión Function)
La función de decisión basada en políticas de servicio (SPDF) se sitúa en el núcleo

de la red del operador con la que el usuario ha contratado el servicio (home domain).
Esta función ofrece a la AF un único punto de contacto y toma decisiones usando

reglas de políticas. Construye las políticas de decisión y comunica estas decisiones
al A-RACF. Para el control de puertas y de NAT se comunica directamente con el C-
BGF. Incluye la lógica para transformar una petición de reserva de recursos del AF
en peticiones de reservas al A-RACF y al C-BGF, coordinando así las solicitudes de
reserva y liberando los recursos sin mantener el estado de sesión.
54/78
Módulo 4
• La función A-RACF (Access - Resource Admision Control Function)
La función de control de admisión y acceso a los recursos (A-RACF) cumple dos

tareas básicas: el control de admisión de sesión y la construcción de políticas de red.
El A-RACF recibe peticiones de QoS y tiene que comprobar si los recursos
necesarios están disponibles en el acceso implicado. Informará al SPDF si los
recursos se han podido reservar o no. Para la calidad de servicio garantizada, el A-
RACF puede aplicar decisiones de control de admisión mediante políticas de QoS de
nivel 2 o nivel 3 en el RCEF, mientras que para la calidad de servicio relativa se
actualizan los parámetros DiffServ de QoS mediante políticas de QoS IP. Las
políticas de la red de acceso son un conjunto de reglas que indican las políticas a
aplicar sobre una línea de acceso concreta.
Las entidades lógicas RCEF, C-BGF y L2TF se han descrito anteriormente dentro del plano
de transporte. Sin embargo, TISPAN incluye estas entidades como pertenecientes al RACS.
Como se observa en la figura anterior, el AF (Application Function) no pertenece a este
subsistema, sino a un subsistema del plano de control, que representa los servicios que
requieren un control de los recursos IP. La razón por la que el AF aparece en la figura
anterior es para mostrar que el SPDF es la única interfaz con los servicios y aplicaciones.
Un ejemplo de AF es el P-CSCF del IMS. Estos subsistemas son usuarios de RACS que
solicitan reserva de recursos e información necesaria para saber cuándo estos recursos
reservados han de ser liberados, empleando para ello la interfaz Gq’, basada en el protocolo
Diameter. Por otro lado, las entidades lógicas que integran RACS actúan sobre las
entidades funcionales del plano de transporte para que éstas empleen los recursos
necesarios para cada sesión que se vaya a establecer. Para ello se están definiendo
interfaces estándar basadas en el protocolo H.248.
En cuanto al tema de la movilidad y la QoS, dado que el acceso se puede producir a través
de la red de acceso de un tercero, los perfiles de QoS han de aplicarse sobre plataformas de
red de terceros. Eso implica que las entidades lógicas de este subsistema se ubicarán en
dominios diferentes, y por tanto, la interfaz entre dichas entidades puede ser una interfaz
entre redes de operadores diferentes. En consecuencia, esa interfaz, basada en el protocolo
Diameter, ha de estar claramente definida.
4.6.1. Consideraciones sobre QoS y el subsistema RACS
TISPAN considera dos arquitecturas para el control dinámico de QoS, conocidas como:
1. QoS garantizada, con límites estrictos en algunos o todos los parámetros de

QoS, tales como throughput, latencia, jitter o probabilidad de pérdida.
2. QoS relativa, con tratamiento Diffserv dinámico, diferenciado para diferentes

clases de tráfico.
Hay que resaltar que el control de QoS en el ámbito de la NGN únicamente abarca a la red
de acceso (impuesto mediante el RCEF) y a los puntos de interconexión entre la red de
55/78
Módulo 4
acceso y la red troncal (A-BGF y C-BGF), o entre redes troncales (I-BGF). La limitación a la
red de acceso y a la interconexión con la red troncal se debe a los problemas de
escalabilidad que a día de hoy supondría un control dinámico de QoS que abarque toda la
red extremo a extremo.
En el ámbito interno a la red troncal de la NGN se presupone que se cuenta con el ancho de
banda suficiente para cursar el tráfico agregado de cada clase (voz, vídeo, datos, etc.). Para
conseguir esto de forma eficiente lo típico será utilizar mecanismos DiffServ estáticos en el
núcleo de red que prioricen el tráfico de cada clase sobre los enlaces troncales de manera
adecuada. Estos mecanismos DiffServ pueden ser aplicados si el núcleo de red es IP/MPLS,
que es lo más habitual.
Para proporcionar QoS, ya sea relativa o garantizada, es necesario un control de admisión.

NGN cuenta con una ventaja respecto a los esquemas tradicionales de redes IP, gracias a la
existencia de un plano de servicio, que puede actuar sobre algunos de los nodos ubicados
en el borde del plano de transporte, como podría ser el caso del BRAS (IP Edge Node) o del
SBC (C-BGF o I-BGF), para controlar el número de accesos y los recursos disponibles en
cada momento.
Además del control de admisión, la QoS garantizada requiere una función de policing o
control del tráfico entrante para asegurar que el cliente no inyecta más tráfico a la red que el
que le corresponde al servicio contratado. Teniendo en cuenta que es posible realizar un
control de admisión desde el plano de servicio, el control de admisión puede llegar a venir
impuesto simplemente por la disponibilidad de una política para aplicar este policing al
tráfico entrante en el IP Edge Node. Hay que recordar que el número de políticas disponibles
para esta función en el IP Edge Node será limitado.
Por último, la QoS garantizada puede implicar realizar una reserva de recursos en las colas
de salida de cada nodo IP situado en el plano de transporte. Esta reserva puede llevar a
problemas de escalabilidad si se realiza atendiendo a flujos individuales. Por tanto, esta
reserva se ha de realizar sobre flujos agregados de tráfico, tal y como se suele hacer
actualmente en cualquier backbone IP, por lo que más que de QoS cabría hablar de CoS o
Class of Service.
En cuanto al SPDF, TISPAN plantea esta función como un punto de contacto único de cara
hacia los AFs. Esto parece indicar que el SPDF seguiría una arquitectura de tipo
centralizada con un único servidor actuando como SPDF, o en su defecto un cluster de
servidores que dan una apariencia única al exterior, pero con mecanismos de alta
disponibilidad internos.
Hay que resaltar que de igual forma que el CLF mantiene información de estado en el NASS
sobre las sesiones de usuario, en el RACS se requiere también almacenar información de
estado. La información de estado mantenida por el RACS abarca todas las sesiones activas
que en un momento dado hayan establecido el total de usuarios conectados a la red. Esta
información de estado se encontrará repartida entre los A-RACF (políticas aplicadas en el IP
Edge Node para cada servicio de cada sesión de usuario) y la SPDF (políticas aplicadas en
el BGF para cada servicio de cada sesión).
56/78
Módulo 4
Si el SPDF es un elemento centralizado, se aplican las mismas consideraciones que al CLF

en el caso de que éste fuera implementado como un único servidor central. Principalmente,
las consideraciones relativas a los problemas de prestaciones y a la redundancia en caso de
fallo.
En el caso del A-RACF, éste no tiene por qué ser un elemento único por cada red de
acceso. La única restricción es que cada IP Edge Node sea en cada momento controlado
por uno y sólo uno de los A-RACFs de la red de acceso. Por el momento, los estándares de
TISPAN no detallan cuál sería la arquitectura de alta disponibilidad de estos elementos.
Por otro lado, TISPAN deja en manos de la configuración local de la SPDF el mecanismo
por el que decide con qué A-RACF y C-BGF ha de contactar para una petición recibida
desde el AF. Si la asignación de direcciones IP, realizada por el NACF del subsistema
NASS, se hace empleando direcciones correspondientes a rangos de direcciones IP
definidos localmente en el IP Edge Node, el SPDF puede tomar esa decisión basándose en
la dirección IP asignada. Eso implica un interfuncionamiento entre el NACF del NASS, y el
SPDF del RACS.
Por último, otro punto a comentar es que el Access Node, cuyo papel en el caso de accesos
xDSL se corresponde con un DSLAM, no se suele considerar afectado por el RACS. Pero
en el propio esquema de la Figura 15 se contempla dicha posibilidad (trazo discontinuo). Ello
se debe a que en algún caso la red de acceso puede emplear un access node con
funcionalidades IP, cuya interfaz agregada maneja tráfico IP. En ese caso, el RACS sí que
ha de actuar sobre la plataforma de acceso.
4.7. IMS: Simulación de servicios telefónicos multimedia
El subsistema IMS de 3GPP ofrece una serie de capacidades genéricas para el desarrollo
de servicios IP multimedia. La filosofía de estos servicios IMS viene determinada por la
tecnología clave de dicho subsistema: el protocolo SIP. IMS está diseñado para ofrecer
servicios de comunicaciones peer-to-peer entre usuarios, de forma controlada por el
operador. La comunicación entre usuarios está orientada a las sesiones, que permiten
aglutinar de forma integrada diversos medios dentro de la misma comunicación: vídeo,
audio, intercambio de documentos, mensajería instantánea, y cualquier otro flujo de datos
de cualquier índole.
Utilizando estas capacidades genéricas del IMS de 3GPP, TISPAN define un servicio
telefónico multimedia con servicios de simulación de RDSI. Este servicio telefónico pretende
ofrecer a los abonados una visión de los servicios de comunicaciones personales NGN con
la misma experiencia de usuario que los servicios telefónicos tradicionales, pero con la
ventaja de la flexibilidad de la nueva tecnología IMS. Por ejemplo, la posibilidad de
establecer llamadas telefónicas de voz y añadir flujos de media (audio o vídeo) de forma
dinámica durante la llamada en curso, como es el caso de la transformación de la llamada
de voz en una videollamada o la transferencia de imágenes en el contexto de la llamada
vocal. Adicionalmente, el servicio telefónico multimedia se complementa con los servicios
suplementarios de la RDSI simulados sobre IMS. Esto permite una suave transición para los
57/78
Módulo 4
operadores RDSI/PSTN hacia NGN, y la evolución del propio servicio telefónico tradicional
hacia un concepto más rico y atractivo.
TISPAN define un conjunto mínimo de servicios de simulación para la telefonía multimedia,

que permitan a los operadores cumplir la legislación vigente para ofrecer servicios
telefónicos en el ámbito de regulación regional, y un conjunto no obligatorio de servicios de
simulación. Dentro de los primeros, se consideran los servicios de presentación y restricción
de la identidad del usuario origen y destino de una comunicación, la detección de
comunicaciones maliciosas y la posibilidad de rechazar comunicaciones anónimas. Dentro
del grupo de servicios de implementación recomendada y opcional se han definido servicios
de simulación como los desvíos de comunicaciones, la suspensión de comunicaciones, el
bloqueo, la indicación de mensaje de buzón, conferencias, transferencias de
comunicaciones, etc.
Dentro de la arquitectura NGN, IMS se ubica como un subsistema de control del plano de
servicios, y su relación con otros subsistemas y entidades de la NGN sigue el mismo modelo
que en 3GPP. Este último organismo, a petición de TISPAN, ha mejorado y añadido
modificaciones en la release 7 para adaptar IMS al entorno de la banda ancha fija. Sin
embargo, existen en la release 1 de NGN ciertas divergencias entre el IMS de 3G y la
versión NGN, que se espera sean también adoptadas por 3GPP en el futuro próximo.
El subsistema IMS presenta una arquitectura horizontal por capas que permite separar cada
una de las funcionalidades específicas: una capa de aplicación, una de control y una capa
de conectividad. La arquitectura de este subsistema se muestra en la Figura 16, en la cual
se observan las distintas entidades y subsistemas con los que interactúa el núcleo (core)
IMS.
Figura 16. Arquitectura del subsistema IMS.
58/78
Módulo 4
Esta arquitectura por capas permite a cada una de ellas evolucionar de forma independiente
a medida que el mercado y la tecnología lo permitan. Soporta la migración hacia nuevas
tecnologías de transporte haciendo las capas superiores independientes de la tecnología de
transporte subyacente en el plano de transporte.
Las entidades principales del IMS son las mismas que en el modelo de 3GPP, sin embargo,
algunos de los elementos de la versión original de IMS se han extraído del núcleo IMS de
TISPAN: algunas de estas entidades se ubican en el plano de servicios, mientras que otras
se han desplazado al plano de transporte.
Así, los elementos encargados de la interconexión con redes heredadas (PSTN/ISDN),

como son los SGF (Signalling Gateway Function) y los MGF (Media Gateway Function),
junto con los servidores MRFP (Media Resources Function Processor) para la inserción y
mezcla de flujos RTP y para transcodificación y reconocimiento de voz y tonos, se han
ubicado en el plano de transporte, dentro del subsistema de funciones de transferencia.
Por otro lado, los AS (Application Server), los UPSF (User Profile Server Function) y los SLF
(Subcription Locator Function) también han sido desplazados. En este caso se han ubicado
en el plano de control, facilitando el acceso de otros subsistemas de control del plano de
servicio a estas entidades.
Una vez mostradas las principales diferencias entre el modelo IMS de TISPAN y el de
3GPP, se debe indicar que las entidades funcionales reciben el nombre de:
• Customer Premises Equipment (CPE). Bajo esta denominación TISPAN engloba

todos los dispositivos en el ámbito residencial que componen el equipo del usuario
NGN.
• Proxy Call Session Control Function (P-CSCF). Es el punto de acceso para los
terminales NGN al núcleo IMS. Conecta al usuario con un Serving CSCF que le
proporciona el servicio. Además, implementa la seguridad de acceso a IMS, y se
encarga de gestionar la calidad de servicio y los recursos del plano de transporte de
forma coherente con el servicio IMS prestado, a través de RACS.
• Serving Call Session Control Function (S-CSCF). Registra a los abonados y realiza
las funciones de control de sesión para los usuarios. Se encarga de determinar
cuando un determinado servicio de valor añadido ha de ser invocado y contacta con
el Application Server que aloja dicho servicio. Se relaciona con el UPSF para las
tareas de registro de abonados y prestación de servicios suplementarios.
• Interrogating Call Session Control Function (ICSCF). Este CSCF se encarga de

determinar el Serving CSCF correspondiente a un determinado abonado para las
operaciones de registro y sesiones entrantes, a partir de la información alojada en el
UPSF.
• User Profile Server Function (UPSF). Este elemento cumple las funciones
equivalentes al HSS de 3GPP. Así, almacena los datos que definen a un abonado, el
estado de registro en la red incluyendo el Serving CSCF con el que se ha registrado
59/78
Módulo 4
el abonado, y almacena los perfiles de servicio que permiten al Serving CSCF

invocar servicios de valor añadido.
• Subscriptor Locator Function (SLF). Coordina los accesos que existan al UPSF, en
caso de haber más de uno.
• Media Gateway Control Function (MGCF). Se encarga de conectar sesiones IMS con
redes heredadas basadas en conmutación de circuitos. El MGCF traduce
señalización IMS a protocolos de la red heredada como BICC o ISUP (Integrated
Services User Part), y controla el MGF (Media Gateway Function), para que dicha
entidad realice la conversión de IP (conmutación de paquetes) a TDM (conmutación
de circuitos).
• Breakout Gateway Control Function (BGCF). En caso de que el núcleo IMS detecte
que una sesión IMS tiene como destino un usuario de una red PSTN o RDSI, se
encarga de determinar el punto de entrada (MGCF) a dicha red heredada.
• Media Resources Control Function (MRCF). Entidad de control de los MRFP (Media
Resources Function Processor), que aporta funcionalidades extra a las
proporcionadas por los MGF para la interconexión con redes heredadas de
conmutación de circuitos, así como la provisión de servicios que impliquen
operaciones sobre los flujos RTP asociados a una comunicación: conferencias,
locuciones y grabaciones.
• Application Server Function (ASF). Ofrece servicios de valor añadido a los usuarios.
Este puede estar localizado en la red del operador o en una ubicación externa. En
TISPAN se definen dos tipos de ASF. El ASF de tipo uno tiene como objetivo
controlar los recursos de transporte a través de RACS. El ASF de tipo dos depende
del subsistema de control que proporciona el servicio básico sobre el que se
construye el servicio de valor añadido. Este tipo es idéntico al Application Server de
3GPP.
• Charging and Data Collection Function. Contiene funciones de recopilación de datos

para realizar la facturación (tanto facturación online como offline), y otras funciones
de control que pueden usar los mismos datos.
La provisión de servicios de valor añadido a través de IMS sigue la misma filosofía que la
tradicional red inteligente: los nodos de control de sesión (Serving CSCF) obtienen del UPSF
los datos de abonado que permiten diferenciar aquellos eventos dentro de una
comunicación que van a implicar la participación de un determinado ASF en el control de la
sesión. Estos ASF alojan la lógica del servicio prestado. De esta forma, la provisión de un
servicio consiste en definir una serie de criterios de filtrado en el perfil del abonado. El
Serving CSCF comprueba esta información de filtrado para determinar cuando delegar el
control de una sesión a un servicio contenido por un ASF.
A diferencia de la red inteligente, la tecnología de creación de servicios IMS se acerca más

al mundo web y los servicios de Internet, lo que simplifica el proceso de creación, puesta en
producción, mantenimiento y supervisión de nuevos servicios. Destaca la familia de
60/78
Módulo 4
tecnologías de desarrollo englobada dentro de la iniciativa JAIN (Java Applications for

Intelligent Networks), que incluye a SIP Servlets y SLEE (Service Logic Execution
Environment).
Como se aprecia en la exposición sobre la arquitectura IMS en TISPAN, la interoperabilidad

con otro tipo de redes basadas en conmutación de circuitos y de paquetes está considerada
en el plano de servicios de TISPAN. Además, la interoperabilidad con servicios móviles 3G
IMS será inmediata cuando se solucionen las divergencias entre el uso de IMS por TISPAN
y el modelo estándar de 3GPP.
4.8. PES: Emulación de los servicios proporcionados por la PSTN

y la RDSI
La finalidad de este subsistema es la evolución de la PSTN actual, basada en conmutación

de circuitos, a una solución basada en conmutación de paquetes con IP como protocolo de
red. Pero al contrario de lo que ocurre en IMS, que está pensado para terminales móviles de
nueva generación con soporte IP nativo, o para teléfonos IP (softphones y hardphones)
conectados a la red mediante accesos fijos de banda ancha, en el subsistema PES lo que
se plantea es la evolución hacia IP del actual servicio telefónico básico, sin modificar las
interfaces de usuario del servicio telefónico convencional. De este modo, el usuario no
percibirá que se ha modificado la forma en la que se le proporciona el servicio telefónico
convencional.
El despliegue de este subsistema permitirá a los operadores fijos tradicionales la sustitución

de su infraestructura basada en centrales de conmutación TDM por otra basada en
conmutación de paquetes IP, sin modificar, como ya se ha indicado antes, las interfaces de
usuario (véase la Figura 17). Es decir, este subsistema es el que permitiría lo que se conoce
como:
• Class 4 replacement, o sustitución de todas las centrales de tránsito de un operador

telefónico convencional.
• Class 5 replacement, o sustitución de las actuales centrales locales (clase 5) y DLCs

V5.2 por plataformas que manteniendo la interfaz de línea (línea analógica, acceso
básico RDSI o BRI, y acceso primario RDSI o PRI), y por tanto, la misma
funcionalidad de cara al usuario final, concentran todo el tráfico agregado
correspondiente a los servicios de voz convencionales a través de interfaces
agregadas IP controladas por el subsistema PES.
61/78
Módulo 4
Figura 17. Entorno del subsistema PES.
El hecho de que un operador opte por desplegar o no este subsistema para seguir dando el
servicio básico en un entorno all IP, dependerá de si decide, a su vez, promover la migración
de los servicios vocales hacia la solución IMS.
El subsistema PES está comenzando a ser tratado por TISPAN y hay dos posibles
planteamientos:
1. La solución basada en el concepto softswitch. Esta es la solución contemplada en la

release 1 de NGN.
2. La solución basada en una evolución del modelo IMS. Esta opción se plantea ya
para la release 2 del modelo.
Para el interfuncionamiento entre la PSTN/ISDN y el subsistema PES, que pueden

pertenecer a operadores de red diferentes, es fundamental el tratamiento a dar a la
señalización. La propuesta de TISPAN se basa en una interconexión como la que
actualmente se está empleando, basada en ISUP sobre enlaces TDM. Pero en el caso de
que la interconexión se produzca entre dos operadores NGN, y dado que lo lógico es que en
ese caso la interconexión tanto de los flujos de media como de señalización sea IP, lo que
TISPAN plantea es el uso de SIP-I, que básicamente es señalización SIP que transporta
mensajes ISUP como un cuerpo de mensaje MIME.
62/78
Módulo 4
Otro aspecto a señalar es que en el subsistema PES, dado que se trata de emular mediante
una red troncal IP los servicios telefónicos convencionales, se ha de trabajar con el
esquema de direccionamiento empleado en la PSTN/ISDN. Es decir, que en el subsistema
PES, el encaminamiento de las llamadas se ha de hacer atendiendo a las direcciones E.164.
En un entorno NGN, un usuario puede tener diversos identificadores, como puede ser un
número de teléfono (dirección E.164) y una URI (Uniform Resource Identifier), que es el
identificador de usuario empleado en las soluciones VoIP/ToIP basadas en SIP. Y tanto en
un escenario IMS como en un escenario PES, nos podemos encontrar con llamadas entre
usuarios que en un momento dado estén empleando mecanismos de identificación
diferentes, dentro del conjunto de opciones permitidas en un entorno NGN. En esas
circunstancias puede ser necesaria una traducción del identificador del usuario llamado. Es
decir, es preciso un mecanismo que permita transformar URIs en direcciones E.164 y
viceversa. El protocolo ENUM (tElephone NUmber Mapping) es fruto del estudio de un grupo
de trabajo del IETF, cuyo objetivo principal ha sido la definición de una arquitectura y un
protocolo, basados en DNS, que permita establecer la correspondencia entre números de
teléfono (direcciones E.164) y URIs.
4.8.1. PES basado en “softswitch”
Esta opción se basa en el concepto de softswitch, promovido por la industria a finales de los
años 90 para que los operadores de redes IP pudiesen ofrecer soluciones de telefonía sobre
IP en competencia con los operadores telefónicos dominantes. El conjunto de softswitch
abarca básicamente tres bloques:
1. Un núcleo encargado del control de estado de las llamadas o Call Control, que
realiza el establecimiento, mantenimiento y liberación de las llamadas, y la
generación de los correspondientes registros de tarificación.
2. Un elemento para el control de las pasarelas con la PSTN o Media Gateway

Controller, bajo el control del Call Control.
3. Y un elemento que actúa de interfaz para la interconexión, en lo que a señalización

de las llamadas se refiere, con la PSTN. Por tanto, este elemento se encarga, bajo el
control del Call Control, de transformar la señalización empleada en la red troncal IP
en señalización estándar de la PSTN, ISUP/SS7.
Este tipo de plataformas se desarrolló sin ningún tipo de estándar de referencia, ni en lo que
a arquitecturas ni en lo que a protocolos se refiere. Eso dificultaba cualquier tipo de
interoperabilidad, y las soluciones desarrolladas al amparo de ese concepto, en general, han
adolecido de grandes problemas, como bajas prestaciones, falta de escalabilidad y escasa
fiabilidad.
En esta opción para el subsistema PES se parte del concepto de softswitch, pero incluyendo
mejoras como son una arquitectura de referencia y la estandarización de todas las interfaces
externas del subsistema, así como la posibilidad de una solución distribuida, con el fin de
ofrecer las prestaciones y escalabilidad requeridas desde el punto de vista de un operador
63/78
Módulo 4
dominante. En la Figura 18 se muestra la propuesta de subsistema PES basado en un

softswitch.
Figura 18. Subsistema PES basado en un “softswitch”.
4.8.2. PES basado en IMS
En este caso se parte del subsistema IMS, tal y como se ha descrito anteriormente, y lo que
se plantea es la incorporación de los elementos necesarios para emular los servicios de
clase 4 y clase 5 de la PSTN/ISDN. En la Figura 19 se muestra la propuesta de TISPAN
para un subsistema PES basado, a su vez, en el subsistema IMS.
Como se puede apreciar en esta figura, el único elemento añadido respecto al núcleo del
subsistema IMS es el AGCF (Access Gateway Control Function). El objetivo de este
elemento es el control de las pasarelas o media gateways de acceso, encargadas de la
transformación de las señales analógicas (POTS) y tramas TDM de los accesos telefónicos
básicos en flujos de paquetes IP y viceversa.
Las ventajas de un subsistema PES basado en una arquitectura IMS son el

reaprovechamiento de todos los elementos del subsistema IMS, y el hecho de disponer de
una arquitectura distribuida y, por tanto, escalable.
64/78
Módulo 4
Figura 19. Subsistema PES basado en el modelo IMS.
4.9. Subsistema de “streaming”
Dentro del modelo NGN, este subsistema (Streaming Subsystem) sería el encargado de los
servicios de streaming, como el vídeo bajo demanda (Video on Demand, VoD), en los que el
control se efectúa por medio de RTSP. Por tanto, este subsistema se encarga de
proporcionar aquellos contenidos que son servidos de forma aislada para cada usuario, es
decir, cada usuario pide un contenido que es servido mediante un flujo o stream dedicado.
Por ejemplo, en el servicio de vídeo bajo demanda, cada usuario elige su película y ésta es
proporcionada mediante streams diferentes para cada petición.
Las plataformas de IPTV, como por ejemplo Imagenio, proporcionan este tipo de servicios.
Pero se ha de tener presente que dentro del marco de NGN este tipo de servicios no se ha
tratado aún, por lo que a continuación se sugieren vías de evolución de los actuales
servicios de VoD sobre IP hacia un modelo integrable en una arquitectura NGN. Para ello se
analizan los diferentes bloques integrantes genéricos de una plataforma de servicios de VoD
y su posible correspondencia con los planos y subsistemas definidos en el modelo NGN.
La arquitectura para ofrecer servicios de streaming consta de un conjunto de servidores de

contenidos (vídeo y audio), una aplicación que proporciona el acceso al servicio, y un
elemento encargado de la autorización de acceso al servicio, siendo, además,
65/78
Módulo 4
imprescindible la existencia de una red que proporcione conectividad entre los usuarios y los
elementos indicados.
4.9.1. Servidores de contenidos
Entre los componentes antes indicados, el núcleo del subsistema de streaming es el

servidor de contenidos. Este elemento es el que atiende las peticiones de los usuarios y
suministra y controla el flujo de paquetes, de forma que el contenido sea obtenido
adecuadamente. Las interacciones entre el usuario y el servidor se realizan directamente sin
sistemas intermediarios. Se pueden emplear varios protocolos para ello, pero el más
empleado es RTSP.
Por tanto, los servidores de contenidos son los elementos de control del subsistema de
streaming, y dentro de la arquitectura NGN, se corresponderían con un AF (Application
Function). Estos servidores reciben las peticiones de los usuarios, donde RTSP es el
protocolo empleado para la señalización entre el usuario y el servidor. La peculiaridad de
estos elementos de control radica en que no sólo intervienen en la señalización, también
suministran el flujo de datos, empleando para ello RTP.
Los contenidos han de ser protegidos por mecanismos de cifrado para evitar su
reproducción en caso de captura del flujo de datos. Pero ello supone conocer la clave de
cifrado para recuperar el contenido original. Al mismo tiempo, se ha de garantizar que la
clave sea conocida únicamente por el proceso encargado de descifrar el contenido y no por
el propio usuario.
Se deben usar algoritmos de última generación para el cifrado, cuidando aquellos puntos
que afecten a la carga del proceso de cifrado y descifrado. El algoritmo y longitud de la clave
empleados puede aumentar el ancho de banda requerido para la transmisión y la capacidad
de procesamiento del cliente que descifra el contenido, por encima de lo admisible para el
servicio.
El cifrado del contenido puede realizarse en tiempo real en el momento en que el contenido
es transmitido, o bien almacenando el contenido previamente cifrado en el servidor de vídeo.
En ambos casos, y como ya se ha apuntado anteriormente, un aspecto fundamental es la
forma en la que se hace llegar la clave al proceso del usuario encargado de descifrar el
contenido. La gestión de las claves de cifrado la efectúa otra aplicación, residente en el área
de servicios, tal y como se explica en el siguiente punto. Esta aplicación proporciona la clave
empleada en el cifrado en el momento de solicitar el contenido. Para la transmisión de la
clave de cifrado ha de emplearse a su vez un canal seguro, como por ejemplo una
comunicación cifrada. Para cifrar esta comunicación se pueden emplear mecanismos de
clave asimétrica, ya que la información transferida en la gestión es pequeña en comparación
con el volumen del contenido a transmitir.
66/78
Módulo 4
4.9.2. Aplicación de acceso al servicio
Otro de los elementos integrantes del subsistema de streaming es la aplicación que permite
el acceso al servicio, proporcionando al usuario la información necesaria sobre el servicio,
para seleccionar contenidos, obtener las claves para la descodificación de los contenidos
cifrados, etc.
Esta aplicación reside en servidores de aplicaciones accesibles directamente por los

usuarios. Por tanto, esta aplicación es un equivalente a un Application Server del
subsistema IMS.
Antes de visualizar un contenido, la petición ha de ser autorizada, y para ello el contenido ha

debido ser adquirido previamente a través del sistema de compras, de forma que la compra
del contenido quede registrada y pueda ser facturada. La aplicación del cliente envía la
petición de compra hacia el sistema de compras, y a partir de este punto se desencadena el
proceso de autorización y la adquisición del contenido queda registrada (véase la Figura 20).
Al mismo tiempo, la aplicación del cliente le pide al servidor el contenido. En ese instante el
servidor comprueba que la petición puede ser servida preguntando al elemento de
autorización. En caso de respuesta afirmativa, el servidor proporcionará el flujo solicitado al
cliente.
Figura 20. Acceso a los contenidos del subsistema de “streaming”.
67/78
Módulo 4
4.9.3. Autorización
Ha de existir un bloque encargado de la autorización de accesos al subsistema de

streaming. Es decir, un elemento que controle qué usuario accede al contenido y si éste
tiene permiso para visualizarlo. Al mismo tiempo, este elemento también toma en cuenta
otros factores para autorizar un servicio, como por ejemplo la existencia de recursos
suficientes para ofrecer un nuevo contenido.
Las peticiones de contenidos son recibidas directamente por el servidor de contenidos, sin
embargo, éste no tiene capacidad para determinar si estas peticiones deben ser atendidas o
no. Por tanto, el servidor interactúa con el bloque de autorización, que es el encargado de
decidir la autorización de las peticiones recibidas (véase la Figura 12).
Figura 21. Autorización de acceso a los contenidos del subsistema de “streaming”.
La decisión para autorizar o denegar el acceso a un contenido se toma atendiendo a dos

criterios: los derechos del usuario, tales como contrato o alquiler de contenidos, y la
disponibilidad de recursos en el sistema. En este sentido:
• En primer lugar, el usuario puede ser autenticado atendiendo a diferentes criterios,

como su dirección IP o un perfil. En el caso de un escenario basado en
direccionamiento IP fijo, esta autenticación resulta sencilla, pero no así en un
escenario en el que la dirección IP se asigne dinámicamente, ya sea vía DHCP o vía
PPPoE. En ese caso, y en un modelo NGN, el bloque encargado de la autorización
en el subsistema de streaming deberá tener interfaz con el NASS. Conocido el
usuario, los servicios disponibles se obtienen de una base de datos, que podrían ser
las bases de datos con los perfiles de usuario contemplados en dicho modelo.
68/78
Módulo 4
En un escenario final, caracterizado por la movilidad (nomadismo), se ha de

contemplar que un mismo usuario, en momentos diferentes, acceda a los servicios
ofrecidos por el subsistema de streaming de la red del operador con el que ha
contratado el servicio, a través de las redes de terceros. Y éstos pueden emplear
distintos mecanismos de acceso y de asignación de direcciones IP (dirección IP fija o
dinámica, PPPoE o DHCP), por lo que en ese escenario futuro, en el elemento de
autorización del subsistema de streaming, la lógica empleada para la autenticación
deberá contemplar diferentes posibilidades.
• En segundo lugar, ante una petición ha de calcularse si existe ancho de banda

suficiente para soportar el flujo de vídeo correspondiente. Las peticiones recibidas en
el sistema de autorización pueden ser de uno de los siguientes tipos:
o Reserva de ancho de banda. El servidor de contenidos solicita reservar ancho de

banda para atender una petición de un contenido. A partir de esa petición, el
sistema de autorización ha de consultar si hay recursos (ancho de banda
disponible) para atender esa petición, y en caso afirmativo, se reserva el ancho
de banda correspondiente y se contabiliza como ocupado.
o Liberación de ancho de banda. Cuando el servidor cierra una sesión, informa de

la liberación al sistema de autorización. De esta forma, el ancho de banda que
ocupaba esta sesión se libera y ya no contabiliza en sucesivas peticiones de
servicios.
Todo esto supone, en un escenario integrado dentro del modelo NGN, una
interacción adicional del subsistema de streaming, a través de su elemento de
autorización, en este caso con el subsistema RACS. Y esta interacción consiste en
ampliar el control de admisión de accesos o CAC (Call Admission Control) del RACS
para que incluya los recursos liberados o consumidos a través del subsistema de
streaming.
Si el resultado de cualquiera de estas comprobaciones es negativo, significa la negación de

autorización para el servicio. Yello hace que el servidor rechace la petición de acceso al
servicio.
4.9.4. Transporte
El último elemento necesario para un servicio de streaming de contenidos bajo demanda es

el propio backbone IP. Éste no forma parte del subsistema de streaming, pero es el que ha
de proporcionar los recursos necesarios para el transporte de los flujos de señalización y
contenidos.
Dadas las características de los tráficos solicitados al subsistema de streaming, se pueden

plantear soluciones que drenen el caudal asociado a estos contenidos del tráfico total que
transita por una red troncal IP que también da soporte a otro tipo de servicios como pueden
ser los servicios de acceso a Internet de alta velocidad, o los servicios de telefonía
multimedia sobre IP.
69/78
Módulo 4
Pero en un escenario caracterizado por la movilidad, si los servidores de vídeo se conectan

a una red IP de propósito general, se conseguirá que sea cual sea la red a través de la cual
acceda el usuario final, éste pueda obtener los contenidos demandados. Y en un entorno
donde el acceso al servicio puede realizarse desde múltiples plataformas y redes de acceso,
deben existir los sistemas capaces de compatibilizar el streaming con estas plataformas.
4.10. Subsistema de difusión de contenidos
Este subsistema (Content Broadcasting Subsystem) agrupa los servicios de difusión de

contenidos a grupos de usuarios. El mismo contenido es enviado al mismo tiempo a un
grupo de usuarios. Dentro de estos servicios de difusión de contenidos entran los servicios
de distribución de canales de TV y Pay Per View. En este tipo de servicios las técnicas de
transporte son diferentes a las de streaming bajo demanda, ya que uno de los objetivos es
reducir la cantidad de paquetes replicados que circulan por la red.
Se utilizan técnicas multicast con este fin, y esto influye en la arquitectura y el modo de
acceso al servicio.
Los usuarios de este tipo de servicios están distribuidos sobre una extensa zona geográfica,
mientras que el contenido de vídeo es generado en un punto central, o en un reducido
conjunto de puntos, y desde ahí se distribuye a todos los usuarios. Con el fin de evitar que el
contenido demandado por estos usuarios (que en el caso de un canal de TV es el mismo
para todos ellos) consuma los recursos de transmisión de la red, se emplea multicast. La
distribución se estructura en dos niveles: en un primer nivel se distribuye el mismo contenido
a un conjunto de puntos de distribución locales, y en una segunda fase, en estos puntos de
distribución local, se replica el mismo contenido hasta los usuarios que han solicitado dicho
contenido.
La distribución desde la cabecera hasta los puntos locales se puede hacer de diversas
formas, por ejemplo, mediante un backbone MPLS, o bien mediante circuitos dedicados. En
los puntos de distribución locales el contenido sólo se replica hacia aquellos usuarios
conectados a dichos puntos de distribución locales que hayan demandado dicho contenido.
La cuestión es cómo se implementa esta distribución. La solución idónea pasa por el empleo
de un backbone IP con soporte de multicast, por ejemplo, usando PIM para el envío de cada
uno de los contenidos (canales), e IGMP para la gestión del acceso a cada canal (grupo
multicast) en los IP Edge Router de la red (por ejemplo, un BRAS). Esta solución es la
aconsejable, y más si se contempla un escenario con movilidad en el que un usuario acceda
en momentos diferentes a este tipo de servicios a través de redes de operadores distintos.
Pero, aunque conceptualmente sea la solución aconsejable, su realización no es sencilla: la
red del operador del servicio debe soportar multicast (IGMP y PIM), y la red de acceso debe
soportar IGM en sus IP Edge Nodes, siendo necesario, además, un elemento que adapte las
peticiones de multicast hechas desde redes de acceso de terceros en un stream desde la
red del proveedor del servicio. Este último aspecto requerirá sin duda un estudio minucioso
por parte de TISPAN.
Una plataforma de IPTV como Imagenio proporciona los servicios propios del subsistema de
difusión de contenidos del modelo NGN. Pero las plataformas actuales de IPTV se basan en
70/78
Módulo 4
una arquitectura propietaria. Por tanto, partiendo de esa situación, y teniendo en cuenta que
la release 1 del modelo NGN no ha abordado todavía este subsistema, se va a plantear
cómo ir integrando los servicios de distribución de canales de TV sobre IP y PPV en una
arquitectura tipo NGN.
Como ya se ha comentado, para los servicios de distribución de canales de TV sobre IP, ya

sea en abierto o en pago por visión, se puede emplear una solución técnica basada en
multicast IP y en IGMP para gestionar el acceso a ese tipo de servicios.
IGMP permite la suscripción de clientes a un grupo multicast, y la posterior liberación de

estas subscripciones. De forma resumida, cada IP Edge Node (BRAS) atiende las
solicitudes que recibe para la suscripción a los grupos de multicast. Además, el IP Edge
Node registra la suscripción y empieza a enviar el correspondiente stream multicast al
cliente a través de la interfaz correspondiente. Cuando el usuario abandona el grupo, envía
una solicitud al IP Edge Node y éste lo atiende eliminando el registro de este usuario.
Adicionalmente, el IP Edge Node comprueba si hay más clientes interesados en este grupo
comunicando por el mismo enlace físico que el usuario acaba de liberar su sesión. Si no
existen otros usuarios interesados en el contenido, éste cesa el stream por esta interfaz.
Estas tareas tienen diferentes implementaciones en función de la versión IGMP empleada.
Según lo expuesto, para los servicios de distribución de contenidos no sería necesario un

elemento de control, un AF en el plano de control, pues el acceso al grupo multicast
correspondiente a un determinado contenido es gestionado directamente por el IP Edge
Node. Pero no es así. Para llegar a ese punto se ha de conocer previamente la dirección IP
multicast del contenido solicitado, para que una vez pedida la suscripción al grupo multicast,
se desencadenen las operaciones necesarias para permitir que el usuario reciba el flujo
asociado a ese contenido, y quede constancia de las peticiones con el fin de facturar dichos
contenidos. Por tanto, además del mecanismo por medio del cual se envían los contenidos a
los usuarios, son necesarios otros elementos para integrar los servicios de distribución de
contenidos en un esquema NGN. Estos elementos son básicamente dos:
1. Aplicaciones que permitan la prestación del servicio.
2. Autenticación y autorización de las solicitudes de los usuarios, y control de admisión

de los flujos asociados.
4.10.1. Aplicaciones
En primer lugar se necesita una aplicación que permite seleccionar al usuario el contenido
que quiere ver. Por medio de esta aplicación se selecciona el canal y el STB del usuario
obtiene la dirección IP del grupo multicast al que ha de suscribirse para recibir el canal
solicitado.
Esta aplicación, dentro de un modelo NGN, se podría corresponder con un Application

Server del subsistema IMS. Pero se necesitan otras aplicaciones que a partir de la selección
del usuario, permitan efectuar la compra efectiva del contenido solicitado por el usuario:
71/78
Módulo 4
• Desencadenando las operaciones necesarias sobre el resto de subsistemas del

plano de transporte necesarias para la prestación del servicio.
• Generando los registros de tarificación necesarios para la facturación al cliente de

esos contenidos.
Desde una perspectiva como la planteada por TISPAN, todas estas aplicaciones se pueden
considerar como las correspondientes al plano de control del subsistema de broadcast.
4.10.2. Autorización y control de admisión
A la hora de autenticar y autorizar el acceso a los contenidos, se pueden plantear dos

alternativas:
1. Emplear un componente dedicado a la autorización del acceso al subsistema de

broadcasting. En ese caso, la solicitud de unión a un grupo multicast vía IGMP es
recibida por el IP Edge Node, y éste pide la autorización al servicio de autenticación.
2. Si no se usa un servidor AAA, entonces el IP Edge Node toma él mismo la decisión

sobre autenticación y autorización, empleando para ello filtros que especifiquen las
direcciones IP (usuarios) que pueden unirse a cada grupo multicast.
De las dos opciones anteriores, la primera encaja fácilmente con la autenticación de

accesos contemplada en el modelo NGN a través del subsistema NASS. De esta forma, los
usuarios solicitan el contenido mediante un mensaje IGMP al elemento de red encargado de
realizar el multicast IP. Y desde éste se consulta al servidor de autorización empleando el
protocolo adecuado, por ejemplo RADIUS o Diameter. En función de la respuesta, la
petición de acceso se autoriza o se rechaza, y en el caso de aceptarse, el subsistema NASS
debería actuar sobre las aplicaciones de control del subsistema para que éstas, a su vez,
actúen vía el subsistema de control de recursos (RACS), y se proceda a reservar los
recursos necesarios en la plataforma de acceso (IP Edge Nodes).
En cambio, en la segunda alternativa el control de admisión puede ser realizado mediante

filtros de tráfico IP en las plataformas de red, en concreto en el IP Edge Node, de forma
robusta y eficiente. Sin embargo, este escenario no es practicable en una red donde la
movilidad obliga a independizar al usuario de su dirección IP y a perder el control sobre ésta.
Por tanto, se plantean opciones de uso de mecanismos independientes de los parámetros
de la red de acceso. La forma más flexible para conseguir esto es el uso de un sistema de
autorización que interactúe con otros subsistemas, conozca el estado de la red y la
información asociada al perfil de cada usuario.
En el caso de uso de filtros, éstos se configuran en los IP Edge Node que dan acceso a los
usuarios, actuando como filtros para las peticiones de los propios usuarios. El elemento de
red dispone de un filtro que especifica las direcciones IP que están habilitadas para unirse a
cada grupo multicast. Existirán tantos filtros como grupos multicast (contenidos). El distintivo
empleado para identificar al usuario es su dirección. Cuando un usuario contrata un nuevo
servicio, por ejemplo un partido de fútbol en pago por visión, se modifica la configuración del
72/78
Módulo 4
equipo afectado con el fin de incluir la dirección IP del usuario en la lista de acceso.
Igualmente, cuando el usuario abandona el servicio, también es necesario realizar una
modificación de las listas de acceso con el fin de eliminar al usuario de aquellos grupos
multicast que corresponden a los servicios abandonados.
El uso de filtros puede ser una solución rápida y robusta, ya que en principio no se requeriría
consultas a otros sistemas, y es el propio equipamiento de red el que tiene la capacidad de
decisión sobre la petición. Esta opción requiere un elemento de configuración de las
plataformas de la red de acceso. Para implementar esta solución, hay dos posibilidades:
1. El uso de mecanismos de configuración, lo que sólo sería valido en un modelo

vertical en el que una misma compañía tenga el control del acceso, el núcleo de red
y los contenidos. Pero esto no sería válido en un entorno con movilidad, en el que un
mismo usuario puede acceder desde distintas redes de acceso operadas por
distintos operadores con diferentes suministradores para sus plataformas de red.
2. La posibilidad de que dicho elemento de configuración, siguiendo el modelo

planteado en la arquitectura NGN y a partir de las aplicaciones del plano de control
del subsistema, actúe como un SPDF del subsistema RACS y vía una interfaz Rq
estándar envíe las políticas de filtrado multicast a aplicar en los IP Edge Node, con
independencia de que estas plataformas pertenezcan a su propia red o a la de un
tercero.
4.11. Aplicación del modelo NGN a medio plazo a una oferta

“quadruple play”
Se entiende por oferta "quadruple play" aquella que integra, además del acceso a Internet
de alta velocidad, servicios multimedia como televisión interactiva y servicios de telefonía
multimedia fija y móvil.
Como ya se ha ido exponiendo en apartados anteriores, el modelo NGN es un modelo en

desarrollo, cuyos objetivos globales distan mucho de alcanzarse a corto plazo. El esfuerzo
actualmente se centra en los servicios telefónicos multimedia, así como en lo referente a los
subsistemas encargados del control del acceso y la asignación de recursos.
Pero aun así, ya es viable plantear a medio plazo un escenario en el que un operador como
Telefónica pueda ofrecer una oferta integrada de servicios de voz fija y móvil, TV interactiva
y acceso a Internet de alta velocidad.
Lo que está contemplando el grupo TISPAN en la release 1 de NGN permitiría plantear un

escenario como el mostrado en la Figura 22. En el mismo se observa un bloque de control
basado en el subsistema IMS que permitiría ofrecer servicios de telefonía multimedia por
medio de una solución IP, tanto a aquellos usuarios con accesos fijos de banda ancha que
dispongan de teléfonos IP o softphones como a usuarios con terminales móviles 3G. El
mismo núcleo de red permitiría servicios de acceso a Internet de gran velocidad (HSI, High
Speed Internet Access). El único servicio de la oferta "quadruple play" no soportado por el
mismo núcleo de red sería el correspondiente a los servicios de IPTV, cuya plataforma
73/78
Módulo 4
actual se conectaría tal y como lo está haciendo actualmente a la red de agregación de

acceso de nivel dos. Y de esta forma sí que se podría comercializar una oferta quadruple
play para usuarios con accesos fijos de banda ancha empleando un núcleo de red único,
con la única salvedad relativa a la forma en la que se integran los servicios de IPTV, que al
menos compartirían la red de agregación de acceso.
Figura 22. Integración de las redes para una oferta de servicios de telefonía, TV y datos.
En el esquema de la figura anterior también se contemplan la integración en ese único

núcleo de red de los servicios de telefonía móvil para todos aquellos usuarios con acceso
móvil 3G, siempre a través del dominio PS.
En dicha figura no se incluye la emulación sobre IP de los actuales servicios de telefonía fija.
Como ya se ha explicado antes, el subsistema que permitiría esta emulación de los servicios
telefónicos convencionales no está completamente estandarizado. Eso será posible en la
medida en que avance, dentro del marco de la release 2 de NGN, la estandarización del
subsistema PES. Pero parece previsible que en un plazo de tiempo no excesivamente
dilatado sea posible plantear la progresiva sustitución de su infraestructura basada en
centrales de conmutación TDM por una infraestructura basada en conmutación de paquetes
IP, sin modificar las interfaces de usuario, tomando como punto de partida el subsistema
IMS y añadiendo los elementos necesarios para que pueda actuar también como PES.
Para una integración completa en el mismo núcleo de red habrá que esperar a futuras
versiones de la arquitectura NGN en las que finalmente se aborden los servicios multimedia
no basados en SIP, como son los servicios de streaming, así como los de TV interactiva. En
la medida que progrese el trabajo de estandarización del modelo NGN, cabe plantearse un
núcleo de red único como el que se muestra en la Figura 23.
74/78
Módulo 4
Figura 23. Núcleo de red único para una oferta integrada de servicios de telefonía fija y móvil, TV y
datos.
Es decir, la integración completa en un núcleo de red único de los servicios de una oferta
quadruple play, con capacidad para ofrecer nomadismo, se completará en la medida en que
los planos de transporte, servidores y aplicaciones de las plataformas IPTV se integren en
los planos equivalentes definidos en el modelo NGN, aun cuando no esté completamente
cerrada la estandarización de dicho modelo.
Este núcleo de red no sería válido únicamente para los usuarios con accesos fijos de banda
ancha y para usuarios con accesos móviles 3G. Al incluir el subsistema PES, también sería
válido para usuarios con acceso fijo de banda estrecha, lo que permitiría una migración
completa hacia la conmutación de paquetes de los servicios de telefonía fija basados en
conmutación de circuitos.
75/78
Módulo 4
5. Conclusiones
En este módulo se han analizado las acciones que el grupo de estandarización TISPAN está
realizando en el seno de la convergencia de redes. Se ha evaluado la estructura de este
comité de estandarización, describiéndose los diferentes grupos que lo integran.
Se puede decir que el proyecto estrella de TISPAN es la estandarización de las redes de

nueva generación, NGN. Debido a esto, se ha realizado una amplia descripción de las
mismas, tanto desde el punto de vista conceptual, como la arquitectura que TISPAN
propone. A continuación se recogen algunas de las conclusiones más relevantes de las
redes NGN, sobre todo como proveedoras de ofertas quadruple play.
Las redes NGN, que están actualmente en sus primeras fases de estandarización,
contemplan efectivamente la integración de todos los servicios, telefonía multimedia fija y
móvil, datos y servicios multimedia interactivos, en un único núcleo de red IP, contemplando,
además, la movilidad de los usuarios, servicios y terminales.
Para ello, en NGN se contempla un modelo estructurado en dos planos, uno de transporte y
otro de servicio, y este último dividido a su vez en control y servicios. Esta arquitectura
estructurada en capas permite a cada una de ellas evolucionar de forma independiente a
medida que el mercado y la tecnología lo permitan, y facilita la migración hacia nuevas
tecnologías de transporte haciendo las capas superiores independientes de la tecnología
subyacente en el plano de transporte.
Técnicamente ya es viable la integración en un único núcleo de red IP de una parte de los

servicios que integran una oferta quadruple play. Los servicios que se pueden integrar son
los de telefonía multimedia, tanto para usuarios con accesos fijos de banda ancha (xDSL),
como para usuarios con terminales móviles 3G accediendo a través del dominio PS (acceso
GPRS), así como el acceso a Internet de alta velocidad. El grado de integración de los
servicios de IPTV en el núcleo de red IP, dado que el modelo NGN no ha abordado todavía
esos servicios, dependerá de la arquitectura de la plataforma empleada para ese tipo de
servicios.
Respecto a los servicios de IPTV (streaming de contenidos de audio y vídeo, broadcast de

canales de TV y PPV), dado que el modelo todavía no ha abordado este tipo de servicios,
no es posible determinar cuál será el escenario final de integración. Una opción inicial
consistiría en la integración con la red de agregación de acceso de nivel dos. Y la
integración será completa en la medida en que el transporte de los flujos de estos servicios
se pueda efectuar a través de la red troncal IP, y las plataformas de control de los servicios
de IPTV puedan hacer uso de las facilidades que ofrecen los subsistemas para el control de
acceso (NASS) y los recursos de red (RACS). Otros de los puntos menos desarrollados del
modelo NGN son los relativos a la gestión y a la facturación integrada de los servicios que
componen una oferta integrada.
De todos modos, el proceso de definición del modelo no ha finalizado, por lo que hay una
serie de puntos abiertos, cuya resolución facilitará una integración completa de todos los
76/78
Módulo 4
servicios de una oferta integrada en un único núcleo de red. A modo de ejemplo, algunos de
estos puntos son:
• La escalabilidad y las prestaciones que puede ofrecer una red NGN. Pero no sólo la
escalabilidad y prestaciones de cada uno de los subsistemas del plano de servicio.
En un escenario en el que todos los servicios se van a ofrecer mediante una única
red troncal IP, tiene especial importancia la escalabilidad y las prestaciones que
pueden ofrecer los subsistemas situados en el plano de transporte, el NASS y el
RACS, que han de dar servicio a todos los subsistemas del plano de control.
• La disponibilidad y las prestaciones de una red NGN deberá ser al menos

comparable a la que hoy en día ofrece la PSTN, los famosos "cinco nueves"
(disponibilidad 99,999 %), que en tantas ocasiones se anuncian y no siempre se
consiguen. Y en cuanto a la escalabilidad, en un escenario a muy largo plazo,
debería ser capaz de permitir la sustitución de la PSTN.
• Las nuevas plataformas MSAN (MultiService Access Node). Estas nuevas

plataformas de acceso integran los accesos fijos e inalámbricos de banda ancha, con
la funcionalidad de A-MGF para los accesos de banda estrecha a los servicios
telefónicos convencionales. Es decir, son nuevas plataformas de acceso que
integran la funcionalidad de DSLAM para accesos xDSL y Access Point para
accesos inalámbricos, junto con la funcionalidad de A-MGF, con interfaces de línea
que permitan seguir ofreciendo POTS y accesos básicos y primarios RDSI. A todo
esto también se podría plantear la incorporación de funcionalidades para la
integración de accesos móviles vía PS, como la funcionalidad de GGSN.
• Todos los temas relativos a la seguridad en NGN, que actualmente está analizando
el Working Group número 7 de TISPAN. Se trata de un tema especialmente
importante, más si se tienen en cuenta aspectos tales como la movilidad, con
posibilidad de acceso a través de redes de terceros, las vulnerabilidades de los
protocolos de señalización empleados en el núcleo de red NGN, como puede ser el
caso de SIP, o la interconexión entre redes NGN de operadores diferentes.
• El nomadismo, en relación con los accesos fijos de banda ancha y la identificación

de la línea a través de la cual un usuario está accediendo en un momento dado, ya
sea de la propia red de acceso del operador que proporciona el servicio, o de la red
de acceso de un tercero. Esto tiene implicaciones en aspectos tales como la
seguridad, la posibilidad de ofrecer el servicio con el nivel de calidad contratado, la
localización y acceso a los servicios de emergencia, etc.
• La implementación de mecanismos que permitan solventar los problemas que

plantea el roaming entre redes de distintos operadores en el caso de los servicios de
distribución (broadcast) de canales de TV y de PPV. En concreto, mecanismos que
permitan adaptar las peticiones de multicast hechas desde redes de acceso de
terceros en un stream desde la red del proveedor del servicio.
• Las posibilidades de desarrollo de nuevas aplicaciones que ofrece la integración en

una misma red de la telefonía convencional, fija o móvil, con la telefonía sobre IP.
Soluciones como ENUM, al permitir la traducción de números de teléfono en URIs
77/78
Módulo 4
(Uniform Resource Identifiers) y viceversa, abren la posibilidad al desarrollo de

nuevas aplicaciones que permitan la localización de cualquier usuario, con
independencia del terminal con el que en un momento dado esté conectado a la red.
78/78
Bibliografía
[Ref 1]
Las Telecomunicaciones y la Movilidad en la Sociedad de la Información. AHCIET y

Telefónica I+D, 2005. (Varios autores)
[Ref 2]
La próxima generación de redes, NGN, un trayecto hacia la convergencia. Francisco

José García Correa, 2006.
[Ref 3]
Un núcleo de red único para una oferta de servicios “quadruple play”. Comunicaciones de
Telefónica I+D, 2006. (Varios autores)
Enlaces
http://portal.etsi.org/tispan/
http://en.wikipedia.org/wiki/TISPAN
http://www.itu.int/home/index.html
http://www.3gpp.org/
Global Standards, the Key Enabler for
the Next Generation Network
David Boswarthick
Technical Officer TISPAN
David.boswarthick@etsi.org
([SR&RPPಫ
([SR&RPPಫ
&LXGDGGH0«
&LXGDGGH0«[LFR
[LFR (QHUR
1
Structure
Telecoms trends - the push to converge
IMS - the platform for convergence
Next generation standards
ETSI TISPAN, making NGN standards
Conclusions
2
Structure
Conclusions
Changing Telecoms Trends

Fixed line usage is reducing dramatically for “classical”
services
Mobile use is increasing steadily even though
penetration is already high.
Broadband Internet deployment shows a rapid growth
trend.
Fixed Mobile
Broadband
4
OPERATORS WANT
VENDORS WANT
6
CUSTOMERS WANT
These Trends are pushing for…
Fixed – Mobile Convergence (FMC)

the integration of mobile and fixed technologies to enable the
seamless distribution of services over fixed and mobile
broadband networks
8
Converged User Experience
Today Tomorrow
ERE
H
Y W
AN O SE
E
–
C HO
C
VI
BILLS
R TO
E
Y
S
D OM
AN REE
F
Converged Network Overview

Services Location/Security
Home
IMS HSS
Connectivity
Core FIXED MOBILE
Access
xDSL WiMAX WLAN GERAN WCDMA
User
10
Structure
Conclusions
11
IMS the Platform for Convergence

IMS is at the heart of Next Generation Convergent Networks
Mobile SIP-based IMS (IP based Multimedia Subsystem) is
the core of both 3GPP (GSM evolved) and 3GPP2 (CDMA
evolved) networks … this is not simply a European view
Tomorrow’s entire multimedia mobile world will be “IMS”
based
SIP (Session Initiation Protocol) based IMS is IP end-to-end
Applications and services can be supported seamlessly across
all networks
SIP is also at the heart of the Internet
SIP
12
What is IMS?
IP Multimedia Subsystem is defined by 3GPP
IMS standards define a network domain dedicated to the
control and integration of multimedia services.
IMS is defined by 3GPP from Release 5 onwards
IMS builds on IETF protocols
Based upon SIP, SDP, COPs and Diameter protocols
3GPP have enhanced these IETF protocols for mobility
IMS in short
Open-systems architecture that supports a range of IP-
based services over the PS domain, employing both
wireless and fixed access technologies
13
What does IMS provide?
Services and Control

Adds call session control to the packet network (GPRS)
enables peer-to-peer real-time services - such as voice,
video - over a packet-switched domain
Mixed Multimedia
Ability to pick and mix various multimedia flows in single
or multiple sessions
Can handle real-time voice, video, data
Connectivity Independence
Provides access to IP based services independent of the
connectivity network: mobile (3GPP’s UMTS, 3GPP2’s
CDMA2000) and fixed networks (TISPAN’s NGN)
14
Structure
Conclusions
15
Making Standards
IS
NA
RE D
A TE
S
D ULA
R
A OP
ND P
A Y
ST HL
H E IG
T H
16
What is being done?
ITU-T FGNGN has set the Framework for NGN
3GPP members are working in the IETF to ensure that the underlying
protocols fit with 3GPP (mobile service) requirements
3GPP has developed IMS, it is now stable, and is being enhanced
OMA is defining services based on the 3GPP IMS service platform
ETSI TISPAN is busy defining the NGN network

based on 3GPP IMS
3GPP and ETSI TISPAN are meeting jointly to adapt 3GPP IMS to fixed
access networks
ETSI TISPAN is feeding back to the ITU-T and creating

a set of implementable NGN Rel-1 Specifications
17
NEXT GENERATION STANDARDS
r ds
nda
s ta ly
b al cal
o lo
gl ed
l ity nt
a e
qu lem
uce mp
o d ni
pr t ca
y
idl tha
p
Ra
18
Structure
Conclusions
19
ETSI - TISPAN
What is ETSI?
ETSI is an independent, not for profit
organization, whose mission is to produce
telecommunications and ICT standards for the
global market place.
What is ETSI TC TISPAN?
TISPAN in an ETSI technical committee, dealing
with fixed networks and migration from circuit
switched networks to packet-based networks
TISPAN focuses on all aspects of
standardization for present and future
converged networks including NGN
TISPAN produces detailed implementable
deliverables that cover NGN services,
architectures, protocols, QoS, security and
mobility aspects within fixed networks
20
ETSI TISPAN Roadmap
3GPP
NGN-R1 start Release 1 Release
Rel-7 2 Release 3
Full
xDSL, Content Del. FMC/Mob ???
WLAN FTTx
2004 2005 2006 2007 2008 2009

Rel-1 bringing Multimedia conversational services
Terminology, Strategy, QoS, Security, NNA & Identification, ENUM
Requirements, General architecture, Early services and protocols
Detailed architecture, Base services/protocols, 3GPP endorsements
Operations Support Systems, Congestion control, NGN user data,
PSTN/ISDN emulation
Rel-2 bringing new services and optimizing resources usage
Content delivery: Streaming, IP-TV, VoD
Optimized resource usage
Corporate users specific requirements
Rel-3
Generalized mobility, and more …?
21
TISPAN_NGN Genesis
A strong industry demand
For new generation Multimedia services over xDSL access
For preparing replacement of soon becoming obsolescent PSTN
For a first Release of specifications in 2005
Giving main standards directions
With realistic and implementable solutions
ETSI TISPAN has developed an architecture consisting of a
number of subsystems:
Access network attachment Subsystem, Resource and admission
control sub-system
Maximizing Fixed and Mobile convergence, through adoption of
3G/UMTS IMS component for support of conversational services
TISPAN collaborating with 3GPP to accommodate Wireline
access network requirements by IMS
A workshop held with 3GPP in Washington end of March 05
To coordinate the IMS evolution and resolve issues
TISPAN contributing to ITU-T on a global standards
ITU-T CSI, SG4, SG 11, SG 13, SG 19, as well as other SDOs
22
NGN Services Requirements
TISPAN_NGN supports legacy POTS services
(PSTN/ISDN Emulation)
Emulates the PSTN/ISDN Telephony service over an IP
infrastructure
This will enable use of the existing ISDN Supplementary
services
TISPAN_NGN R1 defines Voice Service
(Simulation)
Similar - but not identical - to existing PSTN service
Including important supplementary services
Based on IMS capabilities for basic voice call
TISPAN extensions for simulation will to be included in
Rel-7 of 3GPP IMS
Standard capabilities with the aim of making the services
applicable for other IMS networks than TISPAN IMS, e.g. mobile
networks to facilitate seamless fixed mobile convergence for
Telephony over IP services 23
TISPAN NGN Architecture

IMS PSTN/ISDN Emulation to
support legacy terminals
TISPAN xDSL Connectivity Network
Dynamic provision of IP
address and other user
equipment configuration
parameters (e.g. using
DHCP); User authentication,
prior or during the IP (Access)
address allocation Network Attachment (SIP -based)
procedure; Authorisation of Subsystem IP Multimedia Subsystem
network access, based on (Core IMS )
user profile; Access network
Other Networks
configuration, based on user PSTN/ISDN emulation

profile and Location Subsystem
PSTN /
management.
Resource Control
Subsystem
Access Transport
Network Core Transport Network
IP
Responsible for elements of policy control, resource reservation and admission control. It
also includes support for Network Address Translator and Firewall traversal.
24
TISPAN_NGN Release 1
Officially concluded
8 deliverables already published (from earlier meetings)
14 Documents approved at TISPAN#9
33 others Documents (over 20 on interface protocols) completed
and now under TISPAN approval by correspondence
6 others are mature … but not yet approved:
• 4 will go for WG approval by correspondence/for TB approval at #10
• 2 important ones: DES-03019 (NGN SIP & SDP, Endorsement of TS
24.229) and DES-03053 (Endorsement of inter-working in TS 29.163)
are stable and planned for Approval at TISPAN#10.
Still a few dependencies on 3GPP IMS Rel-7

Emergency communications (SA2)
Legal intercept (SA2 and ETSI LI)
IMS Transit, ISUP syntax/encapsulation in SIP
All documents expected to be finalized before Mid'06

25
TISPAN_NGN R1 Content
70 deliverables of Various types
12 Technical Reports (TR): Analysis and support information
39 ETSI Technical Specifications (TS): fast development (TISPAN
approval then Publication)
20 ETSI Standards (ES): strong interest spec (TISPAN approval then
ETSI Members Vote before going for Publication)
No European Norms (EN), for the time being.
Covering various Technical areas
Service/requirements (10), Architecture/detailed requirements (12)
Protocols (37), QoS (2), Security (3), Enum (2), Management (7)
A few Key Specifications remaining to be approved
15 are already published, 47 are approved/in Publication process
8 remain to be approved, before mid'2006 (at TISPAN#10 in February
or TISPAN#11 in June)
26
NGN R1: Architecture
Key Published Specifications
ES 282 001 on the TISPAN NGN Overall Architecture
Key WG Approved specifications

ES 282 007 on the IMS architecture for fixed broadband access
TS 182 006 on the endorsement of 3GPP TS 23.228 (IMS Stage 2)
ES 282 003 on the Resource and Admission Control Subsystem
ES 282 004 on the Network Attachment Subsystem
ES 282 002 on the PSTN/ISDN Emulation Subsystem
TS 182 012 on IMS-based PSTN Emulation architecture
Key Specification remaining to be approved

TS 182 009 on Emergency Calls Architecture
27
NGN R1 Protocols
Key Published Specifications
ES 283 002 on the H.248 profile for Access Gateways
Key WG Approved Specifications
ES 283 024 on the H.248 profile for Trunking gateways
ES 283 018 on the H.248 profile for Border gateways
ES 283 031 on the H.248 profile for media resource processors
ES 283 035 on the DIAMETER profile for the e2 interface
ES 283 034 on the DIAMETER profile for the e4 interface
ES 283 026 on the DIAMETER profile for the Rq interface
TS 183 017 on the DIAMETER profile for the Gq' interface
TS 183 017 on the modification of the 3GPP Cx and Dx interfaces
TS 183 021 on interworking between IP networks
…
Key Specifications remaining to be approved (Feb'06)
ES 283 003 (SIP/SDP profile) & ES 283 027 (SIP / ISUP interworking)
• Missing features: IMS Transit and ISUP encapsulation, Procedures for
emergency calls and support for video control.
28
TISPAN Next Steps
TISPAN#10 scheduled Feb 2006
Finalize/approve remaining NGN R1 Deliverables
Define NGN-R1 Maintenance process
Initiate work on NGN-R2 scope and definition
Subsequent schedule
TISPAN#10bis on 3-7 April'06
WG7 (Security) collocated with 3GPP SA3
WG8 discussing a joint meeting with 3GPP SA5
Closer collaboration required with 3GPP for NGN-R1 and R2
convergence with 3GPP Rel-7
Need to define a strategy for 'Globalization'

TISPAN_NGN R1 deliverables into the ITU-T NGN-GSI framework
TISPAN contributions to upcoming SG13-11-19 meetings
Making normative references where possible (avoid duplication)
29
Joint working: 3GPP & TISPAN

TISPAN has incorporated the 3GPP IMS
into it’s NGN Architecture; i.e. a common IMS
3GPP and TISPAN are developing a single IMS

that incorporates mobile and fixed requirements
3GPP and ETSI TISPAN are meeting jointly

at both Plenary and WG level
TISPAN and 3GPP have a single Project Manager

and harmonized Work Plans / Roadmaps,
i.e. common work planning
30
Structure
Conclusions
31
Key points to take home

IMS is stable and clearly specified by 3GPP in Rel-6
IMS is the platform of choice for Mobile to Fixed convergence
Standardisation involves close coordination between different
bodies such as IETF, 3GPP, TISPAN, OMA, ITU-T, etc.
Robust and open global standards are essential to the long term
success of IMS and NGN
Doing Nothing is NOT a sensible option

Better to have planned convergence than unplanned collision
If you want to influence the standardization process, the time is
to do it is …
NOW
32
For more information…
… about 3GPP
please visit
http://www.3GPP.org
or contact
3GPPContact@etsi.org
… about TISPAN
please visit
http://www.TISPAN.org
or contact
david.boswarthick@etsi.org
33
and finally….
Thank you for your attention

Now Time for your Questions
34
Converged Fixed-Mobile solutions:
The TISPAN_NGN approach
(Sophia, 22 November 2004)
Christian Julien
(ETSI Secretariat)
TC TISPAN TO
christian.julien@etsi.org
Agenda
1. TISPAN_NGN Project: Steps and

Requirements
2. TISPAN_NGN Status: architecture outline
3. How the use of 3G UMTS IMS in NGN will help
Fixed-Mobile convergence for Multimedia
4. Some important issues to be taken care of
5. Summary
2
TISPAN_NGN Genesis
TISPAN: Telecommunication and Internet

converged Services and Protocols for Advanced
Networking
results from the combination, in September 2003, of :

SPAN, formed as a Technical Body from the joining of SPS
(Services, Protocols & Switching) and NA (Network Aspects)
SPAN = Services and Protocols for Advanced
Networks
TIPHON, formed in 1997 as an ETSI Project to study VoIP and
subsequently extended to any Telecom (including Multimedia)
services over IP
TIPHON = Telecommunications and Internet
Protocol Harmonization Over Networks
3
TISPAN_NGN Synergy
The working groups of the TC TISPAN have been

carefully defined to cover the needs of the industry in
specific technical areas of competence
Each project follows a particular technical subject and

co-ordinates across the competence groups
The following slide gives an summary of the way the

new TC leads the way in standardisation
4
TISPAN_NGN Synergy
8 Working Projects
Groups
SERVICES
(EMergency TELecommunication)
DTM (Dynamic asynchronous

Telecom Equipment Identity
OSA (Open Service Access)

ARCHITECTURE
Tispan_NGN
Transfert Mode)
PROTOCOLS
NUMBERING &
EMTEL
F-MMS
ROUTEING
QoS
TESTING
SECURITY
NETWORK
MANAGEMENT
Etc… as needed
Technical approach
Services Typical Services and basic
Goals
features
Capabilities Service Capabilities
(building blocks)
Network & Service Management
QoS QoS, Security, Naming and

Definition
Addressing
Addressing
Naming &
Security
Architecture and
Requirements
Architecture &
Requirements Network and Service
Management (NGN OSS)
Specification
Protocol Selection and

Protocols,
Profiling
Interworking etc.
Evaluation & Modification
(“fit for purpose”)
Test Specification and Test

Testing Suites (to facilitate
interoperability)
6
_NGN goals & Technical overview
The Next Generation Network will eventually
provide:
A multi-service multi-protocol, multi-access, IP based network
- secure, reliable and trusted
• Multi-services: delivered by a common QoS enabled core
network.
• Multi-access: diverse access networks; fixed and mobile
terminals,
• Not one network, but different networks that interoperate
seamlessly
An enabler for Service Providers to offer
• real-time and non real-time, communication services
• between peers, or in a client-server configuration.
Nomadicity and Mobility
• of both users and devices
• inter and inter-Network Domains, eventually between Fixed and
Mobile networks
“My communications services” always reachable,

everywhere, using any terminal.
_NGN Wide range of services
Person-to-Person – Communication Services

Conversational Voice call
Video call
Chat call
Multimedia call
Messaging e-Mail
SMS EMS
MMS
IM
Content-on-demand
Browsing
Download
Streaming
Push
Broadcast
Peer-to-Peer
8
_NGN key assumptions
Support of a wide variety of services
Conversational Streaming TV Broadcasting Messaging Web
Support of fixed and mobile converged services

Well
defined
interfaces
Control Functions between
control and
application
s
Packet-based transfer Independence

between
control and
Backbone transport
DSL/ATM WLAN
DSL/Ethernet Cable Network UTRAN/GPRS
Support of a wide variety of terminals 9
_NGN high level Roadmap
Towards a converged Wireline and Wireless NGN …

Release 1 Release 2 Release 3
xDSL, Fully ???

WLAN FTTx
Nomadic
2004 2005 2006 2007 2008 2009 2010

Release 1 bringing Multimedia services
Nomadicity/user-controlled roaming
xDSL access focus; Access Network Attachment Subsystem
Release 2 optimizing access resources usage
According to user subscription profile and service use
Corporate users specific requirements …
Release 3 introducing full (inter-domain) Nomadicity
Inter-network domain nomadicity/user-controlled roaming
Higher bandwidth access (VDSL, FTTH, Wi-max …)
10
Agenda

Requirements
2. TISPAN_NGN Release 1 Status:
architecture outline
3. Why the use of IMS in NGN will help Fixed-
Mobile convergence for Multimedia
5. Summary
11
_NGN Release 1 scope

Ongoing discussion
Being consolidated meeting after meeting
Stabilized at TISPAN#4 (sept.) & #4bis (nov.) meetings
Major service capabilities under consideration
Real time conversationnal services (Voice, Videotelephony)
Messaging (Instant Messaging, MMS), Presence Management
Legacy services emulation enabling legacy PSTN/ISDN
migration towards NGN
Content delivery such as VOD, Video Streaming, TV-Channel
distribution (if inputs and resources available)
Network Architecture basis
ADSL access prime focus, possibly WLAN (may be deferred to
Release 2)
3G/UMTS IMS sub-system reused as basis for real-time
Conversationnal services (SIP-based session control)
Objective: mid-2005
Pragmatic bottom-up approach for Release 1
Not excluding Top-down (TIPHON-like) approach for preparing
future TISPAN_NGN Releases
12
_NGN architecture design principles
A sub-system oriented approach, enabling:
The addition of new subsystems over the time to cover new
demands and service classes.
To import subsystems from other standardisation bodies.
Flexibility to adjust the architecture.
IP connectivity is provided using two subsystems:
Network Attachment Subsystem (NASS)
Ressource and Admission Control Subsystem (RACS)
First service-oriented subystems include:
The 3GPP IMS suitably adapted to accomodate xDSL-based
access networks requirements (joint effort with 3GPP), supporting
multimedia services and PSTN/ISDN Simulation.
A PSTN/ISDN Emulation subsystem specifically tailored to allow
TDM equipment replacement, while keeping legacy terminals
unchanged.
13
_NGN Architecture overview

Based on
Applications
3GPP IMS R6
Other Multimedia
IP Connectivity Subsystems …
Access Network
And related functionality (RTSP - based)
Streaming services
Network (SIP - based)
Attachment IP Multimedia Subsystem
Functionality (Core IMS)
PSTN
(SIP - I based)
PSTN/ISDN Emulation
Subsystem
Resource and
Admission Control
Functionality
GW GW
GW GW
Access Transport
Network
IP Core Transport Network
3GPP IP-CAN
14
_NGN detailed overview
Applications
Based on
3GPP IMS
IP Connectivity Other Multimedia

Access Network Data
Components …
And related functionality Base
Streaming Services
(RTSP based)
Other Networks
ICF
IP Multimedia
Component (Core IMS)
(SIP based)
PSTN / ISDN Emulation
(SIP-I based)
“Gq”
PSTN / ISDN
Legacy interface
Legacy Terminals
Terminals
Network Attachment Resource and Admission
GW Functionality Control Functionality
NASS RACS
Legacy GW “Go”
Terminals interface TGW
NGN
Terminals Customer MBG
Networks IP Core transport
Access Transport
Network Network
NGN
Terminals
3GPP IP-CAN
3GPP Terminals
15
IMS background (1/3)

IMS introduced in 3GPP Rel5, and further enhanced
in Rel6:
IP Multimedia domain for call control based on
SIP
3GPP specifies features to fullfill operator
requirements, e.g.:
• QoS control
• Charging
• Security
• Subscription profiles
• Interworking with other networks (CS/PSTN)
IMS provides building blocks allowing faster
integration and deployment of IP multimedia
services
16
IMS allows operators to have more control on the
service level than with GPRS only:
Service level awareness
Correlation between the SIP application layer and
the transport in PS domain
Access to services in correlation with a
subscription profile (e.g. basic, silver, gold…)
Better control on the packet resources used
3GPP IMS Releases:
Release 5: frozen since March 2003
Release 6: freezing in December 2004
Release 7: Starting. Stage 1 requirements being
currently defined
17
User Ids
User profile
security roaming
Inter-
QoS Working
policy CS/PSTN
SIP
control
Basic
charging Call
Control
Service logic
APIs
18
IMS component architecture
Based upon an open standard with a strong evolutionary
advantage – IMS architecture & SIP may be extended to
provide for new services Subscriber
Location
Home
Subscriber
Function Server
SLF Appl.
HSS
Server
Diameter Protocol
SIP Protocol
P-CSCF I-CSCF S-CSCF
UE
GGSN
Session control
First Point of Access Point to services
Contact Network
Privacy Control & Hides Topology
QoS & Coinfiguration Registration
Authorisation AS interaction
Local Services: Visited Home Charging etc.
Emergency & Network Network
Local Numbering
19
IMS Registration and Call

Legend
IMS SIP: CSCF Call State Call Flow
Control Functions
Proxy- UE Interface, Local 1 Register & find user Home 4 Register & Download IMS user Profile
Services
Interrogating- Home Network Register & Retrieve required S-
2 5 INVITE UE#2 into call
Contact Point CSCF & it’s capabilities
Serving- Session Control,
3 Choose correct S-CSCF 6 Upon Acceptance, Data Path is Set-up
Service Invocation, AS &
HSS Trigger, Charging,
…
Signaling path Content path Application
I-CSCF Servers
2 3
HSS
IP MULTIMEDIA
P-CSCF 4 SUBSYSTEM
1 S-CSCF
SGSN GGSN 6 GGSN SGSN

UE #1 UE #2
UMTS PACKET UMTS PACKET
DOMAIN DOMAIN
20
IMS Architecture
The HSS holds the IMS
service profile of the
HSS
subscribers.
I-CSCF
Control Plane IMS
Cx
Traffic Plane
I-CSCF Other IP/
Cx
Mw IMS network
S-CSCF
P-CSCF Mm
Go Gi
Gi
CSCFs are the IMS entities responsible
S-CSCF
of the call control: there are 3 typesinterconnects
of to
UTRAN CSCFs depending on their external
role: IP networks and other
•P-CSCF (Proxy CSCF) IMS networks.
•S-CSCF (Serving CSCF)If THIG is used by the operator
•I-CSCF (Interrogating CSCF)toThe
hidePS
itsdomain
internalprovides
configuration,
the
theIP
connection to external
bearer to access to the
UE SGSN GGSN networks goes
IMS, i.e. through
a PDP an I-
context.
CSCF.
PS Domain
21
IMS Architecture
Control Plane
HSS
Traffic Plane IMS I-CSCF
Cx
Other IP/
I-CSCF IMS network
Cx
In Release 6, the PDF Mw
can be separated from The MRF is used Mm
forP-CSCF
multiparty call S-CSCF Mk
the P-CSCF. Those two
entities are then control
connected through the Mr Mi
Gq interface.
MRF
Mg
Gq Go Gi BGCF
Mj Those entities
are responsible
MGCF
Gi for interworking
UTRAN PDF
IMS- SGW
between IMS
MGW and CS
Go Gi Mn domain/PSTN
UE SGSN GGSN
Legacy/
PS Domain PSTN
22
_NGN IMS-based subsystem
Applications
Other
subsystems
IMS
Customer Premises Equipment
Network
Attachment PSTN/ISDN
PSTN/ISDN
Subsystem Emulation
subsystem
Resource and
Admission Control
Subsystem
Service Layer
Transport Layer
Transport Functions
23
Core IMS use in the NGN architecture

NGN
specific
Rf/Ro
impacted
Sh Charging
AS HSS Functions
Network
Attachment Dh Ia
ISC Cx Cx Rf/Ro
Subsystem Ib
IWF
SLF Dx
Mw IBCF
I-CSCF Mw/Mk/Mm Ic
If S-CSCF Mw
« Core
Core IMS
IMS» Mi Mi
SIP BGCF
Mw
Other IP Networks
H.248 Mr Mj Id
Mg
DIAMETER P-CSCF MGCF SGF
MRFC Ie
PSTN/ISDN
Gq
Gm Mp Mn
Resource and Admission Control Subsystem
MRFP T-MGF
A-BGF
UE I-BGF
IP Transport (Access and Core)
24
_NGN standards built on 3GPP IMS specs
Use the “core” IMS as one of the high-level

components of the overall NGN architecture,
with initial focus on xDSL
xDSL-based access networks provide access to IMS and
other subsystems (e.g.; streaming)
xDSL-based access networks as a new type of IP-
Connectivity Access Network for the IMS
Complement the IMS with other subsystems

A resource and admission control subsystem
A network attachment subsystem
A PSTN/ISDN Emulation Subsystem
Other multimedia subsystems and applications
25
Differences between xDSL and

3G Radio Access
Differences which impact the IMS-SIP specifications:
Wireline versus Wireless: The constraints in terms of bandwidth
scarcity, security, transmission delay are different
Terminals: Less stringent requirements are likely to be placed on NGN
terminals (e.g. support of IPv6, availability of USIM/ISIM, codecs...)
Location Information: Location information is different in nature and
usually not available at the UE
Resource management:: Explicit resource reservation signalling not
available in terminals and access network edge points; no dedicated
channel for signalling
Regulatory issues: Different contexts leading to different constraints
Terminals vs Users: Users are not always tied to terminals
Details being discussed between 3GPP (IMS R6 and R7) and

TISPAN
26
IP Connectivity control
IP connectivity is provided using two control subsystems,

which play a role similar to the 3GPP GPRS procedures
Network Attachment Subsystem

IP address allocation (e.g.; using DHCP).
Authentication, taking place at the IP layer
Authorisation of network access
Location management, taking place at the IP layer,
...
Ressource and Admission Control Subsystem
Admission Control
Gate Control
...
27
_PSTN/ISDN Emulation Subsystem
Applications
Other
subsystems
IMS
Network
PSTN/ISDN
Subsystem Emulation
subsystem
Resource and
Admission Control
Subsystem
Service Layer
Transport Layer
Transport Functions
28
Emulation vs Simulation
PSTN/ISDN service continuity in NGN:
PSTN/ISDN Simulation
"Provides PSTN/ISDN service capabilities and interfaces using
adaptation to an IP infrastructure"
The provision of PSTN/ISDN-like services to advanced terminals (IP-
phones) or IP-interfaces. There is no strict requirement to make all
PSTN/ ISDN services available or identical, although end users expect
to have access to the most popular ones, possibly with different
ergonomy.
PSTN/ISDN Emulation
"Provides PSTN/ISDN-like service capabilities using session
control over IP interfaces and infrastructure"
Mimicking a PSTN/ISDN network from the point of view of legacy
terminals (or interfaces) by an IP network, through a gateway. All
PSTN/ISDN services remain available and identical (i.e. with the same
ergonomics); such that end users are unaware that they are not
connected to a TDM-based PSTN/ISDN.
29
_PSTN/ISDN Emulation subsystem
Two approaches under discussion:

Softswitch approach ('Monolithic architecture')
• A shortcut to refer to (often already existing) implementations based
on use of call control software (ported from legacy switches).
• Not requiring standardisation of the internal structure of the
PSTN/ISDN emulation subsystem, only external interfaces
IMS-like approach
• Re-use (all or part) of the IMS functional architecture to specify the
internal structure of the PSTN/ISDN Emulation subsystem
Towards a compromise agreement:
Functional architecture, physical implementation examples
• Standardisation of external interfaces: H.248 profile, network SIP-I
An IMS-like functional architecture does not prevent the
implementators to build a physical architecture using only
softswitches (MGC) and media gateways (MGW).
30
IMS and PSTN/ISDN Emulation
Many similarities
Two session-based control subsystems:
• For supporting multimedia conversational services and
PSTN/ISDN services simulation (IMS)
• For supporting PSTN/ISDN services emulation
Above a managed IP network
Supporting operators’ requirements
• Quality of service, Security, Charging capabilities, Regulatory
constraints....
Clear Benefits
Enables the deployment of common control platforms
• Towards a unique infrastructure for supporting multimedia services
and TDM- switches replacement
Enables service convergence
• new voice services available to all types of subscribers
Enables the scope of nomadism to be extended to legacy
access lines.
31
_Emulation typical configurations

SIP may also be
used if the set of
services to be
emulated is limited
Z H248 SIP-I H248 Z and/or
RGW « downgraded »
RGW or
or AGW
emulation is
AGW considered
DSS1/IUA acceptable (e.g.
S/T second line).
Z H248 SIP-I H248
RGW
or
AGW
V5.2/V5UA
V5.2
AN
Z H248 SIP-I H248
RGW
or
AGW
Z SIP-I
PSTN
H248
ISUP /
RGW
or
H248 ISDN
AGW
TGW
32
_Network Attachment Subsystem
Applications
Other
subsystems
IMS
Network
PSTN/ISDN
Subsystem Emulation
subsystem
Resource and
Admission Control
Subsystem
Service Layer
Transport Layer
Transport Functions
33
_Network Attachment Subsystem
Main functionalities
IP address allocation (e.g.; using DHCP).
Authentication and authorisation, taking place at the IP layer
Access network configuration, based on user profiles.
Location management, taking place at the IP layer
Replaces the 3GPP PS Domain / GPRS procedures
for authentication and location management
Outstanding Issues
Interactions between authentication at the network attachment
level and at the SIP level.
Alignement with DSL Forum Architecture
One NASS per access network or one NASS for several
access networks?
34
_NGN NASS current architecture
Service control
subsystems and
applications
e2 Resource
e4 and
CLF Admission
Control
a2 a4 Subsystem
CDCF NACF UAAF PDBF
e3 a1 a3
e1
TE CNG AMF
35
_Resource and Admission Control
Applications
Other
subsystems
IMS
Network
PSTN/ISDN
Subsystem Emulation
subsystem
Resource and
Admission Control
Subsystem
Service Layer
Transport Layer
Transport Functions
36
_NGN RACS description
Main Functionalities:
Session Admission Control.
Gate Control (including NAPT)
TISPAN R1 : No interactions between RACS in
different networks
Need to support both push and pull procedures
Push mode required for ADSL-based access networks
Issues for future releases:
Admission control at core network boundaries.
Cooperation between peer ressource control subsystems
37
_NGN RACS status

Provides a Gq-like interface to TISPAN
Subsystems and applications
Controls transport ressources at the boundary
between the access and core networks
Using a Gate Control Protocol
May also control NAPT at core network boundaries
TISPAN has recently approved an H.248-based
Gate Control Profile
An alternative COPS-based or SNMP-based
standards may be pushed by some vendors at a
later stage
38
Agenda

Requirements
2. TISPAN_NGN Release 1 Status: architecture
outline
5. Summary
39
Why IMS in NGN ?

IP Multimedia Substem generally fulfills the NGN
requirements for conversational services
For managed, carrier operated telecom network
With Release 6 becomes applicable to a range of access
network types (3G RAN, WLAN)
IMS access (technology) independence
Whole Telecom industry benefit
Will enable simple and effective interworking between
Cellular and Wireline
Growing IMS market, encouraging greater usage
Wider choice of IMS suppliers
Market stimulation, decreasing costs (thanks to shared
development/deployment costs)
…
40
Benefits of IMS use in NGN
TISPAN_NGN has taken the lead in adopting 3G IMS as a key
base component in the NGN architecture
It needs adaptions to support xDSL access (on-going)
Still a number of issues to be addressed (Identifiers, Security,
IPv4/v6 interworking and transition …)
A promissing major step to enable smooth Fixed-Mobile
convergence for Multimedia:
Consolidating the IMS and Service Platforms access & transport
technology independence
Enabling seamless service interworking
An effective basis to support Nomadicity and Mobility features
Still a number of challenges ahead
Resource optimization and transport technology evolution
QoS insurance for Real time services …
Identifiers, Security …
But a significant step is being taken to enable the Multimedia
Fixed-Mobile convergence in TISPAN_NGN Release 1
41
Agenda

Requirements
2. TISPAN_NGN Release 1 Status
5. Summary
42
_NGN IMS-related issues
A promissing approach but many challenges, e.g.
Resource and QoS control in access (and end-end)

QoS insurance (IP flow differenciation)
Policy control (G0) interface
Services interoperability
Services are not (yet) standardized in 3GPP
TISPAN_NGN is intending to standardize a minimum set
Interworking with Legacy networks and Platforms
Terminals
IP addresses, (Line & Personal) Identifiers, SIP Client (Profile) …
IT adaptation and integration
Flexible NGN-OSS
Provisioning, Charging and Billing
To enable use of IT(IP)-based technology in Telecom carriers

grade environment.
43
Using Gq interface in NGN
Gq Interface is located between Multimedia

Subsystem(s) and Resource and Admission
Control Subsystem (RACS)
Gq is used by different subsystems (not only IMS)

and multiple Access Networks
Gq is used to access the following functions:

Resource reservation
Admission Control
NAT Control
Gate and Policy Control
44
Gq interface Extensions
Support for network initiated resource reservations

Besides Pull Model the Push model shall be supported.
Support for requesting Address and Port Translation

Parameters for NAT type of scenarios., e.g.
• interworking of different (private/public) IPv4 address spaces,
query and allocate NAT bindings
• Possibly IPv4/IPv6 interworking
Gate control and service and network policy control
Parameters to access those functions
45
Agenda

Requirements
2. TISPAN_NGN Release 1 Status: architecture
outline
5. Conclusion
46
_NGN summary
A strong industry demand
For new generation Multimedia services on xDSL access
For preparing replacement of soon becoming obsolescent PSTN
For a first Release of specifications by mid-2005
Giving main standards directions
With realistic and implementable solutions
ETSI TISPAN taking the lead to propose an architecture basis
consisting of a range of subsystems:
Maximizing Wireline and Cellular convergence, through adoption of
3G/UMTS IMS component for support of conversational services
Access network attachment Subsystem, Resource and admission
control sub-system … preparing for next Releases
TISPAN collaborating with 3GPP to accommodate Wireline
access network requirements by IMS
A 1st Workshop held last June, a further one next year
To coordinate the IMS specifications evolutions to support various
Wireless and Wireline access technologies
Other collaborations very welcome
ITU-T NGN Focus Group, ATIS is eager to cooperate
European IST projects e.g. which is considering IMS in
the scope of their system architecture too.
47
Acronyms
CSCF Call State Control Function

IMS IP Multimedia Services
IWF Inter-Working Function
GPRS General Packet Radio Service
HSS Home Subscriber Function
MRF Multimedia Resource Function
MGCF Media Gateway Control Function
SIP Session Initiation Protocol
SLF Subscriber Location Function
UMTS Universal Mobile Telecom. System
UTRAN Universal Telecom. Radio Access Net.
48
THANKS FOR YOUR ATTENTION
Questions/Comments ?
ETSI TISPAN Portal:

http://portal.etsi.org/Portal_Common/home.asp
49

Converfim Modulo4

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Converfim Modulo4

Cargado por

Copyright:

Formatos disponibles

Módulo 4

1.1. ¿Qué es TISPAN?

TISPAN es una rama de estandarización de ETSI, especializada en la convergencia de

TISPAN es el responsable de todos los detalles de estandarización (o normalización) para el

Entre las competencias principales de TISPAN se encuentra la definición de aspectos

La Figura 1 muestra el concepto de la convergencia de las redes mediante la actuación de

Figura 1. Esquema de la convergencia de tecnologías.

Actualmente se está trabajando en la Release 2, con el objetivo de mejorar la movilidad, los

Figura 2. Estructura de TISPAN.

Descripción de las competencias centrales de TISPAN

• Definición del nivel de servicio entre las tradicionales redes de conmutación de

Cooperación con otros organismos

1.2. Reflexiones sobre la necesidad de la convergencia

La evolución tecnológica de los últimos años da lugar a que no se asocien de forma

La importancia de la digitalización se basa en varias razones:

1. Permite manejar de forma única toda clase de fuentes de información.

2. Permite una mayor flexibilidad y libertad en la incorporación de nuevos servicios.

3. Es más efectivo almacenar, procesar y, en general, manejar la información en formato

Si echamos la vista atrás y contemplamos la situación de las telecomunicaciones hace

La evolución tecnológica ha traído consigo un paisaje muy diferente. Existe en la actualidad

Pero la cuestión es, ¿Cómo nos afecta la convergencia?

Fundamentalmente a través de la convergencia en servicios, de manera que deja de tener

Por tanto, tenemos que acostumbrarnos a no identificar un determinado servicio o tipo de

Con este panorama, debemos plantearnos la neutralidad tecnológica y las plataformas

La convergencia de los sectores de telecomunicaciones, medios de comunicación y

Consideraciones a tener en cuenta desde la administración.

Desde la Administración, en el momento de abordar las necesidades regulatorias derivadas

La estandarización es necesaria como elemento que garantice la interoperabilidad de los

• Los posibles escenarios de evolución de la convergencia tecnológica.

• Evitar la brecha digital.

• El impulso de la banda ancha.

Desde la Administración se ha de impulsar sin titubeos el despliegue de aquellas

• Impulsar la neutralidad tecnológica.

Es un hecho que paulatinamente van apareciendo distintas tecnologías que ofrecen

• Conseguir una situación de competencia efectiva.

No se puede dudar de la importancia y beneficios de la convergencia para el desarrollo

tecnológico por incluir además cambios no exclusivamente tecnológicos y supone, en

La innovación tecnológica, el desarrollo tecnológico y la inversión, son factores cruciales

Nos encontramos en un momento en el que las nuevas tecnologías de la información y las

La difusión e inversión en TIC ofrece un mayor potencial de crecimiento y mayores

1.3. Organismos vinculados a la estandarización

Diversos organismos y foros de estandarización están trabajando en aspectos relacionados

En este apartado se resume sucintamente la actividad de de estandarización de algunos de

3GPP (3rd Generation Partnership Project) se encarga de la estandarización del sistema

La estandarización en 3GPP ha sido un proceso gradual, con continuas revisiones y

Figura 3. Evolución de la estandarización GSM/UMTS.

En la Release 5 se presentó IMS (IP Multimedia Subsystem) y HSDPA (High Speed

OMA (Open Mobile Alliance) es un organismo de estandarización creado en junio de 2002,

El objetivo último y principal de OMA es garantizar la interoperabilidad extremo a extremo de

servicios con interfaces abiertas e independiente de la tecnología de redes móviles y sus

• Proporcionar productos y servicios basados en estándares abiertos.

• Disponer de una arquitectura y unas tecnologías que posibiliten servicios

• Disponer de una capa de aplicación independiente de las capas de transporte.

• Proporcionar una interoperabilidad de servicios de manera transparente al usuario,

OMA dedica considerables esfuerzos a especificar pruebas de interoperabilidad extremo a

• ARIB, Association of Radio Industries and Businesses (Japón).

• CCSA, China Communications Standards Association (China).

• TIA, Telecommunications Industry Association (EE.UU.).

• TTA, Telecommunications Technology Association (Corea).

• TTC, Telecommunications Technology Committee (Japón).

El trabajo de preparación de las especificaciones técnicas se divide entre cuatro TSGs

• TSG-A (Access Network Interfaces).

• TSG-S (Services and Systems Aspects).