Conmutación de paquetes IP de Telecom - Parte 3

Escrito por leopedrini miércoles, 15 de febrero de 2012 16:07:00 Categories: Curso
Valorar Este Contenido 2 Votos.

Al final del artículo anterior he dicho que vamos a cavar un poco más profundamente en IMS y protocolos de señalización NGN (todo esto ocurre en la capa de aplicación de la arquitectura de red TCP/IP – ver el artículo primero de esta serie).

 

Note: mi blog Smolka et Catervarii (que solo tiene contenido em portugues por lo momento).

 

Y así lo haremos. Debo advertir, sin embargo: es mejor que abróchense los cinturones, porque hay turbulencias por delante. Pocas cosas pueden ser intelectualmente más intimidantes que el estilo de escritura de las normas de telecomunicaciones. La verdad sea dicha, están cada vez mejor, pero aún así leerlas es una propuesta difícil. Incluso las imágenes pueden ser desalentadoras. Así que os ruego: no dejeis que esta imagen vos asusteis de la lectura del resto de este artículo.

 

 

Esta imagen proviene de la Recomendación UIT-T Y.2021. Mira el rectangulo sombreado con las esquinas redondeadas. Hay "núcleo IMS" escrito en él – y realmente es eso. Sin embargo, estamos interesados ​​en una sola entidad allí: el Call Session Control Function (CSCF), y su relación con el equipo de usuario (computadoras de escritorio, portátiles o de mano, smartphones, tablets, lo que sea) identificados por la UE en la imagen.

Cada línea que conecta entidades se llama uma interfaz (la terminología formal es: puntos de referencia, pero no importa). Son la representación de relaciones lógicas entre las entidades, y cada interfaz utiliza un protocolo de capa de aplicación (más de uno, a veces). La interfaz de señalización entre CSCF y la UE se identifica como Gm en la imagen. Y los protocolos de la capa de aplicación utilizadas en la interfaz Gm son SIP y SDP (no estoy explicando algunas de las siglas que ya están explicadas en otra parte – realmente creo que usted están siguiendo estos artículos desde el principio).

¿Y qué CSCF hace? Es el servidor AAA (y más) que hemos hablado en el último artículo. Puesto que parece que la mayoría de los lectores del TelecomHall tienen conocimiento de las redes móviles, entonces podemos explicar las funcionalidades del CSCF de esta manera: es una especie de fusión de HLR (Home Location Register) y de AuC (Authentication Center).

Pero hay en realidad tres entidades llamadas CSCF, que difieren en una letra prefijo: P (Proxy), I (Interrogation) y S (Serving). Estos tres "sabores" de CSCF existen porque estamos hablando de servicios de telecomunicaciones aquí. Así que hay los suscriptores del operador de red, y hay los usuarios visitantes.

Cualquiera que sea el usuário, local o visitante, una de las primeras cosas que él/ella tiene que hacer cuando se conecta a la red es hacier contacto con el P-CSCF. Punto 5.1.1 de la ETSI TS 123 228 ofrece dos métodos alternativos para el descubrimiento de P-CSCF. Creo que la forma práctica es la combinación de ambas:

  • El Dynamic Host Configuration Protocol (DHCP, para redes IPv4 o IPv6) dá a el UE las direcciones IP (v4 o v6) de los servidores de nombres primario y secundario (Domain Naming System – DNS) que son capaces de resolver el nombre completo de dominio (Fully-Qualified Domain Name – FQDN) en las direcciones IPv4 y/o IPv6 primaria y secundaria del I-CSCF;
  • Durante la configuración inicial, o en el ISIM (IMS Subscriber Identification Module – SIM), o incluso a través de procedimentos Over-The-Air (OTA), el UE recibe el FQDN de el I-CSCF.

El I-CSCF envía todas las peticiones de usuarios para el S-CSCF que ha asignado a su servicio. Si el usuario es local, entonces eso es todo. Si el usuario es un visitante, entonces el S-CSCF de la red visitada actúa como un I-CSCF y envía todas las peticiones de usuarios para el S-CSCF de la red nativa del usuario.

Para comprender las entidades restantes en el núcleo del IMS, primero tenemos que entender que los servicios basados ​​en NGN no irán poner los actuales servicios de telecomunicaciones fuera del mercado. Van a tener que vivir juntos, lado a lado, durante mucho tiempo todavía. Así que hay una clara necesidad de NGN y los servicios tradicionales de telecomunicaciones interactúen. Esto es: debería ser posible a las llamadas originadas en equipos de usuario conectados en las NGNs a terminar en los dispositivos comunes de telefonía, y viceversa.

Desde hace unos diez años los operadores comenzaron a sustituir a los centrales tradicionales de telefonía con softswitches.

Un softswitch es un sistema distribuido (lógicamente, y posiblemente también geográficamente), y se puede construirlo (más o menos) con una arquitectura abierta. Sus bloques de construcción principales son:

  • Un Media Gateway Controller (MGC), que se encarga de señalización entre el softswitch y el resto de los elementos de la red;
  • Uno o varios Media Gateways (MGs), que hacen la traducción de los flujos de los medios de comunicación entre las diferentes interconexiones físicas.

El MGC controla los MGs que se le asignan a través de un protocolo de senãlización IP, cuyas características se encuentran en el Recomendación UIT-T H.248.1Gateway Control Protocol: version 3. La siguiente imagen muestra cómo los elementos de softswitch IP y la interconexión con la Red Pública de Telefonía (Public Switched Telephony Network – PSTN) y los protocolos de señalización utilizados.

 

 

Por último, pero no menos importante, está el Multimedia Resources Control Function (MRFC). Algunos servidores de aplicaciones (ver AS-FE en la imagen) necesitan ayuda para prestar servicios a la UEs. Tal ayuda puede ser:

  • Según la Recomendación UIT-T Y.2021 – "multi-way bridging de conferencia, la reproducción de anuncios y transcodificación de los medios";
  • De acuerdo con ETI TS 123 228 – "mezcla de los flujos de los medios de comunicación de entrada (por ejemplo, para múltiples partes), fuente de flujos de los medios (para anuncios multimedia), procesamiento de flujo (por ejemplo, la transcodificación de audio, análisis de los medios de comunicación), control de piso (es decir, gestionar los derechos de acceso a recursos compartidos en un entorno de conferencia)".

Tenga en cuenta que MRFC sólo hace el control de estas actividades. La ejecución real es manejada por los Multimedia Resources Function Processors (MRFPs) en la jerga del ETSI, o Multimedia Resources Proccessor Functional Entities (MRP-FEs) en la jerga de la UIT-T – ambos los nombres se refieren al mismo objeto de software.

Y algo muy importante a tener en cuenta: P-CSCF, S/I-CSCF, BGCF, MRFC y MGCF son funciones lógicas que son implementadas en el software, por lo que pueden existir en una máquina, o se pueden distribuir entre muchas máquinas. Lógicamente, no importa, pero las implementaciones físicas de cada proveedor pueden variar, y pueden generar dudas si no eres consciente de ello.

Ahora bien, esto se está poniendo un poco más largo de lo que esperaba, así que vamos a hacer una pausa aquí, y volver con los protocolos de señalización en el próximo artículo, ¿ok? Pido disculpas si esto se está volviendo un poco difícil de seguir, pero yo realmente no sé cómo decirlo en términos más simples.

Au revoir!