ES2704636T3 - Distribución troncal eficiente del MBMS usando el planteamiento de un solo túnel - Google Patents

Abstract

Dispositivo (23) de pasarela de telecomunicaciones para facilitar la distribución de servicios de difusión/multidifusión multimedia, MBMS, en una red (20, 400) de telecomunicaciones, en donde el dispositivo (23) de pasarela de telecomunicaciones es conectable a un nodo (24) de servicio por medio de una interfaz de control y una interfaz troncal, y en donde el dispositivo (23) de pasarela de telecomunicaciones está adaptado para: - recibir un mensaje de inicio de sesión de MBMS desde un centro (2) de servicio de difusión/multidifusión; - enviar tráfico de control, por medio de la interfaz de control, en una red de control al nodo (24) de servicio; - recibir un identificador de punto extremo de túnel común, cTEID, desde un dispositivo de infraestructura; - enviar como tráfico de control al nodo (24) de servicio un mensaje de solicitud de inicio de sesión de MBMS que incluye el cTEID y una dirección de multidifusión del Protocolo de Internet, IP, para distribución troncal; - recibir información del nodo (24) de servicio, que indica que el nodo (24) de servicio acepta usar la multidifusión IP; y - enviar, por medio de la interfaz troncal, un paquete (600) de datos en una red troncal (21) de multidifusión IP para su recepción por parte de anfitriones que se han unido a un grupo de multidifusión usando el cTEID, en donde el paquete (600) de datos comprende un encabezamiento (601) con la dirección de multidifusión IP, el cTEID (602), una dirección (603) de Multidifusión de MBMS y una carga útil (604) con datos de contenido de medios, y en donde el grupo de multidifusión está asociado a la dirección de multidifusión IP.

Description

DESCRIPCIÓN

Distribución troncal eficiente del MBMS usando el planteamiento de un solo túnel

Campo técnico

La presente invención se refiere al área del Servicio de Difusión/Multidifusión Multimedia (MBMS) y, en particular, a una función mejorada para la entrega de carga útil del MBMS en una red central GPRS.

Antecedentes de la invención

La multidifusión es un servicio que permite que fuentes envíen una única copia de los mismos datos a una dirección que consigue que los datos se entreguen a múltiples destinatarios. En la multidifusión, solamente una copia de un mensaje pasará a través de cualquier enlace en una red, y se realizarán copias del mensaje únicamente en donde los trayectos diverjan. Desde la perspectiva de la red, la multidifusión reduce drásticamente el consumo global de ancho de banda, puesto que los datos se duplican en la red en puntos adecuados en lugar de en los sistemas finales.

En caso de que la multidifusión se use en una red de Protocolo de Internet IP, entonces se le denomina multidifusión IP. Con la multidifusión del Protocolo de Internet IP, no es necesario que los receptores sepan quiénes son los emisores o dónde se encuentran para recibir tráfico de ellos, y no es necesario nunca que los emisores sepan quiénes son los receptores. Ni los emisores ni los receptores necesitan preocuparse por la topología de la red, en la medida en la que la red optimiza la entrega. También existen planteamientos alternativos en los que el receptor conoce al emisor, según se describe en RFC 4607 “Source-Specific Multicast for IP”. La distribución de la información por medio de la multidifusión IP se lleva a cabo sobre la base de una conexión jerárquica de los anfitriones, como, por ejemplo, un árbol. Se han propuesto varios algoritmos para construir árboles de distribución multidifusión, como, por ejemplo, árboles de expansión, árboles compartidos, árboles basados en la fuente, y árboles basados en núcleos. Las descripciones de los algoritmos correspondientes se pueden encontrar en “IP telephony: Packet-based multimedia communications systems”, de O. Hersent, D. Gurle, D. Petit, Addison-Wesley, Harlow, 2000. Después del establecimiento del árbol de distribución, el protocolo de encaminamiento multidifusión IP realiza la distribución de la información. La descripción detallada de los protocolos de encaminamiento multidifusión IP correspondientes también se pueden encontrar en el documento antes mencionado.

La multidifusión es un concepto basado en el receptor, lo cual significa que los receptores se unen a un grupo de sesión multidifusión particular informando a un rúter de multidifusión correspondiente, y el tráfico se entrega a todos los miembros de ese grupo por medio de la infraestructura de la red. Por lo tanto, dentro de la multidifusión IP, la membresía de un grupo de sesión multidifusión es dinámica lo cual significa que los anfitriones pueden unirse a los grupos y abandonarlos en cualquier momento. Para permitir que los anfitriones en las redes indiquen si desean unirse a un grupo de multidifusión particular o abandonarlo, existe un protocolo denominado Protocolo de Mensajes de Grupo de Internet IGMP. Este protocolo deja que el sistema conozca qué anfitriones pertenecen actualmente a qué grupo de multidifusión. Esta información es requerida por los rúters de multidifusión los cuales necesitan saber qué datagramas de multidifusión se van a reenviar a qué interfaz.

El IGMP forma parte de la capa IP y los mensajes IGMP se transmiten en paquetes de datos IP. La versión 1 del IGMP se describe en RFC 1112 “Host extensions for IP multicasting” de S. E. Deering, 1 de agosto, 1989, el documento RFC 2236 “Internet Group Management Protocol, Versión 2”, de W. Fenner, noviembre de 1997 describe la versión 2. El IGMP se ha desarrollado para el IP versión 4. En el Protocolo de Internet IP versión 6 existe un protocolo similar denominado Descubrimiento de Escuchantes de Multidifusión MLD, el cual se usa con el mismo fin que el IGMP. La descripción de la primera versión del MLD se puede encontrar en el documento RFC 2710 “Multicast Listener Discovery (MLD) for IPv6”, de S. Deering, W. Fenner, B. Haberman, octubre de 1999. No obstante, los mensajes usados en el MLD se corresponden con los mensajes IGMP. En lo sucesivo, se usará el IGMP como ejemplo. Aunque no debería limitarse al IGMP, la funcionalidad de la invención viene dada también por el uso del MLD.

En principio, el IGMP usa dos mensajes básicos para cumplir sus tareas, el informe de membresía y el mensaje de consulta de membresía, y se aplican las siguientes reglas. Las diferentes versiones del IGMP contienen mensajes adicionales.

Un rúter de multidifusión envía una consulta de membresía a intervalos regulares para comprobar si cualquier anfitrión sigue perteneciendo a cualquier grupo. El rúter debe emitir una consulta en cada interfaz. La dirección del grupo en la consulta es 0 puesto que el rúter espera una respuesta de un anfitrión para cada grupo que contiene uno o más miembros en cada anfitrión. También es posible enviar una consulta de membresía para un grupo particular en lugar de para todos los grupos. Un anfitrión responde a una consulta IGMP enviando un informe IGMP para cada grupo que todavía contiene por lo menos un usuario. Un anfitrión se une a un grupo también enviando el informe de membresía.

Usando la información recibida mediante la aplicación de los mensajes de informe y de consulta, se establece una tabla con sus interfaces que tienen por lo menos un anfitrión en un grupo de multidifusión. Después de la recepción de los datos de multidifusión, el rúter reenvía los datos sobre cada interfaz, que tiene por lo menos un miembro. La multidifusión en Redes Públicas Terrestres de Telefonía Móvil PLMNs como el Sistema General de Radiocomunicaciones por Paquetes GPRS o el Sistema Universal de Comunicaciones Móviles UMTS requiere cierto desarrollo adicional, por ejemplo en relación con la movilidad de los usuarios y las características de la interfaz aérea. Además, la comunicación en una red de comunicaciones móviles como, por ejemplo, en el UMTS, es una comunicación de unidifusión. A la comunicación de unidifusión se le denomina también comunicación de punto-a­ punto. La comunicación de punto-a-punto significa el envío de un mensaje desde un único emisor a un único receptor. En una red de este tipo, en particular, en la red central, no se prevé la realización de una comunicación de multidifusión. La comunicación de grupo se implementa por medio de una comunicación de punto-a-punto que hace que un emisor transmita por separado paquetes a cada miembro del grupo. Para un grupo con n miembros, se requieren n paquetes en el trayecto total entre el emisor y los receptores, en lugar de un paquete cuando se usa la multidifusión.

A continuación, se proporciona una visión general de la arquitectura de la red del Sistema General de Radiocomunicaciones por Paquetes GPRS.

El GPRS es la mejora por conmutación de paquetes del Sistema Global para Comunicaciones Móviles GSM, el cual es una red por conmutación de circuitos. El GPRS también se ha ampliado para cubrir el Sistema Universal de Telecomunicaciones Móviles UMTS. La mejora por conmutación de paquetes GPRS significa que el usuario puede estar conectado permanentemente en línea pero debe de pagar únicamente por la transferencia de datos real. Para satisfacer los nuevos requisitos, se introducen algunos cambios en la GSM, entre otros nodos lógicos nuevos se introducen el Nodo de Soporte de Servicio GPRS (SGSN) y el Nodo de Soporte de Pasarela GPRS (GGSN). Las funciones principales del GGSN implican una interacción con redes por paquetes IP externas que proporcionan, por ejemplo, conexiones a Proveedores de Servicio de Internet ISPs. Desde el punto de vista de la red IP externa, el GGSN actúa como un rúter para las direcciones IP de todos los abonados a los que prestan servicio las redes GPRS. El GGSN también intercambia información de encaminamiento con la red externa. Cada GGSN presta servicio a una serie de SGSNs, los cuales se pueden disponer en forma de un árbol con el GGSN como raíz del árbol. El SGSN presta servicio a todos los abonados GPRS que están ubicados físicamente dentro del área de servicio geográfica del SGSN. Reenvía paquetes IP entrantes y salientes dirigidos hacia o desde una estación móvil. Para diferenciar entre la funcionalidad de estos nodos en el GSM y el UMTS se usan normalmente nombres extendidos, 2G-SGSN, 3G-SGSN y 2G-GGSN, 3G-GGSN. En la siguiente descripción no se distinguirá entre los nodos GPRS y UMTS.

Se encontrará una descripción detallada de la arquitectura en 3GPP TS 23.060 v7.2.0 (2006-09) 3.rd Generation Partnership Project; Technical Specification Group Services and System Aspects, General Packet Radio Service (GPRS), Service Description, Stage 2 (Release).

Con la introducción de la transmisión en flujo continuo y de los servicios multimedia conversacionales, muchos servicios nuevos de punto-a-multipunto evolucionarán. Algunos ejemplos de dichos servicios son la TV Móvil, la videoconferencia, las pizarras interactivas, los juegos multiusuario en tiempo real, la mensajería multimedia, los mundos virtuales. En particular, el operador de la red proporcionará un gran número de diferentes aplicaciones de multidifusión dentro de la red de telefonía móvil.

El servicio MBMS está diseñado para una entrega eficiente de servicios de multidifusión y difusión a grupos de usuarios en la red por conmutación de paquetes GPRS. A través de la multidifusión y la difusión sobre la interfaz de radiocomunicaciones en una célula, múltiples usuarios pueden recibir de una manera eficiente y simultánea la carga útil de, por ejemplo, un servicio de flujo continuo de TV sobre el mismo canal de radiocomunicaciones, lo cual ahorra recursos de radiocomunicaciones. El servicio se ofrece desde un nodo de control de la red central, el BM-SC. El servicio se establece a través de señalización de control en la red. Para un servicio de difusión MBMS, se construye un árbol de distribución geográfica sobre la base de una difusión “ciega” a una serie de células que pertenecen al Área de servicio, mientras que el servicio de multidifusión MBMS se construye dinámicamente mediante los usuarios que se unen al servicio y el árbol de distribución consistirá en los nodos y las células poblados por los usuarios que se unen a los mismos. Véase la figura 1. El protocolo de distribución en la red central es el protocolo GTP; la señalización y la carga útil son gestionadas, respectivamente, por el GTP-C y el GTP-U.

