Converfim Modulo3

Módulo 3
IMS: IP Multimedia
Subsystem
Módulo 3
IMS: IP Multimedia Subsystem
Índice
1. Visión sobre el Subsistema Multimedia IP....................................................................... 3

1.1. Introducción a IMS................................................................................................... 3
1.2. Tendencia del mercado de comunicaciones ........................................................... 7
1.3. ¿Cómo trabaja IMS? ............................................................................................... 9
2. Arquitectura de IMS ....................................................................................................... 18
2.1. Requisitos de la arquitectura ................................................................................. 18
2.2. Funciones y entidades relacionadas con IMS ....................................................... 22
2.3. Interfases IMS ....................................................................................................... 29
3. Conceptos de IMS ......................................................................................................... 36
3.1. Introducción ........................................................................................................... 36
3.2. Registro de usuarios.............................................................................................. 36
3.3. Inicio de sesión...................................................................................................... 37
3.4. Identificación.......................................................................................................... 38
3.5. Módulos de identidad ............................................................................................ 39
3.6. Servicios de seguridad en IMS.............................................................................. 40
3.7. El punto de entrada de IMS................................................................................... 44
3.8. Asignación del S-CSCF......................................................................................... 45
3.9. Mecanismos de control del tráfico ......................................................................... 46
3.10. Cobro de los servicios ........................................................................................... 47
3.11. Perfil de usuario..................................................................................................... 50
3.12. Provisión de servicios............................................................................................ 52
3.13. Conexión entre usuarios IMS y CS ....................................................................... 53
3.14. Registro de múltiples identidades de usuario........................................................ 55
3.15. Compartir la identidad de usuario entre varios UE................................................ 56
3.16. Compresión SIP .................................................................................................... 57
4. Los servicios .................................................................................................................. 59
4.1. Presencia............................................................................................................... 59
4.2. Mensajería............................................................................................................. 64
4.3. Conferencia ........................................................................................................... 66
5. Protocolos IMS .............................................................................................................. 72
5.1. SIP......................................................................................................................... 72
5.2. SDP ....................................................................................................................... 78
5.3. RTP ....................................................................................................................... 81
5.4. DNS ....................................................................................................................... 83
5.5. TLS ........................................................................................................................ 84
5.6. Diameter ................................................................................................................ 86
5.7. MEGACO............................................................................................................... 91
5.8. COPS .................................................................................................................... 92
5.9. Ipsec ...................................................................................................................... 94
5.10. DHCPv6................................................................................................................. 95
6. Evolución ....................................................................................................................... 97
6.1. Origen de IMS ....................................................................................................... 97
6.2. Evolución hacia All-IP............................................................................................ 99
7. Glosario ....................................................................................................................... 103
8. Referencias.................................................................................................................. 113
2/113
Módulo 3
1. Visión sobre el Subsistema Multimedia IP

1.1. Introducción a IMS
El Subsistema Multimedia IP (IMS) es un estándar reconocido internacionalmente que define
una arquitectura genérica para ofrecer al usuario final voz sobre IP (VoIP) y servicios
multimedia. Inicialmente fue definido por el proyecto “Third Generation Partnership Project”
(3GPP/3GPP2), pero está siendo adoptado por otros organismos, incluyendo el
ETSI/TISPAN (European Telecommunications Standards Institute). El estándar soporta
múltiples tipos de accesos, incluyendo GSM, WCDMA, CDMA2000, acceso por cable de
banda ancha y WLAN.
Para los usuarios, los servicios basados en IMS posibilitan la comunicación persona a
persona, y persona a contenidos de muy distintas formas (incluyendo voz, texto, imágenes y
vídeo, o cualquier combinación de éstos) de una manera personalizada y controlada.
Para los operadores, IMS lleva el concepto de arquitectura por capas un paso más allá,
definiendo una arquitectura horizontal, donde los servicios y las funciones pueden ser
reutilizados para múltiples aplicaciones. La arquitectura horizontal de IMS también especifica
la interoperabilidad, la itinerancia (roaming), y proporciona control sobre la seguridad y el
costo del servicio. Además, está integrado con las redes existentes de voz y datos,
adoptando muchas de las ventajas del dominio de las tecnologías de la información.
IMS posibilita que los servicios sean diseñados de un modo bien estructurado y
estandarizado, gracias a la organización en capas. Al mismo tiempo, provee una
arquitectura que simplifica y agiliza los procesos de creación y puesta en marcha de
servicios, posibilitando la interconexión con redes ya existentes.
La arquitectura horizontal de IMS facilita a los proveedores la creación de nuevos servicios,

ya que elimina los costes y la complejidad de las estructuras tradicionales de red, en las que
se solapan los costes, presencia, gestión de grupos, encaminamiento y provisionamiento.
IMS también proporciona ventajas a los operadores de telefonía fija y móvil de hoy en día,
ya que posibilita una migración segura hacia la arquitectura All-IP, la cual unificará las
demandas de los usuarios finales de nuevos servicios más mejorados y versátiles.
Esto hace de IMS una pieza clave en la convergencia fijo-móvil. Por ello, es probable que
IMS llegue a ser la solución preferida para los negocios de los operadores fijos y móviles.
IMS fue diseñado inicialmente en 3GPP para su uso sobre el subsistema de transporte
GPRS de tercera generación, aunque en la versión 7 (Release 7) se define el estándar
sobre UMTS. El modelo teórico de las redes móviles divide el sistema en diferentes
dominios y planos. Así, IMS implementa el plano de control de los servicios IP multimedia,
mientras que GPRS proporciona las funciones de plano de transporte, tal como se puede
ver en la Figura 1.1.
3/113
Módulo 3
Figura 1.1. Empleo de IMS sobre GPRS.
De esta forma, la función de IMS en los servicios IP multimedia incorpora el procesado y

actuación sobre la señalización y el control de los recursos del plano transporte. GPRS se
encarga de proporcionar conectividad IP dentro del dominio de la red móvil, tanto para la
señalización como para los datos multimedia de usuario. Siguiendo la filosofía establecida
en la separación funcional típica de UMTS y de las redes IP, el flujo de datos
correspondiente a la señalización viaja de forma separada a los flujos de datos multimedia
de usuario, proporcionando en ambos casos GPRS el servicio de transporte. Sin embargo,
el flujo de señalización, que tiene su origen y fin en los terminales de usuario participantes
en el servicio, es transferido vía IMS, al contrario de lo que ocurre con los datos de usuario
que se transfieren directamente entre los terminales sin atravesar el subsistema IMS.
Este concepto establecido en la arquitectura permite, fundamentalmente, emplear

tecnologías de Internet, y origina el atractivo de disponer de los servicios IP multimedia.
Las características principales de los servicios IP multimedia que IMS hace posible son las
siguientes:
• La comunicación orientada a sesión de un usuario a otro(s) usuario(s), o de un

usuario a un servicio.
• La comunicación en tiempo real o diferido.
• Las sesiones IP multimedia compuestas por flujos y contenidos multimedia
diversos, con un nivel adecuado de Calidad de Servicio para vídeo, audio y
sonido, texto, imagen, datos de aplicación, etc.
• La identificación de usuarios, servicios y nodos mediante URIs (Universal
Resource Identifier), que aumenta la usabilidad de los servicios de cara a los
abonados. Éstos ya no tienen que manejar números de teléfono imposibles de
recordar, sino nombres al estilo de servicios Internet, como el correo
electrónico.
Quizás la característica más notable procede de la naturaleza “Internet” de su arquitectura:

IMS permite ofrecer un repertorio de servicios completamente integrados a través de este
subsistema, que combinan sus propias características generando sinergias que contribuyen
a una experiencia de usuario avanzada. Los servicios IMS pueden implementarse, por
ejemplo, en una sola aplicación de usuario final que hace un uso coordinado y simultáneo de
4/113
Módulo 3
la mensajería IP multimedia (instantánea y diferida), del servicio de presencia, de los

servicios web, de la videoconferencia y llamadas de voz sobre IP (usuario a usuario o
multiparty), del streaming, de la difusión multimedia, de la descarga de contenidos, de los
juegos en red y de cualquier otro servicio de Internet basado en TCP/IP, de forma muy
similar a como operan las últimas versiones de los populares clientes de mensajería
instantánea para PC e Internet, pero ofreciendo una Calidad del Servicio (QoS) garantizada
y adaptada a cada flujo de datos, a la vez que permiten al usuario disfrutar de la movilidad y
características de su dispositivo personal 3G IMS.
Sin embargo, IMS no define las aplicaciones o servicios que pueden ofertarse al usuario
final, sino la infraestructura y capacidades del servicio que los operadores o proveedores de
servicio pueden emplear para construir sus propias aplicaciones y producir su oferta de
servicios. El operador IMS puede elegir orquestar los servicios de forma independiente,
combinada o en multitud de variantes. Como ejemplo se pueden poner los dos grupos
siguientes de servicios finales:
• Los servicios heredados (las llamadas básicas de voz, la mensajería textual,

la mensajería multimedia, el correo electrónico, etc.), en los cuales el usuario
percibirá la misma calidad que cuando se prestan a través de los sistemas
tradicionales.
• Los servicios multimedia avanzados. En este tipo de servicios se incluyen la
videoconferencia; la audioconferencia monofónica o estereofónica; la
videoconferencia para personas sordas, video más texto de tiempo real; la
multiconferencias en video, audio o texto; la difusión de medios de TV o radio; el
vídeo bajo demanda; la mensajería instantánea y el chat multimedia; los
videojuegos interactivos multiusuario; el servicio push-to-talk (walkie-talkie); etc.
En este sentido, IMS no impone límites, son la capacidad de la red de acceso y las
características de los terminales las que fijan las restricciones.
Por otro lado, como IMS fue diseñado para una red evolucionada de GSM hereda ciertas
cualidades intrínsecas del mundo móvil, como son:
• Las sesiones interoperador. Los abonados de un operador IMS tienen la

posibilidad de cursar sesiones IP multimedia con abonados localizados en la red
3G IMS de otro operador. La arquitectura de IMS, las entidades funcionales y
sus protocolos, están diseñados para la interconexión con otros sistemas IMS
de otros operadores. En este caso, los flujos de datos de una sesión se
transportan por el sistema GPRS en la red origen, por una red, o redes, IP de
tránsito interoperador y por la red GPRS destino. En el caso de las sesiones
interoperador, los flujos de señalización siempre recorrerán ambos sistemas
IMS.
• La itinerancia. IMS soporta la itinerancia (roaming) de tipo nativo, lo que se
define como la capacidad del sistema de admitir y dar servicio a abonados de
otros operadores que emplean la misma tecnología, y con los que se tiene el
acuerdo de negocio pertinente. Cuando un abonado está en itinerancia, el
subsistema IMS visitado encamina la señalización del abonado itinerante hasta
5/113
Módulo 3
el IMS nativo del abonado, desde donde se reencamina la sesión hacia su

destino.
• La interconexión con redes y servicios heredados. IMS contempla la
interconexión con las redes de circuitos SS7 para servicios de llamadas de voz.
Por tanto, existen elementos IMS para el interfuncionamiento entre las sesiones
multimedia con los componentes de audio y las redes PSTN, GSM o el dominio
de conmutación de circuitos de la propia red 3G. De esta forma, los abonados
con la innovadora tecnología IMS siempre podrán seguir comunicándose con
otros abonados no IMS. Así mismo, el sistema está diseñado para proporcionar
interoperación con redes de circuitos que admiten teleconferencias multimedia
(por ejemplo, videollamadas), como aquellas basadas en 3G-324M o H.324.
• La interconexión con las redes IP multimedia externas e Internet. La futura
Internet albergará servicios IP multimedia avanzados, especialmente para el
caso de comunicaciones en tiempo real o con altos requisitos de QoS. IMS
incorpora componentes para el interfuncionamiento con las redes IP multimedia
externas, de forma que los abonados IMS podrán mantener comunicaciones con
los usuarios de la Internet multimedia.
• La seguridad integrada. Uno de los factores clave del éxito de GSM fue que
incorporaba intrínsecamente mecanismos de seguridad, soportados por la
tarjeta SIM. IMS requiere autenticación de abonado y especifica sus propios
mecanismos y arquitectura de seguridad, que son independientes de los propios
de UMTS. De este modo, la suscripción IMS está soportada por una aplicación
lógica llamada ISIM (IMS SIM) que ejecuta funciones de autenticación de
abonado durante su registro en IMS, además de contener datos de la
suscripción de abonado, de igual forma que la SIM en GSM y la USIM en 3G. La
ISIM reside, junto con la aplicación USIM, en la tarjeta inteligente física. Por
tanto, un abonado que desee acceder a IMS, en primer lugar deberá
autenticarse y registrarse con el núcleo de red UMTS empleando la USIM, y
posteriormente autenticarse y registrarse con IMS utilizando la ISIM.
• La Calidad de Servicio (QoS). El subsistema GPRS de 3G hace uso de la
arquitectura de QoS de UMTS, que define una jerarquía de portadoras
adecuadas para servicios con diferentes requisitos de QoS. Por todo ello, se
han definido nuevas funciones e interfaces opcionales en GPRS 3G de 3GPP
Release 5 que permiten que IMS controle y autorice el uso de recursos del
subsistema de transporte GPRS. Estas funciones son opcionales, y, en caso de
no estar presentes en GPRS, la asignación de recursos a las sesiones IMS se
controlaría mediante los mecanismos ordinarios propios de GPRS y la
suscripción de abonado GPRS.
• La provisión de servicios. IMS posibilita un desarrollo rápido y simplificado de
servicios siguiendo el modelo Internet. La arquitectura IMS cuenta con
interfaces o pasarelas hacia servidores de aplicaciones. En lo que respecta a
las aplicaciones, éstas pueden modificar el transcurso de una sesión multimedia
de una forma muy similar a cómo lo hacen las aplicaciones de red inteligente,
que pueden actuar y modificar una llamada de voz, con la ventaja de la
simplicidad y facilidad del desarrollo de las aplicaciones web. De este modo se
pueden establecer una serie de criterios en la suscripción de usuario IMS, de
forma que el control de una sesión se traspase a un servidor de aplicaciones.
Esto posibilita la implementación de todos los servicios suplementarios
6/113
Módulo 3
tradicionales, así como nuevos servicios avanzados. Por otro lado, IMS define
componentes de pasarela que interactúan con las plataformas del plano de
servicios tradicional de la red 3G, como OSA y CAMEL. De esta forma, las
aplicaciones heredadas OSA y CAMEL pueden también actuar sobre las
sesiones IP multimedia, permitiendo la provisión de servicios IMS desarrollados
por terceras partes.
• La tarificación y facturación. En la tarificación de servicios IP multimedia
intervienen el sistema de facturación de GPRS y el sistema de facturación de
IMS. Este último registra los datos relacionados con la sesión IMS, tales como
los usuarios implicados, la duración, los componentes multimedia empleados y
la QoS autorizada, y los asocia a los correspondientes registros de tarificación
de GPRS que se originaron como consecuencia del transporte de los flujos
multimedia y la señalización de IMS en el subsistema de transporte GPRS. De
esta forma, es posible facturar los servicios según su duración, contenidos,
volumen de datos, destino de la sesión o las diferentes combinaciones de los
anteriores. Por otro lado, el sistema soporta tanto tarificación online como
offline, lo que se traduce en la facturación pospago y prepago, necesaria para
atender a todo el mercado de clientes potenciales.
1.2. Tendencia del mercado de comunicaciones

Los usuarios y las empresas van a determinar la evolución de los servicios multimedia que
los operadores fijos y móviles oferten. Los usuarios, como es normal, esperan que las
operadores le proporcionen más servicios a un coste más reducido y muestran gran interés
por los servicios más allá de los de voz. Se sienten atraídos por los servicios que les
proporcionan una gran cantidad de información de manera amigable. Además, los usuarios
siempre quieren estar conectados, donde sea, cuando sea y como ellos quieran.
Las tecnologías como el acceso a banda ancha, voz sobre IP (VoIP) y LAN inalámbrica
(WLAN, o WiFi) han sido el punto de entrada de los nuevos servicios proporcionados por los
operadores y que los usuarios ya emplean, pero aún así los operadores deben hacer más
atractivos sus servicios aprovechando la tecnología actual y desarrollando otras nuevas.
Necesidades del usuario
El número de usuarios de las telecomunicaciones está experimentando un considerable

aumento. Además, los usuarios son más individualistas, independientes, informados e
implicados que nunca, y acogen con entusiasmo la llegada de nuevos servicios que cubran
sus necesidades prácticas. Estos servicios deben hacer que la comunicación cada día se
aproxime más a un cara a cara, ocultando al usuario final la complejidad técnica del servicio.
Hoy en día los usuarios suelen acceder a información, entretenimiento y otros servicios por
distintos canales. Los operadores tienen una gran oportunidad de integrar y extender los
servicios multimedia hacia nuevos servicios altamente personalizados, bien sea orientado a
persona-a-persona, persona-a-contenido o grupos.
El empleo de servicios de telefonía móvil, mensajes SMS o mensajería instantánea

demuestran cómo los usuarios cubren sus necesidades de comunicación de distintas
7/113
Módulo 3
formas. Los operadores deben ayudarles enriqueciendo los servicios que proporcionan para
que se puedan comunicar en tiempo real con una combinación de voz, vídeo, imágenes y
mensajes.
Cualquier nuevo servicio debe ser natural e intuitivo. Debe también ocultar la tecnología
sobre la que se apoya: si emplea comunicación con hilos, o inalámbrica; en banda estrella o
banda ancha; si es de negocios o personal, etc. La interoperatibilidad entre terminales y
operadores también es una pieza clave, ya que los usuarios quieren que el servicio funcione
independientemente de a qué operador están conectados él o su interlocutor.
Respecto a la seguridad, hasta el momento los servicios de telefonía han sido inmunes a las
intrusiones, virus o ataques spam que caracterizan Internet, y así debe seguir siendo. Las
comunicaciones basadas en IP deben ser seguras, libres de ataques malintencionados, y
con la garantía de que otros usuarios no acceden a los servicios del operador a través de
nuestro terminal, fijo o móvil.
Necesidades de la empresa
Por su parte, las empresas están continuamente buscando la reducción de los gastos y una
gestión más eficiente. Quieren tener el control y demandan flexibilidad en sus
comunicaciones. Si bien las empresas están formadas por individuos que tienen las mismas
necesidad de comunicación que los usuarios particulares, también tienen unas demandas
específicas del mundo empresarial
Las nuevas tecnologías están posibilitando nuevas formas de trabajar, como por ejemplo el
teletrabajo. Esto es posible si en casa, el aeropuerto, etc. tenemos los mismos servicios que
en la oficina.
Con el aumento de las empresas que están distribuidas en distintas regiones de un país, y
las relaciones internacionales, se crea la necesidad de cubrir esas distancias con sistemas
inteligentes que permitan trabajar en colaboración o compartir información. Discutir sobre un
documento o realizar una presentación de forma remota debería ser tan natural como si
todos los participantes estuviesen en la misma sala.
Este intercambio de información remota crea la necesidad de mantener la seguridad y la

confidencialidad de las comunicaciones. Los empleados deben tener la garantía de que las
comunicaciones se realizan de una forma segura y eficiente.
Las comunicaciones entre la empresa y sus clientes también son un aspecto a tener en
cuenta. Por ejemplo, cada vez son más las empresas que ofrecen servicio de atención al
cliente (call center), y el hecho de disponer de una comunicación con vídeo puede ayudar al
personal de la empresa a solucionar el problema de su cliente en un tiempo menor.
Al mismo tiempo, las empresas necesitan que las nuevas comunicaciones sean
interoperables con los sistemas de que disponen en la actualidad, mientras que no realicen
la migración completa a los sistemas basados en IP que mantengan cubiertas sus
necesidades de telefonía, mensajería, presencia, conferencia y colaboración, etc.
8/113
Módulo 3
Necesidades del operador
En general, los operadores buscan formas rápidas y flexibles de responder a las

oportunidades de negocio, de la misma manera que los usuarios quieren evolucionar de la
telefonía a los servicios multimedia.
Cuando el negocio de los operadores se satura, éstos necesitan ampliar la capacidad de los
servicios que ellos ofrecen con el fin de proteger y aumentar sus ingresos. Una manera de
apoyar la expansión de servicios es evolucionar la infraestructura de conmutación de
paquetes para posibilitar la creación y entrega de nuevos servicios multimedia persona a
persona, con el fin de proteger el modelo de negocio.
Por otra parte, la experiencia demuestra que si se quiere alcanzar un mercado de masas la
solución debe estar basada en estándares que posibiliten la interoperatibilidad en distintas
dimensiones, entre ellas la interoperatibilidad terminal con terminal, para poder establecer
servicios de comunicaciones persona a persona. Al mismo tiempo, la interoperatibilidad
entre operadores es necesaria para proporcionar a los usuarios la libertad de utilizar
diferentes redes de manera transparente.
Necesidades de la entidad de regulación
Más allá de los intereses individuales de usuarios y operadores, nos encontramos con los
intereses de un sistema de comunicaciones público, como por ejemplo la protección del
consumidor, la calidad del servicio o la seguridad.
La entidades reguladoras y de estandarización trabajan para asegurar que las

comunicaciones basadas en IP cubren las necesidades de todos los miembros de la
comunidad, resolviendo algunos de los problemas que se presentan como por ejemplo: la
obligación de servicio universal, plan de numeración, portabilidad de número, fiabilidad y
calidad de la voz, servicios emergentes, protección de datos e intromisiones ilegales.
1.3. ¿Cómo trabaja IMS?

IMS cubre las necesidades de los usuarios y operadores descritas en el apartado anterior y
será, por tanto, la solución de tecnología natural. Proporciona una manera abierta y
estandarizada de emplear una arquitectura de red en capas horizontales.
Veamos con un ejemplo cómo IMS soporta las comunicaciones multimedia en la práctica,
con el fin de localizar las capacidades necesarias para llevar a cabo este servicio. Muchas
de las funciones y posibilidades descritas en este apartado ya existen, y no son únicas de
IMS. La diferencia es que IMS emplea un método más enfocado al usuario e integrado.
Un ejemplo de escenario
La integración de voz y datos en las comunicaciones persona a persona es un aspecto

importante. En el ejemplo siguiente se ilustra cómo IMS posibilita estas capacidades para
ayudar en la vida cotidiana.
9/113
Módulo 3
De camino al hotel Ana llama a su colega de trabajo Andrés a su número móvil para discutir
algunos problemas relacionados con un importante proyecto de construcción. Ana activa el
modo de video del teléfono para mostrarle a Andrés de qué está hablando. Andrés ve las
imágenes en su móvil mientras discuten cuál es la mejor solución. Ambos deciden que
necesitan ayuda de sus colegas que están en la oficina.
Ana selecciona el grupo de trabajo de proyecto de su lista de contactos, ve quién está

disponible, e inicia una sesión de grupo “pulsa para hablar”. Juan y Pedro responden que
ellos también han estado pensando en el problema, y tienen unas ideas que les gustaría que
Ana conociera. Cuando Ana llega al hotel arranca su ordenador portátil, abre su lista de
contactos personal e invita a Andrés, Juan y Pedro a unirse una videoconferencia. Juan abre
una presentación y la comparte con sus colegas. Al final de la videoconferencia, Andrés está
caminando todavía hacia la oficina y participa desde su teléfono móvil, pero cambia a su PC
cuando llega a su mesa, unos minutos después.
Este ejemplo nos muestra lo sencillas que puede ser las comunicaciones con el apoyo de
IMS, ya que no es sólo una tecnología que marcará la evolución de estas capacidades.
¿Cómo entra en juego IMS?
¿Qué papel desempeña IMS en la comunicación de Ana con sus colegas? La comunicación
empieza con una llamada telefónica tradicional. Durante la conversación se crea la
necesidad de mostrar y compartir, y la llamada se enriquece con el video.
Ana está en movimiento y actualmente dentro de la red de otro operador. Esto no afecta las
comunicaciones - ella tiene el acceso a los mismos servicios, sin tener en cuenta dónde
está. Todavía puede usar su lista de contactos y puede invitar al grupo de trabajo
predefinido a una sesión “pulsa para hablar”. Esto requiere la interoperatibilidad de servicio
apoyada por IMS. La presencia y gestión de la lista de grupos son una parte natural de la
comunicación y soporta la misma lista de contactos sin tener en cuenta el servicio.
Los servicios no son específicos del tipo de terminal. La videoconferencia tiene participantes
que usan tanto terminales fijos como móviles. IMS posibilita esta convergencia soportando
servicios independientes del modo de acceso. Con las imágenes, fotos, video-telefonía y
servicios multimedia combinados los usuarios podrán variar sus modos de comunicación
usando cualquier combinación de medios de comunicación. Para que esto ocurra, es
necesario emplear IMS.
Creación del servicio y entrega
Antes de la llegada de IMS los servicios se especificaban y soportaban por un solo nodo
lógico, o un conjunto de nodos, los cuales realizaban funciones especializadas para el
servicio. Cada servicio aparece como una isla, con su propio nodo específico del servicio. La
única manera de interactuar entre servicios (por ejemplo, para la composición de servicio)
era por medio de protocolos. En ausencia de un marco común, cada servicio puede tener
que ser diseñado e implementado partiendo de cero.
10/113
Módulo 3
Con la introducción de la arquitectura de IMS, para la creación y puesta en marcha de un

servicio pueden volver a utilizarse muchas funciones ya realizadas. Los servicios de IMS son
almacenados en los Servidores de Aplicación, lo que significa que son implícitamente
almacenados en la capa de aplicación IMS, y definen distintos aspectos del control del
servicio. Por ejemplo, IMS define cómo encaminar las peticiones, en qué protocolos se
soportan, cómo se realiza el cobro del servicio y cómo se activa la composición del servicio.
Un único Servidor de Aplicación puede albergar servicios múltiples. Por ejemplo, telefonía y
mensajería. La colocación de servicios múltiples tiene ventajas significativas, sobre todo con
respecto a la carga de la red de nodos IMS.
Los servicios de colocación en un Servidor de Aplicación reduce la carga de trabajo del

CSCF en la capa de control.
Funciones comunes
IMS lleva el concepto de arquitectura en capas un paso más allá definiendo una arquitectura
horizontal dónde los posibilitadores de servicio (service enablers) y las funciones comunes
pueden ser reutilizados para múltiples aplicaciones. La arquitectura horizontal en IMS
también especifica la interoperatibilidad y la itinerancia, y proporciona el control de
portadora, el cobro por el servicio y la gestión de seguridad.
La arquitectura horizontal de IMS permite a los operadores cambiar sus aplicaciones de

