Aspectos básicos para la utilización de SIP como protocolo de señalización en la red de acceso de sistemas UMTS

Transcripción

1 Aspectos básicos para la utilización de S como protocolo de señalización en la red de acceso de sistemas UMTS Manuel Moreno Martín, Universidad de Oriente. Manuel Álvarez-Campana Fernández-Corredor, Universidad Politécnica de Madrid Joan Vinyes Sanz, Universidad Politécnica de Madrid Resumen Partiendo del desarrollo evolutivo de las especificaciones de los sistemas UMTS, y en aras de armonizar protocolos siguiendo estándares del IETF, se exponen aspectos básicos para utilizar S como protocolo de señalización en la red de acceso de estos sistemas, como son: mensajes S necesarios, requerimientos y variantes de declaración de sesiones S de señalización. Introducción El proceso evolutivo en las especificaciones de los sistemas UMTS (Universal Mobile Telecomunications) del foro 3GPP (3ª Generation Partnership Project), muestra de forma clara la tendencia a la convergencia con el mundo (Internet Protocol) [8], hecho que se representa de manera gráfica en la figura 1. La Release 99 de UMTS se caracteriza por proponer, como elemento nuevo, una red de acceso radio (UMTS Terrestrial Radio Access Network) basada en ATM (Asynchronous Transfer Mode). El núcleo de red CN () reutiliza la infraestructura de los sistemas GSM (Global System for Mobiles) y GPRS (General Packet Radio Service), es decir, TDM (Time Division Multiplex) para el dominio CS (Circuit Switched) e (Internet Protocol) para el dominio PS (Packet Switched). La Release 4 de UMTS añade como novedad la propuesta de una infraestructura para el dominio CS del núcleo de red, esto es, se propone un dominio CS independiente del transporte, por lo que todo el CN se plantea ahora sobre una infraestructura, allanando el camino all. Posteriormente, la Release 5 UMTS, introduce la propuesta del subsistema Multimedia (IMS, Multimedia Subsystem) en el dominio PS, a la vez que se plantea también una infraestructura de transporte alternativa para la red de acceso radio. Con la Release 5 se está ya en presencia de sistemas UMTS all. Este proceso evolutivo conduce a pensar en un futuro como el que se indica en la parte inferior derecha de la figura 1, donde es de esperar un núcleo de red unificado y la posibilidad de utilizar un solo backbone para todo el sistema. Release 99 Release 4 Dominio CS TDM Dominio CS ATM ATM Release 5 Futuro? Dominio CS IMS IMS Iu Figura 1: Evolución UMTS a all 1

2 Esta tendencia hacia ha propiciado también el desarrollo de especificaciones UMTS soportadas en el protocolo de señalización S (Session Initiation Protocol) del IETF (Internet Engineering Task Force), como es el caso del subsistema IMS. En consecuencia, esto sugiere, como también se expone en [8], la valoración de S como protocolo para desarrollar la señalización de la red de acceso de estos sistemas, asunto en el que se centra este trabajo. S y El protocolo S, y extensiones de él, pueden facilitar y armonizar la convergencia e integración entre sistemas de Telecomunicaciones móviles y fijos, e Internet. En [8] se presentan las bases sobre las que debe emplearse S, y la torre de protocolos en que éste debe sustentarse para suplantar los protocolos RANAP (RAN Application Part), NBAP (Node B Application Part) y RNSAP (RNS Application Part) (figura 2), en sustitución de la infraestructura basada en SS7 (Signalling System number 7) ya especificada (figura 3). S - RANAP/NBAP/RNSAP SCTP Capas 1 y 2 Figura 2: Torre de protocolos para el plano de control RNL La capa S-RANAP/NBAP/RNSAP comprende las aplicaciones S que deben sustentar las funciones de los protocolos RANAP, NBAP y RNSAP, esto es, los protocolos RNL (Radio Network Layer) de. RNSAP, cuyos antecedentes están en los protocolos BSSMAP (Base Station System Management Application Part), DTAP (Direct Transfer Application Part) ) y BTSM (Base Transceiver Station Management) de sistemas móviles GSM. Estos protocolos RNL desarrollan funciones muy propias de las redes UMTS, como son los procedimientos relativos a: - la operación de los nodos B, - la interacción entre nodos RNC s ( Radio Network Controller), - la señalización intercambiada entre nodos RNC s y nodos MSC s (Mobile Switching Centre) y SGSN s (Serving GPRS Support Node), - la transferencia directa de señalización entre UE s y nodos CN (), que en buena medida son funciones conducentes a gestionar el recurso de comunicación entre los UE s y la red UMTS. En la figura 5 se representa el contexto de actuación de los protocolos RNL, sobre los interfaces lógicos Iu, Iur e Iub de sistemas UMTS. Por otra parte, el protocolo S [7] está pensado para la gestión de sesiones entre aplicaciones, esto es, entre procesos que corren en máquinas diferentes conectadas a redes. Está enfocado básicamente a gestión de sesiones interactivas sobre redes. Por tanto, S no dispone de lo necesario para desarrollar funciones propias de los protocolos RNL. Para tal tarea se requiere de las extensiones correspondientes. Mensajes S necesarios Dada la disparidad de funciones entre los protocolos RNL y S, no resulta posible suplir con el segundo las funciones de los primeros directamente, pues no hay correspondencia de mensajes de señalización entre éstos. Todo esto ha propiciado y ha conducido a proponer en [8] un escenario como el que muestra la figura 4, donde los nodos UMTS asociados a los interfaces lógicos Iu, Iub e Iur se deben comportar como S UA s (S User Agent) para el soporte de la señalización de la capa de red radio. Funciones de los protocolos involucrados RANAP NBAP Capa de Red de Transporte SCCP MTP3b SSCF-NNI SSCOP AAL 5 SAAL - NNI SSCF-UNI SSCOP AAL 5 RNSAP, RANAP- Capa de Red Radio S -U A A N L I SAAL SCCP MTP3b M3UA SSCF-NNI SCTP SSCOP AAL 5 SIGTRAN Las características del recurso radio que sirve de interfaz entre UE s (User Equipment) y red UMTS, recurso escaso y por tanto compartido, así como la movilidad de los UE s, conducen a la necesidad de los protocolos RANAP, NBAP y Nivel ATM Nivel Físico Figura 3: Torres de protocolos especificados 2