La Fig. 1 describe la situación de acuerdo con las soluciones conocidas. La red 1 de comunicaciones comprende un BM-SC 2 que se usa para difundir un servicio multimedia (a su vez, el BM-SC obtendrá contenido de medios de un servidor de contenido (no mostrado)), por lo menos un GGSN 3, 7 que se usa para distribuir los datos adicionalmente a lo largo de la cadena de comunicaciones, por lo menos un SGSN 4 y por lo menos un RNC 5. Unidades móviles (no mostradas) se comunican con el RNC por medio de un Nodo B (no mostrado). Un túnel GTP 6 establece de punto-a-punto desde el GGSN a cada SGSN implicado, y desde el SGSN a cada RNC implicado. El árbol de distribución MBMS que usa túneles GTP de punto-a-punto entre un GGSN y los SGSNs no es eficiente. Existe un problema con el método de distribución por el que el GGSN tendrá que duplicar la carga útil para muchos SGSNs (RNCs para OTS). Cada paquete de carga útil MBMS que entra en el GGSN puede tener que duplicarse y distribuirse a lo largo de entre 10 y 20 ó cualquier número elevado de SGSNs de aguas abajo. Esta duplicación de paquetes en el GGSN exigirá muchos recursos y puede ralentizar considerablemente el ^g G^s N. Muchos de estos paquetes duplicados se enviarán también sobre la misma interfaz y la misma conexión de salida, lo cual constituye un uso muy ineficiente de los recursos de la red. Es necesaria una gestión más eficiente de paquetes en el GGSN. De manera similar, cada paquete de carga útil MBMS que entra en el SGSN puede tener que duplicarse y distribuirse a lo largo de entre 10 y 20 ó cualquier número elevado de RNCs de aguas abajo. Esta duplicación de paquetes en el SGSN exigirá muchos recursos y puede ralentizar considerablemente el SGSN. Muchos de estos paquetes duplicados se enviarán también sobre la misma interfaz y la misma conexión de salida, lo cual constituye un uso muy ineficiente de recursos de la red. Es necesaria una gestión más eficiente de paquetes en el SGSN. En las solicitudes de patente US 20050007969, 20040246984, y 20060034278 se ha propuesto una primera solución para usar multidifusión IP con vistas a la distribución de carga útil de MBMS en la red central GPRS. Uno de los problemas de esta solución es que tiene un gran impacto sobre los nodos GSSN, SGSN y RNC existentes, en la medida en la que no se reutiliza la implementación del GTP-U. Otro problema es que los métodos propuestos no son aplicables en el servicio de Difusión MBMS. Los métodos propuestos presentan además dificultades de introducción en redes existentes, ya que no se ha descrito ningún mecanismo de repliegue desde la distribución multidifusión IP a la distribución heredada de punto-a-punto. En un estudio en curso del 3GPP, “One Tunnel study” notificada en la TR 23.809, se investida la posibilidad de eludir el SGSN con los túneles GTP-U. Todavía no se ha descrito cómo puede realizarse esto para el MBMS, pero se incluye en esta invención.

La introducción de la aplicación multidifusión en la capa de usuario requiere coordinación sobre la capa de transporte, en particular entre los nodos con respecto a la entrega de datos multidifusión. En PLMNs con múltiples GGSNs, no hay en la actualidad ningún mecanismo de coordinación y sincronización para grupos de multidifusión entre los GGSNs. De manera similar, no hay ningún mecanismo de coordinación o sincronización descrito para los TEIDs asignados por múltiples GGSNs utilizados para la distribución MBMS usando la multidifusión IP y GTP-U. Puede ocurrir, por lo tanto, que múltiples GGSNs en una PLMN estén tratando con el mismo grupo de multidifusión, lo cual da como resultado múltiples grupos de multidifusión y conexiones de multidifusión. Además, si la información de grupo de multidifusión se distribuye en la PLMN, el operador de la PLMN no dispone de ningunos medios para basar cualquier análisis en la membresía de grupo en la PLMN. Esto significa que el operador no puede restringir miembros adicionales o basar cualquier decisión de tarificación en la membresía de grupo total en la PLMN.

El documento VODAFONE GROUP, 3GPP DRAFT; R3-060456, “Support of MBMS in E-UTRAN” da a conocer cómo la arquitectura LTE/SAE soportará el MBMS. Cuando una sesión de multidifusión está preparada para ser entregada, el BM-SC o el UPE de Multidifusión entra en contacto con el controlador de multidifusión. En la opción a), el servicio de multidifusión IP de internet es activado por la recepción de paquetes de enlace descendente desde la dirección de multidifusión IP. En la opción b), el servicio de multidifusión MBMS controlado por el operador es activado por el BM-SC con el mensaje de Solicitud de Inicio de Sesión MBMS.

Sumario de la invención

La invención queda definida por las reivindicaciones 1,4, y 6 a 8.

El objetivo de la presente invención es proporcionar una solución para resolver al menos algunos de los problemas antes mencionados. Esto se prevé en una serie de aspectos en los cuales, en un primer aspecto se prevé un dispositivo de pasarela de telecomunicaciones para facilitar la distribución de servicios de multidifusión difusión multimedia, es decir, MBMS, en una red de telecomunicaciones, dispuesto con conjuntos de distribuciones para: recibir un mensaje de inicio de sesión MBSM desde un centro de servicio de difusión/multidifusión;

enviar tráfico de control en una red de control;

enviar como tráfico de control a un nodo de servicio un mensaje de solicitud de inicio de sesión MBMS e incluir un identificador de punto extremo de túnel común, es decir, cTEID, en el mensaje de solicitud de inicio de sesión MBMS;

recibir información del nodo de servicio indicando la aceptación de uso de la multidifusión IP;

enviar contenido de medios en una red troncal de multidifusión IP a anfitriones que se han unido al grupo de multidifusión usando el cTEID;

El dispositivo puede comprender, además, un conjunto de instrucciones para sincronizar el cTEID con otros dispositivos de la infraestructura con el fin de garantizar la unicidad del cTEID.

El dispositivo todavía puede comprender, adicionalmente, un conjunto de instrucciones para recibir un cTEID exclusivo de otro dispositivo de la infraestructura.

El dispositivo aún puede comprender, además, un conjunto de instrucciones para crear por lo menos un túnel de comunicación de red hacia por lo menos uno de un nodo de servicio y un nodo de control con fines relacionados con un repliegue.

En otro aspecto de la presente invención, se prevé un dispositivo de servicio de telecomunicaciones para facilitar la distribución de servicios de difusión multidifusión multimedia, es decir, MBMS, en una red de telecomunicaciones, dispuesto con conjuntos de instrucciones para:

recibir un mensaje de inicio de sesión de MBSM desde un dispositivo de pasarela de telecomunicaciones, que incluye un identificador de punto extremo de túnel común, es decir, cTEID;

enviar a un dispositivo de control un mensaje de solicitud de inicio de sesión de MBMS e incluir el identificador de punto extremo de túnel común, es decir, cTEID, en el mensaje de solicitud de inicio de sesión de MBMS; recibir información del dispositivo de control indicando la aceptación del uso de la distribución de multidifusión del Protocolo de Internet (IP);

El dispositivo de servicio puede comprender, además, un conjunto de instrucciones para enviar un mensaje de incorporación o mensaje de informe de membresía del protocolo de gestión de grupo de internet, es decir, IGMP, (IGMPv2 e IGMPv3) a una red troncal de multidifusión del Protocolo de Internet.

El dispositivo de servicio puede comprender, además, un conjunto de instrucciones para crear un túnel con vistas a la distribución de datos de carga útil si el dispositivo de control indica una no aceptación del uso de la distribución de multidifusión IP.

Todavía en otro aspecto de la presente invención, se prevé un dispositivo de control de telecomunicaciones para facilitar la distribución de servicios de difusión multidifusión multimedia, es decir, MBMS, en una red de telecomunicaciones, dispuesto con conjuntos de distribuciones para:

recibir, de un dispositivo de servicio de telecomunicaciones, un mensaje de inicio de sesión de MBMS que incluye un identificador de punto extremo de túnel común, es decir, cTEID;

enviar, al dispositivo de servicio, un mensaje de respuesta de inicio de sesión de MBMS con una indicación de que acepta una distribución de multidifusión del Protocolo de Internet;

enviar un mensaje de incorporación o mensaje de informe de membresía del protocolo de gestión de grupo de internet, es decir, IGMP, (IGMPv2 e IGMPv3) a una red troncal de multidifusión del Protocolo de Internet.

El dispositivo de control puede comprender, además, la etapa de enviar un mensaje de salida o mensaje de informe de membresía del protocolo de gestión de grupo de internet, es decir, IGMP, (IGMPv2 e IGMPv3) a una red troncal de multidifusión del Protocolo de Internet para cancelar la recepción de multidifusión (cuando se ha recibido un mensaje de Interrupción de Sesión de MBMS).

Todavía en otro aspecto de la presente invención, se prevé una red de infraestructura de telecomunicaciones para facilitar la distribución de servicios de difusión multidifusión multimedia, es decir, MBMS, que comprende:

un nodo de servicio de difusión/multidifusión, es decir, BM-SC;

un nodo de pasarela;

por lo menos un nodo de servicio; y

por lo menos un nodo de control;

en donde el BM-SC se conecta al nodo de pasarela el cual a su vez se conecta al nodo de servicio por medio de dos interfaces, una interfaz de control y una interfaz troncal, a su vez el nodo de control se conecta al nodo de servicio y/o al nodo de pasarela, y el nodo de pasarela está dispuesto con conjuntos de instrucciones para:

recibir un mensaje de inicio de sesión de MBSM desde el centro de servicio de difusión/multidifusión; enviar tráfico de control sobre la interfaz de control;

enviar como tráfico de control al nodo de servicio un mensaje de solicitud de inicio de sesión de MBMS e incluir un identificador de punto extremo de túnel común, es decir, cTEID, en el mensaje de solicitud de inicio de sesión de MBMS;

recibir información del nodo de servicio indicando la aceptación del uso de la multidifusión IP;

enviar contenido de medios en una red troncal de multidifusión IP a anfitriones que se han unido al grupo de multidifusión usando el cTEID;

La presente invención se prevé también en forma de un método para facilitar la distribución de servicios de difusión multidifusión multimedia, es decir, MBMS, en una red de telecomunicaciones, que comprende las etapas de: recibir en un nodo de pasarela un mensaje de inicio de sesión de MBSM desde un centro de servicio de difusión/multidifusión, es decir, BM-SC;

enviar tráfico de control en una red de control;

enviar como tráfico de control desde el nodo de pasarela a un nodo de servicio (24) un mensaje de solicitud de inicio de sesión de MBMS e incluir un identificador de punto extremo de túnel común, es decir, TEID común, en el mensaje de solicitud de inicio de sesión de MBMS;

recibir información del nodo de servicio indicando la aceptación del uso de la multidifusión IP;

enviar contenido de medios en una red troncal de multidifusión IP a anfitriones (25, 26, 31) que se han unido al grupo de multidifusión usando el TEID común;

El TEID común puede ser exclusivo para cada sesión de MBMS.

El método puede comprender, además, la etapa de sincronizar el TEID común con otros nodos de pasarela conectados al mismo BM-SC.

El anfitrión puede ser por lo menos uno de un nodo de servicio y un nodo de control;

El nodo de servicio puede ser un nodo de soporte de servicio GPRS, es decir, un SGSN, y el nodo de control es uno de entre un Controlador de Estaciones Base, es decir, BSC, y un Controlador de Red de Radiocomunicaciones, es decir, RNC.

El TEID común se puede identificar fijando al menos un bit de una estructura de TEID de manera que indique un estado activo.

El método puede comprender, además, la etapa de usar un procedimiento de repliegue que comprende establecer túneles GTP entre la pasarela y los nodos de servicio y entre los nodos de servicio y los nodos de control.

El método puede comprender, además, una etapa de unión del dispositivo de control a la red troncal de multidifusión IP que comprende enviar un mensaje indicativo del interés de unirse a la red troncal de multidifusión IP, pudiendo comprender la etapa de unión el envío de un mensaje de incorporación o mensaje de informe de membresía del protocolo de gestión de grupos de internet, es decir, IGMP, (IGMPv2 e IGMPv3) a una red troncal de multidifusión del Protocolo de Internet o usando un mensaje de descubrimiento de escuchantes de multidifusión, es decir, MLD. En otro aspecto de la presente invención, se prevé una señal para transportar un servicio de difusión multidifusión multimedia, es decir, MBMS, en una red de telecomunicaciones, que comprende una dirección de multidifusión del protocolo de internet, un identificador de punto extremo de túnel del protocolo de tunelización GPRS, una dirección de multidifusión de MBMS, y datos de contenido de medios.

Por medio de la invención, puede utilizarse, para el servicio MBMS, una distribución troncal eficiente entre un GGSN y un SGSN. Sin este método, el GGSN puede experimentar descargas elevadas por la copia de paquetes de MBMS a la interfaz Gn.