nuevos servicios a la tradicional implementación vertical de la arquitectura, según se
muestra en la Figura 1.2.
Figura 1.2. Transición desde una arquitectura vertical a una horizontal con funciones comunes.
La arquitectura vertical es muy costosa y compleja de construir y mantener. Deben

construirse aplicaciones separadas de cada capa para cada servicio en una red previa a
IMS, y la estructura se reproduce por la red, desde el terminal, a través del núcleo de la red,
hasta el otro terminal de usuario.
IMS proporciona varias funciones comunes que son genéricas en su estructura e

implementación, y puede reutilizarse por todos servicios de la red. Ejemplos de estas
funciones comunes son la gestión de la lista de contactos, la presencia, el
11/113
Módulo 3
aprovisionamiento, la operación y gestión, el directorio, el cobro por el servicio y el

despliegue.
Además de acelerar y simplificar la creación de servicios y procesos de entrega, la

reutilización de infraestructura común, posibilitadores y competencia proporcionadas por
IMS minimizan el OPEX y CAPEX para los operadores, sobre todo en los aspectos como el
servicio de aprovisionamiento, atención al cliente y facturación.
Posibilitadores del servicio
IMS proporciona facilidades para la creación y entrega de servicios multimedia basados en

posibilitadores comunes, que son reutilizados para otros servicios. Estos elementos son
clave para la arquitectura IMS, y se denominan posibilitadores del servicio (service
enablers). Representan los elementos básicos a partir de los cuales se crean los servicios,
ya que los posibilitadores del servicio que se han desarrollado para una aplicación concreta
pueden convertirse en posibilitadores globales cuando se incluyen en nuevas aplicaciones o
servicios.
Existen un gran número de posibilitadores del servicio, pero sin duda los dos más
importantes son el de presencia y la gestión de listas.
Presencia
El posibilitador del servicio de presencia permite informar a un conjunto de usuarios sobre la

disponibilidad y medios de comunicación de otros miembros del grupo. Por ejemplo,
habilitando a los usuarios para verse entre sí (libro de direcciones activo) o para recibir las
alarmas cuando otros usuarios pasan a estar disponibles. En IMS, el servicio de presencia
es sensible a los diferentes tipos de medios de comunicación, usuarios, y sus preferencias.
La función de presencia de IMS también tiene conocimiento de en qué terminales se puede
localizar a un usuario, bien sea en la red inalámbrica o la red cableada. Será el usuario el
que realice la configuración de quién puede ver esa información.
Gestión de listas de grupos
El posibilitador del servicio de gestión de listas de grupo permite a los usuarios crear y
gestionar los grupos de red para el uso por cualquier servicio desplegado en la red. Hay
mecanismos genéricos para la notificación de cambios en las definiciones de grupo.
Ejemplos de la aplicación para la gestión de grupo incluyen: las listas de compañeros
personales; listas de bloque; grupos públicos y privados (por ejemplo, la definición del
servicio VPN orientado a paquetes); las listas de control de acceso; los grupos de chat
públicos o privados; y cualquier aplicación dónde se requiere una lista de identidades
públicas.
Entrega del servicio
IMS proporciona una aproximación más enfocada al usuario que los servicios tradicionales,
desde el punto de vista de los servicios personales. Antes de la aparición de IMS, los
usuarios accedían a los servicios personales desde uno o más puntos específicos,
12/113
Módulo 3
dependientes del usuario. La ruta hacia el servidor también era específica del servicio, y a
menudo propiedad de una empresa. La arquitectura de servicio también estaba orientada al
servicio y la escalabilidad era un problema importante. Con la llegada de IMS, los usuarios
acceden los servicios personales por medio de un punto de acceso estandarizado,
dinámicamente asociado, orientado al usuario e independiente del servicio: el CSCF. El
CSCF se asigna dinámicamente al usuario cuando se produce una petición dirigida a ese
usuario. El encaminamiento hasta el servidor también es independiente del servicio y
estandarizado. La arquitectura está orientada al usuario y es altamente escalable.
Acceso a los servicios
IMS simplifica enormemente el proceso de ingreso y autenticación, tanto para operadores

como usuarios. Antes de la existencia de IMS, cada servicio tenía, a menudo, su propia
manera de autenticar a los usuarios, que bien podía ser estándar o propietaria. No se podía
autenticar al usuario para todos los servicios, pero el operador podía introducir un servicio
de ingreso SSO (Single Sign On) para propagar la autenticación y así evitar el tener que
volver a autentificarse en otros servicios.
Una vez autenticado a través de un servicio de IMS, el usuario puede acceder todos los
otros servicios de IMS que están autorizados para él. De la autenticación se ocupa el CSCF
cuando el usuario ingresa en el sistema. Cuando recibe una petición de servicio, el Servidor
de Aplicación SIP (AS) puede verificar que el usuario se ha autenticado.
Conveniencia y facilidad de uso
Una de las interfases claves para el usuario final es la lista de contactos. Éstas no son sólo
una lista de los contactos del usuario, sino que también muestra su disponibilidad para qué
servicio y en qué terminal. Cuando un usuario final anota un contacto en su teléfono móvil o
software de PC, el sistema se actualiza automáticamente indicando el estado del nuevo
contacto.
Interoperatibilidad de servicios
IMS posibilita la reutilización de relaciones entre operadores. En lugar de desarrollar

diferentes relaciones (acuerdos) para cada servicio, IMS permite establecer una sola
relación entre operadores válida para todos los servicios. Hoy, cuando un usuario desea
acceder a un servicio de otro usuario (por ejemplo, para verificar su estado o situación) el
encaminamiento hacia el otro usuario es específico del servicio. Es más, entran en juego
una interfaz de red dependiente del servicio, un encaminamiento, un punto de acceso al
servicio y la seguridad, y por consiguiente, un acuerdo entre operadores.
Una vez que IMS está operando, el acceso a los servicios de otros usuarios es problema de
la red de IMS, común a todos los servicios personales, como se muestra en la Figura 1.3. La
petición del servicio del operador no se ve involucrada en el encaminamiento.
El interfaz entre redes se establece en el entorno IMS, y se pueden reutilizar el

encaminamiento, el punto de acceso a red, la seguridad y la aceptación del servicio entre
operadores.
13/113
Módulo 3
Figura 1.3. Diferencia en la interoperatibilidad de servicios entre una red anterior a IMS y otra IMS.
Creación del servicio en los terminales
Los servicios de IMS requieren un cliente de IMS/SIP (incluyendo una GUI, lógica de
servicio, encaminamiento y la funcionalidad de descubrimiento) en el equipo del usuario
para poder comunicar con los servidores de la red. El cliente de IMS/SIP se estructura de tal
una manera que las funciones del núcleo se reutilizan para muchas aplicaciones, y muchas
aplicaciones pueden ubicarse en el mismo equipo del usuario. El trabajo necesario para
desplegar un nuevo servicio con IMS es significativamente menor, ya que las funciones del
núcleo ya están en el terminal del usuario.
Interconexión con redes existentes
Existen multitud de servicios en las redes de operadores de hoy en día, y es vital que los
servicios basados en IMS interactúen con éxito con ellos para facilitar su introducción en el
mercado, anime la captación de nuevos servicios, y favorezca las inversiones de los
operadores. Las posibilidades para la interconexión entre los servicios existentes y los
servicios basados en IMS variarán según los servicios reales soportados por cada dominio y
los existentes en los terminales de usuario. Cualquier interconexión debe tener en cuenta la
experiencia del usuario final en su enfoque.
A modo de ejemplo, el servicio de presencia en IMS debe apoyar la interconexión entre los
diferentes dominios de los servidores de presencia, posibilitando que los usuarios se puedan
agregar a cualquier otro usuario a su lista de contactos, independientemente del dominio al
que pertenezcan.
Otra situación importante está en la conexión entre IMS y una red de servicios inteligente,
como por ejemplo una VPN (Virtual Private Network). Por ejemplo, debería ser posible que
los servicios IMS usaran la numeración corta de una red VPN. El servidor de aplicaciones
SIP preguntaría a la red VPN el número entero para poder ejecutar la aplicación.
14/113
Módulo 3
Un posibilitador para la convergencia
Una ventaja del uso de IMS es la convergencia e interconexión de redes en varias

dimensiones: redes de acceso fijo y móvil; redes de mando y servicio; y en la capa de
conectividad.
IMS empezó como un estándar para las redes inalámbricas, pero la comunidad de redes
cableadas, en la búsqueda para un estándar de unificación, pronto comprendió el potencial
de IMS también para la comunicación fija.
Por tanto es un estándar excelente para la convergencia fijo móvil, ya que inicialmente se
diseñó originalmente para los operadores móviles, pero posteriormente se adaptó para los
requisitos de las redes cableadas.
Capas de aplicación y de control común
La introducción de IMS se puede considerar, en algunos aspectos, como un volver a

empezar, ya que las capas de control y aplicación actuales podrían soportar tanto
comunicaciones fijas como móviles.
No obstante, IMS introduce nuevas funciones comunes y posibilitadores de servicio tanto

para trabajar en los mundos fijo y móvil, rellenando el hueco existente entre ellos, de manera
que un usuario de un teléfono móvil o un cliente de PC usará, por ejemplo, las mismas
funciones de lista de grupo que si estuviese en un terminal de telefonía fija.
Las redes de acceso conscientes
Diferentes servicios tienen diferentes necesidades. Algunos servicios requieren gran ancho
de banda, otros una latencia baja, otros requieren gran potencia de cálculo en el terminal.
Esto significa que para que los diferentes servicios sean ejecutados adecuadamente la red
tiene que ser consciente de las diferentes características de los métodos de acceso.
La funcionalidad de acceso múltiple es inherente en la arquitectura de IMS. Si esto se

amplía con el control de acceso consciente y la lógica de servicio para los servicios
multimedia, resulta que IMS ofrece una forma de verdadera convergencia para los
operadores fijos y móviles. Esto permitirá adaptar el servicio entregado a las características
y capacidades del dispositivo actualmente seleccionado y al método de acceso a la red.
Tipos de dispositivos vs redes
Con la introducción de dispositivos portátiles, como las computadoras portátiles y PDAs, y el

empleo de las redes LANs inalámbricas, la frontera entre las comunicaciones fijas y móviles
se ha disipado. ¿Una llamada de VoIP desde una encima de un PDA en un hotspot del
aeropuerto es una llamada fija o móvil?
Una distinción tradicional entre las llamadas fijas y móviles es que con una llamada móvil,
uno llama a una persona; mientras que uno llama a una localización si se usa la red
cableada. Con direcciones personales SIP, las llamadas fijas pueden llegar a ser personales
15/113
Módulo 3
también, según las necesidades del usuario. En este mundo convergente, el tipo de
dispositivo llegará a ser más importante que la arquitectura de la red subyacente. En el
escenario que poníamos de ejemplo, Ana usó un teléfono móvil en el taxi que la solucionó la
comunicación en ese momento. Cuando ella necesitó una pantalla más grande para la
videoconferencia y la aplicación a compartir, cambió a un PC. En ambos casos, Ana pudo
continuar trabajando gracias a la movilidad que permite IMS.
Comunicaciones seguras
La comunicación fiable y segura es una de las primeras prioridades para los usuarios y
operadores. Con IMS, los operadores pueden llevar a cabo servicios de comunicaciones
end-to-end construidos alrededor de varias piedras angulares de la seguridad de IMS. Éstas
incluyen el atributo fundamental de IMS que los operadores de servicios proporcionan a los
usuarios autenticados. El operador de origen tiene la responsabilidad de que ningún servicio
se entrega a usuarios finales anónimos o poco fiables, y ninguna petición de servicio
anónimo, o de empresas u operadores no confiables se atiende. La cadena de
responsabilidad es, por tanto, la siguiente: la autenticación de IMS; los servicios de IMS
controlados que proporcionan el servicio a los usuarios autorizados; los acuerdos del entre
operadores que asignan la responsabilidad; y la interconexión segura de las redes.
Además, se comprueba la existencia de virus en la carga útil (principalmente de voz y

video). La seguridad del dominio se proporciona a través de la autenticación del usuario y la
SSO (Single Sign On). La seguridad de dominio de red se proporciona a través de la
seguridad del sitio donde se alojan las aplicaciones, el nodo de encaminamiento, la
protección del virus y la auditoría. Mientras la seguridad de O&M se apoya en la protección
de la gestión del tráfico y la protección del virus.
Escalabilidad
Los servicios IMS fueron concebidos para el mercado de masas, con calidad de servicio,
proporcionándoles soporte para un mundo de servicios complejo. Estos se agrupan en
paquetes de servicios diferentes que satisfacen las necesidades del cliente específicas.
Estos paquetes de servicio tendrán un número de usuarios diferente, con un
comportamiento distinto que afectará al dimensionado de la red.
En esta situación, la arquitectura IMS ofrece una gran ventaja ya que fue diseñada para
escalarse independientemente del tráfico. Esto significa que la capacidad del CSCF puede
crecer en función del número de suscriptores, y que el número de servidores de aplicación
puede hacerlo en proporción a la utilización de los diferentes servicios. Además, la cantidad
de conexiones entre dominios (por ejemplo, VoIP a PSTN) también puede crecer a medida
que se introducen nuevos servicios que emplean esas conexiones.
Problemas de regulación
Los problemas de la entidad de regulación son importantes en todos los tipos de redes. Sin
embargo, la expansión de IP ha visto la aparición de muchas redes dónde estos problemas
han sido abandonados. Proporcionar llamadas gratis o más baratas ha sido más atractivo
que proporcionar los mecanismos para interceptar legalmente las llamadas, u otras del
16/113
Módulo 3
regulador. Hay fuertes intereses en la comunidad VoIP que sostiene que esa telefonía de IP
no debe regularse de la misma manera a como se ha regulado la red de la telefonía clásica.
Algunas de las funciones de la entidad de regulación se han estandarizado en la

arquitectura de IMS. La interceptación legal de las comunicaciones es una de ellas. La
posibilidad de determinar la situación geográfica del usuario se llevará a cabo en próximas
versiones del estándar. Esta función será aplicable tanto para redes cableadas como
inalámbricas
17/113
Módulo 3
2. Arquitectura de IMS
2.1. Requisitos de la arquitectura
Existe un conjunto básico de requisitos que orientó la creación de la arquitectura IMS y
cómo debe evolucionar en el futuro. En este apartado abordaremos aquellos más
significativos.
Conectividad IP
Un requisito fundamental es que un cliente debe tener conectividad IP para poder acceder a
los servicios IMS, más concretamente se empleará el protocolo IPv6.
La conectividad IP se puede obtener bien desde la red nativa (home network) o desde una
red ajena, visitada (visited network), según se representa en la Figura 2.1. La parte de la
izquierda de dicha figura muestra una conexión en la que el equipo del usuario (UE) obtiene
la dirección IP de una red visitada. En UMTS esto significaría que la red de acceso radio
(radio access network, RAN), el nodo de soporte GPRS de servicio (Serving GPRS Support
Node, SGSN) y la puerta de enlace (Gateway GPRS Support Node, GGSN) se encuentra en
la red visitada cuando el usuario está en itinerancia. La parte de la derecha muestra una
opción en la cual el UE obtiene la dirección IP de la red nativa. En este caso, en una red
UMTS, el RAN y SGSN se localizan en la red visitada, cuando el usuario está en itinerancia.
Obviamente cuando un usuario se encuentra en la red nativa todos los elementos están en
ella, y la conectividad se obtiene de esa red.
Figura 2.1. Opciones de conectividad IMS en itinerancia.
Es importante notar que un usuario puede desplazarse y obtener conectividad IP desde la

red nativa. Esto permite a los usuarios emplear nuevos servicios IMS cuando están en
itinerancia en un área que no tiene IMS, pero sí conectividad IP. En teoría es posible
desarrollar una red IMS en un área concreta y usar itinerancia GPRS o UMTS para conectar
18/112
Módulo 3
a los clientes con su red nativa. En la práctica esto no ocurrirá debido a que el
encaminamiento no es lo suficientemente eficiente.
Independencia de acceso
El estándar IMS se debe diseñar para que los servicios que proporciona puedan funcionar
sobre cualquier tipo de red de conectividad (GPRS, UMTS, WLAN, ADSL, etc.).
Calidad de servicio para los servicios IP multimedia
En Internet los tiempos de retardo son variables y excesivamente altos, por lo que los
paquetes pueden llegar desordenados o alguno se puede perder. Esto no debe ocurrir en el
caso de IMS. El acceso y red de transporte de IMS deben proporcionar calidad de servicio
(QoS) de usuario final a usuario final.
A través de IMS, los UE negocian sus posibilidades y determinan sus requisitos de QoS
durante el protocolo de inicio de sesión (Session Initiation Protocol, SIP). El UE es capaz de
negociar aspectos como:
• Tipo de comunicación multimedia, tráfico, etc.

• Velocidad de bit (bit rate), tamaño de los paquetes, frecuencia de transporte de
los paquetes.
• Empleo de protocolo RTP en función del tipo de comunicación.
• Adaptación al ancho de banda disponible.
Después de la negociación de los parámetros a nivel de aplicación, los UE reservan los

recursos necesarios de la red. Cuando se crea la QoS, los UE codifican y empaquetan los
diferentes ficheros multimedia con el protocolo adecuado (por ejemplo, RTP) y los envían a
la red de acceso y transporte usando un protocolo de transporte (por ejemplo, TCP) sobre
IP. Se da por supuesto que los operadores negocian a nivel de servicio para garantizar la
calidad en la red troncal.
Política de control IP
La política de control significa la capacidad de autorizar y controlar el tráfico IMS, basado en

parámetros de señalización de una sesión IMS. Esto requiere una interacción entre la red de
acceso de conectividad IP e IMS. Los medios que permiten esta interacción se dividen en
tres categorías:
• Los elementos de la política de control pueden analizar qué valores de los

negociados en la señalización SIP se emplean para activar las portadoras del
tráfico.
• Los elementos de la política de control pueden decidir cuando comienza y
termina una sesión SIP entre dos puntos.
• Los elementos de la política de control pueden recibir notificaciones cuando el
servicio de la red de acceso de conectividad IP se ve modificado, suspendido o
19/112
Módulo 3
deja de existir portadora, por ejemplo cuando un usuario está fuera de

cobertura.
Comunicaciones seguras
La seguridad es un aspecto fundamental en cualquier sistema de comunicación e IMS no es

una excepción. IMS proporciona al menos un nivel de seguridad igual al de las redes GPRS,
UMTS o redes de conmutación de circuitos. Por ejemplo, IMS se asegura que los usuarios
se han autenticado antes de que puedan usar los servicios, y los usuarios pueden pedir
privacidad cuando inician una sesión.
Planes de cobro de servicios
Para los operadores, la posibilidad de realizar el cobro a los usuarios por los servicios
prestados es una premisa, para lo que la arquitectura IMS proporciona varias posibilidades,
entre las que se incluyen la posibilidad de realizar el cargo a nivel de sesión IMS o a nivel de
transporte, es decir, por contenido o por servicio. Además, se puede realizar el cargo bien al
usuario que establece la comunicación, o compartiéndolo entre éste y el/los receptor/es de
la misma.
Una sesión IMS puede incluir varios contenidos multimedia (audio, video, etc.) por lo que se
requiere que IMS provea un medio para realizar el cargo por componente. Esto permitiría
realizar el cargo a medida que se añaden componentes a la comunicación, pero para esto
es necesario que la red IMS sea capaz de intercambiar información de cargo entre
operadores.
La arquitectura IMS soporta cargo online u offline. El cargo online es una posibilidad por la
que el cargo se realiza mientras que está teniendo lugar la comunicación, en tiempo real,
por lo que interactúa con el control de sesión. En la práctica un operador puede comprobar
el saldo del usuario antes de permitirle iniciar una sesión y detener la misma cuando el saldo
se agote, como si se tratase de un servicio prepago. El cargo offline, por el contrario, es el
modelo tradicional en el que se recoge la información de cargo durante un tiempo y luego se
factura al usuario.
Soporte para itinerancia
Desde un punto de vista del usuario es importante conseguir acceso a los servicios sin tener
en cuenta la situación geográfica en la que se encuentre. La característica de itinerancia
hace posible el uso de los servicios aunque el usuario no está localizado en el área de
cobertura del servicio de su red nativa.
Interconexión con otras redes
Es evidente que IMS no se ha desarrollado en todo el mundo al mismo tiempo, y además los
usuarios no dispondrán de terminales rápidamente. Esto incrementa el problema de poder
localizar a los usuarios a pesar del tipo de terminal de que dispongan o de donde vivan.
Para que la tecnología IMS tenga éxito, debe poder conectar a los usuarios tan pronto como
sea posible, por lo que debe poder comunicarse con los usuarios de PSTN, RDSI, móviles e
20/112
Módulo 3
Internet. Además, debe poder soportar sesiones con aplicaciones de Internet que no han
sido desarrolladas por la comunidad 3GPP.
Modelo de control de servicio
Inicialmente, cuando un usuario estaba en itinerancia existía una entidad en la red visitada
que permitía controlar el tráfico, como complemento al control del tráfico que se realiza
cuando la conexión es a través de la red nativa. El mantener estos dos modelos de control
implicaba que cada problema debía tener varias soluciones, complicando además la
arquitectura. Por ello el IETF eliminó el control el control en la red visitada, escogiendo el
control de la red nativa, lo que quiere decir que la entidad que accede a la base de datos del
usuario e interactúa directamente con las plataformas del servicio está siempre alojadas en
la red nativa.
Desarrollo de servicios
La importancia de tener una plataforma de servicios escalable y posibilitar el lanzamiento

rápido de nuevos servicios ha significado que ya no se estandarizan conjuntos de
teleservicios, aplicaciones o servicios suplementarios. En su lugar, 3GPP estandariza
capacidades de servicio, y no servicios en sí mismos. La arquitectura IMS debería incluir un
marco para los servicios que proporcione las capacidades necesarias para soportar audio,
video, multimedia, mensajes, ficheros compartidos, transferencia de datos, juegos y
servicios suplementarios.
Diseño en capas
3GPP decidió usar una arquitectura basada en capas. Esto significa que los servicios de
transporte y portadora están separados de la red de señalización IMS y de los servicios de
gestión de sesión. Otros servicios se ejecutan encima de la capa de red de señalización
IMS, según se muestra en la Figura 2.2.
En algunos casos puede ser imposible distinguir entre funcionalidades de la capa alta o
baja, ya que este diseño implica una cierta relación de dependencia entre capas. Como
beneficio, facilita añadir nuevos servicios al sistema posteriormente, como por ejemplo
nuevos métodos de acceso a IMS.
La aproximación en capas incrementa la importancia de la capa de aplicación. Cuando las

aplicaciones están aisladas y existen funcionalidades comunes proporcionadas por la red
IMS la misma aplicación puede ejecutarse en UE que empleen distintos tipos de accesos.
21/112
Módulo 3
Figura 2.2. Arquitectura de capas IMS.
2.2. Funciones y entidades relacionadas con IMS

En este apartado vamos a abordar la descripción del conjunto de funcionalidades y
entidades que forman parte del estándar IMS. Éstas se agrupan en seis categorías
principales: gestión de sesión y encaminamiento (CSCFs), bases de datos (HSS, SLF),
elementos de interconexión (BGCF, MGCF, IM-MGW y SGW), servicios (servidor de
aplicación, MRFC, MRFP), entidades de soporte (THIG, SEG, PDF) y cargo. Es importante
recalcar que IMS no especifica en detalle todas las funcionalidades y entidades, ni las
interacciones entre ellas, sino que describe lo que denomina interfases (reference points). A
continuación describiremos las entidades y funciones que forman IMS.
Proxy CSCF1
El Proxy-Call Session Control Function, P-CSCF (algo así como el servidor proxy de la
función de control de sesión) es el punto de entrada de un usuario a la red IMS. Todo el
tráfico SIP hacia o desde el UE lo hace a través del P-CSCF, el cual realiza una tarea
estándar de proxy, esto es, valida las peticiones, las dirige al destino seleccionado y procesa
y encamina las respuestas. Además es capaz de liberar sesiones que han acabado de una
1
Hemos decidido mantener el nombre de las entidades y funcionalidades en inglés, pero al mismo tiempo se ha
tratado de realizar una traducción lo más lógica posible.
22/112
Módulo 3
manera anormal, como por ejemplo cuando se ha perdido la portadora en una comunicación
vía radio. Puede haber uno o varios P-CSCFs en la red del operador, siendo sus funciones
más importantes las siguientes:
• Encaminar las peticiones de registro SIP al Interrogating-CSCF (I-CSCF)

basándose en el nombre de dominio proporcionado por el UE.
• Encaminar las peticiones SIP y las respuestas recibidas del UE hacia el
Serving-CSCF (S-CSCF).
• Encaminar las peticiones SIP y las respuestas hacia el UE.
• Detectar peticiones de establecimiento de sesión de emergencia.
• Enviar información de la cuenta de usuario a la función Charging Collection
Function (CCF).
• Proveer protección de integridad a la señalización SIP y mantener la seguridad
entre el UE y el P-CSCF. La protección de integridad la proporciona el protocolo
Internet Protocol Security (IPsec) Encapsulating Security Payload (ESP).
• Descomprimir y comprimir los mensajes SIP del UE.
• Suscribir un evento de registro de usuario cuando se conecta en S-CSCF. Esto
es necesario para descargar identidades de usuarios públicos registrados con el
fin de obtener notificaciones cuando éstos se desconecten.
• Ejecutar políticas de medios. El P-CSCF es capaz de comprobar el contenido de
la carga del protocolo Session Description Protocol (SDP) y analizar qué tipo de
medio transporta, o bien la existencia de codecs no permitidos por el usuario.
Cuando no están permitidos el P-CSCF rechaza la petición y envía un mensaje
de error al UE.
• Mantener los timer de la sesión, lo cual permite detectar recursos libres usados
por sesiones muertas
• Interactuar con la función Policy Decision Function (PDF), que es la responsable
de implementar la política local basada en servicio (Service Based Local Policy,
SBLP).
Policy Decision Function (PDF)
La función de decisión de políticas, (Policy Decision Function, PDF) es la responsable de