3 RNC UA-S RNC UA-S B UA-S B UA-S UĀ S Sever S Sever Nube S (Interfaces lógicos Iu, Iub, Iur) MSC-S UA-S MSC-S UA-S SGSN UA-S SGSN UA-S Figura 4: Nodos UMTS con aplicaciones S- RANAP/NBAP/RNSAP No obstante, hay que distinguir las necesidades de cada una de las fases involucradas en la señalización S-RANAP/NBAP/RNSAP [8]. - Apertura de sesión, - Intercambio de mensajes S- RANAP/NBAP/RNSAP, - Cierre de sesión Las fases apertura de sesión y cierre de sesión son abordables directamente con mensajes S, pues son propias de la pretensión de utilizar dicho protocolo. Los métodos S para tal fin son INVITE-ACK y BYE, respectivamente. El método CANCEL para cancelar sesiones solicitadas aún no abiertas. La fase intermedia, intercambio de mensajes S-RANAP/NBAP/RNSAP, tiene que ser desarrollada de acuerdo a las posibilidades que S brinda, pero que de ninguna manera se trata de un mapping de señalización estrictamente hablando. El método INFO resulta adecuado para esta fase, adaptándolo para soportar la señalización RNL. Otros métodos S como REFER, MESSAGE, COMET, SUBSCRIBE, UNSUBSCRIBE, NOTIFY y DO, aún en fase draft, y REGISTER, también deben ser valorados, no obstante, por su naturaleza, quizás no sean adecuados para soportar señalización S- RANAP/NBAP/RNSAP. Los métodos OPTIONS y REGISTER pudiesen ser útiles para la puesta y retirada del servicio de los nodos B y RNC, o en general por razones de operación y mantenimiento, o nuevas instalaciones. Método INFO [6] Este método ha sido definido para el transporte de información de la capa de aplicación, generalmente relativa a la sesión (por ejemplo señalización), que se genere durante la consecución de ésta y sin pretender cambiar el estado de la misma. Esto es, para el trasiego de información de control correspondiente a la aplicación, sin cambiar el estado y parámetros de la sesión S. INFO transporta la información en las cabeceras y/o en el cuerpo del mensaje. Generalmente en su cuerpo, si bien esto es opcional. INFO no define mecanismo alguno que garantice la entrega ordenada de la información transportada en sucesivos mensajes INFO. La cabecera CSeq no debe ser considerada para tal fin, por cuanto ésta se incrementa por cada solicitud S que se origine en la sesión, sea INFO o cualquier otra. Por su naturaleza este método puede soportar, con adaptaciones, las funciones de los mensajes de los protocolos RNL. Dado que SDP (Session Description Protocol) fue concebido para describir sesiones multicast de medios, no es válido para soportar en el cuerpo de mensajes INFO los contenidos de los mensajes de los protocolos RANAP, NBAP y RNSAP. Para esto la solución es: - extender SDP, o - definir nuevos tipos MIME (Multipart Internet Mail Extension), o - desarrollar un protocolo (una sintaxis) de descripción de mensajes de señalización. Red de Acceso Radio () Iub RNC Iur Iub RNC Iu IWF MSC SGSN Figura 5: Contexto de actuación de los protocolos RNL Núcleode Red (CN) También debe valorarse la posibilidad de que algunos mensajes S-RANAP/NBAP/RNSAP puedan ser sustituidos por determinadas mensajes de respuestas S (códigos de estado S) 3