Breve descripción de los dibujos

En lo sucesivo se describirá la invención de una manera no limitativa y de forma más detallada en referencia a realizaciones ejemplificativas que se ilustran en los dibujos adjuntos, en los cuales:

la Fig. 1 ilustra esquemáticamente una topología de red de acuerdo con técnicas conocidas;

la Fig. 2 ilustra esquemáticamente una topología de red de acuerdo con la presente invención;

la Fig. 3 ilustra esquemáticamente un modelo de pila de protocolos de acuerdo con la presente invención;

la Fig. 4 ilustra esquemáticamente la topología de red de la Fig. 2 de manera más detallada; y

la Fig. 5 ilustra esquemáticamente, en un diagrama de bloques, un dispositivo de infraestructura de acuerdo con la presente invención.

La Fig. 6 ilustra esquemáticamente un paquete de datos de acuerdo con la presente invención;

la Fig. 7 ilustra esquemáticamente un procedimiento de Inicio de sesión de acuerdo con la presente invención; la Fig. 8 ilustra esquemáticamente un procedimiento de Interrupción de Sesión de MBMS de acuerdo con la presente invención;

la Fig. 9 ilustra esquemáticamente un Procedimiento de Baja de Registro de MBMS de acuerdo con la presente invención;

la Fig. 10 ilustra esquemáticamente un Procedimiento de Baja de Registro de MBMS iniciado por el BM-SC, de acuerdo con la presente invención;

Descripción detallada de realizaciones preferidas

En la Fig. 2, el numeral de referencia 20 indica de manera general una red de infraestructura de telecomunicaciones dispuesta para permitir servicios de difusión/multidifusión. Un centro de servicio de difusión/multidifusión (BM-SC) 2 está dispuesto para gestionar la difusión y/o multidifusión de contenido de medios suministrado desde un servidor de contenido de medios (no mostrado). El BM-SC está conectado a por lo menos un GGSN 23 (Nodo de Servicio de Pasarela GPRS) el cual, a su vez, está conectado a una red troncal 21 de multidifusión IP. En la red troncal de multidifusión IP, una serie de rutas 32, 33 y 34 encamina contenido de medios (es decir, la denominada carga útil) a RNCs 25, 26 (Controlador de Red de Radiocomunicaciones) que se han establecido como sujetos para la entrega de contenido de medios. En algunos casos, el RNC no puede recibir la carga útil directamente de una manera acorde a la presente invención; el tráfico de carga útil se envía, entonces, en primer lugar a un SGSN 31 (Nodo de Soporte de Servicio GPRS) el cual retransmite el tráfico de carga útil al RNC. Los SGSNs 24 no se usan para la distribución de carga útil si el RNC puede recibir directamente tráfico de carga útil. De acuerdo con la presente invención, la red troncal 29 de multidifusión IP se usa entre el GGSN 23 por medio de al menos un rúter 32 sobre la red troncal de multidifusión IP y cada RNC parte de la red de multidifusión. No obstante, en caso de que el RNC no forme parte de la red de multidifusión usando la presente invención el GGSN 23 enviará los datos sobre la red de multidifusión IP al SGSN 31 por medio de rúters en la red troncal, es decir, el SGSN 31 actuará como anfitrión en la red de multidifusión IP y el SGSN 31 establecerá un túnel 28 entre el SGSN 31 y el RNC 30. En caso de que el SGSN no soporte la presente invención, el GGSN tendrá que establecer un túnel GTP convencional 27 con el SGSN 31.

En lugar de hacer que el GGSN 23 duplique y envíe la carga útil de MBMS a una serie de SGSNs 24 usando una transmisión de túneles de punto-a-punto en la red troncal GPRS 21, sería preferible realizar una multidifusión IP desde el GGSN 23 sobre la red troncal. Se requiere establecer una distribución de multidifusión IP entre el GGSN 23 y los SGSNs 25, 26 (o directamente con RNCs que soportan la multidifusión IP). El GGSN necesitará, entonces, enviar solamente una copia del paquete de carga útil de MBMS a la red troncal GPRS, y los rúters en la red troncal de Multidifusión IP gestionarán la duplicación y la distribución de paquetes a los SGSNs, véase la Fig. 2.

El RNC 30 de más a la izquierda en la anterior Fig. 2 no soporta la distribución de multidifusión IP y, por lo tanto, sí que obtiene la carga útil de MBMS por medio de una unidifusión de MBMS normal desde el SGSN 31. Todos los RNCs 25 bajo el SGSN de más a la derecha de la Fig. 2 soportan la distribución de multidifusión IP y, por lo tanto, no es necesario que el SGSN 24 forme parte del árbol de distribución (de plano de usuario) en absoluto, sino que únicamente es parte del plano de control del establecimiento de la comunicación.

La Fig. 4 ilustra una red similar a la que se describió en la Fig. 2, con la diferencia de que se indican también un servidor 416 de contenido de medios en las estaciones móviles 406, 407 y 408. En la Fig. 4, el numeral de referencia 400 indica la configuración de la red de infraestructura. Un servidor 416 de contenido de medios envía contenido de multidifusión, por medio de una conexión 415, a un BM-SC 401 el cual tiene el control del servicio de multidifusión. El BM-SC envía información de control de multidifusión y de plano de usuario, por medio de una conexión 414, a un GGSN 402 el cual, a su vez, envía tráfico de plano de control a los SGSNs 404 de la red por medio de conexiones 412 de plano de control. Cuando se establecen conexiones, la información de plano de usuario se transmite 413 por medio de la red troncal 415 de multidifusión IP a través de por lo menos un rúter 403 en la red troncal o bien directamente 417 a cada RNC 405 que tiene implementada la presente invención o bien indirectamente 418, 411 por medio de un SGSN 404. Los RNC's son responsables de transferir el tráfico de plano de usuario adicionalmente a las estaciones móviles 406, 407, 408. Las estaciones móviles pueden ser cualquier dispositivo de comunicaciones o dispositivo computacional adecuado con capacidades de comunicación, por ejemplo, aunque sin carácter limitativo, un teléfono móvil, un asistente personal digital (PDA), un ordenador portátil, un reproductor de MP3 o reproductor de DVD portátil (o dispositivos similares de contenido de medios), una cámara digital, o incluso dispositivos fijos, tales como un PC. Un PC también se puede conectar, por medio de una estación móvil, como estación final de los medios difundidos/multidifundidos.

El servicio de multidifusión troncal se utiliza únicamente para una distribución eficiente y no debe confundirse con el servicio de multidifusión de usuario.

A continuación se describirá más detalladamente la invención.

En la Fig. 3 se refleja una vista de la idea básica en relación con los protocolos. La Fig. 3 muestra la arquitectura de una red según se normalice en el 3GPP. No obstante, esto no debería considerarse como una restricción para la invención. La Fig. 3 muestra una situación en la que una estación móvil MS se comunica a través de la interfaz Uu con una red de acceso UTRAN. La interfaz Iu-PS conecta la UTRAN con un 3G-SGSN, el cual se comunica, a través de la interfaz Gn, con el 3G-GGSN. La Fig. 3 proporciona una visión general de las diferentes pilas de protocolos en los diferentes nodos usados en el UMTS. La siguiente descripción se concentra meramente sobre las dos capas IP en el dominio por conmutación de paquetes, representadas como IP, PPP y UDP/IP, y sobre la capa GPT-U. En la Fig. 3, se mencionan los otros protocolos por razones de complementariedad.

Los anteriormente mencionados requisitos y restricción para la funcionalidad y forma de comunicación de los nodos introducidos orientados a la conmutación por paquetes, como el SGSN o el GGSN, tienen su impacto sobre las pilas de protocolos desarrolladas. Como consecuencia de la función del GGSN como rúter y como interfaz con las redes externas, se ha introducido la capa IP por debajo de la capa de aplicación. Además, debido a la restricción de tener una red IP entre el GGSN y el SGSN, se introduce una conexión lógica IP como medio de transporte, por debajo de la capa GTP-U.

Por lo tanto, con respecto a la Fig. 3, existen dos capas IP, en lo sucesivo descritas como IP de aplicación y capa IP de transporte. La capa IP de aplicación está situada en la pila de protocolos directamente debajo de los protocolos de aplicación, Aplicación, y conectando la estación móvil y el 3G-GGSN. Esta capa IP es transparente a la red por conmutación de paquetes, esto se representa en la Fig. 3 con una línea directa que va desde la MS al 3G-GGSN. La segunda capa IP es la capa IP de transporte usada para la transmisión entre el SGSN, el GGSN y la UTRAN. El tráfico de carga útil se transporta a través de la Gn encapsulado en un protocolo de tunelización específico de cada aplicación, el protocolo de Tunelización GPRS GTP, el cual es un ejemplo de un protocolo de capa de transporte para la tunelización. Los paquetes GPT usan el UDP como protocolo de transporte. No obstante, existen diferentes protocolos de tunelización, los cuales son responsables de la construcción de un túnel. El GTP es meramente un ejemplo y no debe considerarse como limitativo con respecto a la invención.

La capa UDP/IP marcada usará el servicio de Multidifusión IP con los cambios propuestos aquí. Puede observarse que la invención que usa el direccionamiento de multidifusión IP en la capa UDP/IP marcada, es decir, la capa IP de transporte, no cambia la pila de protocolos 3GPP normalizada actual. De esta manera, se minimiza el impacto sobre los nodos cuando se implementa la distribución de multidifusión IP. La función de reenvío de paquetes en nodos de soporte de MBMS no se ve en esencia afectada cuando se introduce la distribución de multidifusión IP.

Señalización para la distribución de multidifusión IP para el MBMS

1. El BM-SC inicia un servicio MBMS enviando un Inicio de Sesión al GGSN, que incluye parámetros para el MBMS.

2. El GGSN envía una solicitud de Inicio_Sesión_MBMS a todos los SGSNs de su “Lista de nodos de aguas abajo” (alternativamente el BM-SC puede proporcionar una lista de RNCs en el parámetro de “Lista de nodos de aguas abajo” en el mensaje de Inicio de Sesión al GGSN. A continuación, el GGSN (o el nodo de servicio correspondiente) enviaría directamente una señalización al RNC, usando una interfaz Iu nueva. Esto no existe en la arquitectura actual de la CN 3GPP pero puede existir en arquitecturas futuras del 3GPP, por ejemplo, en la Red Central por Paquetes Evolucionada del estudio de la SAE del 3GPP), e incluye una “dirección de Multidifusión IP para distribución troncal” propuesta (IE GTP nuevo), y también un TEID-U común propuesto (IE GTP nuevo). Si se usa la Multidifusión-Específica-Fuente, en el IE GTP nuevo se incluye también una “Dirección para fuente de multidifusión” (por ejemplo, el GGSN). El GGSN seleccionará este TEID-U común propuesto de manera que sea exclusivo para cada servicio MBMS con el fin de garantizar que los nodos receptores (RNC y 2G-SGSN) reciben TEIDs exclusivos para cada servicio MBMS.

3. El SGSN acepta el Inicio de sesión y envía una respuesta de Inicio_Sesión_MBMS al GGSN, que incluye una indicación de que se acepta la distribución de Multidifusión IP y fija el IE de Dirección del SGSN para Plano de Usuario a la “dirección de Multidifusión IP para distribución troncal” recibida del GGSN.

• Si un SGSN no acepta la dirección de Multidifusión IP propuesta para la distribución troncal (o el TEID-U propuesto), lo indicará incluyendo una Dirección de SGSN para tráfico de usuario de unidifusión ordinaria y un TEID-U en la respuesta de Inicio_Sesión_MBMS.

El SGSN envía un mensaje de solicitud de inicio de sesión de MBMS a cada RNC (o BSC) conectado aguas abajo, y recibe una respuesta de inicio de sesión de MBMS con una indicación de que se acepta la multidifusión IP.

• Si un RNC no acepta la Dirección de multidifusión IP para distribución troncal propuesta (o el TEID-U propuesto), el SGSN lo indicará incluyendo una dirección IP de RNC para tráfico de usuario, de unidifusión, ordinaria, y un TEID-U en la respuesta de Inicio_Sesión_MBMS.

4. El SGSN envía un mensaje de IGMP (IPv4) o mensaje de MLD (IPv6) a la red troncal de multidifusión IP para unirse a la multidifusión de distribución. Este puede ser un mensaje IGMPv3 ó MLDv2, por ejemplo, cuando se usa la SSM (RFC 4604).