hacer las políticas de decisión basándose en la información del medio y de la sesión,
obtenida del P-CSCF. Actúa como un punto de decisión para el control SBLP, para lo que se
han definido las siguientes funcionalidades:
• Almacenar la información de tipo de medio y sesión (dirección IP, números de

puerto, anchos de banda, etc.).
• Generar un testigo que identifique el PDF y la sesión.
• Proveer autorización de acuerdo a la información del medio y sesión
almacenados cuando se recibe una petición autorizada desde el GGSN.
• Actualizar la autorización cuando se produzcan cambios en la sesión o el medio.
• Capacidad para retirar la autorización en cualquier momento.
23/112
Módulo 3
• Capacidad para habilitar el uso de una portadora autorizada (por ejemplo,

Packet Data Protocol, o PDP).
• Capacidad para impedir el empleo de una portadora autorizada cuando sea
oportuno.
• Informar al P-CSCF cuando una portadora se pierde o se modifica.
• Pasar un identificador de cargo IMS al GGSN y pasar un identificador de cargo
de medio al P-CSCF.
CSCF Interrogativo
El Interrogating-CSCF (I-CSCF) es un punto de contacto dentro de la red del operador para

todas las conexiones destinadas a un abonado de la red de ese operador. Pueden existir
muchos I-CSCFs en la red de un operador, y las funciones que realiza son:
• Contactar con el HSS para obtener el nombre del S-CSCF que está
manteniendo a un usuario.
• Asignar un S-CSCF basándose en las capacidades recibidas del HSS.
• Encaminar las peticiones SIP o las respuestas hacia el S-CSCF.
• Enviar información relativa a la cuenta hacia el CCF.
• Proveer funcionalidades ocultas, llamadas Topology Hiding Inter-network
Gateway (THIG). THIG se podría usar para ocultar la configuración, capacidad y
topología de la red más allá de la red del operador.
Serving-CSCF (S-CSCF)
El Serving-CSCF (S-CSCF) es el cerebro de IMS, situado en la red nativa (home network).

Realiza control de las sesiones y registro de servicios de los UE. Mientras que un UE está
conectado en una sesión, el S-CSCF mantiene el estado de dicha sesión e interactúa con
las plataformas del servicio y las funciones de cargo según sea necesario. Puede haber
varios S-CSCF, y pueden tener distintas funcionalidades dentro de la red del operador. Sus
funciones más importantes son:
• Manejar las peticiones de registro actuando como una entidad de registro. El S-

CSCF conoce la IP del UE y qué P-CSCF está utilizando como punto de entrada
a IMS.
• Autentificar a los usuarios por medio del esquema Authentication and Key
Agreement (AKA) de IMS. El AKA permite autentificación mutua entre el UE y la
red nativa.
• Descargar información de usuario y datos relacionados con el servicio desde el
HSS durante el registro.
• Encaminar tráfico de terminales móviles hacia el P-CSCF, el I-CSCF, el
Breakout Gateway Control Function (BGCF) o el servidor de aplicación (AS).
• Realizar el control de la sesión, ya que puede actuar como un servidor proxy.
• Interactuar con las plataformas de servicio, es decir, decidir cuándo una petición
o una respuesta necesita ser encaminada a un AS para realizar un mayor
procesamiento.
24/112
Módulo 3
• Trasladar números E.164 a identificadores de recursos universales SIP (URI)

usando un sistema de nombres de dominio (DNS).
• Supervisar los temporizadores de registro con el fin de poder eliminar el registro
a los usuarios cuando sea necesario.
• Seleccionar un centro de emergencia durante una sesión IMS de emergencia.
• Ejecutar políticas de medio. S-CSCF puede comprobar la carga SDP y el tiempo
de información que transporta, con el fin de realizar tareas de filtrado.
• Mantener los temporizadores de la sesión.
• Enviar información relacionada con la cuenta al CCF para hacer cargos offline y
al Online Charging System (OCS) para los cargos online.
Home Subscriber Server (HSS)
El Home Subscriber Server (HSS) es el elemento de almacenamiento de datos principal de

IMS. Los datos que almacena incluyen las identidades del usuario, información de registro y
parámetros de acceso, entre otros.
Las identidades de usuario pueden ser de dos tipos: privadas y públicas. La identidad
privada es aquella que se asigna a un usuario por la red nativa del operador y se emplea
con propósitos como el registro y la autorización, mientras que la identidad pública es la que
otros usuarios pueden usar cuando quieren establecer una comunicación.
Los parámetros IMS se emplean para activar sesiones e incluir información como la
autenticación, autorización de itinerancia, y nombres S-CSCF.
El servidor HSS también contiene un subconjunto de la funcionalidad Home Location

Register y Authentication Center (HLR/AUC) requerida por el dominio de conmutación de
paquetes PS y de circuitos CS. La estructura del servidor HSS se muestra en la Figura
2.3. La comunicación entre las diferentes funciones HSS no está estandarizada.
Figura 2.3. Estructura de HSS.
La funcionalidad HLR se requiere para proporcionar soporte a las entidades del dominio
PS, como SGSN y GGSN, posibilitando el acceso a sus servicios. De una manera similar
HLR proporciona soporte para los servicios CS, como los servidores MSC/MSC,
permitiendo acceder a los servicios del dominio CS y soportar itinerancia en redes
GSM/UMTS.
La entidad AUC almacena una clave secreta por cada abonado que se emplea con el fin de
generar datos de seguridad dinámicos para los abonados móviles. Estos datos son usados
25/112
Módulo 3
para autenticación mutua en la red. Los datos de seguridad también se emplean para
protección y cifrado de las comunicaciones de radio entre los UE y la red.
Puede existir más de un HSS en la red nativa, dependiendo de número de abonados

móviles, la capacidad de los equipos y la organización de la red.
Subscription Locator Function (SLF)
La función Subscription Locator Function (SLF) se emplea como un mecanismo de

resolución que permite al I-CSCF, el S-CSCF y el AS encontrar la dirección del HSS que
guarda la información de un abonado cuando existen múltiples HSS en la red del operador.
Multimedia Resource Function Controller (MRFC)
El controlador Multimedia Resource Function Controller (MRFC) es necesario para soportar

los servicios basados en portadora, como las conferencias o anuncios a un usuario. Además
el MRFC puede enviar información de la cuenta de usuario al CCF y al OCS.
Multimedia Resource Function Processor (MRFP)
El procesador Multimedia Resource Function Processor (MRFP) proporciona recursos en la

capa de usuario que son utilizados por el MRFC. Realiza además las siguientes funciones:
• Mezcla los streams que se están recibiendo simultáneamente, por ejemplo, en

multiconferencias.
• Es una fuente de ficheros multimedia, por ejemplo los anuncios a los usuarios.
• Realiza procesado de los streams, en el caso de la transcodificación o el
análisis de los ficheros multimedia.
Application Server (AS)
Si recordamos la estructura en capas de IMS, los servidores de aplicación no son entidades

puras, sino que son funciones de la capa superior. No obstante, los AS se describen como
parte de las funciones IMS porque son entidades que proporcionan valor añadido a los
servicios multimedia IMS.
Un AS reside en la red nativa o en una red de un tercero, siendo sus funciones

principales las siguientes:
• Posibilidad de procesar las sesiones SIP recibidas desde IMS.

• Capacidad de originar peticiones SIP.
• Capacidad de enviar información de la cuenta de usuario al CCF y al OCS.
Los servicios que ofrece no están limitados a los servicios SIP, ya que un operador puede
ofrecer servicios basados en aplicaciones personalizadas para redes móviles con lógica
mejorada (Customized Applications for Mobile network Enhanced Logic, CAMEL) y la
arquitectura de servicio abierta (Open Service Architecture, OSA). Por tanto, el término
26/112
Módulo 3
“AS” se usa para referirse tanto a lo SIP AS, OSA Service Capability Server (SCS) y
CAMEL IP Multimedia Service Switching Function (IM-SSF).
Usando OSA un operador dispone de las características de control de llamada,

interacción con el usuario, estado del usuario, capacidades del terminal, gestión de
cuenta y gestión de políticas y de cargo. Además, otro beneficio es que puede ser
utilizado como un mecanismo estándar para proporcionar AS de terceros de una
manera segura, ya que OSA por si mismo contiene las características de acceso inicial,
autentificación, autorización, registro y descubrimiento.
La función IM-SSF fue introducida en IMS pasa dar soporte a servicios ya existentes
desarrollados en el CAMEL Service Environment (CSE). Implementa las características
de una red CAMEL y se interconecta con la interfaz CAMEL Application Part (CAP).
Un servidor SIP AS es un servidor basado en SIP que integra una gran cantidad de
servicios multimedia de valor añadido. Se puede emplear para dar servicio de
presencia, mensajería y conferencia, entre otros. La Figura 2.4 muestra cómo se
interconectan las diferentes funciones. Desde la perspectiva del servidor S-CSCF,
tanto SIP AS como el servidor OSA y el IM-SSF tienen el mismo comportamiento.
Figura 2.4. Arquitectura del servidor de aplicación.
Un AS debe estar dedicado a un servicio, pero un usuario debe poder acceder a varios
servicios simultáneamente, por lo que deben existir varios AS por abonado. Además,
debe haber uno o más AS involucrados en una sesión. Por ejemplo, un operador puede
tener más de un AS para controlar el tráfico de un usuario basándose en sus
preferencias (por ejemplo, redirigir todas las comunicaciones multimedia a una máquina
concreta entre las 5 de la tarde y las 7 de la mañana), y otro AS para adaptar el
contenido de los mensajes instantáneos a las capacidades del UE (tamaño pantalla,
número de colores, etc.).
27/112
Módulo 3
Breakout Gateway Control Function (BGCF)
La función Breakout Gateway Control Function (BGCF) es la responsable de determinar

donde se produce una pérdida de sesión en el dominio CS. La pérdida de sesión se puede
producir en la misma red donde se localiza el BGCF, o bien en otra red. Si se produce en la
misma red, la función BGCF selecciona una función MGCF para mantener la sesión. Si se
produce en otra red, BGCF envía la sesión hacia otro BGCF en la red donde se produjo
dicha pérdida de sesión.
Media Gateway Control Function (MGCF)
La función Media Gateway Control Function (MGCF) es una pasarela que posibilita la
comunicación entre los usuarios IMS y CS. Toda la señalización de las llamadas entrantes
de un usuario CS se envían al MGCF que realiza la conversión de protocolo entre el ISDN
User Part (ISUP) o el Bearer Independent Call Control (BICC) al protocolo SIP y redirige la
sesión a IMS. De la misma manera, todas las sesiones iniciadas en IMS que van a usuarios
CS se encaminan por medio del MGCF. Además, MGCF también controla los canales en el
nivel de usuario con el IMS Media Gateway IMS-MGW.
IMS Multimedia Gateway Function (IMS-MGW)
La función IMS Multimedia Gateway Function (IMS-MGW) proporciona el enlace entre las
redes CS (PSTN, GSM) e IMS, a nivel de usuario. Determina el comportamiento de los
canales de una red CS, ejecuta la conversión entre terminales y realiza la transcodificación y
procesamiento de señal en el nivel de usuario cuando es necesario. Además, IMS-MGW
puede proporcionar avisos a los usuarios CS.
Signalling Gateway (SGW)
La pasarela de señalización, signalling gateway (SGW) se emplea para conectar redes

con señalización distinta, como por ejemplo redes basadas en SCTP/IP con redes con
señalización SS7. El SGW realiza la conversión de señales en ambos sentidos a nivel
de transporte. El SGW no interpreta los mensajes de la capa de aplicación (por
ejemplo, BICC o ISUP). En la Figura 2.5 se muestra la conversión de señales que
realiza SGW, donde se observa que la conversión es únicamente a nivel de transporte.
Figura 2.5. Conversión de señales en el SGW.
28/112
Módulo 3
Security Gateway (SEG)
Para proteger el tráfico, éste pasa a través de una pasarela de seguridad, security gateway
(SEG), antes de entrar o abandonar un dominio de seguridad. Los dominios de seguridad se
refieren a redes que son manejadas por una misma autoridad administrativa. Típicamente,
coincide con los límites de la red del operador. La pasarela SEG se ubica en el borde del
dominio de seguridad y refuerza la política de seguridad entre dominios. La red del operador
puede tener más de una pasarela SEG con el fin de tener redundancia, o por motivos de
rendimiento, simplemente.
Entidades de cargo
Existen diferentes entidades de cargo con sus correspondientes interfases, que se verán en
el apartado siguiente.
2.3. Interfases IMS

Según hemos comentado en el apartado anterior, las entidades se relacionan mediante las
interfases, empleando para ello protocolos definidos. En la Figura 2.6 se muestran estas
interfases, indicando las entidades que conectan. En este apartado describiremos
brevemente dichas entidades, dejando para el tema 4 el estudio de los protocolos.
Figura 2.6. Entidades e interfases IMS.
Para una mayor claridad no se han incluido todos los elementos de la arquitectura IMS
en la Figura 2.6, por lo que hay que tener en cuenta que en dicha figura:
• No se han representado las funciones e interfases relacionadas con el cargo.

• No muestra todos los tipos posibles de AS.
29/112
Módulo 3
• No muestra las conexiones a nivel de usuario entre las diferentes redes IMS y
los AS.
• No muestra las interfases SEG, Mm, Mk y Mw.
• Las líneas discontinuas representas enlaces directos entre entidades.
• Las interfases ISC, Cx, Dx, Mm, Mw terminan tanto en el Serving-CSCF (S-CSCF) como
en el I-CSCF.
Interfaz Gm
La interfaz Gm conecta el UE a IMS, y se emplea para transportar los mensajes de

señalización entre ambos, más concretamente entre el UE y el P-CSCF. Los procedimientos
en esta interfaz se pueden dividir en tres categorías principales: registro, control de sesión y
transacción.
• Registro: Aquellos que emplea el UE para enviar peticiones de registro con

indicación de los métodos de seguridad soportados al P-CSCF. Además informa
al UE si la sesión ha sido iniciada o finalizada.
• Control de sesión: Contiene los métodos para las sesiones con origen o destino
en redes móviles. En las sesiones con origen en redes móviles Gm encamina
las peticiones desde el UE hasta el P-CSCF, y en las sesiones con destino a las
mismas realiza el encaminamiento contrario.
• Transacción: Se emplean para enviar peticiones (por ejemplo, MESSAGE) y
recibir las respuestas a dichas peticiones (por ejemplo, 200 OK). La diferencia
con los procedimientos de control de sesión es que en los de transacción se
establece un diálogo.
Interfaz Mw
La interfaz Mw conecta diferentes entidades CSCF, pudiendo dividirse sus funciones

en tres categorías:
• Registro: En los procedimientos de registro el P-CSCF envía las peticiones del

UE al I-CSCF, el cual pasa las peticiones al S-CSCF. Este último resuelve la
respuesta también por medio de la interfaz Mw.
• Control de sesión: Contiene mecanismos para las sesiones con origen o destino
en redes móviles. En las sesiones con origen en redes móviles envía las
peticiones desde el P-CSCF al S-CSCF pasando por el I-CSCF, siendo el
camino contrario para las sesiones con destino a una red móvil.
• Transacción: Contiene procedimientos para pasar peticiones y recibir las
respuestas.
Interfaz de control de servicio IMS
En la arquitectura IMS las entidades AS almacenan y ejecutan servicios como el de

presencia, mensajería o encaminamiento de sesión. Por ello debe existir una interfaz para
enviar y recibir mensajes SIP entre el AS y el CSCF. Esta interfaz se denomina IMS Service
Control (ISC), el cual tiene unos procedimiento que se pueden dividir en dos categorías:
30/112
Módulo 3
• Encaminamiento de una petición SIP a un AS: Cuando un S-CSCF recibe una

petición la analiza, y determina hacia qué AS la debe encaminar para realizar su
procesamiento.
• Peticiones SIP iniciadas en un AS.
Interfaz Cx
La información de los abonados y los datos de servicio se almacenan en el HSS. Estos

datos centralizados son utilizados por el I-CSCF y el S-CSCF cuando un usuario se registra
o recibe una petición de sesión, por lo que debe establecerse una comunicación entre el
HSS y el CSCF. Esta comunicación se establece por la interfaz Cx, empleando el protocolo
Diameter. Los procedimientos se dividen entres categorías principales: gestión de
localización, mantenimiento de los datos de usuario y autenticación de usuarios.
Los procedimientos de gestión de localización a su vez se pueden dividir en dos grupos:

registro y eliminación del registro y recuperación de localización. El registro y eliminación del
registro se puede producir entre el I-CSCF y el HSS o bien entre el S-CSCF y el HSS. En el
primer caso cuando el I-CSCF recibe una petición SIP-REGISTER de parte del P-CSCF a
través de la interfaz Mw envía una petición de registro conocida como User-Authorization
Request (UAR) que contiene la identidad privada y pública del usuario, el identificador de la
red visitada, la información de encaminamiento y el tipo de autorización. Cuando el HSS
recibe la petición envía una respuesta (User-Authorization Answer, UAA) con el resultado de
la autorización y el nombre del S-CSCF.
Cuando es el S-CSCF el que recibe la petición SIP REGISTER del I-CSCF, envía una orden
Server-Assignment-Request (SAR) al HSS para informarle de qué C-CSCF está
sirviendo al usuario, o bien que ha dejado de prestarle servicio cuando ha finalizado el
tiempo establecido. El HSS responde con una orden Server-Assignment-Answer (SAA)
que contiene el resultado de la ejecución de la orden de petición, el perfil de usuario e
información sobre el cargo del servicio.
El procedimiento de recuperación de localización permite localizar el S-CSCF cuando se

recibe una petición SIP diferente de REGISTER. Envía una orden Location-Info-Request
(LIR) al HSS que contiene las identidades públicas y privadas del usuario obtenidas del URI
y la información de encaminamiento incluyendo la dirección del HSS. El HSS responde con
una orden Location-Info-Answer (LIA) con la respuesta a la orden de petición, el nombre del
S-CSCF y sus capacidades.
Los procedimientos de gestión de usuarios se encargan de mantener actualizada la

información relativa a los usuarios. Durante el proceso de registro los datos referentes al
usuario se descargan desde el HSS al S-CSCF por medio de la interfaz Cx, pero es posible
que esos datos cambien una vez que se han enviado al S-CSCF. En ese caso el HSS
actualiza la información con una orden Push-Profile-Request (PPR) que contiene la
identidad privada del usuario, la información de encaminamiento y los datos
específicos del usuario. La orden PPR se asiente con una orden Push-Profile-Answer
(PPA), que simplemente indica el resultado de la operación.
31/112
Módulo 3
La actualización tiene lugar instantáneamente con una excepción: cuando el S-CSCF

está dando servicio a un usuario no registrado, en cuyo caso el HSS no envía el
comando de actualización al S-CSCF.
Los procedimientos de autenticación se confían a un sistema de secretos compartidos

preconfigurados. Los secretos compartidos y las secuencias de números se almacenan en
el módulo IP Multimedia Services Identity Module (ISIM), tanto en el UE como en el HSS.
Cuando un S-CSCF trata de identificar a un usuario es necesario realizar el envío de
información por un canal seguro. Para ello el S-CSCF envía una orden Multimedia-Auth-
Request (MAR) al HSS. Este último responde con una orden Multimedia-Auth-Answer (MAA)
dentro de la cual se incluye un vector de identificación y un esquema de autentificación,
como por ejemplo Digest-AKAvl-MD5, entre otras informaciones.
Interfaz Dx
Cuando existe más de un HSS en la red, los I-CSCF y S-CSCF no saben con cuál de ellos
tienen que contactar, por lo que necesitan contactar primero con el SLF, y para este
propósito se ha desarrollado la interfaz Dx. Esta interfaz se emplea junto con el Cx y emplea
el protocolo Diameter para obtener la dirección del HSS al que se deben conectar, según el
protocolo mostrado en la Figura 2.7. En la figura, cuando un I-CSCF recibe una petición
INVITE éste pregunta al SLF cuál es el HSS al que se debe conectar y éste le responde que
el HSS #2.
Figura 2.7. Resolución de la dirección HSS usando SLF.
Interfaz Sh
Un servidor SIP AS o OSA AS puede necesitar datos de usuarios o conocer a qué S-CSCF
debe enviar una petición. Esta información se almacena en el HSS, por lo que debe haber
una interfaz entre el HSS y el AS, que en este caso se denomina Sh y emplea el protocolo
Diameter. Los procedimientos que implementa se dividen en dos categorías: manejo de
datos y suscripción/notificación.
Los procedimientos de manejo de datos hacen posible obtener datos del usuario del HSS,
como por ejemplo datos relacionados con el servicio, información de registro, identidades,
filtro inicial, nombre del S-CSCF que da servicio al usuario, dirección de facturación, etc.
Para acceder a esta información el AS emplea la orden User-Data-Request (UDR), a la cual
responde el HSS con una orden User-Data-Answer (UDA).
32/112
Módulo 3
Por otra parte, los procedimientos de suscripción/notificación permiten al AS obtener una

notificación cuando algún dato de un usuario determinado se actualiza en el HSS. El
servidor AS envía una petición Subscribe-Notifications-Request (SNR) al HSS indicando los
datos que deben generar una notificación en caso de que cambien. El HSS responde con
una orden Subscribe-Notifications-Answer (SNA) que indica el resultado de la operación.
Interfaz Si
La interfaz Si la utiliza un servidor AS para comunicarse con el HSS cuando es del tipo
CAMEL AS. Se emplea para transportar la información de suscripción CAMEL desde el HSS
hasta el servidor CAMEL AS, empleando para ello un protocolo Mobile Application Part
(MAP).
Interfaz Dh
Cuando existe más de un servidor HSS en la red, el AS necesita saber con cual de ellos
debe contactar. Para saberlo contacta primero con el SLF por medio de la interfaz Dh, que
se emplea siempre junto con la interfaz Sh, y emplea el protocolo Diameter. Para obtener la
dirección del HSS, el servidor AS envía una petición al SLF por medio de la interfaz Sh.
Interfaz Mm
La interfaz Mm permite la comunicación entre una red IMS y otras redes IP multimedia. Esta
interfaz permite al I-CSCF recibir peticiones de sesión de otro servidor SIP o terminal. De la
misma manera, S-CSCF emplea Mm para enviar peticiones originadas en IMS a otras redes.
Interfaz Mg
La interfaz Mg enlaza la función CS MGCF con IMS, concretamente con el I-CSCF. Permite
a la función MGCF enviar la señalización de sesión desde el dominio CS al I-CSCF,
empleando el protocolo SIP. Es decir, la función MGCF es la responsable de convertir la
señalización ISUP en SIP.
Interfaz Mi
Cuando el S-CSCF descubre que se necesita encaminar una sesión al dominio CS se

emplea la interfaz Mi para reenviar la sesión al BGCF.
Interfaz Mj
Cuando el BGCF recibe una señalización de sesión que le ha llegado vía Mi, selecciona el
dominio CS en la cual se ha producido. Si está en la misma red, encamina la sesión al
MGCF por medio de la interfaz Mj, empleando el protocolo SIP.
Interfaz Mk
33/112
Módulo 3
Cuando el BGCF recibe una señalización de sesión por medio de la interfaz Mk, selecciona
el dominio CS en la cual se ha producido. Si se ha producido en otra red reenvía la sesión al
BGCF de la otra red por medio de la interfaz Mk, empleando el protocolo SIP.
Interfaz Ut
La interfaz Ut conecta el UE y el AS. Permite al usuario la gestión segura y la configuración

de los servicios proporcionados por su red, almacenados en el AS. Los usuarios pueden
utilizar la interfaz Ut para crear identidades públicas, listas de recursos, entre otras cosas. A
modo de ejemplo, los servicios de presencia y conferencia utilizan esta interfaz. Para ello se
ha elegido el protocolo http.
Interfaz Mr
Cuando el S-CSCF necesita activar servicios basados en portadora, envía la señalización

SIP al MRFC por medio de esta interfaz, empleando protocolo SIP. No obstante, la interfaz
Mr no está completamente definida en el estándar.
Interfaz Mp
La interfaz Mp se emplea cuando el MRFC necesita controlar los streams, por ejemplo para
crear conexiones para una conferencia.
Tabla 2.1. Resumen de las interfases.

Nombre Entidades relacionadas Propósito Protocolo
Gm UE, P-CSCF Intercambio de mensajes entre UE y CSCFs SIP
Mw P-CSCF, I-CSCF, S-CSCF Intercambio de mensajes entre CSCFs SIP
ISC S-CSCF, I-CSCF, AS Intercambio de mensajes entre CSCF y AS SIP
Cx I-CSCF, S-CSCF, HSS Comunicación entre I-CSCF/ S-CSCF y HSS Diameter
Dx I-CSCF, S-CSCF, SLF Usado por I-CSCF/S-CSCF para encontrar un Hss correcto en un entorno Diameter
con múltiples HSS
Sh SIP AS, OSA SCS, HSS Intercambio de información entre SIP AS/OSA SCS y HSS Diameter
Si IM-SSF, HSS Intercambio de información entre IM-SSF y HSS MAP
Dh SIP AS, OSA, SCF, IM-SSF, Usado por AS para encontrar un HSS correcto en un entorno Diameter
HSS con múltiples HSS
Mm I-CSCF, S-CSCF, external IP Intercambio de mensajes entre IMS y redes IP externas No specific.
Mg MGCF -+ I-CSCF MGCF convierte señalización ISUP a señalización SIP y encamina la SIP
señalización SIP hacia I-CSCF

Mi S-CSCF -> BGCF Intercambio de mensajes entre S-CSCF y BGCF SIP
Mj BGCF -> MGCF Intercambio de mensajes entre BGCF y MGCF en la misma red IMS SIP
Mk BGCF -> BGCF Intercambio de mensajes entre BGCFs en diferentes redes SIP
Mr S-CSCF, MRFC Intercambio de mensajes entre S-CSCF y MRFC SIP
Mp MRFC, MRFP Intercambio de mensajes entre MRFC y MRFP H.248
Mn MGCF, IM-MGW Permite control del flujo de los recursos a nivel de usuario H.248
Ut UE, AS (SIP AS, OSA SCS, Posibilita al UE a gestionar la información relacionada con sus servicios HTTP
IM-SSF)
Go PDF, GGSN Permite a los operadores controlar la QoS en el nivel de usuario e COPS
intercambiar información de cargo entre redes IMS y GPRS
Gq P-CSCF, PDF Intercambiar información relacionada con las políticas entre Diameter
P-CSCF y PDF
34/112
Módulo 3
3. Conceptos de IMS
3.1. Introducción
Este capítulo se inicia con una primera descripción de los procesos de registro y
establecimiento de sesión en IMS, describiendo las entidades relacionadas. La intención no
es dar una descripción detallada, ni no dar una visión global del proceso que ayude al lector
a entender los diferentes conceptos IMS que se explican en más adelante.
Antes de que un equipo de usuario (UE) se registre es necesario descubrir la entidad IMS a
la cual enviar la petición REGISTER. Este concepto se denomina descubrimiento Proxy-Call
Session Control Function (P-CSCF) (apartado 3.7). Además del proceso de registro el
usuario necesita encontrar las identidades de los usuarios en los módulos de identidad
(apartados 3.4 y 3.5). También, durante el proceso de registro se asignará al usuario un S-
CSCF (apartado 3.8), se realizará una autenticación y una asociación de seguridad
(apartado 3.6), se descargará un perfil de usuario al servidor S-CSCF asignado (apartado
3.11), se inicializará la compresión SIP (apartado 3.16) y se obtendrán las identidades
públicas del usuario (apartado 3.14).
El apartado 3.9 explica cómo se aplica la política de control IP cuando un usuario establece
una sesión, y cómo se proporcionan los servicios se aborda en el apartado 3.12. El apartado
3.10 muestra cómo un operador realiza el cargo al usuario. La interconexión de redes con la
red de conmutación de circuitos (CS) se describe en el apartado 3.13, y por último el
concepto de compartir una sola identidad entre múltiples terminales se analiza en el
apartado 3.15.
3.2. Registro de usuarios