4 Requerimientos para sesiones de señalización S-RANAP/NBAP/RNSAP La utilización de S para sesiones de señalización necesita declarar o establecer los siguientes elementos: - que se trata de una sesión S para señalización, y no una sesión para medios (voz, vídeo, etc.), - protocolo de señalización (RANAP, NBAP, RNSAP), - procedimiento del protocolo de señalización en cuestión, y - mensaje del protocolo de señalización. El primer elemento, sesión de señalización, debe estar contenido en cabeceras del mensaje INVITE, definidas o por definir. El segundo elemento, el protocolo de señalización de que se trate, puede estar contenido en un mensaje INVITE o en mensajes INFO, en cabeceras (definidas o por definir) o en el cuerpo del mensaje. El tercer elemento, el procedimiento, de ser necesario, igualmente aparecería en un mensaje INVITE o en mensajes INFO, en cabeceras (definidas o por definir) o en el cuerpo del mensaje. El cuarto elemento, es decir, los mensajes del protocolo a través de los cuales se desarrolla éste, se declararían en mensajes INFO, a través de las cabeceras y cuerpo de éstos. Por ejemplo, a través de las cabeceras se podría identificar el mensaje como tal, y el cuerpo soportaría el contenido del mensaje de señalización. En la tabla 1 se muestran las tres opciones que en principio pueden ser consideradas, de acuerdo a lo antes planteado. Declaración Opción 1 Opción 2 Opción 3 Sesión S de Señalización INVITE INVITE INVITE Protocolo de Señalización INVITE INVITE INFO Procedimiento de INVITE INFO INFO Señalización Mensaje de Señalización INFO INFO INFO Tabla 1: Opciones de declaración de elementos para sesiones de señalización S- RANAP/NBAP/RNSAP Opción 1: condiciona el establecimiento de sesión S de señalización por cada procedimiento de determinado protocolo, es decir, relaciona sesión S de señalización con el par protocolo procedimiento. Opción 2: condiciona el establecimiento de sesión S de señalización por cada protocolo de señalización, esto es, relaciona sesión S de señalización con un protocolo. Opción 3: condiciona el establecimiento de sesión S de señalización para cualquier protocolo. Teniendo en cuenta que para que un par de nodos asociados a la nube --Iu-Iub-Iur (figura 4) puedan dialogar en base a lo antes establecido, es decir, desarrollar los diálogos de señalización correspondientes a los protocolos RANAP/NBAP/RNSAP a través del protocolo S, se necesita establecer una sesión S, lo que solo se puede iniciar con el método INVITE, y que además, entre un par determinado de estos nodos solo se requiere dialogar con un único protocolo (RANAP, NBAP o RNSAP), entonces la opción 2 de la tabla 1 parece ser la adecuada para este propósito. Sobre la base del mismo razonamiento, se puede concluir que la opción 3 no es adecuada para estos fines, independientemente de que los nodos RNC deban tener la capacidad de diálogo en base a los tres protocolos de señalización indicados. Finalmente, la opción 1 no es descartable en principio, pero sugiere pensar que conduce a una mayor carga de tráfico de señalización y a relentizar el proceso de señalización en comparación con la opción 2. Apertura de sesiones S- RANAP/NBAP/RNSAP Para la apertura de sesiones de señalización S-RANAP/NBAP/RNSAP se deben utilizar los mensajes INVITE, 200 y ACK. Se trata de establecer sesiones de señalización referente a los protocolos RNL entre sendos UA s empotrados en nodos UMTS. En este caso la negociación de la sesión S pudiese resultar más ligera que en el caso de sesiones de medios (voz, etc.), pues ahora se trata de entes que van a dialogar, por intermedio de S, en base a un protocolo de señalización específico, por lo que la negociación de sesión en este caso debe versar únicamente en relación con la solicitud de establecer sesión de señalización respecto a determinado protocolo RNL, y los UA s deben conocer de antemano los parámetros de la sesión. La apertura de una sesión de señalización S- RANAP/NBAP/RNSAP debe comenzar declarando dos cosas: 4