5. El GGSN puede enviar únicamente una copia de la carga útil de usuario de MBMS a la red troncal, en donde se efectúa la duplicación de los paquetes y los mismos se distribuyen a los SGSNs, con la dirección “dirección de multidifusión IP para distribución troncal”

6. Cuando el SGSN recibe la carga útil en la dirección “dirección de Multidifusión IP para distribución troncal”, el SGSN comprueba el TEID-U y encuentra el Contexto_Portador_MBMS asociado y envía el paquete usando el método de MBMS habitual en dirección descendente a los RNCs.

El GGSN puede seleccionar de manera ventajosa el TEID-U común propuesto de manera que sea exclusivo para cada servicio/sesión de MBMS con el fin de garantizar que los nodos receptores (RNC y 2G-SGSN) reciben TEIDs exclusivos para cada servicio MBMS. Usando el mensaje de solicitud de Inicio_Sesión_MBMS se garantiza que el sistema puede tratar con configuraciones tanto de difusión como de multidifusión.

Si hay múltiples GGSNs que proporcionan servicios MBMS, estos GGSNs usarán diferentes TEID-Us comunes. Este TEID-U común y las direcciones de Multidifusión IP usadas se pueden sincronizar mediante

a) configuración en los GGSNs, y/o

b) señalización entre GGSNs, y/o

c) función de asignación de TEID en un dispositivo de red aparte, por ejemplo, un BM-SC, y señalización desde el dispositivo de red aparte a los GGSNs.

Si un SGSN o RNC recibe una Solicitud de Inicio de Sesión con un TEID-U común que ya se usa en el SGSN o RNC, el nodo se replegará al plano de usuario de MBMS Rel-6 asignando un TEID-U nuevo y devolviendo el mismo en la Respuesta de Inicio de Sesión en lugar del TEID-U Común propuesto.

Para evitar en su totalidad TEID-Us en conflicto y el subsiguiente repliegue al plano de usuario de MBMS Rel-6, se puede usar una división del espacio de TEID-U. Esto se puede realizar, por ejemplo, asignando uno de los 32 bits en el TEID-U de manera que indique MBMS. A continuación, ese bit se fijará siempre en TEID-Us comunes asignados por GGSNs, pero nunca en TEID-Us asignados internamente en SGSNs o RNCs.

Debe indicarse que este método es igualmente válido para la OTS (Solución de Un Solo Túnel, en donde la comunicación de plano de usuario (es decir, carga útil) se comunica directamente entre el GGSN y el RNC según se describe en TR 23.873), con la adición de que el SGSN informa al GGSN sobre si el RNC ha aceptado la Dirección de Multidifusión IP propuesta y el TEID-U común propuesto, e informa al RNC sobre la “Dirección de Multidifusión IP para distribución troncal” y sobre el TEID-U común a usar para la recepción de carga útil de MBMS para el servicio de MBMS particular (IE nuevo/impacto en el RANAP). A continuación, el RNC debe enviar un mensaje IGMP (IPv4) o un mensaje MLD (IPv6) a la red troncal con el fin de recibir la carga útil del GGSN. Además, en este caso, el SGSN debe proporcionar al GGSN una lista de direcciones IP de RNC y TEID's de RNC para todos los RNCs que no aceptan la multidifusión IP.

Debe indicarse, además, que la única diferencia entre el modo de multidifusión MBMS y el modo de difusión MBMS se encuentra en cómo se construye el árbol de distribución y, en particular, la “Lista de Nodos de Aguas Abajo” del GGSN. En el modo de difusión de MBMS, la lista se recibe del BM-SC. En el modo de multidifusión de MBMS, la misma se construye mediante solicitudes de Registro_MBMS recibidas de SGSNs con móviles (MS) que desean unirse a una sesión de multidifusión.

Debe indicarse, además, que la solución funcionará también para la OTS con desplazamiento itinerante, puesto que el GGSN doméstico tratará al GGSN visitado (xGGSN, es decir, GGSN Proxy) como un SGSN (para la ^o T^s que usa el método de GGSN Proxy). Es el xGGSN el que inicia la multidifusión IP en su propia red troncal. Es decir, el GGSN Proxy puede escoger no usar el transporte de multidifusión sobre la red externa (es decir, GRX), y, entonces, el GGSN Proxy devolverá su propia dirección IP y su propio TEID para obtener la carga útil de MBMS a través de un túnel de unidifusión GTP-U MBMS tradicional. La multidifusión entre dominios de red de operadores diferentes debería evitarse debido a problemas tanto de seguridad, como técnicos y de tarificación. El método antes descrito para desplazamientos itinerantes puede funcionar de esta manera para especificaciones de redes centrales de telefonía móvil del 3GPP de la siguiente generación, conocidas también como SAE, donde el Anclaje Visitado adopta el papel del GGSN Proxy. Otro método que puede funcionar para desplazamientos itinerantes es si una PLMN dispone de un Rúter de Borde en la frontera con la GRX, el cual actúa para recibir unidifusión desde la PLMN Doméstica y enviar multidifusión dentro de la PLMN Visitada. Un tercer método puede ser que, con el uso del SSM, Protocolo de multidifusión encaminado por la fuente, puede resultar aceptable utilizar el transporte de Multidifusión IP incluso entre PLMNs.

La solución funcionará para una ISRAU en el caso de Multidifusión, puesto que el GGSN enviará siempre una solicitud de Inicio_Sesión_MBMS al SGSN nuevo.

Contextos de portadores MBMS

El GGSN mantiene Contextos_Portador_MBMS para los servicios MBMS. Con el método propuesto, el GGSN mantendrá un Contexto_Portador_MBMS común para todos los nodos de aguas abajo para un servicio.

Como ejemplo: un Contexto_Portador_MBMS para un servicio 001, en donde los SGSNs 2, 3 y 4 han aceptado pertenecer al árbol de distribución de Multidifusión IP, puede tener el siguiente aspecto (Obsérvese que el SGSN 1 ha rechazado pertenecer a la distribución de Multidifusión IP, y el GGSN debe copiar paquetes individualmente al SGSN 1):

MBMS_Bearer_Content_001

APN = MBMS APN 01

List_of_Downstream_Nodes {

SGSN 1

IP-address 192.168.100.10 TEID-U 10

SGSN 2, SGSN 3, SGSN 4

Multicast-address 239.192.200.21 TEID-U 11

}

El GGSN tendrá un TEID-C por SGSN y Contexto_Portador_MBMS. (Un TEID-C por SGSN y Contexto_Portador_MBMS para la Ot S). El GGs N tiene un TEID-U común por Contexto_Portador_MBMS para todos los nodos de aguas abajo que aceptan la Multidifusión IP (propuestos por el GGSN). El GGSN tiene un TEID-U por SGSN/RNC de unidifusión y Contexto_Portador_MBMS.

Otro ejemplo cuando, para la distribución de multidifusión IP, se usa la Multidifusión Específica de la Fuente (SSM) según la RFC 4607 y la RFC 4604, y se usa la tunelización directa (Un Solo Túnel) del GGSN al RNC, un Contexto_Portador_MBMS para un servicio puede tener el siguiente aspecto:

MBMS_Bearer_Context_001

APN = MBMS APN 01

List_of_Downstream_Nodes {

SGSN 1

IP-address 192.168.100.10 TEID-U 10

SGSN 2, SGSN 4, RNC, 31, RNC, 32, RNC 33

Multicast-address 232.192.200.21 TEID-U 11

Address-to-multicast-Source 192.168.111.21

}

Gestión de errores

Cuando un SGSN o RNC se reinicia o falla de alguna otra manera, el GGSN recibirá una indicación de Error, cuando el nodo que falle reciba un paquete de carga útil de enlace descendente para el cual no tiene ningún túnel GTP-U activo. Cuando se usa la multidifusión IP, el GGSN no podrá averiguar a partir de los campos de la indicación de Error, en qué SGSN (o RNC) se originó el mensaje.

No obstante, en la mayoría de los casos, si un SGSN (o RNC) rechaza recibir carga útil de MBMS, esto será debido a un reinicio o un fallo importante, por el que los contextos de PDP que fallan identificarán el nodo fallido.

Aparecería un problema especial solamente cuando un SGSN (o RNC para la OTS) acepte carga útil de contexto de PDP ordinaria, pero, por algún motivo, no acepte carga útil de MBMS, recibida por medio de una multidifusión IP, aún cuando ya ha enviado un mensaje IGMP (IPv4) o mensaje MLD (IPv6) a la red troncal de multidifusión IP. Este caso debería ser suficientemente infrecuente para que los dos siguientes remedios constituyan una solución suficiente.

Remedio en el caso de difusión: el GGSN, tras la recepción de una indicación de error no identificado, puede retransmitir la solicitud de Inicio_Sesión_MBMS a todos los SGSNs/RNCs de su lista de nodos de aguas abajo. Los SGSNs activos simplemente devolverán un acuse de recibo y aceptarán el mensaje sin ninguna acción adicional. Los SGSNs que fallen no responderán y se eliminarán de la “Lista de Nodos de Aguas Abajo” del GGSN para el Contexto_Portador_MBMS.

Remedio en el caso de multidifusión: no se permite ninguna retransmisión de la solicitud de Inicio_Sesión_MBMS. Todos los Contextos_UE_MBMS pertenecientes al SGSN que está fallando y este Contexto_Portador_MBMS serán borrados. No obstante, esto no será posible, a razón por la que estos Contextos_UE_MBMS seguirán permaneciendo hasta que se desactive el Contexto_Portador_MBMS.

En caso de que, por algún motivo, los remedios anteriores no sean aceptables, el GGSN tendría que inspeccionar el encabezamiento del datagrama IP que contiene la indicación de Error. Este encabezamiento contiene la dirección IP de unidifusión del SGSN que envió la indicación de Error.

Debe indicarse que un SGSN/RNC que falle debería enviar una Salida IGMP (IGMP Leave) a la red de multidifusión troncal. Si el nodo que falla envía una Salida IGMP, o señaliza de alguna otra manera a la red troncal de multidifusión IP que no desea recibir mensajes de enlace descendente de multidifusión, el GGSN no recibirá indicaciones de Error repetidas, incluso si el nodo que falla no se elimina de la “Lista de Nodos de Aguas Abajo” del GGSN.

El mecanismo periódico del IGMP “Solicitud de Consulta/Respuesta de Consulta” para comprobar si hay todavía escuchantes de una sesión de multidifusión acabará desactivando la entrega de carga útil transportada por multidifusión MBMS en la red troncal IP.

En caso de que el operador use múltiples GGSNs para MBMS, cada GGSN forma su propio árbol de distribución. Esto no difiere con respecto a cómo funciona ya en la actualidad. La diferencia es que la totalidad o parte del árbol de distribución ahora usará la multidifusión IP para el transporte.

Es ventajoso que las direcciones de multidifusión IP estén sincronizadas entre GGSNs usados para el MBMS. Además, el TEID-U común, de manera ventajosa, está sincronizado. Pueden usarse diferentes soluciones alternativas para esta sincronización:

• Configuración (configurar intervalos diferentes en GGSNs diferentes)

• Señalización entre GGSNs (para evitar direcciones y TEID-Us en conflicto)

• Función de sincronización en el BM-SC y señalización entre el GGSN y el BM-SC para la sincronización La solución antes mencionada del MBMS se implementa en una serie de nodos de infraestructura en forma de conjuntos de instrucciones en software. La Fig. 5 ilustra, en un diagrama de bloques esquemático, un nodo de infraestructura (GGSN, SGSN, o RNC) de acuerdo con la presente invención (por ejemplo, un nodo de soporte), en donde una unidad 501 de procesado gestiona datos de comunicación e información de control de comunicación. El nodo 500 de infraestructura comprende, además, una memoria volátil (por ejemplo, RAM) 502 y/o memoria no volátil (por ejemplo, un disco duro o disco flash) 503, y una unidad 504 de interfaz. El nodo 500 de infraestructura puede comprender, además, una unidad 505 de comunicaciones de sentido descendente y una unidad 506 de comunicaciones de sentido ascendente, cada una de ellas con una interfaz de conexión respectiva. Todas las unidades del nodo de infraestructura se pueden comunicar entre sí de manera directa o indirecta a través de la unidad 501 de procesado. El software para gestionar la comunicación hacia y desde las unidades móviles conectadas a la red se ejecuta al menos parcialmente en este nodo y se pueda almacenar también en el nodo; no obstante, el software también se puede cargar dinámicamente tras el arranque del nodo o en una fase posterior durante, por ejemplo, un intervalo de servicio. El software se puede implementar en forma de un producto de programa de ordenador y se puede distribuir y/o almacenar en un soporte extraíble y legible por ordenador, por ejemplo, un disquete, un CD (Disco Compacto), un DVD (Disco de Vídeo Digital), soportes de memoria extraíbles flash o similares (por ejemplo, compactflash, SD secure digital, memorystick, miniSD, MMC multimediacard, smartmedia, transflash, XD), HD-DVD (DVD de Alta Definición), o DVD Bluray, soportes de memoria extraíble basados en USB (Bus Serie Universal), soportes de cinta magnética, soportes de almacenamiento óptico, soportes magneto-ópticos, memoria de burbujas, o se puede distribuir como una señal propagada por medio de una red (por ejemplo, Ethernet, ATM, ISDN, PSTN, X.25, Internet, Red de Área Local (LAN), o redes similares con capacidad de transportar paquetes de datos al GGSN).