Antes de realizar el registro IMS para poder acceder a los servicios desde el UE, éste debe
obtener una portadora IP y descubrir el punto de entrada: el P-CSCF. Por ejemplo, en el
caso de un acceso por GPRS el terminal de usuario activa el contexto Packet Data Protocol
(PDP) para poder utilizar señalización SIP.
El registro IMS se compone de dos fases, mostradas en la Figura 3.1. En la primera fase
(parte izquierda de la Figura 3.1) el UE envía una petición SIP REGISTER al P-CSCF que
ha descubierto, la cual contiene un identificador y un nombre de dominio local (la dirección
del I-CSCF). El P-CSCF procesa la petición y obtiene la dirección IP del I-CSCF. Éste
contacta con el HSS para buscar las capacidades del S-CSCF seleccionado, después de lo
cual reenvía la petición REGISTER al S-CSCF. El S-CSCF detecta que el usuario no está
autorizado, busca información de autenticación del HSS y envía al usuario una respuesta
401 Unauthorized.
En la segunda fase (parte derecha de la Figura 3.1) el UE envía una nueva petición
REGISTER al P-CSCF, y si es correcta descarga el perfil de usuario del HSS y acepta el
registro con una respuesta 200 OK. Una vez que el UE está autorizado puede iniciarse una
35/112
Módulo 3
sesión. Durante este proceso de registro tanto el UE como el P-CSCF aprenden qué S-
CSCF de la red dará servicio el UE.
Figura 3.1. Diagrama de registro IMS.
Es responsabilidad del UE mantener su registro activo refrescándolo periódicamente, ya que

en caso contrario el S-CSCF eliminará su registro después de un tiempo. Cuando el UE
quiere eliminar su registro simplemente envía una petición REGISTER en la que el tiempo
de expiración es cero.
3.3. Inicio de sesión

Cuando un usuario A quiere establecer una sesión con un usuario B, el terminal de usuario
A genera una petición SIP INVITE y la envía por medio de la interfaz Gm al P-CSCF, el cual
procesa la petición (por ejemplo, la descomprime, verifica la identidad del usuario, controla
el servicio, etc.) y la reenvía al S-CSCF. A su vez, el S-CSCF procesa la petición,
interactuando con los AS y determina el punto de entrada de la red del operador del usuario
B. El I-CSCF recibe la petición y contacta con el HSS para encontrar el S-CSCF que da
servicio al usuario B. El S-CSCF del usuario B procesa también la petición, interactuando
con los servidores AS y la envía al P-CSCF, que encamina la petición al terminal del usuario
B, que responde generando una respuesta 183 Session Progress que vuelve al terminal del
usuario A por la ruta establecida (UE B --> P-CSCF --> S-CSCF --> I-CSCF --> S-CSCF -->
P-CSCF --> UE A), según se muestra en la Figura 3.2. Después de un intercambio de
peticiones y respuestas, se establece la sesión y se puede empezar a utilizar la aplicación,
por ejemplo una partida de ajedrez en línea.
36/112
Módulo 3
Figura 3.2. Diagrama de establecimiento de sesión.
3.4. Identificación
Como ya hemos comentado, un usuario tiene una identidad privada y una o varias públicas.
La identidad privada es única y está definida por el operador de la red nativa para identificar
unívocamente a sus propios usuarios. Realmente no identifica a los usuarios, sino a las
suscripciones, pero aún así se emplea ampliamente para propósitos de autenticación, así
como para facturación y administración. El identificador privado se ajusta al formato
denominado NAI (Network Access Identifier). Un ejemplo puede ser: usuario@uah y se
almacena indefinidamente en el módulo IMS Identity Module (ISIM).
Las identidades públicas se emplean en las peticiones de comunicación con otros usuarios y
pueden estar publicadas en agendas, páginas web, etc. Estas identidades deben tomar la
forma de un SIP Uniform Resource Identification (URI) o un Uniform Resource Locator
(URL), para números de teléfono, y también se almacenan en el ISIM. Ejemplos de estas
entidades serían sip:manuel.lopez@uah.es y tel:+34918856540.
Veamos con un ejemplo cómo se relacionan la identidad privada y las públicas. Juan está
trabajando para una empresa de venta de coches y utiliza un mismo terminal para mantener
comunicaciones profesionales y personales. Para las comunicaciones profesionales tiene
dos identidades: sip:jpg@ventacoches.com y tel:+34915559164, mientras que para su vida
personal utiliza las identidades sip:Juan@midominio.com y tel:+34915552345. Al tener dos
identidades puede dar un tratamiento distinto a los dos tipos de comunicaciones, y así por
ejemplo, puede hacer que las llamadas a su identidad profesional que se reciben más tarde
las 17 horas y las recibidas en fines de semana y vacaciones sean atendidas por un
contestador automático.
Los datos de usuario de Juan se almacenan en dos perfiles de usuario distintos, y cada vez
que usa uno de los perfiles se descarga la información del HSS por medio del S-CSCF. En
la Figura 3.3 se relacionan las identidades públicas, con los perfiles y la identidad privada.
37/112
Módulo 3
Figura 3.3. Relaciones entre las identidades de usuario.
Con la introducción de los distintos servicios que proporciona IMS también fue necesario
identificarlos con el fin de tener información de qué servicios están alojados en cada AS.
Para ello se implementó el concepto de Public Service Identifier, que adopta la forma de un
SIP URI o de un URL telefónico. Por ejemplo, en el servicio de mensajería hay un
identificador para el servicio de listas de mensajes, que para Juan podría ser
sip:listamensajes_juan@dominio.com. Si un usuario envía un mensaje a esta URI, el
mensaje se reenvía a todos los miembros de la lista.
Por último, también requieren estar identificados los nodos de red que realizan el
encaminamiento SIP por medio de un identificador URI. Estos identificadores deben figurar
en los encabezados de las tramas SIP, si bien no es necesario que estén publicados en
ningún servidor de nombres DNS. Un ejemplo de URI de un nodo podría ser:
sip:alcala.scscf1@uah.es.
3.5. Módulos de identidad

Existen dos módulos relacionados con la identidad de los usuarios: El IMS Services Identity
Module (ISIM) y el Universal Subscriber Identity Module (USIM).
El ISIM es una aplicación que reside en una tarjeta que se inserta en el terminal de usuario,
denominada Universal Integrated Circuit Card (UICC). Este módulo almacena datos
relacionados con el usuario proporcionados por el operador, pudiendo estos datos dividirse
en seis categorías (Figura 3.4):
• Claves de seguridad. Se trata de claves de integridad (para proteger la

señalización SIP) y encriptación (para proporcionar comunicaciones
confidenciales).
• La identidad privada del usuario. Empleada en el proceso de registro.
• Las identidades públicas del usuario. Para emplearlas en las comunicaciones
con otros usuarios.
• El nombre de dominio de la red nativa. Es el punto de entrada a la red IMS, y se
emplea en el proceso de registro.
38/112
Módulo 3
• Datos administrativos adicionales. Necesario para algunas operaciones IMS o

bien por los fabricantes para hacer un test del terminal.
• Reglas de acceso. Almacena información sobre qué números de identificación
personal se deben verificar para poder acceder a las aplicaciones.
Figura 3.4. Módulo de identidad IMS.
Por su parte, el módulo USIM se emplea para acceder al dominio de conmutación de

paquetes (Packet Switched, PS) e identifica inequívocamente a un abonado. Al igual que
ISIM, reside en la UICC, y contiene datos como: parámetros de usuarios para acceso al
dominio PS, IMSI y lista de puntos de acceso permitidos.
3.6. Servicios de seguridad en IMS

Abordaremos a continuación cómo se implementa la seguridad en IMS, pero no desde el
punto de vista criptográfico, para lo cual existe una extensa bibliografía, sino a un nivel de la
arquitectura de seguridad, explicando los componentes que la forman y los protocolos.
La arquitectura de seguridad de IMS consiste en tres bloques, según se muestra en la

Figura 3.5. El primer bloque es el Network Domain Security (NDS), que proporciona
seguridad a nivel IP entre diferentes dominios y nodos dentro de un dominio. La seguridad
de acceso basada en protocolo SIP es otro de los bloques. Es independiente salvo por la
excepción de los parámetros de seguridad que le proporciona el protocolo Authentication
and Key Agreement (AKA), necesario para los accesos vía UMTS. AKA también se emplea
para la seguridad de aplicaciones basadas en protocolo HTTP, a través de las
Bootstraspping Server Function (BSF).
La seguridad de IMS está basada en claves secretas compartidas entre el ISIM y el centro
de autenticación de la red nativa del usuario (AUC). Estas claves se encuentran en el ISIM,
el elemento más importante de la seguridad, que a su vez se almacena en la tarjeta de
usuario (UICC). Además, para poder realizar una consulta con el protocolo AKA sobre el
ISIM el usuario necesita introducir un código PIN, por lo que la seguridad IMS es bastante
39/112
Módulo 3
robusta, ya que hace falta disponer del terminal del usuario y de un código que sólo él
conoce.
Figura 3.5. Arquitectura de seguridad de IMS.
La seguridad del dominio de red
Una de las mayores debilidades de los sistemas 2G era la solución de seguridad

implementada en el núcleo de la red, ya que aunque las comunicaciones vía radio estaban
encriptadas, la comunicación entre nodos no lo estaba, incluso cuando se hacían también
por vía radio. Aunque ya en los sistemas 3G se protege todas las comunicaciones IP en el
núcleo de la red, IMS añade la seguridad NDS que incluye confidencialidad, integridad de
datos y autenticación, usando una combinación de mecanismos criptográficos y aplicando el
protocolo de seguridad IPsec.
El “dominio de seguridad” es esencial en el concepto de NDS. Un dominio de seguridad es

una red operada por una única autoridad administrativa que mantiene unas políticas de
seguridad uniformes, por lo que la seguridad de todos servicios de la red es la misma. En
muchos casos el dominio de seguridad corresponde con el núcleo de la red del operador. En
NDS las interfases entre dominios de seguridad se indican como Za, y si están dentro del
mismo dominio con Zb. Todas las comunicaciones entre distintos dominios se deben hacer
obligatoriamente por medio de la interfaz Za, ya que emplea mecanismos de protección e
integridad de datos y encriptación, mientras que esto último es opcional para la interfaz Zb.
En la Figura 3.6 se representa la comunicación entre dos UE. El primero de ellos (el de la
parte superior) se encuentra en su red nativa y el segundo en una red visitada.
40/112
Módulo 3
Figura 3.6. Comunicación entre dominios de seguridad.
Por otra parte, el tráfico que se intercambia entre dominios pasa a través de una pasarela de
seguridad (SEG), la cual actúa de túnel entre los dominios reforzando la seguridad, y
además puede incluir filtrado de paquetes y cortafuegos.
Acceso de seguridad de los servicios basados en SIP
Como ya hemos comentado, SIP es el núcleo de IMS y se emplea para crear, gestionar y
terminar las sesiones multimedia, por lo que es importante proteger la señalización de este
protocolo. El núcleo de la red está protegido por NDS, pero las comunicaciones que se
establecen entre el UE y el P-CSCF, por medio de la interfaz Gm, están fuera del alcance de
NDS.
Para solucionarlo, IMS establece lo que llama “dominios de confianza”, los cuales están
formados por las funciones P/I/S-CSCF, la función BGCF, la función MGCF/MRFC y todos
los AS que no son propiedad de terceros. La identidad de los usuarios se intercambia entre
los elementos que forman un dominio de confianza sin verificación ninguna, puesto que se
da por supuesto que es válida, la cual ha sido asignada por el P-CSCF, que es el punto de
acceso del usuario. Además, el modelo de confianza tiene una propiedad importante, que es
41/112
Módulo 3
la propagación: si existe confianza entre una primera entidad y una segunda, y entre una
segunda y una tercera, también existe entre la primera y la tercera.
La autenticación del acceso IMS está basada en el protocolo AKA. Puesto que AKA no
puede ejecutarse directamente sobre IP, hace falta un vehículo que transporte los mensajes
entre el UE y la red nativa, y este no es otro que el protocolo SIP. Además de la
autenticación del usuario, el UE e IMS también tienen que negociar los mecanismos de
seguridad que van a usar en la interfaz Gm. El UE y el P-CSCF intercambian información
sobre los distintos mecanismos que soportan y se selecciona el más alto que sea común a
ambos. Como mínimo el mecanismo de seguridad debe proporcionar protección de
integridad de los datos. Una vez establecida la sesión, la lista de mecanismos posibles se
devuelve a la red de una manera segura con el fin de verificar que la elección ha sido
correcta.
También es necesario destacar que el P-CSCF al que se conecta el usuario puede

encontrarse en la red visitada, pero según el protocolo AKA las claves sólo son accesibles
en la red nativa, por lo que la autenticación se debe realizar allí. No obstante es necesario
realizar cierta delegación de funciones. Esto se soluciona enviando las claves de sesión al
P-CSCF asignado dentro de los mensajes SIP de registro.
Acceso de seguridad de los servicios basados en HTTP
Además del tráfico SIP el terminal UE maneja otro tipo de tráfico en ciertas aplicaciones
IMS, por medio de la interfaz Ut, que permite confidencialidad de datos transportados en
tráfico HTTP. Para ello, la autenticación de este tráfico también está basada en AKA.
Como parte de la arquitectura de autenticación, IMS define la arquitectura Generic

Bootstrapping Architecture (GBA), mostrada en la Figura 3.7.
La función BSF y el terminal UE realizan autenticación mutua basada en AKA permitiendo al

terminal acceder a las claves de sesión, las cuales son necesarias para poder acceder a las
funciones de la aplicación de red (NAF).
Por otra parte, la interfaz Ut emplea Seguridad en la capa de transporte (TLS) para
mantener la confidencialidad e integridad de los datos.
42/112
Módulo 3
Figura 3.7. Arquitectura Generis Bootstrapping Architecture (GBA).
3.7. El punto de entrada de IMS

Para poder comunicarse con IMS, el UE debe conocer la dirección del P-CSCF. El
mecanismo por el cual obtiene esta dirección se denomina descubrimiento P-CSCF, y
dentro del estándar se han definido dos posibles: el procedimiento Dynamic Host
Configuration Protocol's (DHCP) domain name system (DNS) y el procedimiento GPRS.
Además se puede configurar de forma manual la dirección del P-CSCF en el UE.
En el procedimiento GPRS (Figura 3.8), el UE envía una petición PDP con un indicador
activo mostrando que requiere la dirección del P-CSCF al Gateway GPRS Support Node
(GGSN) por medio del SGSN. Como respuesta obtiene la dirección solicitada.
Figura 3.8. Descubrimiento por procedimiento GPRS.
43/112
Módulo 3
En el procedimiento DHCP DNS, mostrado en la Figura 3.9, el UE envía una petición DHCP
a la red de acceso de conectividad (CAN), la cual reenvía la petición al servidor DHCP. El
servidor DHCP puede devolver una lista de direcciones IPv6 de P-CSCF o bien los nombres
de dominio, en cuyo caso el UE necesita consultar al DNS para obtener la dirección
Figura 3.9. Procedimiento DHCP DNS para obtener la IP del P-CSCF.
3.8. Asignación del S-CSCF

Una vez establecida la comunicación con el P-CSCF, el siguiente paso es asignar un S-
CSCF. Se pueden dar tres casos en los que se requiere asignación: cuando un usuario se
registra en la red, cuando un usuario no registrado recibe una petición SIP, o cuando un S-
CSCF asignado ha dejado de responder.
Cuando un usuario se registra en la red se envía una orden REGISTER al P-CSCF

descubierto, el cual encuentra el I-CSCF de la red nativa del usuario. Entonces el I-CSCF
intercambia mensajes con el HSS y recibe las capacidades del S-CSCF para cada servicio,
basándose en las cuales selecciona uno de ellos. En la Figura 3.10 se muestra un ejemplo
de asignación S-CSCF.
Cuando un terminal recibe una petición SIP, por ejemplo porque otro usuario está intentando
establecer una comunicación con él, es necesario asignarle un S-CSCF. Si el HSS no tiene
información sobre qué S-CSCF se le asignó previamente, devuelve las capacidades de
todos los S-CSCF disponibles al I-CSCF, que decide cuál de ellos asignar.
En caso de que un S-CSCF no responda, el estándar IMS permite asignar uno distinto. Para
ello el I-CSCF envía una petición al HSS para que le devuelva la lista de los posibles con el
fin de elegir otro distinto.
Por otra parte, un S-CSCF es desasignado cuando un usuario se desconecta de la red o

finaliza su sesión, por ejemplo porque ha vencido el tiempo establecido. Es responsabilidad
del S-CSCF eliminar el nombre de usuario del HSS.
44/112
Módulo 3
Figura 3.10. Ejemplo de asignación S-CSCF.
3.9. Mecanismos de control del tráfico

Uno de los problemas más importantes que tenía que resolver IMS era la separación entre
la capa de control y la de usuario. La total independencia de las dos capas es casi imposible
porque si no existe interacción entre ambas los operadores no pueden controlar la calidad
del servicio, el origen y el destino del tráfico o cuando comienzan y terminan las
transmisiones. Por ello se creó un mecanismo para controlar el uso del tráfico de portadora,
basado en los parámetros SDP negociados en la sesión IMS. Este servicio se denomina
Control Service-Based Local Policy (SBLP). La Figura 3.11 muestra las entidades
relacionadas con el SBLP, donde se puede observar la función de decisión de políticas
(PDF) y la interfaz Gq. Las demás entidades que se pueden ver en la figura son:
• IP bearer service (BS) manager: gestiona los servicios de portadora IP usando

mecanismos estándar. Reside en el GGSN y opcionalmente en el UE.
• Translation/Mapping function: proporciona interconexión entre los mecanismos y
parámetros usados en el UMTS BS y aquellos usados en el IP BS. Reside en el
GGSN y opcionalmente en el UE.
• UMTS BS manager: Gestiona las peticiones de reserva de recursos del UE.
Reside en el GGSN y en el UE.
• Policy enforcement point: es una entidad lógica que refuerza las decisiones
realizadas por el PDF. Reside en el IP BS manager del GGSN.
• Policy decision function: es una entidad lógica de decisión de políticas que
emplea mecanismos IP estándar para implementar SBLP en la capa IP.
45/112
Módulo 3
Figura 3.11. Entidades SBLP.
3.10. Cobro de los servicios

Como ya hemos anticipado, la arquitectura de cobro IMS soporta tanto el cobro offline como
online. El cobro online es aquel en el que las entidades IMS, como por ejemplo los AS,
interactúan con el sistema de cobro online, y este a su vez lo hace con el saldo del usuario
en tiempo real, controlando y monitorizando los cargos de los servicios utilizados. Por el
contrario, el cargo offline es un proceso por el que a partir de la información de los servicios
proporcionados, y una vez finalizada la sesión, se realiza el cargo, por lo que el sistema de
cobro no afecta al funcionamiento del servicio utilizado. En este modelo el usuario recibe
una factura mensual con el coste de los servicios prestados durante un periodo de tiempo.
Puesto que se trata de dos modelos de diferente naturaleza, son necesarias dos soluciones
distintas.
Arquitectura de cobro offline
El elemento principal de la arquitectura de cobro offline es la función Charging Collection

Function (CCF). El CCF recibe información de las entidades IMS por la interfaz Rf.
Posteriormente procesa la información y obtiene el CDR, que se pasa al sistema de
facturación. La Figura 3.12 muestra la arquitectura de cobro offline en el caso de que los dos
terminales se encuentren en itinerancia. En caso contrario sólo habrá un CCF involucrado.
El Charging Collection Function (CCF) permite al operador tener una única interfaz del
sistema de facturación, ya que recoge la información de facturación de todas las entidades
involucradas (AS, MRFC, S-CSCF, I-CSCF, P-CSCF, BGCF, MGCF). Se puede implementar
como un elemento aislado y centralizado o bien integrar su funcionalidad en las entidades
IMS. La ventaja de tenerlo aislado es que reduce la carga de procesamiento de las
entidades IMS.
46/112
Módulo 3
Figura 3.12. Arquitectura para el cobro offline.
El Charging Gateway Function (CGF) en el dominio PS (packet switched) transfiere la

información de cobro desde los nodos SGSN y GGSN a la red del operador que realiza la
facturación. La funcionalidad del CGF en el dominio PS es similar a la del CCF en el dominio
IMS
Tanto el CCF como el CGF envían los CDR al sistema de facturación que crea la factura.
En ella se indican, por ejemplo, el número de sesiones, los destinos, la duración y el tipo de
sesión.
La información de cobro generada por cada una de las entidades atravesadas por una
sesión se envía al CCF por medio de la interfaz Rf, utilizando el protocolo Diameter
Accounting Request (ACR)
Por otra parte, el CCF emplea la interfaz Bi para transferir los CDRs creados al sistema de
facturación. Puesto que pueden existir muchos sistemas de facturación distintos, el estándar
no define el protocolo a utilizar, pero recomienda utilizar FTP sobre TCP/IP
Arquitectura de cobro online
Las entidades S-CSCF, AS y MRFC son las que tienen posibilidad de realizar cobro online.
Los AS y MRFC utilizan la interfaz Ro, mientras que el S-CSCF utiliza la interfaz de control
de servicio IMS (ISC) para comunicarse con el sistema de cobro online (Online Charging
System, OCS). La Figura 3.13 muestra la arquitectura de cobro online.
47/112
Módulo 3
Figura 3.13. Arquitectura de cobro online.
En este diagrama de bloques podemos encontrar el Event Charging Function. Cuando el UE

requiere algún servicio del AS o del MRFC que precisa de autorización previa, estos
contactan con el Event Charging Function (ECF) por medio de la interfaz Ro antes de enviar
el servicio al usuario. El ECF concederá permiso siguiendo dos modelos de autorización
diferentes: el cargo inmediato por evento, o el cargo por evento con unidad de reserva.
En el modelo de cargo inmediato por evento el ECF selecciona la tarifa apropiada para el
evento (por ejemplo, mover una pieza en una partida de ajedrez en línea), deduce de la
cuenta del usuario una cantidad de dinero determinada y concede permiso al AS o MRFC.
En el modelo de cargo por evento con unidad de reserva el ECF determina el importe del
servicio deseado en el caso de que el coste no se indique en el protocolo ACR. Entonces el
ECF reserva una cantidad de dinero de la cuenta del usuario y envía al AS o MRFC la
cantidad de recursos que el usuario puede utilizar (por ejemplo, una cantidad de tiempo o un
volumen de datos). Cuando el usuario consume los recursos o el servicio ha concluido el AS
o MRFC informan al ECF de la cantidad de recursos consumidos y los deduce de la cuenta
del usuario. Este modelo se utiliza cuando el AS o el MRFC no pueden determinar la
cantidad de recursos que necesitarán para cubrir un servicio determinado.
Por otra parte, el Session Charging Function (SCF) realiza el cobro de acuerdo con el uso
que se hace de los recursos, basándose en las peticiones realizadas al S-CSCF por medio
de la interfaz ISC. El SCF debería ser capaz de controlar el establecimiento de sesión
después de comprobar la cuenta del usuario, y terminarla cuando la cuenta está a cero. El
SCF, al igual que el ECF, soporta tanto el cargo inmediato por evento como el cargo por
evento con unidad de reserva.
El SGSN usa la interfaz basada en CAP (CAMEL Application Part, CAP) para solicitar
permiso para el uso de la portadora por parte del Bearer Charging Function (BCF). El BCF
controla el uso de la portadora e interactúa con las funciones de cobro.
48/112
Módulo 3
Finalmente, la función de Rating determina la tarifa o precio para realizar el cobro. Por
ejemplo, la determinación de la tarifa la realiza en función del tiempo que dura la sesión,
mientras que el precio lo determina a partir del número de servicios y su naturaleza
prestados. Es posible ejecutar la función del coste bien antes o después del uso del servicio.
La función de correlación permite unir la información de cobro procedente de múltiples

fuentes (ECF, SCF y BCF). Se necesita para asegurar un único cargo por cada servicio
prestado, uniendo varias CDRs procedentes de distintas entidades.
La interfaz Ro permite el envío por desde el AS y MRFC hacia el ECF, por medio del
protocolo Diameter, con el fin de realizar el cobro online. Como los mensajes y el protocolo
son los mismo para el cobro online y offline, el AS y el MRFC deberían distinguir cuando
aplicar un cargo online u offline. Esta decisión se basa en la información proporcionada por
el operador, o bien recibida en la señalización SIP
3.11. Perfil de usuario

Cuando un usuario se suscribe a la red de un operador, éste debe asignarle un perfil de
usuario. El perfil de usuario contiene, al menos, una identidad privada y un perfil de servicio.
En la Figura 3.14 se puede observar la estructura general de un perfil de usuario, el cual
puede contener más de una identidad privada en caso de que el usuario esté usando una
identidad pública compartida. En dicha figura también se muestra que una sola suscripción
IMS puede contener múltiples perfiles de servicio, lo cual permite diferentes tratamientos
para las diferentes identidades públicas del usuario.
Figura 3.14. Estructura de un perfil de usuario IMS.
Un perfil de servicio es un conjunto de informaciones que están almacenadas en el HSS y

se transfieren al S-CSCF durante las operaciones de gestión de usuarios Server-
Assignment-Answer (SAA) y Push-Profile-Request (PPR), por medio del protocolo Diameter.
El perfil de servicio se puede dividir en tres partes:
• Identificación pública.
• Servicio de autorización del núcleo de la red.
49/112
Módulo 3
• Criterios de filtrado iniciales.
La identificación pública comprende las identidades públicas de un usuario asociadas a un