5 - naturaleza de la sesión (sesión de señalización S- RANAP/NBAP/RNSAP), y - medio a intercambiar (protocolo RNL ) Para esto se pueden abordar dos posibles soluciones, declarando la sesión a través de cabeceras S o a través del cuerpo de estos mensajes S, con SDP u otra sintaxis descriptiva. El primero conduce a extensiones S, y el segundo a extensiones SDP. La tercera posible solución implica definir una nueva sintaxis. Declaración de sesión en base a cabeceras Con el método INVITE, las cabeceras propias de éste, más cabeceras que posibiliten declarar que se trata de una sesión de señalización para cierto protocolo RNL, puede bastar como invitación de inicio de sesión. Con las cabeceras Subject (indica la naturaleza de la sesión) y Accept (indica el tipo de medios aceptados en la respuesta) puede ser posible realizar ambas declaraciones, sesión S de señalización y protocolo RNL, respectivamente. Para esto se requieren las correspondientes extensiones S en relación con los contenidos de estas cabeceras y la funcionalidad que se pretende adicionar. Como es lógico, también deben estar presentes en esta solicitud las cabeceras Call-ID, From, To, CSeq, Via y Content-Length. Este mensaje INVITE no necesita, en primera instancia, cuerpo de mensaje, pues con dichas cabeceras debe ser suficiente para cursar invitación a otro nodo en relación con una sesión S de señalización y el protocolo RNL que se requiera. La respuesta afirmativa a la solicitud INVITE, a través del mensaje de respuesta 200, tampoco debe contener cuerpo de mensaje. Lo mismo se desprende para el mensaje de confirmación ACK. No se requiere cuerpo de mensaje en ambos casos porque los contenidos de las cabeceras Subject y Accept deben ser suficientes para la negociación de la apertura de sesión. En consecuencia, los types SDP que normalmente S utiliza en el cuerpo de sus mensajes INVITE para solicitar iniciar sesiones multimedia, v, c, m, a, y por tanto la presencia del cuerpo de mensaje, no se requieren en el caso de sesiones S para señalización, por cuanto una vez aceptada y abierta la sesión S de señalización, de la manera antes indicada: puerto que lo han hecho antes los mensajes INVITE, 200 y ACK. ( type c ), - con las cabeceras Subject y Accept se suple la función de los types m y a, - el type v no tiene sentido si se obvia el cuerpo de mensaje tipo SDP Entonces, con las cabeceras Subject y Accept, y las extensiones relativas a éstas ya indicadas, se pudiera suplir el cuerpo de mensaje SDP en los mensajes INVITE y 200, o en los mensajes 200 y ACK, en la apertura de sesiones de señalización S-RANAP/NBAP/RNSAP. Declaración de sesión en base al cuerpo del mensaje Otra posible consideración es que la declaración de sesión S de señalización y protocolo RNL corra a cargo del cuerpo del mensaje con contenido SDP, o con contenido no SDP, excluyendo cabeceras para esto, y por tanto no utilizando las cabeceras Subject y Accept y sus correspondientes extensiones en el sentido antes indicado. Cuerpo SDP En este caso, los types SDP necesarios son v, m, a, pues el type c no se requiere de acuerdo a lo ya antes señalado, esto es, los mensajes S que soportarán los correspondientes mensajes de los protocolos RNL se cursarán a través de los puntos de conexión (dirección y puerto) por donde se cursen los mensajes de apertura de la sesión. Los types m y a tienen que ser extendidos para esta finalidad (señalización), o definir nuevos types SDP para protocolos de señalización soportados en S. En cualquier caso, se trata de extensiones al protocolo SDP. Cuerpo no SDP Se trata del caso antes comentado, es decir, un protocolo para describir sesiones de señalización. Estaría por definir. En cualquier caso, la declaración de sesión S de señalización y protocolo RNL a través del cuerpo SDP o no SDP del mensaje INVITE, es posible que relentice, en cierta manera, los procesos de señalización, por cuanto el UA receptor del mensaje debe procesar el contenido del cuerpo del mensaje en aras de conocer la naturaleza de la sesión, a diferencia de la declaración en base a cabeceras, pues en ésta dicha información está contenida en sendas cabeceras. - ésta seguirá desarrollándose a través del mismo punto de conexión, esto es, a través de la misma dirección y 5