La Fig. 6 ilustra esquemáticamente un paquete 600 de datos de acuerdo con la presente invención. El paquete 600 de datos comprende un encabezamiento 601 con una dirección de multidifusión IP y un TEID GTP 602. En su interior se sitúa una dirección 603 de Multidifusión MBMS y, finalmente, la carga útil 604 con datos de contenido de medios.

Una ventaja de esta invención es que, para el servicio MBMS, puede usarse una distribución troncal eficiente entre un GGSN y un SGSN. Sin este método, en el GGSN pueden producirse descargas considerables por la copia de paquetes MBMS a la interfaz Gn.

Además, la solución cubierta en esta invención se centra en el dominio de conmutación por paquetes en una red GSM o UMTS. No obstante, la solución se puede aplicar de manera general a redes con 2 capas IP, un nivel IP de aplicación y un nivel IP de transmisión, tal como se corresponde con el caso en el que se aplica tunelización. En general, la idea se puede aplicar siempre que se usa la tunelización, por ejemplo, en GPT, L2T^p , IPSec, e IP Móvil. Además, para casos en los que la capa de transporte se basa en otra tecnología que soporta la transmisión de multidifusión, como, por ejemplo, ATM, pueden aplicarse los mecanismos.

Además, debe entenderse que pueden aplicarse los mismos mecanismos, por ejemplo, para crear un grupo de transporte de multidifusión para aplicación como el flujo continuo de punto-a-multipunto (RTSP) o los servicios multimedia conversacionales (SIP).

A continuación se describirá más detalladamente la invención en relación con cambios en la norma para el MBMS dentro del 3GPP: TS23.246.

La UTRAN/GERAN es responsable de entregar eficientemente datos de MBMS al área de servicio MBMS designada. Una entrega eficiente de datos de MBMS en el modo de multidifusión puede requerir mecanismos en la UTRAN/GERAN, por ejemplo, el número de usuarios dentro de una célula antes de y durante una transmisión de MBMS se podría usar para seleccionar un portador de comunicaciones adecuado. Las transmisiones de MBMS se pueden iniciar y terminar de manera intermitente. La UTRAN/GERAN soportará el inicio y la terminación de transmisiones de MBMS por parte de la red central. Además, la UTRAN/GERAN podrá recibir datos de MBMS desde la red central a través de portadores Iu compartidos por muchos UEs. La UTRAN también puede soportar la recepción de datos de MBMS desde la red central a través de una multidifusión IP. La UTRAN/GERAN soportará una movilidad de receptores de MBMS tanto intra-RNC/BSC como inter-RNC/BSC. Se espera que la movilidad provoque una pérdida limitada de datos. Por lo tanto, los servicios de usuario de MBMS deben poder hacer frente a una potencial pérdida de datos provocada por la movilidad de UE.

La UTRAN/GERAN podrá transmitir anuncios de servicio de usuario MBMS, información de búsqueda (no específica del MBMS) y soportará otros servicios en paralelo con el MBMS (por ejemplo, en función de las capacidades del terminal, el usuario podría dar origen a o recibir una llamada, o enviar y recibir mensajes mientras está recibiendo contenido de vídeo de MBMS).

El SGSN

El papel del SGSN dentro de la arquitectura MBMS es llevar a cabo funciones de control de servicio de portadores MBMS y proporcionar transmisiones de MBMS a la UTRAN/GERAN. En el caso de la Multidifusión M^b MS, las funciones de control de servicio de portadores de MBMS se llevan a cabo para cada UE individual. En el caso del modo de Difusión de MBMS, las funciones de control se llevan a cabo independientemente de los UEs. Cuando se usa la multidifusión IP para transmisiones de MBMS, el SGSN puede saltarse en el caso 3G, es decir, los datos MBMS se envían directamente del GGSN al RNC. El SGSN proporcionará soporte para procedimientos de movilidad intra-SGSN e inter-SGSN. Específicamente, esto requiere que el SGSN almacene un contexto de UE de MBMS específico del usuario para cada servicio portador de MBMS de multidifusión activado y que traslade estos contextos al SGSN nuevo durante procedimientos de movilidad inter-SGSN. El SGSN podrá indicar su soporte MBMS al UE, del mismo modo que podrá sincronizarse con el UE, cuyos contextos de UE de MBMS estén todavía activos. El SGSN podrá generar datos de tarificación por cada servicio portador de MBMS de multidifusión para cada usuario. El SGSN no lleva a cabo una tarificación en línea ni para el servicio portador de MBMS ni para el servicio de usuario de MBMS (esto es gestionado en el BM-SC).

El SGSN podrá establecer portadores Iu y Gn compartidos por muchos usuarios tras recibir un inicio de sesión desde el GGSN. De manera similar, el SGSN podrá suprimir estos portadores tras instrucciones del GGSN.

El GGSN

El papel del GGSN dentro de la arquitectura MBMS es prestar servicio como punto de entrada para tráfico de multidifusión IP como datos MBMS. Tras notificación del BM-SC, el GGSN podrá solicitar el establecimiento de un plano de portador para una transmisión MBMS de difusión o multidifusión. Además, tras notificación del BM-SC, el GGSN podrá suprimir el plano de portador establecido. El establecimiento del plano de portador para servicios de multidifusión se lleva a cabo hacia aquellos SGSNs y/o RNCs que han solicitado recibir transmisiones para el servicio portador MBMS de multidifusión específico. Para el servicio de difusión, el establecimiento del plano de portador se lleva a cabo hacia aquellos SGSNs y/o RNCs incluidos en la “Lista de nodos de aguas abajo” recibida desde un nodo de aguas arriba, en particular, en el GGSN, recibida del BM-SC. Para un plano de portador optimizado, puede usarse dentro de la red central el transporte de multidifusión IP. A continuación, el plano de portador se establece entre el GGSN y el SGSN y/o directamente entre el GGSN y RNCs.

El GGSN podrá recibir tráfico de multidifusión IP específico del MBMS, y encaminar estos datos a los túneles GTP apropiados y configurados como parte del servicio portador de MBMS.

El GGSN también puede proporcionar características que soporten el servicio portador de MBMS y que no sean exclusivas del MBMS. Son ejemplo de las mismas:

- Cribado de Mensajes (no necesario si las fuentes de la MBMS son internas en la PLMN);

- Recopilación de Datos de Tarificación;

- Tarificación Basada en el Flujo.

Contexto de portador de MBMS

El Contexto de Portador de MBMS, al que se hace referencia como Contexto de Servicio de MBMS en la RAN, contiene toda la información que describe un servicio portador de MBMS particular y se crea en cada nodo implicado en la entrega de los datos MBMS. Para el modo de Multidifusión de MBMS, se crea un Contexto de Portador de MBMS en el SGSN y GGSN cuando se crea el primer Contexto de UE de MBMS en el nodo o cuando un nodo de aguas abajo lo solicita. Para el modo de Difusión de MBMS, se crea un Contexto de Portador de MBMS en el SGSN y el GGSN cuando se recibe, desde un nodo de aguas arriba, el mensaje de Inicio de Sesión de MBMS. El Contexto de Portador de MBMS se configura estáticamente en la Función de Transporte y Proxy del BM-SC; la forma de llevar a cabo esto se sitúa fuera del ámbito de esta memoria descriptiva. El Contexto de Portador de MBMS se crea en el BSC modo Iu y en el SRNC cuando se crea un primer Contexto de UE de MBMS en el BSC/SRNC. El procedimiento de Inicio de Sesión de MBMS puede crear un Contexto de Portador de MBMS en un BSC/RNC que no disponga todavía de ningún Contexto de Portador de MBMS.

Un Contexto de Portador de MBMS, una vez creado, puede estar en uno de dos estados que reflejan el estado del recurso del plano de portador del servicio portador de MBMS correspondiente:

- “Activo”, refleja el estado de un Contexto de Portador de MBMS en el cual se requieren recursos de plano de portador en la red para la transferencia de datos MBMS. Este estado se mantiene siempre que haya una sesión MBMS correspondiente en curso.

- “En espera” refleja el estado de un Contexto de Portador de MBMS en el cual no se requiere ningún recurso de plano de portador en la red para la transferencia de datos MBMS. Este estado se mantiene siempre que no haya ninguna sesión de MBMS correspondiente en curso.

Calidad de servicio

Será posible que la red controle parámetros de calidad de servicio para sesiones de servicios portadores de MBMS de multidifusión y difusión. Todos los atributos de QoS relacionados con el servicio portador UMTS descrito en TS 23.107 son aplicables a servicios portadores de MBMS.

En comparación con los servicios portadores de punto-a-punto, existen las siguientes limitaciones:

- Para la clase de tráfico, se soportarán únicamente las clases de segundo plano y flujo continuo.

- Para la relación de errores de SDU, se soportan únicamente valores superiores, es decir, los valores que describen números superiores de SDUs perdidas o alteradas (los valores concretos para las clases de segundo plano y flujo continuo son 10-2 y 10-1).

- Para la velocidad de bits máxima, consúltese los valores descritos en TS 22.246.

- Para la Velocidad de bits garantizada de la Clase de Tráfico de Flujo Continuo: en función del uso de los recursos de radiocomunicaciones por otros servicios, algunas células del Área de Servicio de MBMS pueden no tener suficientes recursos disponibles para una Sesión de MBMS. La RAN puede decidir no establecer un RB en células en las que no haya disponibles recursos solicitados. La RAN no rechaza un mensaje de Solicitud de Inicio de Sesión MBMS ni siquiera si una o más células no tiene suficientes recursos para establecer portadores de radiocomunicaciones.

Los servicios portadores de MBMS de la clase de segundo plano son los más adecuados para el transporte de servicios de usuario MBMS, tales como mensajería o descargas. En el flujo de tráfico pueden aplicarse almacenamiento de memoria intermedia, esquemas de conformación y descarte de paquetes para adaptarse a los recursos disponibles y a las condiciones cambiantes de la red. El tiempo de transferencia total no es crítico para los servicios portadores de la clase de segundo plano puesto que normalmente el contenido se debe haber recibido en su totalidad y se debe haber almacenado en el UE antes de que el usuario pueda acceder al mismo.

Los servicios portadores de MBMS de la clase de flujo continuo son los más adecuados para el transporte de servicios de usuario de MBMS, tales como el flujo continuo. En cuanto a los servicios portadores de punto-a-punto, la red debe minimizar el retardo de transferencia de paquetes (y la fluctuación del retardo) de los servicios portadores de la clase de flujo continuo en la medida de lo posible. El descarte de paquetes debería ser la acción preferida de acondicionamiento del tráfico aplicada al flujo de tráfico para adaptarse a los recursos disponibles. La diferencia principal entre las clases del segundo plano y del flujo continuo para el MBMS es el soporte de una velocidad de bits garantizada en el caso del flujo continuo. No se proporciona ninguna indicación al UE en los casos en los que la RAN no pueda proporcionar la QoS solicitada. Como consecuencia, algunos UEs pueden no recibir la sesión de MBMS o partes de la misma. Para la clase de segundo plano, la RAN puede continuar distribuyendo datos en condiciones de congestión pero con tasas de pérdida de paquetes potencialmente elevadas, con lo cual el servicio de usuario de MBMS tendrá que proporcionar la suficiente redundancia en los datos con el fin de poder hacer frente a la alta pérdida de paquetes.