servicio. Los identificadores pueden ser del tipo SIP URI o tel URI, y llevan asociado un
indicador para que, en caso de estar activado, esa identidad no se pueda utilizar en ningún
servicio, salvo en el registro y eliminación del registro. Por ejemplo es el caso de una
identidad temporal.
El servicio de autorización del núcleo de la red lleva a cabo las tareas relacionadas con
la política de medios. Contiene un número entero que identifica un perfil de medio, abonado
en el S-CSCF. Esta información permite a los operadores definir diferentes perfiles de
abonados en sus redes IMS. Los operadores definen diferentes categorías de consumidores
(oro, plata o bronce), dependiendo del tipo de servicios que pueden utilizar cada uno. El
almacenamiento de ese número en el S-CSCF optimiza los accesos al HSS y reduce el
empleo de la interfaz Cx. El valor de estos números enteros no está estandarizado, y se
puede ver un ejemplo en la Figura 3.15.
Figura 3.15. Autorización de medios en el S-CSCF.
Los criterios de filtrado iniciales describen cuándo se debe reenviar un mensaje SIP al
servidor AS, y adoptan la forma de ”información de disparo de servicio”. En la Figura 3.16 se
observa que un criterio de filtrado inicial está compuesto por ninguna o una instancia de
punto de disparo de servicio y una instancia de servidor de aplicación (AS). Cada criterio de
filtrado inicial de un perfil de servicio tiene un único número entero que se utiliza en el S-
CSCF. Cuando se asignan múltiples criterios de filtrado de servicio, el S-CSCF accede a
ellos por orden numérico, por lo que se accederá antes a los criterios con prioridad mayor.
Figura 3.16. Estructura de un criterio de filtrado inicial.
50/112
Módulo 3
El punto de disparo describe las condiciones que se deben comprobar para determinar si
se permite el acceso al servidor AS solicitado. La ausencia de punto de disparo indica que
siempre se permiten los accesos al AS. Cada punto de disparo contiene una o varias
instancias, relacionadas por operadores lógicos (AND, OD, NOT).
El servidor de aplicación indica a qué AS se accede si la condición de disparo se cumple.

Puede contener información de cómo proceder en caso de que se le deniegue el acceso al
servidor AS, basándose en los criterios de filtrado. Además, el servidor de aplicación
contiene cero o más instancias del servicio de información, que proporciona información que
es transferida al AS por medio del S-CSCF cuando se cumplen los criterios.
3.12. Provisión de servicios

IMS no es un servicio en sí, sino que es una arquitectura basada en SIP para proporcionar
servicios IP avanzados y aplicaciones encima de una red PS, e incluye los mecanismos
necesarios para invocar dichos servicios. Esta funcionalidad se denomina “provisión del
servicio”, que está formada por tres elementos fundamentales:
• La definición de los servicios, o conjuntos de servicios.

• La creación de los datos del criterio de filtrado cuando se realiza una
suscripción.
• El reenvío de la petición inicial de servicio al servidor AS:
El primer punto no lo abordaremos ya que es algo que tienen que definir los operadores o
proveedores de servicio, por lo que describiremos los dos elementos restantes.
Siempre que un usuario realiza una suscripción que contiene servicios de valor añadido, o
un operador está ofreciendo utilizar un AS como parte de la infraestructura IMS, se requiere
crear unos datos específicos del servicio. Estos datos son parte del perfil de usuario, más
concretamente, estos datos se representan como criterio de filtrado inicial. Cuando se
construye este criterio un operador necesita conocer:
• ¿Qué es un punto de disparo?

• ¿Cuál es el AS correcto en caso de que se produzca el disparo?
• ¿Cuál es la prioridad del criterio de filtrado inicial?
• ¿Qué se debería hacer si el AS no responde?
El punto de disparo es un concepto que se emplea para determinar si se puede establecer

conexión con el AS. Contiene múltiples instancias del punto de disparo, que a su vez está
formado por los elementos mostrados en la Figura 3.17:
• URI solicitada: indentificador URI a la que se quiere acceder con la petición (por
ejemplo, mtx@depeca.uah.es).
• Método SIP: indica el tipo de petición (por ejemplo, INVITE o MESSAGE).
• Cabecera SIP: contiene información relacionada con la petición, en forma de
cadena que es interpretada como una expresión regular, como por ejemplo un
51/112
Módulo 3
nombre en el campo FROM de la cabecera que indica la identidad del solicitante

de la petición.
• Caso de sesión: tiene tres posibles valores: originando, terminando o
terminando no registrado, indicando si el S-CSCF debería usar el filtro en
función de la situación en la que se encuentre la conexión.
• Descripción de sesión: define el punto de disparo de la sesión y va
empaquetado dentro del cuerpo del método SIP.
Figura 3.17. Estructura del servicio de disparo.
Los criterios de filtrado iniciales se descargan al S-CSCF durante el registro del usuario o
cuando finaliza una petición de un usuario no registrado. Después de descargarlos desde el
HSS, el S-CSCF realiza los siguientes pasos:
1. Comprueba si la identidad pública de usuario está permitida, en caso contrario procede

con el siguiente paso.
2. Comprueba si la petición es de establecimiento de origen o terminación de
comunicación.
3. Selecciona el criterio de filtrado inicial para la sesión.
4. Comprueba si la petición coincide con los criterios de mayor prioridad para ese usuario
comparando el perfil de servicio con la identidad pública del usuario:
• Si la petición cumple los criterios, el S-CSCF envía la petición al AS y aplica el
mismo criterio en el método SIP recibido como respuesta del AS.
• Si la petición no coincide con el criterio de mayor prioridad, comprueba si
cumple alguno de los siguientes, por orden de prioridad.
• Si no cumple ningún criterio, el S-CSCF devuelve la petición.
3.13. Conexión entre usuarios IMS y CS

Debido al tiempo que ya tienen en el mercado las redes de conmutación de circuitos (CS),
como por ejemplo las redes cableadas y los terminales móviles, la mayoría de los usuarios
utilizan terminales propios de estas redes. Por ello es deseable que IMS pueda
interconectarse con las redes CS para poder establecer comunicaciones cuando un usuario
se encuentra en cada una de las redes. Esto implica una interconexión a nivel de usuario y a
nivel de control. A nivel de control la tarea la lleva a cabo el MGCF, que mapea la
señalización SIP en el Bearer Independent Call Control (BICC) o ISUP utilizado en redes
CS, y viceversa. A nivel de usuario la conexión la realiza el IMS-MGW. Determina los
canales de portadora de la red CS (PSTN/ISDN/GSM) y las tramas IP o ATM en las redes
52/112
Módulo 3
PS y las traduce a IMS. Además realiza tareas de codificación y decodificación,

cancelaciones de eco y comprobación de las tramas.
Cuando un usuario IMS establece una comunicación con otro usuario de una red CS, el
primero no necesita saber si el segundo pertenece a una red IMS o CS. Simplemente hace
una llamada. La petición de sesión que produce llega al S-CSCF empleando una petición tel
URL del tipo tel:+34915556788, y necesita realizar una petición ENUM para convertir la
petición a SIP URI. Una vez convertido el S-CSCF trata de enviar la petición a la red IMS de
destino, y en caso de que no sea posible intentará alcanzar la red CS del usuario final. Para
alcanza la red CS el S-CSCF envía la petición al BGCF de la misma red. Éste tiene dos
opciones: reenviarla a la pasarela de la misma red, o bien enviarla a otra red. Lo normal es
que lo envíe a la pasarela MGCF de la misma red para convertir la señalización a
ISUP/BICC. En caso de que esto falle buscará otro BGCF de otra red IMS que pueda
realizar la operación. MGCF actúa como punto final de la señalización SIP, y negocia tanto
con las entidades IMS como con las CS (por ejemplo, con un servidor MSC). En la Figura
3.18 se puede observar el concepto de interconexión cuando la sesión tiene origen en un
usuario IMS y termina en un usuario CS. Las flechas indican el recorrido de los mensajes.
Figura 3.18. Interconexión IMS-CS cuando un usuario IMS llama a uno CS.
En caso de que la llamada se origine en un usuario CS y finalice en un usuario IMS, se

gestiona como una llamada normal CS, pero cuando se analiza se envía al servidor MGCF
de la red nativa del usuario. Después de recibir el mensaje ISUP/BICC, el MGCF interactúa
con el IMS-MGW para crear una conexión a nivel de usuario y convierte la señalización a
SIP, enviando una petición SIP INVITE al I-CSCF, que a su vez encuentra el S-CSCF del
usuario de destino con la ayuda del HSS. Entonces el S-CSCF toma las acciones
necesarias para enviar la petición SIP INVITE al terminal de usuario. A partir de entonces el
MGCF establece la comunicación entre ambos usuarios. La Figura 3.19 muestra cómo se
53/112
Módulo 3
establece la interconexión cuando la llamada se origina en un usuario CS y termina en un

usuario IMS. Las flechas indican el recorrido de los mensajes.
Figura 3.19. Interconexión IMS-CS cuando un usuario CS llama a uno IMS.
3.14. Registro de múltiples identidades de usuario

SIP sólo puede registrar una identidad pública de usuario al mismo tiempo, por lo que si el
usuario tiene más de una identidad pública, tiene que registrar cada una de ellas
individualmente. Como esto podría consumir más recursos de los necesarios, 3GPP
desarrolló un método para registrar más de una identidad al mismo tiempo, conocido como
registro implícito.
Un conjunto de registro implícito es un grupo de identidades públicas que se registran

mediante una sola petición. Cuando una de las identidades públicas del conjunto se registra,
todas las demás identidades se registran también. Lo mismo ocurre en el proceso de
eliminación del registro de una identidad. Cada una de las identidades de un conjunto puede
utilizarse para diferentes perfiles de servicio, pero también pueden utilizarse varias de ellas
para el mismo perfil.
Para registrar las identidades implícitas el UE debe enviar una petición SUBSCRIBE con el
fin de registrar el conjunto de identidades en el S-CSCF. Cuando éste recibe la petición
devuelve la identidad pública de usuario registrada implícitamente en una petición NOTIFY.
Por ejemplo, un usuario podría tener cuatro identidades agrupadas en dos conjuntos (Figura
3.20). El primer conjunto tiene las identidades cmg@depeca.uah.es y tel:+23915553435. El
segundo conjunto contiene cmg@micasa.com y tel:+34915553456. Cuando este usuario
envía una petición REGISTER conteniendo la identidad cmg@depeca.uah.es el S-CSCF la
registra normalmente y después de obtener la autenticación descarga los perfiles de servicio
54/112
Módulo 3
asociados a la identidad registrada así como el conjunto de identidades implícitas (perfil de

servicio 1). Para registrar implícitamente las demás entidades públicas el terminal debe
enviar una petición SUBSCRIBE al S-CSCF y este realizará la operación y devolverá la
identidad de usuario tel:+34915553456 en una orden NOTIFY.
Figura 3.20. Ejemplo de conjunto de registro implícito.
3.15. Compartir la identidad de usuario entre varios UE

Tradicionalmente en las redes CS cada usuario tenía su propio número Mobile Subscriber
International ISDN Number (MSISDN) que lo identificaba unívocamente, pero esta técnica
no es posible cuando el usuario utiliza distintos UE con el mismo MSISDN simultáneamente,
ya que tener dos móviles con el mismo número MSISDN puede provocar conflictos en la
red. Hoy en día los usuarios disponen de más de un UE con diferentes capacidades (con
pantalla grande o pequeña, con cámara o sin ella, con teclado completo o sólo numérico),
cada uno de ellos para diferentes propósitos, y se debería conseguir que un usuario fuera
accesible por medio de la misma identidad independientemente del UE que estuviese
utilizando. Esto es otro de los aspectos que viene a solucionar IMS.
IMS permite a los usuarios registrar la misma identidad pública desde varios terminales UE.
Además, un usuario puede indicar sus preferencias en cada UE durante la fase de registro.
La Figura 3.21 muestra un ejemplo en el que un usuario tiene dos terminales: uno para
sesiones de vídeo y otro para aplicaciones de charla y juegos. Cuando alguien llama al
usuario, el S-CSCF decide a qué terminal se envía la petición en primer lugar. Esta decisión
se toma a partir de las preferencias que se proporcionaron en el momento del registro. Por
ejemplo, si la sesión que se quiere establecer tiene vídeo el S-CSCF seleccionaría el
terminal UE2.
55/112
Módulo 3
Figura 3.21. Múltiples terminales.
Además del encaminamiento basado en las preferencias el S-CSCF puede realizar

bifurcaciones de dos tipos:
• Bifurcaciones secuenciales.
• Bifurcaciones paralelas.
En las bifurcaciones secuenciales se contacta con diferentes UE uno tas otro. Por ejemplo,
el S-CSCF envía la petición al UE2 y si el usuario no responde dentro de un periodo de
tiempo la envía al UE1.
En las bifurcaciones paralelas la conexión se establece simultáneamente con todos los

terminales, y el usuario decide con cual de ellos contestar a la llamada, pero sólo desde uno
de ellos.
3.16. Compresión SIP

SIP es un protocolo de señalización basado en texto con una arquitectura cliente servidor
que controla las sesiones multimedia entre dos o más participantes. Los mensajes contienen
una gran cantidad de cabeceras y parámetros, incluyendo extensiones e información relativa
a la seguridad. Establecer una sesión SIP es un proceso complicado que implica codificar,
negociar las extensiones, notificaciones de calidad de servicio, etc. En general, proporciona
un marco flexible para establecer sesiones con diferentes requerimientos. No obstante, el
inconveniente es la gran cantidad de bytes y de mensajes que se intercambian a través de
las interfases. Este incremento en el número de mensajes significa:
• Los procedimientos de establecimiento de llamada usando SIP requieren más

tiempo para completarse que aquellos que usan señalización específica, por lo
que el usuario final observará un retardo en el establecimiento de llamada que
puede resultar molesto.
• La señalización una vez establecida la comunicación afecta al rendimiento del
sistema y a la calidad del servicio.
56/112
Módulo 3
Por tanto, las aplicaciones que requieren comportamiento en tiempo real requieren una
atención especial cuando se emplea SIP. Para acelerar el proceso de establecimiento de
llamada el 3GPP incluido la posibilidad de compresión de SIP tanto en el UE como en el P-
CSCF.
57/112
Módulo 3
4. Los servicios
4.1. Presencia
El servicio de presencia implica dos aspectos fundamentalmente: hacer que otros usuarios
vean el estado en que nos encontramos, y que podamos ver también su estado de
conectividad. La información de presencia incluye:
• La disponibilidad del usuario y el terminal.

• Las preferencias de comunicación.
• Las capacidades del terminal.
• La actividad actual del usuario.
• Su localización.
Se prevé que el servicio de presencia facilite las comunicaciones móviles en general y no

sólo mediante el servicio de mensajería instantánea, principal objetivo del servicio de
presencia. El intercambio de mensajes es un servicio ampliamente utilizado en Internet, y el
servicio de presencia es un buen complemento al mismo, ya que si podemos conocer qué
usuarios amigos están en línea podemos iniciar una sesión de Chat con él. Sin embargo, en
un entorno móvil, la información de presencia no sólo se utiliza para el intercambio de
mensajes, sino que también se emplea como testigo de la disponibilidad de un usuario para
cualquier tipo de comunicación, ya sea llamadas de voz, video, sesión de juegos, etc., ya
que todas ellas están basadas en la presencia.
Las aplicaciones específicas de la presencia empiezan a estar ya disponibles. Un ejemplo

típico es un listín telefónico con información de presencia, lo cual lo hace dinámico (Figura
4.1). El usuario que consulta el listín puede ver la información sobre su interlocutor antes de
establecer la llamada.
Figura 4.1. Presencia dinámica.
58/112
Módulo 3
El protocolo SIP se ha ampliado con un paquete llamado “presencia” que contiene todas las
funciones relativas a este servicio. También se han creado las definiciones necesarias para
advertir al abonado y al usuario al que llamamos del propósito de la presencia:
• Presencia: Una entidad que proporciona información sobre el servicio.

• Vigilantes: Entidades que proporcionan información de presencia a un servicio
de presencia.
Además se han definido dos entidades del protocolo SIP:
• Agente de presencia (PA): Capaz de almacenar información del abonado y

generar las notificaciones.
• Agente de presencia de usuario (PUA): Manipula la información de presencia
para publicarla.
Según hemos comentado anteriormente, en el cuerpo de la petición NOTIFY se envía la

información del estado del usuario, empleando un formato MIME "application/pidf+xml", el
cual contiene una información determinada sobre el usuario, pero que puede ampliarse
según las necesidades.
El servicio de presencia en la arquitectura IMS
La información de presencia de un usuario se puede obtener de un gran número de

entidades en una red IMS. Podría ser de un PUA situado en una red externa, de un PUA
situado en el propio terminal o bien de un PUA localizado en la red, como una entidad
aislada. También lo podríamos encontrar en la forma de servidor de presencia, como si se
tratase de un servidor de aplicación. La Figura 4.2 representa una arquitectura de referencia
para dar soporte al servicio de presencia en IMS.
Figura 4.2. Arquitectura de referencia para dar soporte al servicio de presencia en IMS.
59/112
Módulo 3
En esta figura aparecen las siguientes entidades:
• Servidor de presencia: gestiona la información de presencia descargada por el

PUA y las peticiones de suscripción al servicio.
• Vigilante de presencia: Identifica la red objetivo para una petición de presencia y
obtiene su dirección.
• Presencia presente: Identifica el servidor de presencia asignado a cierta petición
• Agente de presencia de usuario: Proporciona la información de presencia al
servidor.
La lista de recursos
Lo habitual es que un usuario disponga de la información de presencia de un grupo de

amigos. Por motivos de congestión de la red y limitación del ancho de banda, no es viable
que el UE envíe una petición de presencia para cada uno de sus amigos, por lo que se ha
incorporado una extensión de la petición de notificación para poder suscribir una lista de
recursos con una sola orden SUBSCRIBE. La lista debe estar identificada por un URI, y
contener cero o más referencias a otros URI, bien sean usuarios u otras listas. En el servicio
de presencia estos recursos son los datos de presencia de cada usuario, y la entidad que
proporciona la lista de recursos se denomina Resource List Server (RLS).
El RLS puede generar suscripciones individuales por cada recurso contenido en la lista. Si la
petición es aceptada, se genera automáticamente la orden NOTIFY conteniendo un cuerpo
MIME "multipart/related" que internamente lleva una aplicación que gestiona la información
de la lista.
Configuración de la autorización de presencia
La información de presencia está disponible a diferentes niveles, desde diferentes puntos de

vista, y para diferentes vigilantes. Esto significa que diferentes vigilantes pueden estar
autorizados a ver distintas partes de la información de presencia. Es el servicio de presencia
el que determina qué puede ver cada vigilante; y en qué momento, basándose en niveles de
autorización.
Publicación de la presencia
La publicación de la información de presencia puede realizarse con una extensión del

protocolo SIP. La cabecera de una petición PUBLISH contiene dicha información, con un
tiempo de vida de 3600 segundos, por defecto. El cuerpo de la petición PUBLISH contiene
información adicional sobre el servicio.
Paquete de plantillas de eventos
Los usuarios pueden obtener información sobre un recurso mediante un paquete de

eventos, en cuyo caso estos usuarios se denominan vigilantes. Un paquete de plantillas de
eventos posibilita que un usuario obtenga información de qué vigilantes existen y el estado
en el que se encuentran. Este paquete se denomina winfo.
60/112
Módulo 3
Los usuarios se pueden suscribir a este paquete de plantillas para ver quien está solicitando
información de presencia y el estado de la misma. Esta información contiene dos aspectos
importantes: el estado de cada suscripción y el evento que causa la transición desde el
estado anterior al estado actual. El estado de la suscripción puede ser alguno de los
siguientes:
• Inicial: No hay estado para la suscripción.

• Terminado: Se ha prohibido al vigilante suscribirse al paquete de eventos.
• Activo: El vigilante ha sido autorizado a suscribirse.
• Pendiente: no se ha atendido la petición de suscripción.
• Esperando: Similar a pendiente, pero se avisa al paquete de eventos que un
usuario quiere suscribirse.
Ejemplo de flujo en durante la operación del servicio de presencia
En la Figura 4.3 se muestra un ejemplo de flujo de un vigilante que se ha suscrito al servicio

de presencia que reside en una red diferente, mientras que el suscriptor reside en su red
nativa. El diagrama de flujo muestra la petición inicial NOTIFY como respuesta la orden de
SUBSCRIBE.
Figura 4.3. Suscripción al servicio de presencia finalizada con éxito.
En la Figura 4.4 muestra un ejemplo de un servicio de presencia que ha publicado

información correctamente, donde el UE se comporta como un PUA.
En la Figura 4.5 se representa el diagrama de flujo de un vigilante que se suscribe a una

lista de recursos del servicio de información. La lista de presencias (recursos) se referencia
por su dirección URI SIP. Se puede observar como inmediatamente después de la
confirmación del servicio se envía la orden NOTIFY con el contenido de la lista. Si el RLS no
dispone de información de presencia de los recursos de la lista la orden NOTIFY contiene un
cuerpo vacío.
61/112
Módulo 3
Figura 4.4. Publicación finalizada con éxito.
Figura 4.5. Suscripción a una lista de recursos.
Finalmente, en la Figura se muestra como se intercambian los mensajes entre el PUA y el

dominio PS cuando un usuario se suscribe para recibir notificaciones sobre los cambios de
estado de otros miembros. El camino que siguen los mensajes es el mismo que el de la
petición PUBLISH, y se observa la respuesta inmediata de notificación después de la
aceptación del servicio.
Figura 4.6. Suscripción a la información de un vigilante.
62/112
Módulo 3
4.2. Mensajería
Existen muchas formas de mensajería, pero todas ellas tienen en común el envío de un
mensaje de una entidad a otra. Los mensajes pueden adoptar muchas formas, incluir
muchos tipos de datos y ser enviados de distintas maneras. Hoy en día es habitual el
intercambio de mensajes multimedia así como mensajes de texto enviados casi en tiempo
real en los sistemas de mensajería o como correo electrónico. En este apartado
analizaremos más en detalle el funcionamiento de este servicio en el contexto de IMS.
Introducción a la mensajería IMS
Los mensajes en IMS pueden ser de tres tipos:
• Mensajes instantáneos.
• Mensajes basados en sesión.
• Mensajes diferidos.
Cada uno de estos tipos tiene sus propias características, aunque en definitiva todos ellos
se basan en el envío de un mensaje de A a B. Sin embargo, la manera en que se
construyen las aplicaciones encima de estos servicios puede ocultar el hecho que son
formas distintas de mensajería. De hecho, uno de los requisitos importantes para la
mensajería de IMS es la fácil interconexión entre distintos tipos de mensajería.
Arquitectura de la mensajería IMS
Los tres tipos de mensajes en IMS utilizan la arquitectura directamente. Los mensajes
diferidos emplean también el dominio de conmutación de paquetes (PS), que es una
infraestructura separada de IMS.
Mensajería instantánea
La mensajería instantánea utiliza el método SIP MESSAGE para enviar mensajes entre
iguales, casi en tiempo real. La Figura 4.7 muestra un flujo de mensajes instantáneos típico.
En este tipo de mensajes el UE genera la petición MESSAGE completándolo con el

contenido del mensaje, que bien puede ser texto o fragmentos de datos multimedia, como
sonidos o imágenes, y con la dirección del destinatario. La petición es enviada por la
infraestructura IMS de manera similar a la orden INVITE hasta que el mensaje alcanza su
usuario de destino.
Podría producirse una respuesta al mensaje, de manera que se establezca un diálogo entre
los dos usuarios, sin embargo, a diferencia de la mensajería basada en sesión, no existe
protocolo de sesión, y cada mensaje es una unidad independiente, no relacionada con las
anteriores. Es decir, el contexto sólo existe en la mente de los usuarios.
63/112
Módulo 3
Figura 4.7. Flujo en la mensajería instantánea.
Mensajería basada en sesión
La mensajería basada en sesión está relacionada con otro método de mensajería existente
en Internet: El Internet Relay Chat (IRC). En este tipo de mensajería el usuario establece
una sesión en la que la unidad de información son mensajes cortos de texto. Como en
cualquier otra sesión, la mensajería basada en sesión tiene un tiempo limitado: comienza
cuando los participantes establecen una sesión y termina cuando los participantes la cierran.
Después de que la sesión se establece, los mensajes fluyen directamente entre ellos, según
se representa en la Figura 4.8.
La mensajería basada en sesión puede ser de igual a igual (peer-to-peer), en cuyo caso se
parece a una llamada de voz, es decir, se recibe una invitación a entrar en la sesión, pero en
este caso las unidades de información son mensajes. No obstante, esto no es una limitación
porque es posible combinar una sesión de mensajería con otro tipo de sesiones. De hecho,
muchas aplicaciones útiles se basan en esta funcionalidad, por ejemplo las llamadas de
video con un canal de texto destinadas a personas que carecen de audición.
La mensajería basada en sesión también está relacionada con la conferencia, ya que

empleando la mensajería se puede establecer una conferencia chat entre múltiples usuarios.
Una conferencia chat también se puede comparar con un canal IRC, o un grupo chat de
Internet. Los proveedores deberán ofrecer a los usuarios la posibilidad de establecer chats
privados, donde los participantes estén restringidos, y chats públicos, mantenidos por el
propio proveedor.
Mensajería diferida
La mensajería diferida, en realidad, son los conocidos mensajes multimedia MMS

(Multimedia Messaging Service). Se decidió de esta manera por compatibilidad con las
redes existentes. Ya en la Release 6, se abordó la integración de MMS con IMS,
especialmente en el tema de direccionamiento y el empleo de SIP para notificar a los UE la
llegada de un mensaje MMS.
64/112
Módulo 3
Figura 4.8. Flujo en mensajería basada en sesión.
4.3. Conferencia
Una conferencia es una conversación entre varios participantes. Existen distintos tipos,
dentro de los que se incluyen las conferencias ligeramente acopladas, con múltiples
participantes (multiparty) y fuertemente acopladas. En este apartado abordaremos estas
últimas ya que son las de mayor interés en IMS.
65/112
Módulo 3
Una conferencia no solo implica intercambio de audio, sino también empleo de video y texto.
Su popularidad ha crecido enormemente debido a la posibilidad de simular una reunión cara
a cara de una manera bastante real, por ejemplo compartiendo una pizarra o viendo las
caras de los participantes para percibir las emociones de los mismos.
Arquitectura del servicio de conferencia
En la conferencia fuertemente acoplada existe un elemento central de control donde cada

participante tiene una conexión. El centro de control proporciona una gran variedad de
servicios, incluyendo la mezcla de datos multimedia, la transcodificación y las notificaciones
a los usuarios participantes.
Este punto central, foco del servicio, es el agente usuario Session Initiation Protocol user
agent (SIP UA), que está identificado por un SIP URI, el cual establece la señalización SIP
entre los participantes.
Para la conferencia existen un conjunto de reglas que incluyen directivas acerca de la