6 Conclusiones Se han expuesto aspectos básicos en relación con la posibilidad de utilizar S como protocolo de señalización en la red de acceso de sistemas UMTS, en aras de armonizar protocolos en la RAN siguiendo estándares del IETF. Por su naturaleza, son indispensables para este fin los métodos S INVITE, ACK, BYE, CANCEL e INFO. Este último se vislumbra como el tipo de mensaje S adecuado para soportar, básicamente en su cuerpo, los contenidos de información correspondientes a los mensajes de los protocolos de señalización RNL. Como requisito básico para sesiones de señalización S- RANAP/NBAP/RNSAP se debe declarar, en la apertura de ésta, su naturaleza (señalización) y el protocolo RNL a suplir con S. Ésto, a través de cabeceras (extensiones S) o a través del cuerpo del mensaje de solicitud INVITE (extensiones SDP o sintaxis descriptiva no SDP). Bibliografía y referencias 1. 3GPP TR v1.5.1 (2001). Transport in Work Task Technical Report. Diciembre GPP TS v (2001). Bearer Independent CS. Junio GPP TS v5.0.0 (2001). Multimedia (IM) Subsystem-Stage 2 (Release 5). Abril GPP TS v1.1.0 (2001). Signalling flows for the multimedia call control based on S and SDP; stage 3. Junio GPP TS v0.4.0 (2001). Multimedia Call Control Protocol based on S and SDP. Julio DONOVAN, R. (2000). The S INFO Method. RFC IETF, Octubre HANDLEY, M., SCHULZRINNE, H., SCHOOLER, E., ROSEMBERG, J. (1999). S: Session Initiation Protocol. IETF RFC MORENO, M., ALVAREZ-CAMPANA, M. y VINYES, J. (2002). S en la parte de sistemas UMTS: algunas consideraciones. Conferencia Internacional TELEC 02, Santiago de Cuba, Julio ROSENBERG, J., SCHULZRINNE, H. y CAMARILLO, G. (2001). SCTP as a Transport for S. Specification Internet Draft, IETF, draft-ietf-sip-sctp-01.txt. Noviembre Expira Mayo Siglas utilizadas 3GPP: 3ª Generation Partnership Project AAL: ATM Adaptation Layer ATM: Asynchronous Transfer Mode BSS: Base Station Subsystem BSSMAP: BSS Management Appl. Part BTS: Base Transceiver Station BTSM: BTS Management CN: CS: Circuit Switched GPRS: General Packet Radio Service GSM: Global System for Mobiles IETF: Internet Engineering Task Force IMS: Multimedia Subsystem : Internet Protocol MIME: Multipart Internet Mail Extension MSC: Mobile Switching Centre MTP3b: Message Transfer Part level 3- broadband NBAP: Node B Application Part NNI: Network-Node Interface Protocol PS: Packet Switched RAN: Radio Access Network RANAP: RAN Application Part RNC: Radio Network Controller RNL: Radio Network Layer RNS: Radio Network Subsystem RNSAP: RNS Application Part RTC: Red Telefónica Conmutada SAAL: Signalling ATM Adaptation Layer SCCP: Control Signalling Connetion Part SCTP: Stream Control Transmission Protocol SDP: Session Description Protocol SGSN: Serving GPRS Support Node S: Session Initiation Part SS7: Signalling System number 7 SSCF: Service Specific Coordination Function SSCOP: Service Specific Connection Oriented TDM: Time Division Multiplex UA: User Agent UDP: User Datagram Protocol UE: User Equipment UMTS: Universal Mobile Telecomunications UNI: User-Network Interface : UMTS Terrestrial Radio Access Autores Manuel Moreno Martín (mmoreno@cipres.upm.es), Ingeniero Electricista, Universidad de Oriente, Santiago de Cuba, 1981.Profesor del Dpto. de Telecomunicaciones y Electrónica, UO. Desarrolla su tesis doctoral en temas a fines a señalización Vo y redes móviles, en la ETSI de Telecomunicación de la Universidad Politécnica de Mandrid. Manuel Álvarez-Campana Fernández- Corredor (mac@dit.upm.es), Doctor Ingeniero de Telecomunicación (ETSIT-UPM, 1995). Profesor del Departamento de Ingeniería Telemática de la Universidad Politécnica de Madrid. Actualmente su interés se centra en los sistemas de comunicaciones móviles de tercera generación UMTS. Joan Vinyes Sanz (vinyes@dit.upm.es), Doctor Ingeniero de Telecomunicación (ETSIT-UPM, 1980). Catedrático de Ingeniería Telemática de la Universidad Politécnica de Madrid. Sus líneas de actividad actuales se centran en sistemas móviles celulares y telefonía. 6