No obstante, los servicios de usuario de MBMS que, normalmente, usarían servicios portadores de MBMS de la clase de segundo plano pueden decidir usar un servicio portador de MBMS de la clase de flujo continuo si el servicio de usuario de MBM^s no puede hacer frente a la alta pérdida de paquetes.

La Prioridad de Asignación y Retención del Servicio Portador de MBMS prevé la priorización entre servicios portadores de MBMS, y entre servicios portadores de MBMS y servicios portadores que no sean de MBMS.

Puesto que el servicio portador de MBMS transfiere datos a muchos UEs en paralelo y debido a la carencia de canal de realimentación en el nivel de radiocomunicaciones, son difíciles de lograr bajas relaciones de error de SDU. Cuando la relación resultante de errores de paquete no es adecuada para el servicio de usuario de MBMS o cuando se requiere una prevención de pérdida de datos, un servicio de usuario de MBMS puede llevar a cabo la retransmisión de datos de MBMS a través de un contexto de PDP de punto-a-punto.

Árbol de distribución de QoS MBMS

Los datos de MBMS se distribuirán a múltiples usuarios a través de un árbol de distribución de MBMS que puede pasar a través de muchos BSCs/RNCs, muchos SGSNs y uno o más GGSNs. Además, algunos recursos portadores se pueden compartir entre muchos usuarios que accedan al mismo servicio portador de MBMS con el fin de ahorrar recursos. Como resultado, cada rama de un árbol de distribución de MBMS se establece ventajosamente con la misma QoS. Un árbol de distribución de MBMS tiene ventajosamente la misma QoS para todas sus ramas. Cuando se ha creado una rama del árbol de distribución de MBMS, no es adecuado que otra rama (por ejemplo, debido a la llegada de un UE nuevo o al cambio de ubicación de un UE con eliminación de una rama y adición de otra nueva) tenga impacto en la QoS de ramas ya establecidas.

No existe ninguna (re)negociación de QoS entre elementos de red (por ejemplo, entre un RNC y un SGSN). Esto implica que algunas ramas pueden no establecerse si el nodo en red en cuestión no puede aceptar el requisito de QoS.

Identidad de Grupo Móvil Temporal

La Identidad de Grupo Móvil Temporal (TMGI) se usa con fines de notificación del MBMS. El BM-SC asigna una TMGI globalmente única por cada servicio portador de MBMS. La estructura de la TMGI se define en TS 23.003. Para servicios portadores de MBMS Multidifusión, la TMGI se transmite al UE por medio del procedimiento de Activación de Servicio de Multidifusión de MBMS. Para el Servicio de Difusión, la TMGI se puede obtener por medio de un anuncio de servicio.

La TMGI es una identificación de servicio portador de MBMS eficiente en cuanto a los recursos, y es equivalente a la identificación de servicio portador de MBMS que consta de la dirección de multidifusión IP y un APN.

Distribución de multidifusión IP

En el GGSN, resultará posible, por configuración, permitir la distribución de carga útil de MBMS usando una Multidifusión IP en la red troncal. La distribución de Multidifusión IP se realiza desde un GGSN a nodos de aguas abajo (desde un GGSN a SGSNs o desde un GGSN directamente a RNCs). Los nodos y rúters usarán el modelo de servicio de Multidifusión Específico de la Fuente (SSM) según se especifica en RFC 4607 y RFC 4604. Para nodos que no soportan la distribución de Multidifusión IP se realiza un repliegue a la distribución heredada de punto-a­ punto.

El GGSN escoge una dirección de Multidifusión IP para la distribución y una dirección de Fuente así como un TEID-U común. La dirección de Multidifusión IP y de Fuente propuesta para la distribución y el TEID-U común son indicados por el GGSN a los SGSNs de aguas abajo en el Inicio de Sesión. El SGSN puede aceptar o rechazar la distribución propuesta de Multidifusión IP e indicarlo en la Respuesta de Inicio de Sesión de MBMS. Si la acepta, el SGSN notificará el canal (dirección de Multidifusión IP y de Fuente) a la red troncal con el fin de unirse a la distribución de multidifusión del servicio portador y el GGSN enviará los datagramas de usuario de servicio portador sobre la red troncal usando una distribución de Multidifusión IP. En caso de que un SGSN no acepte la distribución de Multidifusión IP, el GGSN se replegará a la distribución de unidifusión para el SGSN en cuestión.

La dirección propuesta de Multidifusión IP y de Fuente para la distribución y el TEID-U común son indicados, además, por el SGSN al RNC de aguas abajo (y al BSC en el modo Iu) en el Inicio de Sesión. El RNC puede aceptar o rechazar la distribución propuesta de Multidifusión IP en la Respuesta de Inicio de Sesión de MBMS al SGSN. Si es aceptada, el RNC notificará el canal (dirección de Multidifusión IP y de Fuente) a la red troncal con el fin de unirse a la distribución de multidifusión del servicio portador. Si todos los nodos de aguas abajo de la RAN aceptasen la distribución de Multidifusión IP, y si no existe ningún BSC en el modo Gb en el árbol de distribución aguas abajo, no es necesario que el SGSN notifique el canal a la red troncal.

El nodo de aguas abajo indicará si se acepta la distribución de Multidifusión IP en la Respuesta de Inicio de Sesión. Si falta esta indicación, el nodo de aguas arriba tratará el nodo de aguas abajo como si no aceptase la distribución de Multidifusión IP y usará la distribución de unidifusión. El GGSN asignará direcciones de Multidifusión IP usadas para la distribución de MBMS de acuerdo con la RFC 4607. Cuando se usan varios GGSN para la distribución de carga útil del MBMS, las direcciones de Multidifusión IP y los TEIDs comunes usados se coordinarán por configuración. Habrá mecanismos en el protocolo GTP-U que evita choques entre TEIDs comunes asignados por el GGSN y TEIDs asignados por el SGSN y el RNC.

Procedimiento de inicio de sesión de MBMS

El BM-SC inicia el procedimiento de Inicio de Sesión de MBMS cuando está preparado para enviar datos. Esta es una solicitud para activar todos los recursos portadores necesarios en la red para la transferencia de datos de MBMS y para notificar a UEs interesados sobre el inminente inicio de la transmisión. A través de este procedimiento, al(a los) GGSN(s) y al(a los) SGSN(s) que se han registrado previamente para el servicio portador de MBMS correspondiente y a todos los BSCs/RNCs que están conectados a un SGSN registrado se les proporcionan atributos de sesión de MBMS, tales como QoS, Área de servicio de MBMS, duración de sesión estimada, tiempo hasta la transferencia de datos de MBMS. Además, el procedimiento asigna el plano de portador a todos los GGSNs registrados y todos los SGSNs registrados y a BSCs/RNCs que responden al mensaje de solicitud de inicio de sesión.

Después de enviar el mensaje de Solicitud de Inicio de Sesión, el BM-SC espera durante un retardo configurable (tiempo hasta la transferencia de datos de MBMS) antes de enviar datos de MBMS. Este retardo debería ser lo suficientemente grande para evitar el almacenamiento en memoria intermedia de datos de MBMS en entidades diferentes al BM-SC, es decir, el retardo debería permitir que la red llevase a cabo todos los procedimientos requeridos para permitir la transferencia de datos de MBMS antes de que el BM-SC envíe datos de MBMS. Por ejemplo, la notificación de UEs y el establecimiento de portadores de radiocomunicaciones se deberían realizar antes de que lleguen datos de MBMS a la RAN. El retardo se puede situar en la región de múltiples segundos o decenas de segundos. Puede resultar útil que el BM-SC tenga la capacidad de configurar diferentes retardos para servicios portadores de MBMS en 2G y 3G, respectivamente.

Para servicios portadores de MBMS multidifusión, el registro de SGSNs y GGSNs es iniciado por procedimientos de Activación de Servicio de multidifusión MBMS, procedimientos de Actualización de Área de Encaminamiento Inter SGSN, un procedimiento de Reubicación de RNS de Servicio Inter SGSN y es ejecutado por procedimientos de Registro del MBMS. Además, con fines relacionados con los traspasos, debería mencionarse el Traspaso PS Entre Tecnologías de Acceso de Radiocomunicaciones (IRAT) en relación con el registro.

Para servicios portadores de MBMS de difusión, la lista de nodos de aguas abajo del BM-SC y el GGSN se logran de las siguientes maneras:

- La lista de nodos de aguas abajo para el GGSN se enviará desde el BM-SC al GGSN en la Solicitud de Inicio de Sesión.

Normalmente, el GGSN contenido en la “lista de nodos de aguas abajo” para el BM-SC es el GGSN por defecto (o dos por motivos de resiliencia).

En la Fig. 7 se presenta el procedimiento global de Inicio de Sesión, con los números de etapa indicados:

701. La función de Transmisión y Sesión de BM-SC envía un mensaje de Solicitud de Inicio de Sesión para indicar el inicio inminente de la transmisión y para proporcionar los atributos de sesión (TMGI, QoS, Área de servicio de MBMS, Identificador de sesión, duración de sesión estimada, difusión/multidifusión, lista de nodos de aguas abajo para el GGSN (Difusión solamente), tiempo hasta la transferencia de datos de MBMS, ...) y el indicador de 2G/3G. El mensaje se envía a la función de Transporte y Proxy del BM-SC, la cual, a continuación, lo reenvía a los GGSNs enumerados en el parámetro de “lista de nodos de aguas abajo” del Contexto de Portador de MBMS correspondiente. La función de Transporte y Proxy del BM-SC fija el atributo de estado de su Contexto de Portador de MBMS a “Activo”. Para un servicio portador de MBMS de difusión, el GGSN crea un contexto de portador de MBMS. El GGSN almacena los atributos de sesión y la lista de nodos de aguas abajo en el Contexto de Portador de MBMS, fija el atributo de estado de su Contexto de Portador de MBMS a “Activo” y envía un mensaje de Respuesta de Inicio de Sesión al BM-SC. La función de Proxy y Transporte lo reenvía a la función de Sesión y Transmisión del BM-SC. La función de Proxy y Transporte del b M-SC copia Solicitudes de Inicio de Sesión en la Función de Membresía del BM-SC con fines relacionados con la tarificación.

702. El GGSN envía un mensaje de Solicitud de Inicio de Sesión de MBMS que contiene los atributos de la sesión (TMGI, QoS, Área de servicio de MBMS, Identificador de sesión, duración de sesión estimada, difusión/multidifusión, tiempo hasta la transferencia de datos MBMS, direcciones de Multidifusión IP y de Fuente para distribución troncal, TEID-U común, ...) y el indicador de 2G/3G a los SGSNs enumerados en el parámetro “lista de nodos de aguas abajo” del Contexto de Portador de MBMS correspondiente. Para un servicio portador de MBMS de difusión, el SGSN crea un contexto de portador de MBMS. El SGSN almacena los atributos de sesión y el indicador de 2G/3G en el Contexto de Portador de MBMS, fija el atributo de estado de su Contexto de Portador de MBMS a “Activo”. Si el SGSN acepta el Inicio de sesión y la dirección propuesta de Multidifusión IP y de Fuente para la distribución troncal (y el TEID-U común propuesto), el SGSN envía un mensaje de Respuesta de Inicio de Sesión de MBMS al GGSN, incluyendo una indicación de que se acepta la distribución de Multidifusión IP, y fija el IE de Dirección de SGSN para Plano de Usuario a la parte de la dirección de multidifusión de la “dirección de Multidifusión IP y de Fuente para distribución troncal”, y fija el TEID para plano de portador, que será usado por el GGSN para reenviar los datos de MBMS, al “TEID-U común” recibido desde el GGSN. Si un SGSN no acepta la dirección propuesta de Multidifusión IP y de Fuente para distribución troncal (o el TEID-U común propuesto), el SGSN indicará esto incluyendo una indicación de que no se acepta la distribución de Multidifusión IP (u omitirá la indicación) e incluirá una Dirección de SGSN de unidifusión ordinaria para tráfico de usuario y un TEID-U escogido por el SGSN en el mensaje de Respuesta de Inicio de Sesión de MBMS. Para el servicio portador de MBMS, un SGSN que recibe múltiples mensajes de Solicitud de Inicio de Sesión de MBMS establece solamente un plano de portador con un GGSN, por ejemplo, para el primer mensaje de Solicitud de Inicio de Sesión de MBMS.