duración de la sesión, quien puede y quien no puede unirse a la conferencia, definición de
los roles de los participantes así como sus responsabilidades y las políticas de quién puede
adoptar cada uno de los roles.
Existen diferentes formas de crear una conferencia. Un método es usando SIP para crear
una conferencia ad hoc, que es aquella creada sin fecha fijada y es de corta duración. Otra
posibilidad es emplear el protocolo Conference Policy Control Protocol (CPCP) para crear
una conferencia en una fecha concreta.
El servidor de conferencia es el encargado de crear una conferencia nueva, asignarla un

URI y recibir las peticiones INVITE de los participantes para unirse a la misma. Su
localización debe ser pública para poder crear conferencias ad hoc mediante el protocolo
SIP.
El protocolo CPCP es un protocolo del lado del cliente que se emplea para manipular las
reglas que rigen la conferencia, representadas por una URI y únicas para cada conferencia
establecida. La URI de las políticas de conferencia apunta al servidor de políticas de
conferencia.
En la Figura 4.9 se representa una arquitectura para la conferencia. Se pueden observar las
interfases entre entidades y los protocolos usados. El UA es un participante que crea una
conferencia ad hoc o se une a la conferencia creada usando CPCP enviando una petición
SIP INVITE. En cualquier caso el resultado final es la adscripción a una conferencia.
66/112
Módulo 3
Figura 4.9. Arquitectura de la conferencia.
Paquete de eventos SIP para estado de la conferencia
El paquete de eventos es utilizado para advertir de los cambios producidos entre los
participantes. En otras palabras, un usuario puede saber, mediante notificaciones, quien se
ha unido a la conferencia. Gracias a este paquete de eventos los participantes pueden saber
el estado de un usuario participante en la conferencia.
Los usuarios pueden suscribirse enviando una petición SIP SUBSCRIBE al identificador URI
de la conferencia, que identifica el foco. El foco actúa como notificador para este paquete de
eventos, denominado “conferencia”. Este elemento aparece en la cabecera de la petición
SUBSCRIBE, y en el cuerpo se incluye la información del estado de la conferencia en forma
del tipo MIME "application/conference-info + xml".
La información que se proporciona sobre el estado de los usuarios es: el nivel de

participación actual en la conferencia (llamado estado de actividad) y el método por el cual el
participante entró o dejó la conferencia (llamado estado histórico). El estado de actividad
puede ser: conectado, desconectado, o en espera; mientras que el estado histórico puede
ser: llamante, llamado, partió, iniciado o fallido. El estado de la conferencia también contiene
información sobre el tipo de conexión que tiene cada participante.
Ejemplo de diagramas de flujo para el servicio de conferencia
Cuando se crea una conferencia con un URI el participante genera una petición inicial
INVITE y añade la dirección URI a la petición.
El servidor de conferencia crea el foco para la nueva conferencia, le asigna un URI y lo

devuelve en la cabecera de la respuesta 200 (OK). Al recibir esta respuesta a la petición, el
participante almacena la cabecera de dicho mensaje como dirección URI de la conferencia.
Este URI se puede utilizar para pasárselo a otros usuarios con el fin de que puedan
suscribirse a la misma, o bien para suscribirse al paquete de eventos de la conferencia. La
Figura 4.10 muestra un ejemplo de flujo de mensajes para crear una conferencia.
67/112
Módulo 3
Figura 4.10. Creación de una conferencia usando una URI.
Cuando se genera una petición REFER destinada a un usuario con el fin de invitarlo a una
conferencia, la cabecera de la petición incluye la dirección URI de la conferencia. El usuario
invitado responde con indicando la aceptación de la invitación, según se muestra en la
Figura 4.11.
Otra forma de invitar a un usuario a una conferencia es enviando la petición REFER al foco,
e incluyendo la URI del participante invitado en la cabecera. Esto provoca que el foco
genere una petición NOTIFY invitando al usuario a la conferencia.
Figure 4.11. Invitando a un usuario a una conferencia empleando una petición REFER.
En la Figura 4.12 se muestra un ejemplo de flujo de un usuario suscribiendose al estado de

la conferencia. La figura muestra la notificación inmediata que se produce en ese momento.
68/112
Módulo 3
Figura 4.12. Suscripción a un estado de conferencia.
Empleando la interfaz Ut, un mensaje CPCP puede ser enviado al servidor de conferencias
para iniciar una nueva. En la Figura 4.13 se muestra un ejemplo de esto, en el cual se crea
una conferencia y se añaden participantes. El usuario A crea la conferencia siguiendo el
siguiente procedimiento:
Figura 4.13. Creación de conferencia usando CPCP.
• El usuario B es invitado a unirse a la conferencia.

• El usuario C se une a la conferencia.
• Moderador es el usuario A.
• Hora de inicio: 20-Noviembre-2006-7:00GMT.
• Hora de fin: 20-Noviembre-2006-15:00GMT.
69/112
Módulo 3
• Asunto: autorización de actividades de esta noche.

• Medio: Audio/adaptive multi-rate (AMR).
A las 7:00 del 28 de Noviembre el servidor de conferencia crea el foco. Éste lee la lista de
llamadas y descubre que el usuario B se encuentra en ella y le envía una invitación a unirse
a la conferencia. El usuario A se suscribe al paquete de eventos y observa que el usuario B
ya se ha unido a la conferencia. Después de eso el usuario C se une y el usuario A recibe
información de este hecho. A las 15:00 el foco envía un mensaje terminando la conferencia.
70/112
Módulo 3
5. Protocolos IMS
5.1. SIP
SIP es un protocolo de la capa de aplicación empleado para establecer, modificar o terminar
una sesión multimedia en una red IP. Es parte de la arquitectura multimedia cuyos
protocolos están continuamente siendo estandarizados por el Internet Engineering Task
Force (IETF). Sus aplicaciones incluyen, pero no están limitadas a: voz, video, juegos,
mensajería, control de llamada y presencia.
La idea de un protocolo de señalización de sesión sobre IP viene de 1992, donde ya se

pensaba en las conferencias. SIP apareció a finales de 1996 como un elemento del IETF
Mbone (backbone multicast), una red multicast experimental. Fue empleado por IETF para la
distribución de contenidos multimedia, incluyendo reuniones del IEFT, seminarios y
conferencias. Debido a su simplicidad fue adoptado como protocolo para VoIP, y acabó
siendo un estándar del IETF en 1999. Desde entonces SIP se ha mejorado para incluir
nuevas posibilidades y características.
Principios de diseño
SIP, como parte del IETF, está basado en http y el protocolo de gestión de red SNMP. La
Figura 5.1 muestra donde queda SIP dentro de la pila de protocolos.
SIP se creó teniendo intentando cumplir los siguientes objetivos:
• Protocolo neutral que pueda funcionar sobre protocolos confiables (TCP, SCTP)
y no confiables (UDP).
• Encaminamiento directo (para rendimiento) o por proxy (para control).
• Separación de la señalización y la descripción del medio, para que se puedan
añadir nuevas aplicaciones y medios.
• Extensibilidad.
• Movilidad personal.
71/112
Módulo 3
Figura 5.1. Pila de protocolos.
Arquitectura SIP
Los elementos que forman el protocolo SIP se pueden clasificar en dos tipos: agentes de
usuario (UA) e intermediarios (servidores). El caso ideal es que la comunicación entre dos
puntos finales (UAs) se realice sin intermediarios, pero esto no se puede dar, ya que los
administradores de la red y los proveedores del servicio habitualmente quieren controlar el
tráfico que circula por su red. En la Figura 5.2 se muestra un establecimiento de llamada
típico, lo que se conoce como “Trapezoide SIP”.
Un terminal, normalmente el UE, envía y recibe peticiones SIP y respuestas, siendo por
tanto el punto final de las tramas multimedia. En este terminal se ejecuta una aplicación o
existe un hardware específico. Este UA está formado por dos partes:
• Cliente de agente de usuario (UAC): La aplicación que inicia la comunicación.

• Servidor de agente de usuario (UAS): Acepta, redirecciona o rechaza las
peticiones. Envía respuestas a las peticiones recibidas.
Los intermediarios SIP son entidades lógicas por las cuales pasan los mensajes de camino
a su destino final. Estos intermediarios encaminan las tramas, e incluyen:
72/112
Módulo 3
Figura 5.2. Trapecios SIP.
• Servidor proxy: recibe y encamina las peticiones SIP. Puede interpretar o

reescribir ciertas partes del mensaje, incluyendo el cuerpo, pero manteniendo el
sentido del mismo. También puede enviar varias peticiones a distintos
elementos al mismo tiempo. Esta entidad se conoce como Proxy de bifurcación.
Existen tres tipos de servidores Proxy:
o Proxy de estado de diálogo: Si retiene el estado del diálogo que se

produce desde que se establece la petición (INVITE) hasta que finaliza
(BYE).
o Proxy de estado transaccional: Si mantiene el estado del cliente y
servidor durante el proceso de petición.
o Proxy sin estado: Si reenvía todas las peticiones y respuestas que
recibe, sin almacenar ninguna información.
• Servidor de redirección: Mapea la dirección de las peticiones en nuevas

direcciones, es decir, redirecciona pero no participa en la transacción de
mensajes.
• Servidor de localización: Mantiene información sobre la localización de los
usuarios.
• Registrador: Servidor que acepta peticiones REGISTER. Estos servidores se
usan para almacenar enlaces específicos entre direcciones SIP y las
direcciones del host donde se encuentra actualmente el usuario.
Además, para proporcionar servicios SIP a los usuarios hacen falta dos elementos
adicionales:
73/112
Módulo 3
• Servidor de aplicación: La entidad que proporciona el servicio final a los

usuarios.
• Agente de usuario back-to-back: Es donde un UAS y un UAC se unen.
Formato de los mensajes
Según se muestra en la Figura 5.3, un mensaje SIP está formado por tres partes: la línea de
inicio, las cabeceras del mensaje y el cuerpo del mensaje.
Figura 5.3. Formato de mensaje SIP.
La línea de inicio contiene distinta información dependiendo de si el mensaje es una

petición o una respuesta. Para las peticiones se denomina línea de petición, y línea de
estado para las respuestas. Un ejemplo de petición SIP podría ser el siguiente:
INVITE sip: mmg@depeca.uah.es SIP/2.0