703. El SGSN envía un mensaje de Solicitud de Inicio de Sesión de MBMS que incluye los atributos de la sesión (TMGI, QoS, Área de servicio de MBMS, Identificador de sesión, duración de sesión estimada, difusión/multidifusión, tiempo hasta la transferencia de datos de MBMS, lista de RAs...) a cada BSC y/o cada RNC que esté conectado a este SGSN. Cuando el mensaje se envía a un RNC/BSC en modo Iu, la dirección de Multidifusión IP para distribución troncal y el TEID-U común también se incluirán si es que se han recibido del GGSN. El indicador de 2G/3G será usado por el SGSN para determinar si el mensaje de Solicitud de Inicio de Sesión de MBMS se envía solamente a BSCs, o solamente a RNCs, o tanto a RNCs como a BSCs. Para un servicio portador de MBMS de difusión, el BSC/RNC crea un Contexto de Servicio de MBMS. El BSC (en modo Iu) y/o el RNC almacenan los atributos de sesión en el Contexto de Servicio de MBMS, fija el atributo de estado de su Contexto de Servicio de MBMS a “Activo”, y responde con un mensaje de Respuesta de Inicio de Sesión de MBMS. El RNC/BSC en modo Iu incluye el TEID en el mensaje de Respuesta de Inicio de Sesión de MBMS para el plano de portador de Iu que será usado por el SGSN para reenviar los datos de MBMS. Si el RNC acepta el Inicio de sesión y la dirección de Multidifusión IP propuesta para distribución troncal (y el TEID-U común propuesto) el RNC envía un mensaje de Respuesta de Inicio de Sesión de MBMS al SGSN, incluyendo una indicación de que se acepta la distribución de Multidifusión IP. Si un RNC no acepta la dirección propuesta de Multidifusión IP para distribución troncal (o el TEID-U común propuesto), el RNC indicará esto incluyendo una indicación de que no se acepta la distribución de Multidifusión IP (u omitiendo la indicación) e incluirá un TEID-U para el plano de portador de Iu en el mensaje de Respuesta de Inicio de Sesión de MBMS. Un BSC en modo GB que no presta servicio al Área de Servicio de MBMS no necesita almacenar los atributos de la sesión. Un BSC/RNC que recibe múltiples mensajes de Solicitud de Inicio de Sesión de MBMS establece solamente un plano de portador con un SGSN.

703a. Si el RNC acepta la distribución de Multidifusión IP, el RNC se une al grupo de multidifusión en la red troncal IP. Se unirá con los procedimientos establecidos en RFC 3376, RFC 3810 y RFC 4604.

703b. Si al menos un RNC no aceptó la distribución de Multidifusión IP o si hay BSCs en modo Gb, el SGSN se une al grupo de multidifusión en la red troncal IP. Se unirá con los procedimientos establecidos en RFC 3376, RFC 3810 y RFC 4604.

704. El BSC/RNC establecen los recursos de radiocomunicaciones necesarios para la transferencia de datos de MBMS a los UEs interesados. El establecimiento de los recursos de RAN se puede planificar de acuerdo con el parámetro de tiempo hasta la transferencia de datos de MBMS.

Debe indicarse que, normalmente, el nodo de aguas arriba proporciona el mensaje de Solicitud de Inicio de Sesión de MBMS una vez por cada sesión de MBMS a un nodo de aguas abajo. No obstante, debido a la “Conexión Intradominio de Nodos de RAN a Múltiples Nodos de la Red Central”, un BSC/RNC puede recibir el mensaje de Solicitud de Inicio de Sesión de MBMS de varios SGSNs.

Procedimiento de interrupción de sesión de MBMS

La función de Sesión y Transmisión de BM-SC inicia el procedimiento de Interrupción de Sesión de MBMS cuando considera que ha terminado la sesión de MBMS. Típicamente, la sesión se termina cuando se espera que no haya más datos de MBMS a transmitir durante un periodo de tiempo suficientemente prolongado como para justificar una liberación de recursos del plano de portador en la red. El procedimiento de propaga a todos los SGSNs y GGSNs que están registrados para el servicio portador de MBMS correspondiente y a BSCs/RNCs que tienen un plano de portador de Iu establecido con un SGSN.

En la Fig. 8 se presenta el procedimiento global de Interrupción de Sesión de MBMS:

801. La función de Sesión y Transmisión de BM-SC envía un mensaje de Solicitud de Interrupción de Sesión a la función de Proxy y Transporte del BM-SC, la cual lo reenvía a todos los GGSNs enumerados en el parámetro “lista de nodos de aguas abajo” del Contexto de Portador de MBMS afectado para indicar que la sesión de MBMS se ha terminado y se pueden liberar los recursos del plano de portador. La función de Proxy y Transporte del BM-SC fija el atributo de estado de su Contexto de Portador de MBMS a “En espera”. El GGSN envía un mensaje de Respuesta de Interrupción de Sesión a la función de Proxy y Transporte del BM-SC, la cual lo reenvía a la función de Sesión y Transmisión del BM-SC. La función de Proxy y Transporte del BM-SC copia Solicitudes de Interrupción de Sesión en la función Membresía de BM-SC con fines relacionados con la tarificación.

802. El GGSN envía un mensaje de Solicitud de Interrupción de Sesión de MBMS a todos los SGSNs que tienen un plano de portador establecido con el GGSN, libera los recursos correspondientes de plano de portador hacia estos SGSNs y fija el atributo de estado de su Contexto de Portador de MBMS a “En Espera”. El GGSN libera el Contexto de Portador de MBMS en caso de un servicio portador de MBMS de difusión.

802a. Si el SGSN está usando la distribución de multidifusión IP, deshabilitará la recepción, proveniente de la red troncal IP del servicio portador de MBMS particular. Usará los procedimientos establecidos en RFC 3376, RFC 3810, y RFC 4604.

803. El SGSN libera el TEID y los recursos del plano de portador sobre los cuales estaba recibiendo datos MBMS desde el GGSN correspondientes al servicio portador de MBMS afectado, y envía un mensaje de Solicitud de Interrupción de Sesión de MBMS a todos los BSCs/RNCs que tienen un plano de portador establecido con el SGSN. El SGSN libera el Contexto de Portador de MBMS en caso de un servicio portador de MBMS de difusión.

803a. Si el RNC/BSC está usando la distribución de multidifusión IP, deshabilitará la recepción proveniente de la red troncal IP del servicio portador de MBMS particular. Usará los procedimientos establecidos en RFC 3376, RFC 3810, y RFC 4604.

804. El RNC libera los recursos afectados de radiocomunicaciones y de Iu; el BSC libera los recursos de radiocomunicaciones afectados. El BSC/RNC libera el Contexto de Servicio de MBMS en caso de un servicio portador de MBMS de difusión. Un BSC en modo Gb enviará un acuse de recibo al SGSN incluso si no hay ningún contexto de MBMS activo en el BSC.

Procedimiento de baja de registro del MBMS

Procedimiento de baja de registro de MBMS común

La Baja de Registro del MBMS es el procedimiento por el cual un nodo de aguas abajo informa a un nodo de aguas arriba de que ya no necesita recibir señalización, atributos de sesión y datos para un servicio portador de MBMS particular, y, por lo tanto, desearía ser eliminado del árbol de distribución correspondiente.

El procedimiento de Baja de Registro de MBMS es iniciado:

- Por el SGSN o GGSN cuando el último Contexto de UE de MBMS para un servidor portador de MBMS particular se elimina del nodo, y el parámetro “lista de nodos de aguas abajo” en el Contexto de Portador de MBMS correspondiente está vacío;

- Por el SGSN o GGSN cuando el último nodo registrado en la “lista de nodos de aguas abajo” se da de baja de un servicio portador de MBMS para el cual no hay ningún Contexto de UE de MBMS correspondiente; o

- Por el DRNC (RNC de Baja de registro) que se registró en un SGSN cuando elimina el Contexto de Servicio de MBMS asociado.

El procedimiento de baja de registro se muestra en la Fig. 9:

A. Cuando el DRNC que está registrado en un SGSN ya no aloja ningún UE interesado en ese servicio portador de MBMS, el DRNC solicita la baja de registro del servicio portador de MBMS a su SGSN padre. Como opción de implementación, el DRNC puede decidir no darse de baja del registro del servicio portador de MBMS inmediatamente cuando se cumplan estas condiciones, por ejemplo, con el fin de evitar una señalización innecesaria en caso de que el RNC necesitase nuevamente el mismo servicio portador de MBMS poco tiempo después. Además, el SGSN y/o el GGSN pueden decidir no darse de baja del registro inmediatamente con el fin de evitar una señalización innecesaria, es decir, esperar un cierto periodo de tiempo antes de dar de baja del registro al DRNC. El SGSN elimina el identificador del RNC del parámetro “lista de nodos de aguas abajo” del Contexto de Portador de MBMS afectado, y confirma la operación enviando un mensaje de Respuesta de Baja de Registro de MBMS al RNC. Si se había establecido un plano de portador de Iu entre el DRNC y el SGSN para este servicio portador de MBMS, se libera el plano de portador de Iu. Si el RNC está usando una distribución de multidifusión IP, deshabilitará la recepción proveniente de la red troncal IP del servicio portador de MBMS particular. Usará los procedimientos descritos en RFC 3376, RFC 3810, y RFC 4604.

B. Cuando la “lista de nodos de aguas abajo” de un Contexto de Portador de MBMS particular en el SGSN se vacía, y el SGSN no tiene ningún Contexto de UE de MBMS vinculado a ese Contexto de Portador de MBMS, el SGSN envía un mensaje de Solicitud de Baja de Registro de MBMS (dirección de multidifusión IP, APN) a su GGSN de aguas arriba asociado al Contexto de Portador de MBMS.

El GGSN elimina el identificador de SGSN del parámetro “lista de nodos de aguas abajo” del Contexto de Portador de MBMS afectado, y confirma la operación enviando un mensaje de Respuesta de Baja de Registro de MBMS al SGSN. Si se había establecido un plano de portador entre el SGSN y el GGSN para este servicio portador de MBMS, el plano de portador de libera. Si el SGSN está usando la distribución de multidifusión IP, deshabilitará la recepción proveniente de la red troncal IP del servicio portador de MBMS particular. Usará los procedimientos descritos en RFC 3376, RFC 3810, y RFC 4604.

C. Cuando la “lista de nodos de aguas abajo” de un Contexto de Portador de MBMS particular en el GGSN se vacía, y el GGSN no tiene ningún Contexto de UE de MBMS vinculado a ese Contexto de Portador de MBMS, el GGSN envía un mensaje de Solicitud de Baja de Registro (dirección de multidifusión IP, APN) a la función Proxy y de Transporte del BM-SC. Si se había establecido un plano de portador a través de la Gi para este servicio portador de MBMS, el plano de portador se libera.

El BM-SC elimina el identificador del GGSN del parámetro “lista de nodos de aguas abajo” del Contexto de Portador de MBMS afectado, y confirma la operación enviando un mensaje de Respuesta de Baja de Registro al GGSN. Procedimiento de baja de registro de MBMS iniciado por el BM-SC

Este Procedimiento de Baja de Registro de MBMS es iniciado por el BM-SC cuando se termina el servicio portador de MBMS específico. Este procedimiento suprime el árbol de distribución para la entrega de atributos de sesión y datos MBMS. Este procedimiento da como resultado la liberación de todos los Contexto de Portador de MBMS y de los Contextos de UE de MBMS asociados en los nodos a lo largo del árbol de distribución. Este procedimiento se muestra en la Fig. 10:

1001. El BM-SC envía un mensaje de Solicitud de Baja de Registro a todos los GGSNs contenidos en el parámetro “lista de nodos de aguas abajo” del Contexto de Portador de MBMS correspondiente, para indicar que la sesión se ha terminado, y cualquier recurso de portador de MBMS relacionado será liberado.

El GGSN devuelve un mensaje de Respuesta de Baja de Registro al BM-SC. El BM-SC libera todos los Contextos de UE de MBMS y el contexto de Portador de MBMS correspondiente.

1002. El GGSN envía un mensaje de Solicitud de Baja de Registro de MBMS a todos los SGSNs contenidos en el parámetro “lista de nodos de aguas abajo” del Contexto de Portador de MBMS correspondiente. El SGSN devuelve un mensaje de Respuesta de Baja de Registro de MBMS al GGSN, y libera todos los recursos de portador si el atributo de estado del Contexto de Portador de MBMS está “Activo”. Si el SGSN está usando la distribución de multidifusión IP, deshabilitará la recepción proveniente de la red troncal IP del servicio portador de MBMS particular. Usará los procedimientos descritos en RFC 3376, RFC 3810, y RFC 4604. El GGSN libera todos los Contextos de UE de MBMS y el Contexto de Portador de MBMS afectado. Si se había establecido un plano de portador a través de la Gi para este servicio portador de MBMS, se libera el plano de portador.

1003. El SGSN envía un mensaje de Solicitud de Baja de Registro de MBMS a todos los RNCs conectados con este SGSN. El RNC devuelve un mensaje de Respuesta de Baja de Registro de MBMS al SGSN, y libera todos los recursos de portador si el atributo de estado del Contexto de Servicio de MBMS está “Activo”. Si el RNC está usando la distribución de multidifusión IP, deshabilitará la recepción proveniente de la red troncal IP del servicio portador de MBMS particular. Usará los procedimientos descritos en RFC 3376, RFC 3810, y RFC 4604. El SGSN libera todos los Contextos de UE de MBMS y el Contexto de Portador de MBMS afectado. Si se había establecido un plano de portador entre el SGSN y el GGSN para este servicio portador de MBMS, el plano de portador se libera.

1004. El RNC libera los recursos de radiocomunicaciones afectados, todos los Contextos de UE de MBMS y el Contexto de Servicio de MBMS. Los procedimientos detallados se especifican en TS 25.346 y TS 43.246. La RAN puede notificar a los UEs de que se ha terminado el servicio de Portador de MBMS, de manera que el UE puede desactivar localmente su contexto de UE de MBMS, especificándose los procedimientos detallados en TS 25.346 y TS 43.246.

Aún cuando la presente invención se ha descrito en referencia a una solución de red 2.5 y 3G (por ejemplo, GPRS y UMTS), también se puede aplicar a otras redes que funcionan de una manera similar, por ejemplo, soluciones futuras de comunicación inalámbrica en función de cómo se establezca la arquitectura en estos casos. La solución hace uso de la separación entre el plano de control y el plano de usuario estableciendo los túneles con la utilización del plano de control, pero enviando los datos de carga útil reales sobre la red troncal de plano de usuario. Debe indicarse que la solución de acuerdo con la presente invención también puede encontrar aplicabilidad en una solución 2G con la diferencia de que el SGSN actuará como anfitrión en lugar del RNC, y el SGSN transmitirá información de carga útil a un BSC para su transporte posterior a cada estación móvil (MS). Con algunas correcciones del BSC, es posible que este último también pueda actuar como anfitrión de una manera similar al RNC.

Debe indicarse que la expresión “que comprende” no excluye la presencia de otros elementos o etapas diferentes a aquellos enumerados, y los vocablos “un” o “una” que preceden a un elemento no excluyen la presencia de una pluralidad de dichos elementos. La invención se puede implementar, al menos en parte, o bien en software o bien en hardware. Debe indicarse, además, que cualquier símbolo de referencia no limita el alcance de las reivindicaciones, y que diversos “medios”, “dispositivos” y “unidades” se pueden representar con el mismo artículo de hardware. Las realizaciones antes mencionadas y descritas se aportan únicamente como ejemplos y no deben ser limitativas de la presente invención. Para aquellos versados en la materia se pondrán de manifiesto otras soluciones, usos, objetivos y funciones dentro del alcance de la invención según se reivindica en las siguientes reivindicaciones de patente descritas.

Abreviaturas

BM-SC Centro de Servicio de Difusión/Multidifusión

GGSN Nodo de Servicio de Pasarela GPRS

GPRS Servicio General de Radiocomunicaciones por Paquetes

GTP Protocolo de Tunelización de GPRS

GRX Central de Itinerancia GPRS

IE Elemento de Información

IGMP Protocolo de Gestión de Grupos de Internet

IP Protocolo de Internet

ISRAU RAU Inter SGSN

MBMS Servicio de Difusión/Multidifusión Multimedia

MLD Descubrimiento de Escuchantes de Multidifusión

MS Estación Móvil (teléfono móvil en una red GPRS)

OTS Solución de Un Solo Túnel

PDN Red de Datos por Paquetes

PDP Protocolo de Datos por Paquetes

PLMN Red Pública Terrestre de Telefonía Móvil

RAU Actualización de Área de Encaminamiento

RNC Controlador de Red de Radiocomunicaciones

SGSN Nodo de Soporte de Servicio GPRS

TEID Identificador de Punto Extremo de Túnel

TEID-C TEID que identifica un túnel de plano de Control

TEID-U TEID que identifica un túnel de plano de Usuario

UE Equipo de Usuario (=MS)

UMTS Sistema Universal de Telecomunicaciones Móviles

UTRAN/GERAN Red de Acceso de Radiocomunicaciones Terrestre Universal/Red de Acceso de Radiocomunicaciones GSM/EDGE

Claims (13)

REIVINDICACIONES

1. Dispositivo (23) de pasarela de telecomunicaciones para facilitar la distribución de servicios de difusión/multidifusión multimedia, MBMS, en una red (20, 400) de telecomunicaciones, en donde el dispositivo (23) de pasarela de telecomunicaciones es conectable a un nodo (24) de servicio por medio de una interfaz de control y una interfaz troncal, y en donde el dispositivo (23) de pasarela de telecomunicaciones está adaptado para:

- recibir un mensaje de inicio de sesión de MBMS desde un centro (2) de servicio de difusión/multidifusión;

- enviar tráfico de control, por medio de la interfaz de control, en una red de control al nodo (24) de servicio;

- recibir un identificador de punto extremo de túnel común, cTEID, desde un dispositivo de infraestructura;

- enviar como tráfico de control al nodo (24) de servicio un mensaje de solicitud de inicio de sesión de MBMS que incluye el cTEID y una dirección de multidifusión del Protocolo de Internet, IP, para distribución troncal;

- recibir información del nodo (24) de servicio, que indica que el nodo (24) de servicio acepta usar la multidifusión IP; y

- enviar, por medio de la interfaz troncal, un paquete (600) de datos en una red troncal (21) de multidifusión IP para su recepción por parte de anfitriones que se han unido a un grupo de multidifusión usando el cTEID, en donde el paquete (600) de datos comprende un encabezamiento (601) con la dirección de multidifusión IP, el cTEID (602), una dirección (603) de Multidifusión de MBMS y una carga útil (604) con datos de contenido de medios, y en donde el grupo de multidifusión está asociado a la dirección de multidifusión IP.

2. Dispositivo de pasarela de telecomunicaciones según la reivindicación 1, adaptado, además, para sincronizar el cTEID con otros dispositivos de infraestructura con el fin de garantizar la unicidad del cTEID.

3. Dispositivo de pasarela de telecomunicaciones según la reivindicación 1, adaptado, además, para crear por lo menos un túnel de comunicaciones de red con por lo menos uno de un nodo (24) de servicio y un nodo (25, 26) de control con fines relacionados con el repliegue.

4. Dispositivo (24) de servicio de telecomunicaciones para facilitar la distribución de servicios de difusión/multidifusión multimedia, MBMS, en una red (20, 400) de telecomunicaciones, adaptado para:

- recibir un mensaje de solicitud de inicio de sesión de MBMS desde un dispositivo (23) de pasarela de telecomunicaciones, por medio de una interfaz de control del dispositivo (23) de pasarela de telecomunicaciones, que incluye un identificador de punto extremo de túnel común, cTEID, y una dirección de multidifusión del Protocolo de Internet, IP, para distribución troncal;

- enviar a un dispositivo (25, 26) de control un mensaje de solicitud de inicio de sesión de MBMS que incluye el identificador de punto extremo de túnel común, cTEID y la dirección de multidifusión IP para distribución troncal; - enviar información al dispositivo (23) de pasarela de telecomunicaciones indicando que el dispositivo (24) de servicio de telecomunicaciones acepta usar la multidifusión IP; y

- recibir del dispositivo (25, 26) de control un mensaje de respuesta de inicio de sesión de MBMS con una indicación de que el dispositivo de control acepta usar la distribución de multidifusión IP.

5. Dispositivo de servicio de telecomunicaciones según la reivindicación 4, adaptado, además, para enviar un mensaje de incorporación del protocolo de gestión de grupos de internet, IGMP, o mensaje de informe de membresía, IGMPv2 e IGMPv3, a una red troncal de multidifusión del Protocolo de Internet.

6. Dispositivo (25, 26) de control de telecomunicaciones para facilitar la distribución de servicios de difusión/multidifusión multimedia, MBMS, en una red (20, 400) de telecomunicaciones, adaptado para:

- recibir, de un dispositivo (24) de servicio de telecomunicaciones, un mensaje de solicitud de inicio de sesión de MBMS que incluye un identificador de punto extremo de túnel común, cTEID, y una dirección de multidifusión de Protocolo de Internet, IP, para distribución troncal;

- enviar, al dispositivo (24) de servicio de telecomunicaciones, un mensaje de respuesta de inicio de sesión de MBMS con una indicación de que el dispositivo (25, 26) de control de telecomunicaciones acepta usar la distribución de multidifusión IP;

- enviar un mensaje de incorporación del protocolo de gestión de grupos de internet, IGMP, o mensaje de informe de membresía, a una red troncal (21) de multidifusión de Protocolo de Internet para unirse a un grupo de multidifusión asociado a la dirección de multidifusión IP; y

- recibir un paquete (600) de datos sobre la red troncal (21) de multidifusión IP, en donde el paquete (600) de datos comprende un encabezamiento (601) con la dirección de multidifusión IP, el cTEID (602), una dirección (603) de Multidifusión de MBMS y una carga útil (604) con datos de contenido de medios.

7. Red (20, 400) de infraestructura de telecomunicaciones para facilitar la distribución de servicios de difusión/multidifusión multimedia, MBMS, que comprende:

- un nodo (2) de servicio de difusión/multidifusión, BM-SC;

- un dispositivo (23) de pasarela de telecomunicaciones según la reivindicación 1;

- por lo menos un dispositivo (24) de servicio de telecomunicaciones según la reivindicación 4; y

- por lo menos un dispositivo (25, 26) de control de telecomunicaciones según la reivindicación 6.

8. Método para facilitar la distribución de servicios de difusión/multidifusión multimedia, MBMS, en una red (20, 400) de telecomunicaciones, que comprende las etapas de:

- recibir en un nodo (23) de pasarela un mensaje de inicio de sesión de MBMS desde un centro (2) de servicio de difusión/multidifusión, BM-SC;

- enviar, desde el nodo (23) de pasarela, tráfico de control en una red de control a un nodo (24) de servicio;

- recibir, en el nodo (23) de pasarela, un identificador de punto extremo de túnel común, cTEID, desde un dispositivo de infraestructura;

- enviar como tráfico de control desde el nodo (23) de pasarela al nodo (24) de servicio un mensaje de solicitud de inicio de sesión de MBMS que incluye el cTEID y una dirección de multidifusión de Protocolo de Internet, IP, para distribución troncal;

- recibir, en el nodo (23) de pasarela información desde el nodo (24) de servicio indicando que el nodo (24) de servicio acepta usar la multidifusión IP; y

- enviar, desde el nodo (23) de pasarela, un paquete (600) de datos en una red troncal de multidifusión IP para su recepción por parte de anfitriones (25, 26, 31) que se han unido a un grupo de multidifusión usando el TEID común, en donde el paquete (600) de datos comprende un encabezamiento (60l) con la dirección de multidifusión IP, el TEID común (602), una dirección (603) de Multidifusión de MBMS y una carga útil (604) con datos de contenido de medios, y en donde el grupo de multidifusión está asociado a la dirección de multidifusión IP.

9. Método según la reivindicación 8, en el que el TEID común es único para cada sesión de MBMS.

10. Método según la reivindicación 8, en el que el anfitrión es por lo menos uno de un nodo (24) de servicio y un nodo (25, 26) de control.

11. Método según la reivindicación 8, en el que el TEID común se identifica fijando por lo menos un bit de una estructura de TEID de manera que indique un estado activo.

12. Método según la reivindicación 8, que comprende, además, la etapa de usar un procedimiento de repliegue que comprende establecer túneles GTP entre la pasarela (23) y los nodos (24) de servicio y entre los nodos (24) de servicio y los nodos (25, 26) de control.

13. Método según la reivindicación 8, que comprende, además, una etapa de unión del dispositivo (25, 26) de control a la red troncal de multidifusión IP comprende enviar un mensaje indicativo del interés de unirse a la red troncal de multidifusión IP.