Via: SIP/2.0/UDP cscfl.depeca.uah.es:5060;branch=z9hG4bK8542.1 Via:
SIP/2.0/UDP [5555::1:2:3:41:5060;branch=z9hG4bK45a35h76 Max-Forwards: 69
From: Cesar <sip:cmg@depeca.uah.es>;tag=312345 To: Maria Jose
<sip:mmg@depeca.uah.es>
Call-ID: 105637921
CSeq: 1 INVITE Contact: sip:cmg@[5555::1:2:3:41 Content-Type: application/sdp
Content-Length: 159
[body]
La línea de petición SIP contiene tres componentes:
• el método: que indica el tipo de petición, de entre las seis definidas: INVITE,
CANCEL, ACK, BYE, REGISTER, OPTIONS,
• la dirección URI: identifica el recurso al cual va dirigida la petición,
• la versión del protocolo, por ejemplo, si es la 2.0 incluiría “SIP/2.0".
La línea de estado en la respuesta también está formada por tres componentes:
• la versión del protocolo: igual que en la línea de petición,
74/112
Módulo 3
• el código de estado: código de tres dígitos que identifica la naturaleza de la

respuesta,
• frase: es un texto libre que proporciona una pequeña descripción del código de
estado.
Las cabeceras contienen información relacionada con la petición, por ejemplo la identidad
del iniciador de la comunicación y el destinatario. También se especifica las características
del cuerpo del mensaje. Algunas cabeceras son obligatorias, y son:
• To header To: SIP-URI(;parameters)

• From header From: SIP-URI(;parameters)
• Call-ID header: Call-ID: unique-id
• CSeq header: CSeq: digit method
• Via header: Via: SIP/2.0/[transport-protocol] sent-by(;parameters)
• Max-Forwards header: Max-Forwards: digit
• Contact header: Contact: SIP-URI(;parameters)
El cuerpo del mensaje puede contener información textual, que es interpretada según el
código de estado. Normalmente, en una sesión SIP el cuerpo del mensaje se ajusta al
formado del protocolo SDP.
La dirección SIP URI
La dirección SIP URI tiene la forma de una dirección de correo electrónico:

usuario@dominio, y puede ajustarse a dos esquemas:
• sip:cmg@depeca.uah.es: Es una SIP URI la forma más común.

• sips:cmg@depeca.uah.es: Es una SIP URI segura (SIPS).
A su vez existen dos tipos de SIP y SIPS:
• Address of record (AOR): Es una dirección SIP que identifica a un usuario y

necesita de un DNS para resolverla, como por ejemplo sip:cmg@depeca.uah.es.
• Fully qualified domain name (FQDN): Dirección IP en la que identifica el host
concreto, como por ejemplo: sip:cmg@127.233.4.12 o
sip:cmg@pc2.depeca.uah.es.
Una dirección SIP también puede llevar parámetros, en la forma

sip:userinfo@hostport[parametro][cabecera].
Algunos ejemplos de direcciones SIP URI podría ser:
• sip:cmg@depeca.uah.es
• sip:cesar.mataix@depeca.uah.es; transport= tcp
• sip: +1-212-555-1234@gw.com;user=phone
75/112
Módulo 3
• sip:root@136.16.20.100:8001
• sip:cesar.mataix@registro.com;method = REGISTER
La dirección Tel URI
La URI telefónica, o Tel URI, se emplea para identificar recursos por medio de un número de
teléfono, pudiendo ser un número global, o bien local. El número global sigue el formato
conocido en la telefonía, comenzando por el signo ‘+’, mientras que los números locales
siguen las normas específicas del plan de numeración privado. Los números locales
necesitan especificar un contexto representado por el nombre de un dominio o un número
global. Algunos ejemplos de Tel URI son:
• Número global: tel:+358-9-23-45678.

• Número local con nombre de dominio como contexto: tel:45678;phone-context=
uah.es.
• Número local con número global como contexto: tel:45678;phone-context=
+358-91-23.
El registro
El protocolo SIP soporta los conceptos de movilidad del usuario y descubrimiento. Un

usuario puede hacerse visible para las comunicaciones enlazando su AOR con una
dirección, lo cual permite la movilidad del usuario ya que éste se puede registrar desde
cualquier dispositivo que soporte SIP, incluyendo ordenadores personales, PDAs o teléfonos
móviles.
El descubrimiento del destinatario de una petición SIP es la función principal de los

servidores intermediarios. Cuando se recibe una petición se contacta con el servidor de
localización, para obtener la dirección del AOR de destino de la petición. Esta asociación
entre el AOR y la dirección se crea en la cabecera de un mensaje SIP, ya que se incluyen
los campos “To:” y “Contact:”. Un usuario se puede registrar desde múltiples dispositivos
simultáneamente enviando peticiones REGISTER, y también puede crear múltiples enlaces
al mismo dispositivo.
Los registros SIP requieren refresco periódico, ya que el tiempo que permanecen está
limitado por el tiempo de vida, indicado en la cabecera de la petición de registro, que por
defecto es de una hora. Si el UA no refresca el registro antes de ese tiempo, se elimina.
También se puede eliminar un registro enviando una petición REQUEST en la que el tiempo
de expiración sea de 0.
Diálogos
Un diálogo es una relación SIP entre dos colaboradores. El diálogo proporciona los estados
necesarios para encaminar y secuenciar los mensajes entre ellos.
Los diálogos se identifican por el Dialog-ID y los UAs emplean este identificador para hacer
un seguimiento de los mensajes. Un Dialog-ID está formado por el Call-ID, una marca local y
76/112
Módulo 3
otra remota. Para el UAC la marca local es la que aparece en la cabecera From de la
petición inicial de diálogo, y la marca remota es la que aparece en la cabecera To de la
respuesta. Para el UAS la marca local es la que aparece en la cabecera To de la respuesta
y la remota la que aparece en la cabecera From de la petición inicial.
Para crear, enviar, recibir y procesar mensajes de un diálogo es necesario que exista un
denominado “estado del diálogo”, que está formado por el dialog-ID, un número de
secuencia local, un número de secuencia remota, una URI local, una URI remota, un
objetivo remoto, un indicador llamado “seguro” y una ruta.
Un diálogo está en un estado inicial cuando recibe una respuesta provisional en el UAC, es
decir, cuando se crea el diálogo; y se mueve al estado “confirmado” cuando se recibe la
respuesta de confirmación “200 OK”.
Por su parte, cuando un UAS responde a una petición de diálogo debe copiar las
direcciones URI que aparecen en la cabecera de la petición, manteniendo el orden, ya que
le indican la ruta a seguir por los mensajes. También debe añadir una cabecera Contact en
la respuesta que indique
Sesiones
Una sesión multimedia consiste en un conjunto de usuarios que envían mensajes

multimedia y que los reciben, junto con los mensajes intercambiados. Las sesiones emplean
los diálogos SIP para establecerse.
El rol que juega SIP en las sesiones es el de establecer las sesiones y transportar los datos
SDP en el cuerpo de los mensajes.
La sesión se inicia con el método INVITE, incluyendo en el cuerpo una oferta SDP. Como
respuesta se espera que el UAC envíe un mensaje ACK. Si el UAC quiere cancelar la
invitación a la sesión envía una petición CANCEL. Si el UAS recibe esta petición CANCEL
responde con un mensaje “200” seguido de una respuesta "487 Request Terminated". Es
importante recordar que todas las transacciones deben finalizar con una respuesta.
Si el UAC no está satisfecho con la respuesta que llega en el mensaje “200”, envía un
mensaje ACK seguido de una petición BYE para terminar la sesión. Por su parte, si el UAS
no está satisfecho con la oferta de sesión, envía una respuesta “488”. Una sesión finaliza
con la respuesta BYE.
5.2. SDP
El protocolo de descripción de sesión (Session Description Protocol, SDP) es un protocolo
de la capa de aplicación basado en texto y empleado para describir las sesiones multimedia,
en función de las capacidades que el usuario llamante y el llamado indican en el
establecimiento de sesión. Estas capacidades pueden cambiar durante el establecimiento
de sesión, o bien durante la propia sesión.
77/112
Módulo 3
Contenido de los mensajes SDP
Un mensaje SPD contiene la siguiente información:
• Descripción del nivel de sesión: Incluye el identificador de sesión y otros

parámetros como la dirección IP, el título, la información de contacto y el
creador de la sesión.
• Descripción temporal: Tiempos de inicio y fin y de repetición.
• Tipo de medio y formato: Protocolo de transporte y número de puerto, así como
otros parámetros
Un mensaje SDP está formado por un conjunto de líneas ordenadas según la enumeración
anterior. En la Tabla 5.1 se muestran las líneas de descripción del nivel de sesión,
identificadas por una letra. Así mismo en la Tabla 5.2 se recogen las líneas de descripción
relativas al tiempo. Y para finalizar, la Tabla 5.3 contiene las líneas de descripción a nivel de
medio.
Table 5.1. Líneas SDP del nivel de sesión.
Campo Descripción
v Protocol version
o Origin and session ID
s Session name
i Session information
u URI for session
e Email address
p Phone number
c Connection information
b Bandwidth information
z Time zone correction
k Encryption key
a Attribute lines
Tabla 5.2. Líneas SDP del nivel de tiempo.
Campo Descripción
t Time session is active

r Repeat times
Formato del mensaje SDP
La sintaxis de SDP es muy estricta y todas las líneas siguen el siguiente formato:
<character>=<value>
78/112
Módulo 3
No se permiten espacios en blanco a ambos lados del carácter ‘=’, y el campo <value>
contiene uno o más parámetros separados por un espacio en blanco:
value=parameterl parameter2 ... parameterN
Tabla 5.3. Líneas SDP del nivel de medio.
Campo Descripción
m Media and transport
i Media title
c Connection information
b Bandwidth information
k Encryption key
a Media attributes
Algunas líneas SDP de ejemplo
Línea de protocolo de versión
La versión del protocolo SDP es la 0, por lo que la línea v del mensaje siempre contendrá:
v=0
Línea de información de conexión
La línea c puede estar presente a nivel de sesión o de medio. Si está presente en ambos
medios se atiende en primer lugar a la línea del nivel de medio. Su formato es el siguiente:
c=<network type> <address type> <network address>
La línea c tiene tres parámetros:
• Tipo de red: De momento solo definido para Internet. Su valor es "IN".

• Tipo de dirección: Hay dos tipos posibles: IP4 o IP6.
• Dirección de red: Identifica la dirección IP o el nombre de dominio donde se
recibe el medio.
Línea de medio
La línea m contiene información sobre el medio, incluyendo información de transporte. La

sintaxis es la siguiente:
m=<media> <port> <transport> <format-list>
Los parámetros tienen el siguiente significado:
79/112
Módulo 3
• Medio: Tipo de medio. Por ejemplo audio, video, juegos.

• Puerto: Número de puerto por el que se recibe el medio.
• Transporte: Protocolo de transporte empleado: UDP, RTP.
• Lista de formato: Contiene información adicional sobre el medio.
Si el protocolo de transporte es RTP el número de puerto para el protocolo de control de

RTP es el de RTP+1, y el número de puerto RTP siempre debe ser un número par.
Línea de atributo
La línea a define los atributos del medio y se emplea para expandir las posibilidades de
SDP. Los atributos lo pueden ser a nivel de sesión, medio o ambos, y su interpretación
depende del medio al que están relacionados. La sintaxis es la siguiente:
a=<attribute field> [ " : "<attribute value>]
El atributo campo contiene el nombre del atributo, y se separa del valor por dos puntos.
5.3. RTP
El protocolo RTP permite la comunicación de datos en tiempo real entre usuarios, pero
también proporciona unos servicios necesarios, como son la identificación, la numeración de
la secuencia, la marca de tiempo y la monitorización. RTP no sólo proporciona calidad de
servicio, sino que permite la monitorización usando el protocolo RTCP.
RTP para envío de datos en tiempo real
Los campos que están presentes en un paquete del protocolo RTP (Figura 5.4) son los
siguientes:
• Versión (V): Versión del protocolo.

• Padding (P): Si está activado se completa con bytes de relleno. Esto es
necesario para algunos algoritmos de encriptación que trabajan con un tamaño
fijo de octetos.
• Extensión (X): Si está activado, existe extensión de la cabecera.
• Cuenta CSRC (CC): Número de fuentes que contribuyen a la cabecera.
• Marca (M): Su interpretación se define por el perfil.
• Tipo de carga útil (PT): Identifica el formato de la carga útil.
• Número de secuencia: Se incrementa en 1 por cada paquete RTP y se emplea
para ordenar los paquetes recibidos.
• Marca de tiempo: Indica cuándo se muestreó el primer octeto.
• Fuente de sincronización (SSRC): Permite identificar la fuente de los paquetes
RTP.
• Fuente de contribución (CSCR): Contiene una lista de los SSCR indicando las
fuentes que han contribuido en una trama.
80/112
Módulo 3
Figura 5.4. Formato del paquete RTP.
El receptor puede recibir los paquetes desordenados y con retraso, lo que provoca una
distorsión de la información llamada “jitter”. En la Figura 5.5 se muestra un ejemplo de cómo
se pueden recibir paquetes RTP fuera de secuencia debido a la congestión de la red
TCP/IP. El número de secuencia de RTP, junto con la marca de tiempo, permite reordenar
los paquetes para minimizar la distorsión.
Figura 5.5. Efecto jitter.
Protocolo RTCP
Los paquetes del protocolo de control RTP (RTCP) se transmiten periódicamente a todos los
participantes de una sesión, cumpliendo cuatro funciones principales:
• Proveer realimentación para la QoS en la distribución de datos en tiempo real.

• Transportar el identificador de la fuente RTP (llamado CNAME).
• Permitir un intervalo de distribución de paquetes RTP ajustable.
• Transportar información de control de la sesión.
Cada participante debe enviar paquetes RTCP. Si existen muchos, por ejemplo en una
conferencia, se plantea un problema de escalabilidad. Para solucionarlo, la frecuencia a la
cual los paquetes RTCP son enviados se ajusta de manera inversamente proporcional al
número de participantes, ocupando un porcentaje pequeño de uso del ancho de banda.
81/112
Módulo 3
5.4. DNS
En redes grandes, como Internet, sería imposible identificar cada sistema solamente por su
dirección IP. Emplear nombres para los sistemas sería más conveniente ya que ayudan a
los usuarios y administrador a identificar más fácilmente los recursos. El servicio de nombres
de dominio (Domain Name Service, DNS) es una base de datos distribuida que almacena
los nombres y sus correspondientes direcciones IP de cualquier recurso de una red TCP/IP,
como Internet o la red IMS. Cada entrada en la base de datos se denomina resource record
(RR).
Los nombres alfanuméricos, llamados nombres de dominio, tienen una arquitectura

jerárquica, y cada elemento de la jerarquía identifica una zona (país, compañía,
departamento, ordenador). Una entrada en un servidor DNS que relaciona el nombre de
dominio con la dirección IP se denomina address record (A record), y en el caso de redes
IPv6, AAAA record.
ENUM
ENUM define el uso del almacenamiento DNS de números de telecomunicación públicos

internacionales siguiendo el formato E.164. Esto es útil para saber qué servicios están
disponibles en qué dominios. Imaginemos que un usuario A, desde un teléfono de la red
telefónica pública conmutada, quiere llamar a un usuario B que emplea VoIP. El usuario A
no puede introducir la dirección SIP en su terminal, por lo que introduce el número E.164 del
usuario B. La llamada alcanza la pasarela y hace una consulta DNS ENUM para obtener la
dirección SIP (Figura 5.6), haciendo posible establecer una llamada IP a IP empleando
número E.164. Los pasos que se llevan a cabo son los siguientes:
1. EL usuario A llama al número E.164 +135812345678.

2. El dominio de conmutación de circuitos contacta con la pasarela.
3. La pasarela formatea el número E.164 en un nombre de dominio cualificado,
8.7.6.5.4.3.2.1.8.5.3.el64.arpa, y consulta el DNS.
4. El DNS devuelve la entrada correspondiente: sip:userB@ejemplo.com.
5. La pasarela contacta con el DNS para obtener la dirección IP del servidor SIP.
6. El servidor DNS devuelve la dirección IP del servidor SIP.
7. La pasarela encamina la llamada al servidor SIP.
8. El servidor SIP contacta con el usuario B y se establece la llamada.
82/112
Módulo 3
Figura 5.6. Ejemplo de llamada de CS a IMS.
5.5. TLS
El protocolo TLS proporciona seguridad en la capa de transporte para aplicaciones de
Internet, mediante confidencialidad e integridad de los datos entre dos puntos finales. TLS
opera en un protocolo de transporte confiable, como TCP.
Una ventaja de TLS es que las aplicaciones pueden utilizarlo de forma transparente para
comunicarse entre sí de forma segura. Otra es que TLS es visible para las aplicaciones, de
manera que son conscientes de las tareas de cifrado y certificados de autenticación
negociados durante la inicialización de una sesión TLS, en tanto que con el protocolo IPsec
las políticas no son visibles por las aplicaciones.
TLS permite negociación para una gran cantidad de conjuntos de cifrado, el uso de
compresión de datos y múltiples conexiones. Esto reduce la sobrecarga que introduce el
protocolo para cada nueva conexión entre aplicaciones.
El protocolo TLS se sitúa encima de una conexión orientada al transporte, como TCP y
proporciona confidencialidad de datos usando criptografía de clave simétrica e integridad de
datos usando comprobación de la autenticación del mensaje codificado (checksum, MAC).
Las claves se generan únicamente para cada sesión, basándose en los parámetros de
seguridad intercambiados durante el protocolo de establecimiento de sesión. Este protocolo
también se emplea para encapsular protocolos de capas superiores para protegerlos, como
por ejemplo el protocolo TLS Handshake Protocol.
La operación básica del protocolo TLS es la siguiente:
1. Lee los mensajes a transmitir.

2. Fragmenta los mensajes en segmentos manejables por el protocolo.
83/112
Módulo 3
3. Comprime los datos, si la compresión está activada.

4. Calcula el MAC.
5. Encripta los datos.
6. Transmite el resultado al destino.
En el lado contrario de la conexión TLS, las operaciones se realizan en el sentido contrario.
1. Recibe los datos del emisor del mensaje.

2. Desencripta los datos.
3. Verifica la MAC.
4. Descomprime los datos, si están comprimidos.
5. Ensambla los fragmentos para formar el mensaje.
6. Envía el mensaje a protocolos de capas superiores.
Protocolo handshake TLS
El protocolo handshake TLS se apoya sobre el TLS y se emplea para autenticar el cliente y
el servidor, intercambiar las claves criptográficas y negociar los algoritmos de encriptación e
integridad de datos antes de que las aplicaciones comiencen a utilizarlo. La Figura 5.7
muestra el flujo de mensajes que se intercambian. En primer lugar el cliente y servidor
intercambian mensajes Hello. A continuación el cliente envía un mensaje ClientHello, que es
respondido por el servidor con un mensaje ServerHello. Estos mensajes establecen la
versión del protocolo TLS, los mecanismos de compresión utilizados, el juego criptográfico y,
posiblemente, el identificador de la sesión.
Entonces el servidor envía algunos mensajes asociados a ServerHello y dependiendo de el

juego de cifrado seleccionado envía su certificado de autenticación. El servidor también
puede enviar un mensaje de intercambio de claves y una petición de certificado al cliente.
Para indicar el final del mensaje ServerHello envía el mensaje ServerHelloDone.
A continuación el cliente envía su certificado y la clave. Opcionalmente puede enviar un

mensaje CertificateVerify para verificar el certificado pedido por el servidor. Entonces, cliente
y servidor envía los mensajes ChangeCipherSpec y habilitan de nuevo la negociación, pero
ya con los parámetros de seguridad resultado de la negociación. El primer mensaje
intercambiado con le nuevo mecanismo es Finished, que incluye un compendio de todos los
mensajes intercambiados en la negociación.
Como hemos comentado anteriormente, es posible resumir una sesión TLS. Para ello el
cliente sugiere en sus mensajes ClientHello un identificador de sesión usando
anteriormente, que es el que se quiere continuar. Si el servidor puede continuar con esa
sesión porque lo encuentra en su caché, el protocolo se abrevia, devolviendo los mensajes
ChangeCipherSpec y Finished inmediatamente después de el mensaje ServerHello.
84/112
Módulo 3
Figura 5.7. El protocolo handshake TLS.
5.6. Diameter
Diameter es un protocolo de autenticación, autorización y cuentas (Authentication,
Authorization and Accounting, AAA) desarrollado por IETF para Internet. Se emplea para
proporcionar servicios AAA para una gran variedad de tecnologías. En lugar de construir un
protocolo desde la nada, se decidió basarlo en RADIUS (Remote Authentication Dial In User
Service) que ya había sido utilizado para proporcionar servicios de AAA, inicialmente
pensado para accesos mediante MODEM, y lo aplicaron a diferentes tipos de accesos,
como los accesos inalámbricos, las operaciones de itinerancia, etc.
El protocolo Diameter final se dividió en dos partes: el protocolo base y las aplicaciones
Diameter. El protocolo base es necesario para enviar datos, negociar capacidades, manejar
errores y proporcionar extensibilidad. Por su parte, la aplicación Diameter define funciones
específicas y unidades de datos. Se han definido unas cuantas aplicaciones Diameter, como
son Mobile IP, NASREQ, Extensible Authentication Protocol (EAP), Diameter credit control y
Aplicación SIP Diameter.
85/112
Módulo 3
El protocolo base Diameter emplea tanto el protocolo TCP como SCTP (Stream Control
Transmission Protocol) como transporte, pero se recomienda el uso de SCTP, y para
asegurar las comunicaciones se emplean tanto Internet Protocol Security (IPsec) como
Transport Layer Security (TLS).
Componentes del protocolo
Diameter es un protocolo punto a punto, por lo que ningún nodo puede iniciar una petición.
Emplea tres tipos de nodos distintos: clientes, servidores y agentes. Los clientes son
generalmente dispositivos de frontera que realizan tareas de control de accesos a la red
IMS. Los agentes proporcionan servicios de retransmisión, proxy o redirección, mientras que
los servidores gestionan las peticiones de autenticación, autorización y gestión de cuentas
para un dominio particular.
Clientes y servidores Diameter
Los clientes Diameter son los que originan la petición AAA. El servidor atiende la petición en
función de la aplicación a la que se dirige la petición, y los agentes proporcionan servicios de
valor añadido tanto a los servidores como a clientes. Habitualmente un cliente Diameter es
un servidor de acceso a la red (network access server, NAS) que realiza tareas de AAA para
una tecnología concreta. El NAS necesita autenticar el terminal que está intentando
conectarse a la red antes de que pueda acceder a los recursos. Por ejemplo, en una red
WLAN el punto de acceso necesita determinar la identidad del usuario antes de que éste
pueda acceder.
Agentes Diameter
Los agentes Diameter se desarrollaron para mejorar el balanceo de carga de la red, y la

administración y mantenimiento, concentrando las peticiones y añadiendo mensajes
adicionales de procesamiento. Son transparentes al protocolo, pero no a las aplicaciones
Diameter. Ellos solamente aceptan peticiones y encaminan mensajes basados en dominios
y terminales conocidos. Existe un tipo de agentes, llamados agentes relay, que se utilizan
para reducir la carga de la red, ya que los NASs de un área concreta se pueden agrupar y
actuar detrás de un agente relay, evitando tener que configurar cada uno de los NAS con la
información necesaria del dominio en el que se encuentran. De una manera similar, un
servidor Diameter puede tener un agente relay que gestione la configuración de carga
causada por añadir y eliminar NAS de la red.
Por otra parte, los agentes denominados agentes de redirección usan la tabla de
enrutamiento de dominio Diameter para determinar cual es el siguiente nodo de una petición
determinada. En lugar de encaminar el mensaje únicamente, el agente devuelve un mensaje
de respuesta que incluye la identidad del próximo nodo del mensaje, de manera que el que
originó el mensaje sabe porqué nodos ha pasado, y puede encaminar el siguiente mensaje
hacia alguno de ellos directamente.
86/112
Módulo 3
Otros agentes Diameter son los agentes proxy. Los agentes proxy. Éstos llevan mensajes
de valor añadido. Son similares a los agentes de redirección en que los mensajes se
encaminan basándose en una tabla de encaminamiento, pero difieren en que tienen la
capacidad de modificar los mensajes implementando políticas de refuerzo.
Finalmente, los agentes de traducción realizan la adaptación entre el protocolo Diameter y

otros protocolos AAA. Los agentes de traducción tienen la finalidad de poder conectar redes
ya existentes a la infraestructura Diameter, ya que actualizar estos equipos existentes no es
tarea fácil.
Estructura del mensaje
Los mensajes Diameter consisten en una cabecera seguida de un cierto número de pares
atributo-valor (AVPs). La cabecera es la mostrada en la Figura 5.8.
Figura 5.8. Cabecera del protocolo Diameter.
En la cabecera existen unos indicadores, llamados indicadores de orden, que representan el

tipo de mensaje. Por ejemplo si en indicador ‘R’ está activo indica que es un mensaje de
petición mientras que si no lo está es un mensaje de respuesta; si ‘P’ está activo indica que
el mensaje se puede almacenar en un proxy, o debe ser procesado localmente en caso
contrario; el indicador ‘E’ indica que el mensaje de respuesta es un mensaje de error; el ‘T’
indica que es una retransmisión; y los indicadores ‘r’ no están implementados.
El campo Command-Code indica cuál es la orden asociada al mensaje. Es un campo de 24

bits en el que cada combinación representa una orden distinta. El campo Application-ID se
emplea para indicar la aplicación que envía el mensaje. El Identificador Hop-by-Hop ayuda a
relacionar peticiones y respuestas, mientras que el Identificador End-to-End detecta
mensajes duplicados.
El campo AVPs contiene los elementos de información sobre la autenticación, autorización y

contabilidad, así como información sobre el encaminamiento, la seguridad y la configuración.
Cada AVP contiene una cabecera y unos datos específicos.
87/112
Módulo 3
Servicios Diameter
Realmente el protocolo Diameter proporciona dos tipos de servicios a las aplicaciones

Diameter: autenticación y/o autorización, y contabilidad. Una aplicación puede hacer uso de
la autenticación o autorización por separado, o combinarlas ambas. Por otra parte, el
servicio de contabilidad se puede invocar independientemente de los servicios de
autenticación y autorización.
Autenticación y autorización
Los servicios de autenticación y autorización están entremezclados con Diameter, ya que las
peticiones de un cliente de autorización o autenticación se llevan a cabo por una petición
Diameter.
El protocolo base Diameter proporciona servicios de autorización en modo orientado o no

orientado al estado. En la primera de ellas el servidor mantiene el estado de la sesión y la
sesión de autorización tiene una duración determinada. No obstante, la sesión puede
terminarse por decisión del cliente, abortada por el servidor o por finalización del tiempo de
vida. En cualquier caso la sesión puede volver a establecerse. Las funciones para ello las
proporciona el protocolo base Diameter.
Contabilidad
El protocolo base Diameter proporciona servicios para contabilidad de las aplicaciones

Diameter. Cuando una sesión de contabilidad no está activa no se reservan los recursos ni
en el cliente ni en el servidor. Una petición de servicio de contabilidad (ACR) activa una
sesión en la que la información de contabilidad puede ser de dos categorías basándose en
el tipo de servicio:
• Servicios de duración medible: en los que está claramente definido el inicio y el

fin de los mismos. Se crea una anotación cuando se crea el servicio y otra
cuando finaliza.
• Eventos on-time: son servicios con una duración no medible, en el que se crea
una anotación sólo cuando se crea el servicio.
La estrategia de contabilidad de una sesión está impuesta por el servidor de contabilidad, o

el servidor de autorización de una sesión de usuario. El servidor de contabilidad indica al
cliente qué tipo de sesión debe establecer: de duración medible u on-time. Opcionalmente
también especifica el tiempo de intervalo usado para crear las anotaciones.
Aplicaciones Diameter usadas en 3GPP
Hay dos aplicaciones Diameter que se emplean en IMS. La primera de ellas es la aplicación
Diameter SIP, que se utiliza en las interfases Cx, Dx, Sh y Dh. La segunda es la aplicación
de control de crédito Diameter, que se utiliza en la interfaz Ro para realizar el cago online.
88/112
Módulo 3
Aplicación Diameter SIP
La aplicación Diameter SIP define una aplicación Diameter que puede ser usada para
autenticar usuarios y autorizar el empleo de diferentes recursos SIP. Está relacionada con la
interfase Cx en funcionalidad, pero en realidad está diseñada para ser lo suficientemente
genérica para poder emplearse en otros escenarios.
La arquitectura general de una aplicación Diameter SIP se muestra en la Figura 5.9. Los
servidores Proxy A y Proxy B tienen diferentes roles. El proxy A está configurado como un
proxy limítrofe, mientras que el proxy B es el proxy propio del dominio. El proxy A maneja las
funciones del servidor I-CSCF, mientras que el proxy B hace lo propio con el servidor S-
CSCF. Para aumentar la redundancia y tolerancia a fallos pueden existir nodos SL
(Subscriber Locator) adicionales que se implementan la funcionalidad de agentes relay o de
redirección.
Figura 5.9. Arquitectura de aplicación SIP basada en Diameter.
La aplicación Diameter SIP define un conjunto de códigos de orden basados en el protocolo

base Diameter, que son:
• UAR/UAA: Determina si un usuario está autorizado a recibir cierto servicio y, en

caso afirmativo, indica el servidor loca capaz de proporcionarlo.
• SAR/SAA: Asigna un servidor SIP a un usuario concreto y le envía el perfil de
usuario.
• LIR/LIA: Determina la próxima entidad a la que enviar el mensaje.
• MAR/MAA: Autentifica y autoriza a un usuario par aun servicio específico.
• RTR/RTA: Eliminación de un registro originada por el servidor Diameter.
• PPR/PPA: envía de forma asíncrona el perfil del usuario al servidor SIP desde el
servidor Diameter.
89/112
Módulo 3
Aplicación de control de crédito Diameter
La aplicación de control de crédito Diameter se emplea para el control en tiempo real del
coste de una serie de servicios. Este modo de operación prepago se utiliza ampliamente en
el mercado de telefonía móvil, en el que en lugar de recibir una factura mensual los usuarios
consumen saldo del crédito disponible a medida que se utilizan algún servicio. La aplicación
de control de crédito tiene dos partes principales:
• Control de crédito y coste: El coste de los servicios se tiene que calcular en

tiempo real, al igual que el cargo en el crédito del usuario. De ello se encarga
esta parte.
• Autorización de crédito: La cuenta de crédito del usuario se tiene que comprobar
para ver si tiene saldo suficiente para establecer un servicio, y cuando esto
ocurre, debe bloquear parte del crédito y devolver lo que no haya consumido
una vez finalizada la comunicación.
Al igual que en el protocolo base Diameter, una sesión de control de crédito se puede
ajustar a dos modelos: autorización de crédito con reserva de crédito, o autorización de
crédito con cargo directo. En el primer caso se evalúa el coste aproximado del servicio a
prestar y el servidor reserva una cantidad de saldo suficiente y cuando finaliza el servicio se
devuelve la cantidad de crédito no consumida. En el segundo modelo se realiza un cargo
por cada evento que ocurre en la sesión.
5.7. MEGACO
MEGACO (Media Gateway Control Protocol) es un protocolo empleado para comunicar la
pasarela de medios y el controlador de pasarela de medios, que tienen una relación
maestro-esclavo, gestionando la señalización y la sesión durante una conferencia
multimedia. Se utiliza en la interfaz Mp.
Los elementos principales de la pasarela de medios son las terminaciones y los contextos,
ambos controlados por el controlador. Una terminación es fuente o destino de una o más
tramas, de las cuales la terminación mantiene información relevante para su
encaminamiento.
Se pueden unir diferentes terminaciones en un contexto, pero si no se unen cada

terminación aislada forma un contexto llamado nulo. El contexto describe la topología de las
terminaciones, por ejemplo incluye parámetros sobre cómo se relacionan éstas entre sí.
El protocolo también define una serie de órdenes para manipular las entidades lógicas
descritas (terminaciones y contextos). Estas órdenes son las siguientes:
• Add: Añade una terminación a un contexto, o bien se emplea para crear un

contexto nuevo.
• Modify: Modifica las propiedades de una terminación o de una trama multimedia.
• Substract: Elimina una terminación de un contexto, o bien si es la única
terminación del contexto, al borrarla borra también el contexto.
90/112
Módulo 3
• Move: Cambia una terminación de contexto.

• AuditValue: Devuelve las propiedades de una terminación.
• AuditCapabilities: Devuelve todos los posibles valores de las propiedades de
una terminación.
• Notify: Mediante esta orden la pasarela informa al controlador de que se ha
producido cierto evento.
• ServiceChange: Mediante esta orden la pasarela informa al controlador de que
se ha producido cierto cambio en un servicio.
Cada orden puede tener asociados una serie de parámetros, llamados descriptores, y
también puede devolverlos como resultado de su ejecución. Los descriptores consisten en
una serie de elementos con valores asociados.
5.8. COPS
El protocolo COPS (Common Open Policy Service), desarrollado por el IETF, tiene como
objetivo la administración, configuración y refuerzo de las políticas de seguridad. Define un
sencillo protocolo de peticiones y respuestas para intercambiar información de políticas
entre servidores y clientes. Los clientes se denominan Policy Enforcement Points (PEPs) y
los servidores Policy Decision Point (PDP). El protocolo utiliza una arquitectura cliente
servidor en la cual un PEP envía peticiones, actualizaciones y órdenes de borrado al PDP, el
cual revuelve una respuesta al primero con la decisión tomada. Un tipo especial de PDP es
el Local PDP (LPDP), utilizado por los PEP para solicitar políticas cuando no hay
comunicación con ningún PDP. Este modelo se puede apreciar en la Figura 5.10.
Figura 5.10. Modelo COPS.
91/112
Módulo 3
Existen dos modelos principales para el control de políticas COPS:
• Outsourcing: El PEP asigna la responsabilidad de autorización a un PDP

externo. Este modelo asume que existe una relación de uno a uno entre un PEP
y un PDP.
• Configuration: A diferencia del modelo anterior, en este modelo no existe
relación entre los eventos en el PEP y las ediciones en el PDP. El PDP puede
configurar el PEP basándose tanto en eventos externos como en eventos
producidos en el PEP.
El protocolo COPS utiliza conexiones TCP entre el PEP y el PDP para el envío de mensajes,
y no el estado de la comunicación, sino que se basa en petición/respuesta. El protocolo
también admite la extensión, dentro de la cual se puede describir el formato del mensaje y
los objetos que transporta.
Las tramas del protocolo COPS están formadas por una cabecera y una serie de objetos de
tipo conocido. EL formato de la cabecera se muestra en la Figura 5.11, y está formada por
los campos:
• Version: Indica la versión del protocolo COPS.

• Flags: Indicadores del mensaje. De momento solo está definido con el valor 0x1,
que indica si el mensaje fue solicitado por otro mensaje COPS previo.
• OP code: Código de operación COPS (algunas ordenes son REQ, RPT, etc.)
• Client type: Identifica el cliente de las políticas y determina la interpretación de
los objetos que se incluyen en la trama.
• Message length: Tamaño del mensaje en octetos.
Figura 5.11. Cabecera COPS.
El formato de los objetos de COPS se muestra, a su vez, en la Figura 5.12, y consiste en:
• Length: Longitud del objeto en octetos.

• C-Num: Indica la clase de información que contiene el objeto.
• C-Type: Identifica el subtipo o la version de la información contenida en el
objeto.
El resto de octetos almacena la información propia del objeto.
92/112
Módulo 3
Figura 5.12. Objetos específicos de COPS.
5.9. IPsec
El protocolo IPsec (Internet Protocol Security) proporciona varios servicios de seguridad en
la capa IP, tanto en Ipv4 como en Ipv6, ofreciendo protección para los protocolos de las
capas superiores. IPsec se emplea típicamente en las comunicaciones seguras entre los
host y las pasarelas de seguridad. El conjunto de servicios de seguridad que ofrece incluye:
• Control de accesos.
• Protección para la integridad de datos.
• Autenticación de datos en origen.
• Protección contra repetición.
• Confidencialidad.
• Limitación del tráfico confidencial.
IPsec puede funcionar siguiendo dos modelos: modo transporte y modo túnel. El modo
transporte está principalmente pensado para proporcionar servicios de seguridad a los
protocolos de las capas superiores, mientras que el modo túnel se emplea para comunicar
de manera segura dos pasarelas de seguridad. La diferencia entre ambos es que en el
modo transporte IPsec proporciona seguridad limitada a las cabeceras IP, mientras que en
el modo túnel está protegido todo el datagrama IP.
Los componentes de la arquitectura de seguridad IPsec son:
• Protocolos de seguridad: Se trata de los protocolos AH (Authentication Header)

y ESP (Encapsulated Security Payload).
• Asociaciones de seguridad: Definición de la base de datos de políticas de
seguridad y la base de datos de asociación de seguridad, así como la gestión y
uso de dichas asociaciones.
• Gestión de claves: Distribución de las claves criptográficas de los protocolos de
seguridad con el protocolo Internet Key Exchange (IKE).
• Algoritmos usados para la encriptación y la autenticación.
93/112
Módulo 3
5.10. DHCPv6
El protocolo de configuración de host dinámico versión 6 (Dynamic Host Configuration
Protocol for Internet Protocol Version 6, DHCPv6) es un protocolo cliente servidor que
permite a los dispositivos la configuración automática de la dirección IP gracias a un servidor
DHCP. También proporciona otra información de configuración.
Los mensajes DHCP se intercambian entre clientes y servidores usando el protocolo UDP.
Los clientes escuchan por el puerto 546 y los servidores por el 547. Los clientes emplean un
enlace local para transmitir y recibir mensajes DHCP. Los clientes envían los mensajes
DHCP utilizando multicast para localizar un servidor antes de solicitarle una dirección IP, así
como otras opciones de configuración. El servidor responde con un mensaje de presencia y
entonces el cliente escoge uno de los servidores que le han respondido y le envía un
mensaje de petición. El servidor responde con un mensaje de confirmación en el que le
asigna una dirección IP con una duración en tiempo limitada, por lo que el cliente debe
enviar periódicamente un mensaje de renovación antes de que le caduque la dirección IP
asignada. La Figura 5.13 muestra el formato del mensaje DHCP, siendo los campos que lo
forman los siguientes:
• Tipo de mensaje: Tipo del mensaje, que puede ser de solicitud, advertencia,
petición, confirmación, renovación, enlace, respuesta, denegación,
reconfiguración, petición de información, etc.
• Identificador de transacción: Es un Identificador del mensaje.
• Opciones: Opciones del mensaje.
Figura 5.13.formato del mensaje DHCP.
Las opciones se emplean para añadir información adicional, siendo el formato el mostrado
en la Figura 5.14. Los campos que lo conforman son:
• Código de opción: un código específico para cada una de las opciones posibles.
• Longitud de la opción: Tamaño en octetos de los datos de la opción.
• Datos de opción: El contenido de la opción.
Figura 5.14. Formato de las opciones DHCP.
94/112
Módulo 3
Para el protocolo SIP se han definido dos opciones posibles que permite a los clientes
localizar su servidor proxy SIP. Una opción lleva una lista de nombres de dominio de
servidores SIP y la otra una lista de direcciones IPv6. La lista de nombres de dominio de
servidores SIP puede contener múltiples nombres de dominio en orden de preferencia,
mientras que la lista de direcciones IPv6 contiene direcciones IP de 128 bits de los
servidores SIP disponibles para el cliente.
95/112
Módulo 3
6. Evolución
6.1. Origen de IMS
El Instituto de Estándares de Telecomunicaciones Europeo (European Telecommunications
Standards Institute, ETSI) era la organización de estandarización que definió el Sistema
Global para las Comunicaciones Móviles (Global System for Mobile Communications, GSM)
al final de los años 80 y principios de los 90. ETSI también definió la arquitectura de red de
GPRS. El último estándar que sólo abordaba GSM se publicó en 1998, y en el mismo año se
fundó 3GPP por las entidades de estandarización de Europa, Japón, Corea del Sur, el
EE.UU. y China para especificar el sistema de telefonía móvil de tercera generación, que
comprende el Wideband Code Division Multiple Access (WCDMA) y el Time Division/Code
Division Multiple Access (TD-CDMA), el acceso de radio y un núcleo de red GSM
evolucionado (http://www.3gpp.org/About/3gppagre.pdf). La mayoría del trabajo y
especificaciones se heredó del Grupo Móvil Especial (SMG) del ETSI. El grupo 3GPP
decidió preparar las especificaciones de manera que se publicasen de manera anual, siendo
la primera versión la Release 99 (3GPP R99).
3GPP Release 99 (3GPP R99)
La elaboración de la primera versión del estándar les llevó un año y se publicó en 1999. La
funcionalidad de la versión se paralizó en diciembre de 1999, si bien algunas
especificaciones base lo hicieron después, en marzo de 2001. La rápida elaboración fue
posible porque el trabajo real se dividió entre dos organizaciones: 3GPP y ETSI SMG. 3GPP
desarrolló los servicios, arquitectura del sistema, y los accesos radio WCDMA y TD-CDMA.
ETSI SMG desarrolló los accesos radio GSM/Enhanced Data Rates for Global Evolution
(EDGE). Los accesos radio WCDMA fueron la mejora más importante al sistema 3G basado
en GSM en esta versión del estándar. Además de WCDMA, UTRAN (UMTS terrestrial radio
access network) introdujo la interfaz Iu. Comparado con las interfaces A y Gb hay dos
diferencias significativas. Primero, en la interfaz Iu los transcoding se realizan en el núcleo
de la red, mientras que en GSM es función del BTS (estación del transceptor base).
Además, la encriptación y la gestión de movilidad a nivel de celda en la inerfaz Iu se realiza
por el controlador de red de radio (RNC), mientras que en GSM se realizaba en el nodo de
soporte GPRS (Serving GPRS Support Node, SGSN).
La Arquitectura de Servicio Abierta (OSA) se introdujo para la creación de los servicios.

Desde el punto de vista del servicio, el objetivo era dejar de estandarizar los nuevos
servicios y concentrarse en las capacidades de servicio, como toolkits. Este principio fue
seguido bastante bien, a pesar del entorno de la casa virtual (VHE), un concepto que cubría
la creación de todos los servicios, y que todavía carece de una buena definición.
3GPP Release 4
Después de la Release 1999, 3GPP empezó a especificar la Release 2000, incluyendo el

llamado All-IP, que posteriormente pasó a llamarse IMS. Durante el año 2000 se comprendió
no se iba a poder completar el desarrollo de IMS en ese año, por tanto la Release 2000 se
separó en dos versiones distintas: Release 4 y Release 5
96/112
Módulo 3
Se decidió que la Release 4 se completaría sin IMS. Las nuevas funcionalidades más
importantes de 3GPP Release 4 fueron el concepto de servidor MGW, los protocolos del
núcleo de red para transporte IP, las mejoras de LCS para UTRAN y mensajería multimedia
y transporte IP para los usuarios de la interfaz Gb. 3GPP Release 4 estaba funcionalmente
parado y completado oficialmente en marzo de 2001. El requisito de compatibilidad
retroactiva, esencial para la interfaz de radio, se mejoró en septiembre de 2002.
3GPP Release 5 y Release 6
La Release 5 finalmente introdujo IMS como parte del estándar de 3GPP. Se pretende que
IMS se convierta en una arquitectura basada en IP, independiente del modo de acceso y
estandarizada, que se interconecte con las existentes redes de voz y datos fijas (por
ejemplo, PSTN, ISDN, Internet) y los usuarios móviles (por ejemplo, GSM, CDMA). La
arquitectura de IMS lo hace posible al establecer comunicaciones IP peer-to-peer con todos
los tipos de clientes con la necesaria calidad del servicio. Además de la gestión de la sesión,
la arquitectura de IMS aborda funcionalidades que son necesarias para la entrega de
servicio completa (por ejemplo, registro, seguridad, cobro, control de portadora e
itinerancia). En definitiva, IMS formará el corazón del núcleo de la red IP.
El contenido de la Release 5 fue duramente discutido, y finalmente las funcionalidades de

3GPP Release 5 se pararon en marzo de 2002. La consecuencia de esta decisión era que
muchas características fueron pospuestas para la nueva versión, Release 6.
La Release 6 de IMS viene a solucionar las limitaciones de la Release 5 y también contiene

nuevas características. Release 6 se completó en 2004. Es en la versión 6 donde 3GPP
define una arquitectura para los servicios multimedia IP basados en SIP. Contiene la
funcionalidad de elementos lógicos, una descripción de cómo se conectan los elementos, los
protocolos seleccionados y procedimientos.
Es importante comprender que la optimización para el entorno de comunicaciones móviles

se ha diseñado para la autenticación del usuario y autorización basados en identidades
móviles, reglas definitivas en la interfaz de usuario para comprimir los mensajes SIP y
seguridad y mecanismos de control de política que permiten pérdida de radio y
recuperación. Es más, se dirigen aspectos tan importantes desde el punto de vista del
operador como la gestión del cobro de los servicios y el control de los mismos.
El desarrollo de IMS se distribuyó en múltiples grupos dentro del 3GPP. 3GPP sigue un
método de trabajo en el cual el existen tres diferentes etapas. En fase 1 se evalúa la
descripción de servicio desde el punto de vista del usuario y el operador. En la fase 2 los
problemas se dividen en elementos funcionales y se identifican las interacciones entre los
mismos. En fase 3 se definen todos los protocolos y procedimientos en detalle. La Figura 6.1
muestra los grupos de trabajo más importantes y sus áreas de responsabilidad que están
involucradas en el desarrollo de IMS.
97/112
Módulo 3
Figura 6.1. Grupos de trabajo de 3GPP relacionados con IMS.
3GPP Relase 7
El 3GPP Release 7 continúa con el impulso de UMTS permitiendo velocidades aún mayores
y mejoras en la capacidad, como también un mayor soporte de servicios en tiempo real
como voz sobre IP (VoIP), juegos interactivos y push-to-talk por móvil. Las optimizaciones
incluyen prestaciones como Multiple Input Multiple Output (MIMO – Múltiple Entrada Múltiple
Salida), llevando las velocidades teóricas pico a niveles muy por encima de los 14 Mbps,
además de mejorar la velocidad promedio de transmisión de la celda. Otras prestaciones de
la Release 7 incluyen: mejoras a la Red de Acceso de Radio (RAN - Radio Access Network),
como conectividad continua, mejoras en la latencia de setup, mejoras en la Red Central e
IMS relacionadas con la telefonía multimedia, soporte para la continuidad de las llamadas de
voz, y Policy and Charging Convergence (PCC – Convergencia de Políticas y Cargos).
3GPP también trabajó en esta versión sobre una nueva interfase de radio y una nueva
arquitectura de sistema para manejar el rápido crecimiento del tráfico de datos IP y para
asegurar la competitividad para la próxima década. La continua evolución de las tecnologías
3GPP llevará las velocidades teóricas pico a más de 100 Mbps para el enlace descendente
y 50 Mbps para el enlace ascendente, reduciendo la latencia a niveles comparables con los
de lnternet por banda ancha fija, es decir, menos de cinco milisegundos en condiciones
ideales.
6.2. Evolución hacia All-IP

Los operadores que quieran proporcionar servicios multimedia IP deberían implementar sin
más demora IMS. La razón es que IMS proporciona servicios estándar, bien estructurados,
interconexión con las redes existentes y convergencia fijo-móvil. Al mismo tiempo,
proporciona una arquitectura probada que simplifica y acelera la creación de nuevos
servicios.
La huella de la evolución hacia all-IP
El estándar IMS está adoptándose por la comunidad de las telecomunicaciones de una

manera creciente. Es hoy la única norma para la comunicación basada en SIP. Los
operadores pueden implementar las soluciones de IMS hoy para obtener beneficios lo más
pronto posible. Las huellas de la evolución mostradas aquí tienen la intención de mostrar
que IMS no sólo proporciona servicios que generan ingresos, sino que también influencian el
comportamiento de los usuarios.
98/112
Módulo 3
Desde una perspectiva de infraestructura de red, IMS puede ser muy costoso, no sólo como
resultado de los costes de horizontalización, sino también por lo que se refiere al
funcionamiento y mantenimiento. La visión de All-IP posibilita un núcleo de red para los
múltiples accesos, por lo que reduce el costo de propiedad.
Evolución inalámbrica
Desde una perspectiva móvil, lo racional sería introducir servicios multimedia que usen una
infraestructura de IMS común, así como sus posibilitadores del servicio. La implementación
de IMS está empezando hoy, con los servicios como el servicio estándar Push to talk over
Cellular (PoC). Adicionalmente, la arquitectura de IMS también puede usarse para
enriquecer la telefonía basada en conmutación de circuitos, combinando capacidades de los
dominios basados en conmutación de paquetes y circuitos. VoIP también se introducirá con
el tiempo en las redes inalámbricas pero de momento está limitado a la disponibilidad de las
redes de radio con conmutación de paquetes. Esto mejorará sin embargo con el tiempo. Se
agregarán nuevas capacidades multimedia, incluyendo video, mensajería, servicios push
personalizados, etc. con el fin de mejorar los servicios de conmutación de paquetes. Esto se
hará en línea con la demanda del mercado, y de acuerdo con normas definidas por 3GPP,
OMA, etc.
Servicios iniciales
El servicio Push to Talk over Cellular (PoC) es uno de los primeros servicios basados en
IMS que está disponible en la red inalámbrica. PoC ofrece los servicios mejorados para la
comunicación persona a persona y de grupo, incluyendo configuración no perturbadora,
transparencia, (muestra a los miembros en una llamada de grupo) y gestión de presencia.
Opera completamente en el dominio de conmutación de paquetes y está basado en
posibilitadores y funciones comunes IMS. Por ejemplo, control de presencia, listado del
grupo, conferencia entre múltiples usuarios y seguridad.
Enriquecimiento de la telefonía con servicios combinacionales
Los servicios combinacionales permiten al usuario compartir información al instante e

interactivamente, como imágenes, video, y contenido web con la persona con la que están
hablando, al mismo tiempo que habla. Los servicios combinacionales posibilitan el
acercamiento de nuevos servicios multimedia móviles, que se pueden introducir al mismo
tiempo que los servicios de la voz existentes. De esa manera, se introducen los nuevos
servicios en los pasos evolutivos.
Esto permite a los operadores poder utilizar su infraestructura de conmutación de circuitos.

Los servicios combinacionales posibilitan al operador acercarse al comportamiento del
usuario, combinando los servicios de telefonía tradicionales con cualquier tipo de contenido
multimedia. Este tipo de servicios son fáciles de utilizar, pudiendo ser enseñados de persona
a persona durante una llamada, reduciendo la barrera que supone la entrada de nuevos
servicios, un factor importante para poder introducir un nuevo servicio con éxito al mercado.
Incluso cuando las redes All-IP sean habituales, el enriquecimiento de la telefonía basada en
conmutación de circuitos se mantendrá hasta que todos los usuarios hayan migrado
completamente a la red All-IP.
99/112
Módulo 3
Telefonía IP
El componente multimedia inalámbrico basado en conmutación de paquetes VoIP

evolucionará para mejorar ciertos aspectos gradualmente, como son el espectro y eficacia
de la infraestructura con IP vía radio y calidad del servicio end-to-end. Es importante notar
que este componente de VoIP ya tiene experiencia en otros soportes, como son las redes
cableadas de banda ancha, WLAN, etc.
Las ventajas de empezar la introducción de IMS con PoC y los servicios combinacionales, e
introduciendo después el componente de VoIP es que los elementos principales de la
arquitectura IMS están ya implementados. Los operadores podrán entonces llevar a cabo
una solución VoIP al mercado de masas en tiempo real, apoyándose en la infraestructura
extendida y los posibilitadores de servicio, que son parte de la arquitectura de IMS. Los
operadores también pueden comenzar a realizar la convergencia fijo-móvil sin necesidad de
cambios en la arquitectura.
Evolución cableada
Hay varios factores que indican una evolución más rápida hacia All-IP basado en redes IMS
que en el caso de las redes móviles. Por ejemplo, no hay restrcciones en el ancho de banda,
ni problemas de itinerancia, y los terminales tienen la suficiente potencia de cálculo para
ejecutar cualquier aplicación.
Todas estas características favorables para IMS implican que los operadores de redes
cableadas pueden empezar a introducir servicios de nueva generación y reducciones en el
OPEX y CAPEX. El reemplazo de la telefonía basada en circuitos basada en banda ancha y
la tecnología VoIP ha comenzado a producirse ya. Sin embargo, en muchos casos, estas
soluciones están basadas en arquitecturas propietario y no están construidas de acuerdo al
estándar IMS.
IMS es la única arquitectura estándar existente para la comunicación basada en SIP en las
redes cableadas, por lo que está siendo adoptada por ETSI/TISPAN. Una parte importante
para el éxito de este estándar en la unidad de la comunidad de las telecomunicaciones.
Expandiendo oferta de servicios existentes
Los operadores de redes cableadas han invertido mucho dinero en su infraestructura de

banda ancha. Ellos están ahora listos para dar un nuevo paso en la evolución, puesto que
ya están obteniendo beneficios de las inversiones en dicha infraestructura.
Con la mezcla apropiada de servicios, los proveedores de servicio pueden entrar en este
segmento del mercado. Por ejemplo, con una solución cableada basada en IMS, un
operador puede ofrecer la telefonía IP directamente, y además utilizar los elementos básicos
de IMS (las funciones comunes y posibilitadores de servicio) para enriquecer el servicio
VoIP con capacidades multimedia como la videoconferencia, la gestión de presencia, la lista
de contactos y la mensajería instantánea.
100/112
Módulo 3
El mercado de las empresas
Uno de los segmentos más convenientes y aprovechables para los servicios de

comunicación multimedia enriquecidos es el mercado de la empresa. Dentro de este
segmento hay una gran demanda de servicios de comunicación fiables que faciliten la
operativa diaria de la empresa.
Una aplicación interesante en el mercado de la empresa es IP Centrex, también conocido

como una solución de PBX virtual. Combinando los servicios multimedia de IMS con IP
Centrex se pueden crear los servicios de colaboración avanzados convenientes para el
mercado de las grandes empresas. La solución combinada organizará un repertorio
completo de servicios personales y de grupo, con la suma de apoyo multimedia como la
comunicación con video, la conferencia, la colaboración, la gestión de presencia, la
mensajería instantánea, la integración de Outlook y soporte para los trabajadores remotos.
101/112
Módulo 3
7. Glosario
3GPP Third Generation Partnership Project
3GPP2 Third Generation Partnership Project 2
ARR IPv4 address resource record
AAAA RR IPv6 address resource record
AAA Authentication, authorization and accounting
AAL ATM adaptation layer
ACA Accounting-Answer
ACR Accounting requests
ADSL Asynchronous Digital Subscriber Line
AH Authentication header
AKA Authentication and key agreement
AMR Adaptive multi-rate
AOR Address of record
API Application program interface
APN Access point name
ARIB Association of Radio Industries and Businesses (Japan)
AS Application server
ATM Asynchronous transfer mode
AUC Authentication centre
AUID Application usage ID
AUTN Authentication token
AUTS Synchronization token
AV Authentication vector
AVP Attribute value pair; audio video profile
B2BUA Back to back UA
102/112
Módulo 3
BCF Bearer Charging Function
BER Bit error ratio
BGCF Breakout Gateway Control Function
BICC Bearer Independent Call Control
BNF Backus-Naur Form grammar
BS Bearer service; billing system
BSF Bootstrapping Server Function
BTS Base Transceiver Station
CAMEL Customized Applications for Mobile network Enhanced Logic
CAP Camel Application Part
CCF Charging Collection Function
CCSA China Communications Standards Association
CDMA Code Division Multiple Access
CDR Charging Data Record
CGF Charging Gateway Function
CK Ciphering key
CN Core Network
COPS Common Open Policy Service
COPS-PR Common Open Policy Service Usage for Policy Provisioning
CPCP Conference Policy Control Protocol
CPIM Common Presence and Instant Messaging
CPS Conference policy server
CRLF Carriage Return Line Feed
CS Circuit-switched
CSCF Call Session Control Function
CSCN Circuit Switched Core Network
CSE CAMEL Service Environment
CSRC Contributing source
103/112
Módulo 3
DDDS Dynamic Delegation Discovery System
DES Data Encryption Standard
DHCP Dynamic Host Configuration Protocol
DL Downlink
DOI Domain of interpretation
DOS Denial of service
DNS Domain name system
DSL Digital Subscriber Line
DTMF Dual-tone multifrequency
EAP Extensible Authentication Protocol
ECF Event Charging Function
EDGE Enhanced Data Rates for Global Evolution
ENUM E.I64 number
ESP Encapsulation security payload
ETSI European Telecommunications Standards Institute
FQDN Fully qualified domain name
FSM Finite state machine
GAA Generic Authentication Architecture
GBA Generic Bootstrapping Architecture
GBR Guaranteed bit rate
G-CDR GGSN-CDR
GCID GPRS charging identifier
GGSN Gateway GPRS Support Node
GPRS General Packet Radio Service
GSM Global System for Mobile Communications
HLR Home location register
HSS Home Subscriber Server
HTTP Hyper Text Transfer Protocol
104/112
Módulo 3
IAB Internet Architecture Board
IANA Internet Assigned Numbers Authority
ICID IMS charging identifier
I-CSCF Interrogating-CSCF
IESG Internet Engineering Steering Group
IETF Internet Engineering Task Force
IK Integrity key
IKE Internet Key Exchange
IMS-MG IP Multimedia Subsystem-Media Gateway Function
IMS IP Multimedia Subsystem
IMSI International Mobile Subscriber Identifier
IM-SSF IP Multimedia Service Switching Function
101 Interoperator identifier
IP Internet Protocol
IP-CAN IP-Connectivity Access Network
IPsec Internet Protocol security
IPv4 Internet Protocol Version 4
IPv6 Internet Protocol Version 6
IRC Internet Relay Chat
ISAKMP Internet Security Association and Key Management Protocol
ISC IMS Service Control
ISDN Integrated Services Digital Network
ISIM IP Multimedia Services Identity Module
ISP Internet Service Provider
ISUP ISDN User Part
IV Initialization vector
LI Layer 1
LCS Location services
105/112
Módulo 3
LIA Location-Info-Answer
LIR Location-Info-Request
LPDP Local policy decision point
M3UA SS7 MTP3-user adaptation layer
MAA Multimedia-Multimedia-Answer
MAC Message Authentication Checksum
MAP Mobile Application Part
MAR Multimedia-Auth-Request
Mbone Multicast backbone
MBR Maximum bit rate
MCC Mobile country code
MDS Multimedia Delivery Service
MEGACO Media Gateway Control Protocol
MGCF Media Gateway Control Function
MGW Media gateway function
MIB Management information base
MID Media stream identification
MITM Man in the middle
MIME Multipurpose Internet Mail Extension
MMS Multimedia Messaging Service
MMSC Multimedia Messaging Service Centre
MNC Mobile network code
MOBILE II Mobile Internet Protocol
MPV Music photo video
MRFC Multimedia Resource Function Controller
MRFP Media Resource Function Processor
MSC Mobile switching centre
MSIN Mobile Subscriber Identification Number
106/112
Módulo 3
MSISDN Mobile Subscriber International ISDN Numbe
MSRP Message Session Relay Protocol
MTP Message Transfer Part
MTPn Message Transfer Part level n
MTU Maximum transfer unit
NAF Network Application Function
NAI Network access identifier
NAPTR Naming authority pointer
NAS Network access server
NASREQ Network Access Server Requirements
NDS Network Domain Security
NTP Network Time Protocol
OCS Online Charging System
OMA Open Mobile Alliance
OSA Open Services Architecture
P2P Peer to peer
PA Presence agent
P-CSCF Proxy-CSCF
PCMU Pulse code modulation u-law
PDF Policy Decision Function
PDP Packet Data Protocol; policy decision point
PEF Policy Enforcement Function
PEP Policy Enforcement Point
PIB Policy information base
PKI Public Key Infrastructure
PLMN Public Land Mobile Network
PNA Push-Notification-Answer
PoC Push to talk over the cellular service
107/112
Módulo 3
PNR Push-Notification-Request
PPA Push-Profile-Answer
PPR Push-Profile-Request
PRACK Provisional response acknowledgement
PRC Provisioning class
PRI Provisioning instance
PRID Provisioning instance identifier
PS Packet-switched; presence server
PSI Public service identity
PSTN Public Switched Telephone Network
PUA Presence user agent; Profile-Update-Answer
PUR Profile-Update- Request
QoS Quality of service
RADIUS Remote Authentication Dial In User Service
RAN Radio access network
RAND Random challenge
RES Response
RFC Requests For Comments
RLS Resource list server
RNC Radio network controller
ROAMOPS Roaming operations
RSVP Resource Reservation Setup Protocol
RTA Registration-Termination-Answer
RTCP RTP Control Protocol
RTP Real-time Transport Protocol
RTP/AVP RTP Audio and Video Profile
RTR Registration-Termination-Request
S/MIME Secure MIME
108/112
Módulo 3
SA Security association
SAA Server-Assignment-Answer
SAD Security Association Database
SAR Server-Assignment-Request
SBLP Service-based local policy
S-CDR SGSN-CDR
SCF Session Charging Function
SCS Service Capability Server
S-CSCF Serving-CSCF
SCTP Stream Control Transmission Protocol
SDP Session Description Protocol
SDU Service Data Unit
SEG Security Gateway
SGSN Serving GPRS Support Node
SGW Signalling Gateway
SHA Secure Hash Algorithm
SigComp Signalling Compression
SIM Subscriber Identity Module
SIP Session Initiation Protocol
SIPS Secure SIP
SL Subscriber locator
SLA Service-level agreement
SLF Subscription Locator Function
SMI Structure for Management Information
S/MIME Secure MIME
SMG Special Mobile Group
SNA Subscribe-Notifications-Answer
SNMP Simple Network Management Protocol
109/112
Módulo 3
SNR Subscribe-Notifi cations- Request
SPD Security Policy Database
SPI Security Parameter Index
SPT Service point trigger
SQN Sequence number
SRF Single reservation flow
SRV Service records
SS7 Signaling System No. 7
SSF Service Switching Function
SSRC Synchronization source
TCP Transmission Control Protocol
TCP/IP TCP/IP stack
TD-CDMA Time Division/Code Division Multiple Access
THIG Topology Hiding Inter-network Gateway
TIA Telecommunications Industry Association (North America)
TLS Transport Layer Security
TTA Telecommunications Technology Association (South Korea)
TTC Telecommunications Technology Committee (Japan)
TTL Time to live
TU Transaction User
UA User Agent
UAA User-Authorization-Answer
UAC User Agent Client
UAR User-Authorization-Request
UAS User agent server
UDA User-Data-Answer
UDP User Datagram Protocol
UDR User-Data-Request
110/112
Módulo 3
UDVM Universal decompressor virtual machine
UE User equipment
UICC Universal Integrated Circuit Card
UL Uplink
UMTS Universal Mobile Telecommunications System
URI Uniform resource identifier
URL Universal resource locator
URN Uniform resource name
USIM Universal Subscriber Identity Module
UTRAN UMTS terrestrial radio access network
VHE Virtual home environment
VoIP Voice over IP
WAP Wireless Application Protocol
WB Wideband
WCDMA Wideband Code Division Multiple Access
WLAN Wireless Local Area Network
XCAP XML Configuration Access Protocol
XML Extensible Markup Language
XRES Expected response
111/112
Módulo 3
8. Referencias
Bibliografía
• Miikka Poikselkä et al. “IMS. IP Multimedia Concepts and Services”. Second

edition. John Wiley & Sons. 2006.
• Gonzalo Camarillo y Miguel Ángel García-Martín. “The 3G IP Multimedia
Subsystem (IMS): Merging the Internet and the Cellular Worlds”. Second edition.
John Wiley & Sons. 2006.
• Juha Korhonen. “Introduction to 3G Mobile Communications”. Second edition.
Artech House Publishers. 2003.
• Varios autores. “Redes UMTS. Arquitectura, movilidad y servicios”. Ediciones
Ra-ma. 2006.
• Ericsson. “IMS. IP Multimedia Subsystem”. White paper. October 2004.
Enlaces
• http://www.telefonica.es/sociedaddelainformacion/
• http://www.telefonica.es/sociedaddelainformacion/pdf/publicaciones/movilidad/ca
pitulo_12.pdf
• http://www.telefonica.es/sociedaddelainformacion/pdf/publicaciones/movilidad/ca
pitulo_5.pdf
• 3GPP Specifications - Numbering scheme:
http://www.3gpp.org/specs/numbering.htm
• Business Communications Review Magazine - IMS 101 What You Need To
Know Now:
http://www.bcr.com/carriers/public_networks/ims_101_what_need_know_now_2
005061514.htm
• IP Multimedia Subsystem - Wikipedia, the free encyclopedia:
http://en.wikipedia.org/wiki/IP_Multimedia_Subsystem
• Tech Invite -- SIP-IMS Technical Portal – Home: http://www.tech-invite.com/
• www.3gpp.org - -ftp-Specs-: http://www.3gpp.org/ftp/Specs/
112/112

Converfim Modulo3

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 Modulo3

Cargado por

Copyright:

Formatos disponibles

Módulo 3

1. Visión sobre el Subsistema Multimedia IP....................................................................... 3

1. Visión sobre el Subsistema Multimedia IP

La arquitectura horizontal de IMS facilita a los proveedores la creación de nuevos servicios,

Figura 1.1. Empleo de IMS sobre GPRS.

De esta forma, la función de IMS en los servicios IP multimedia incorpora el procesado y

Este concepto establecido en la arquitectura permite, fundamentalmente, emplear

• La comunicación orientada a sesión de un usuario a otro(s) usuario(s), o de un

Quizás la característica más notable procede de la naturaleza “Internet” de su arquitectura:

la mensajería IP multimedia (instantánea y diferida), del servicio de presencia, de los

• Los servicios heredados (las llamadas básicas de voz, la mensajería textual,

• Las sesiones interoperador. Los abonados de un operador IMS tienen la

el IMS nativo del abonado, desde donde se reencamina la sesión hacia su

1.2. Tendencia del mercado de comunicaciones

Necesidades del usuario

El número de usuarios de las telecomunicaciones está experimentando un considerable

El empleo de servicios de telefonía móvil, mensajes SMS o mensajería instantánea

Este intercambio de información remota crea la necesidad de mantener la seguridad y la

Necesidades del operador

En general, los operadores buscan formas rápidas y flexibles de responder a las

Necesidades de la entidad de regulación

La entidades reguladoras y de estandarización trabajan para asegurar que las

1.3. ¿Cómo trabaja IMS?

La integración de voz y datos en las comunicaciones persona a persona es un aspecto

Ana selecciona el grupo de trabajo de proyecto de su lista de contactos, ve quién está

¿Cómo entra en juego IMS?

Creación del servicio y entrega

Con la introducción de la arquitectura de IMS, para la creación y puesta en marcha de un

Los servicios de colocación en un Servidor de Aplicación reduce la carga de trabajo del

La arquitectura horizontal de IMS permite a los operadores cambiar sus aplicaciones de

La arquitectura vertical es muy costosa y compleja de construir y mantener. Deben

IMS proporciona varias funciones comunes que son genéricas en su estructura e

aprovisionamiento, la operación y gestión, el directorio, el cobro por el servicio y el

Además de acelerar y simplificar la creación de servicios y procesos de entrega, la

Posibilitadores del servicio

IMS proporciona facilidades para la creación y entrega de servicios multimedia basados en

El posibilitador del servicio de presencia permite informar a un conjunto de usuarios sobre la

Gestión de listas de grupos

Entrega del servicio

Acceso a los servicios

IMS simplifica enormemente el proceso de ingreso y autenticación, tanto para operadores

Conveniencia y facilidad de uso

IMS posibilita la reutilización de relaciones entre operadores. En lugar de desarrollar

El interfaz entre redes se establece en el entorno IMS, y se pueden reutilizar el

Creación del servicio en los terminales

Interconexión con redes existentes

Un posibilitador para la convergencia

Una ventaja del uso de IMS es la convergencia e interconexión de redes en varias

Capas de aplicación y de control común

La introducción de IMS se puede considerar, en algunos aspectos, como un volver a

No obstante, IMS introduce nuevas funciones comunes y posibilitadores de servicio tanto

Las redes de acceso conscientes

La funcionalidad de acceso múltiple es inherente en la arquitectura de IMS. Si esto se

Tipos de dispositivos vs redes

Con la introducción de dispositivos portátiles, como las computadoras portátiles y PDAs, y el

Además, se comprueba la existencia de virus en la carga útil (principalmente de voz y

Algunas de las funciones de la entidad de regulación se han estandarizado en la

Figura 2.1. Opciones de conectividad IMS en itinerancia.

Es importante notar que un usuario puede desplazarse y obtener conectividad IP desde la

Calidad de servicio para los servicios IP multimedia

• Tipo de comunicación multimedia, tráfico, etc.

Después de la negociación de los parámetros a nivel de aplicación, los UE reservan los

La política de control significa la capacidad de autorizar y controlar el tráfico IMS, basado en