ES2329420T3

ES2329420T3 - Procedimiento para asignar al menos un enlace de datos utiles a al menos un enlace multiplex.

Info

Publication number: ES2329420T3
Application number: ES07704106T
Authority: ES
Inventors: Thomas Belling
Original assignee: Siemens AG; Siemens Corp
Current assignee: Siemens AG; Siemens Corp
Priority date: 2006-01-27
Filing date: 2007-01-24
Publication date: 2009-11-25
Anticipated expiration: 2027-01-24
Also published as: EA200900848A1; ATE428253T1; PL2073480T3; EA020306B1; US8811162B2; ATE437520T1; CN102710654A; JP5185827B2; EP1994714B1; DE502007001133D1; US20120113916A1; CN101375577A; EA200870203A1; EP2073480A1; EP1994714A1; US20090010217A1; EP1814278A1; WO2007085606A1; EP2058996A1; JP2009524960A

Abstract

Procedimiento para la asignación de al menos un enlace de datos útiles a al menos un enlace múltiplex previsto entre un primer elemento de red (MSC-A) y un segundo elementos de red (MSC-B), caracterizado porque el primer elemento de red (MSC-A) genera un primer mensaje de señalización y lo transmite al segundo elemento de red (MSC-B), indicándole mediante el primer mensaje de señalización al segundo elemento de red (MSC-A) la disponibilidad del primer elemento de red (MSC-A) para el transporte del enlace de datos útiles, de los que al menos hay uno, a través del respectivo enlace múltiplex, porque en función de la disponibilidad indicada del primer elemento de red (MSC-A) y de si el transporte del enlace de datos útiles, de los que al menos hay uno, es apoyado a través de un enlace múltiplex por el segundo elemento de red (MSC-B), el segundo elemento de red (MSC-B) asigna a cada uno de los enlaces de datos útiles, de los que al menos hay uno, bien un enlace múltiplex entre el primer elemento de red (MSC-A) y el segundo elemento de red (MSC-B) o bien elige para este enlace de datos útiles un transporte fuera de un enlace múltiplex y porque mediante un segundo mensaje de señalización generado en el segundo elemento de red (MSC-B) y transmitido al primer elemento de red (MSC-A), se le indica al primer elemento de red (MSC-A) la posible asignación del enlace de datos útiles, de los que al menos hay uno, a un enlace múltiplex (mv).

Description

Procedimiento para asignar al menos un enlace de datos útiles a al menos un enlace múltiplex.

La invención se refiere a un procedimiento para asignar al menos un enlace de datos útiles a al menos un enlace múltiplex previsto entre un primer elemento de red y un segundo elemento de red.

Para transmitir datos de voz a través de un sistema de comunicaciones móvil o bien sistema de telefonía móvil, se utilizan cada vez más procedimientos de transmisión de datos orientados a paquetes, en los que en función del protocolo de transmisión utilizado en cada caso se ponen a disposición campos de datos que presentan distintos tamaños para transmitir los datos de voz comprimidos. Como protocolos de transmisión se utilizan la mayoría de las veces protocolos de transmisión "Layer 2" (de la capa 2), como por ejemplo el protocolo Ethernet, así como el protocolo de Internet protocolo (IP), el "User Datagram Protocol" protocolo de datagrama de usuario (UDP) (RFC 768), el "Realtime Transport Protocol" protocolo de transporte en tiempo real (RTP) (RFC 3550) y en algunos casos también el "Iu Framing Protocol" protocolo de entramado Iu (IuFP) (3GPP TS 29.415).

Por ejemplo en el llamado dominio CS de la red núcleo ("Core Network") de un sistema de telefonía móvil de la tercera generación (3GPP) para la transmisión de datos por ejemplo entre una llamada unidad Media Gateway (MGWs) o de pasarela de medios y/o un "Mobile Switching Center" (MSC) o centro de conmutación móvil, se establece un llamado enlace de datos "Nb". Los datos a transmitir de voz o multimedia se comprimen por ejemplo mediante una unidad codificadora de voz "Adaptive Multi-Rate" (AMR) o de multivelocidad adaptiva y a continuación los datos de voz comprimidos se transmiten mediante el "Iu Framing Protocol" protocolo (IuFP) (3GPP TS 29.415) o el protocolo RTP, UDP o IP (ver al respecto el estándar 3GPP TS 29.414).

Los campos de datos de los correspondientes protocolos de transmisión, es decir, las correspondientes cabeceras (header), son en su conjunto a menudo bastante más grandes que los datos allí transmitidos, como por ejemplo datos de voz comprimidos. Por ejemplo, presenta el campo de datos de un paquete de datos IP un tamaño de 20 bytes (versión IP 4.0) o bien 40 bytes (versión IP 6.0). Los campos de datos del protocolo UDP presentan un tamaño de 8 bytes y por el contrario los campos de datos del protocolo RTP 16 bytes y los del protocolo IuFP incluyen 4 bytes. A diferencia de ello, presentan los datos comprimidos mediante la unidad codificadora de voz AMR un tamaño de 35 bytes en el modo "12.2 kHz" o un tamaño de 5 bytes en el modo "Silence Indication" (SID) o indicación de silencio, utilizado en medio de las pausas de voz.

Entre al menos dos unidades de conmutación móvil o dos unidades de pasarela de medios (media gateway) se transmiten por lo general simultáneamente varios enlaces de datos útiles, como por ejemplo enlaces telefónicos, por ejemplo según el estándar para la llamada interfaz NB. Análogamente a la interfaz Nb, puede realizarse la transmisión de datos mediante la interfaz "Iu" igualmente prevista en un sistema de telefonía móvil 3GPP, existente entre una unidad de pasarela de medios o una unidad de conmutación móvil y una llamada unidad "Radio Network Controller" (RNC) o controlador de red de radio (ver al respecto 3GPP TS 25.414, así como 25.415).

Según los estándares actualmente existentes, se establece mediante la interfaz Nb ó Iu para cada enlace de datos útiles a transmitir, por ejemplo para una conversación telefónica, un enlace de datos propio, físicamente separado, enlace de datos IP/UDP/RTP según el correspondiente protocolo de datos, a través del cual se transmiten los paquetes de datos constituidos según el correspondiente protocolo de transmisión IP, UDP y RTP.

Tanto en el marco de la interfaz Nb como también en el de la interfaz Iu, se termina el protocolo de datos IP, UDP y RTP en cada caso en la unidad de pasarela de medios (media gateway) contigua y en la unidad de conmutación móvil contigua o bien la unidad RNC contigua, es decir, los campos de datos de los distintos paquetes de datos transmitidos a través del enlace de datos Nb ó Iu, presentan, al menos parcialmente, coincidencias y se leen y siguen procesando en las citadas unidades a continuación de la transmisión. A diferencia de ello, los campos de datos de paquetes de datos realizados según el protocolo IuFP son retransmitidos sin modificar mediante la correspondiente unidad de pasarela de medios o unidad de conmutación móvil.

Además, se conocen en el campo de la tecnología de la transmisión muchas tecnologías múltiplex mediante las cuales se transmiten datos de varios enlaces de datos útiles aproximadamente a la vez mediante un enlace de datos multiplexado. Tales enlaces de datos previstos para transmitir varios enlaces de datos útiles o bien enlaces telefónicos, se denominarán a continuación enlaces múltiplex.

En la interfaz Nb ó Iu es ventajoso transmitir datos de varios enlaces de datos útiles conjuntamente dentro de un enlace múltiplex transportado preferiblemente mediante protocolos IP/UDP/RTP. Con ello pueden estar incluidos en un paquete de IP que contiene en cada caso sólo una cabecera de IP, UDP y RTP, datos de varios enlaces de datos útiles, en cada caso preferiblemente con una cabecera IuFP propia y datos útiles propios, como por ejemplo datos de voz comprimidos. De esta manera puede reducirse considerablemente la anchura de banda necesaria para el transporte. Desde luego, esta posibilidad aún no se ha descrito en el estándar.

Para establecer un enlace de datos útiles a través de un enlace de datos Nb, se prevé el llamado "BICC IP Bearer Control Protocol" protocolo de control del portador (IPBCP) (ITU-T Q.1970), que a su vez utiliza el llamado "Session Description Protocol" o protocolo de descripción de sesión protocolo (SDP) (IETF RFC 2327) (ver al respecto 3GPP TS 29.414). El protocolo IPBCP prevé, para establecer un enlace de datos útiles entre una primera y una segunda unidad de pasarela de medios, la transmisión de un mensaje "IPBCP-Request" (solicitud IPBCP) desde la primera a la segunda unidad de pasarela de medios. La segunda unidad de pasarela de medios contesta a este mensaje mediante un mensaje "IPBCP-Response" (respuesta IPBCP). Mediante los citados mensajes IPBCP intercambian la primera y la segunda unidad de pasarela de medios entre sí sus correspondientes direcciones de IP y números de puerto UDP, cuyo conocimiento es necesario para intercambiar datos entre la primera y la segunda unidad de pasarela de medios. Los mensajes IPBCP se transmiten de manera transparente mediante los llamados protocolos de señalización BICC (ITU-T Q.1902 1-5).

La misión de la invención consiste en indicar un procedimiento para la asignación de al menos un enlace de datos útiles a un enlace múltiplex previsto entre al menos un primer elemento de red y al menos un segundo elemento de red, en el que se reduzca claramente la anchura de banda de transmisión necesaria para transmitir los datos útiles, por ejemplo datos de voz. La tarea se resuelve partiendo del preámbulo de la reivindicación 1 mediante sus características caracterizadoras.

El aspecto esencial del procedimiento correspondiente a la invención ha de considerarse que es que mediante el primer elemento de red se genera un primer mensaje de señalización y se transmite al segundo elemento de red, indicándose mediante el primer mensaje de señalización al segundo elemento de red la disponibilidad del primer elemento de red para transporte al menos un enlace de datos útiles a través de en cada caso un enlace múltiplex. En función de la disponibilidad indicada del primer elemento de red y de si el transporte de al menos un enlace de datos útiles es apoyado a través de un enlace múltiplex por el segundo elemento de red, asigna el segundo elemento de red a cada uno de los enlaces de datos útiles, de los que al menos hay uno, un respectivo enlace múltiplex entre el primer elemento de red y el segundo elemento de red o bien elige para este enlace de datos útiles un transporte fuera de un enlace múltiplex. Mediante un segundo mensaje de señalización generado en el segundo elemento de red y transmitido al primer elemento de red, se le indica al primer elemento de red la posible asignación del enlace de datos útiles, de los que al menos hay uno, a un enlace múltiplex. Ventajosamente, en el procedimiento correspondiente a la invención no es necesario que el primer elemento de red que inicia la asignación conozca el nodo de destino del enlace de datos útiles. Con ello puede también ampliarse el protocolo IPBCP estandarizado en el que el mensaje de solicitud IPBCP transmitido por el primer elemento de red, la mayoría de las veces es enviado sin el conocimiento del segundo elemento de red que recibe el mismo, o bien ampliarse el protocolo de señalización SIP igualmente estandarizado en el procedimiento correspondiente a la invención. Mediante el establecimiento del correspondiente enlace de datos útiles a través de un enlace múltiplex, pueden transmitirse en particular datos de voz comprimidos mediante una anchura de banda claramente reducida.

Ventajosamente, en el procedimiento correspondiente a la invención tampoco es necesario introducir nuevos mensajes en el protocolo IPBCP, sino que los mensajes existentes sólo tienen que ser ampliados adecuadamente.

Por lo demás, el procedimiento correspondiente a la invención posibilita ventajosamente a elección el transporte de un enlace de datos útiles entre un primer elemento de red que apoya el transporte de datos a través de un enlace múltiplex y un segundo elemento de red que según el estándar existente sólo apoya el transporte de enlace de datos útiles fuera de enlaces múltiplex.

Ventajosamente tiene en cuenta el segundo elemento de red al elegir el enlace múltiplex si en el enlace múltiplex existen suficientes recursos libres para el nuevo enlace de datos útiles, como por ejemplo una información de dirección libre para el enlace de datos útiles.

En el caso de que se utilice el protocolo IPBCP, se intercambia al establecerse cada enlace de datos útiles separadamente un llamado mensaje IPBCP-Request (de solicitud IPBCP) y un llamado mensaje IPBCP-Response (de respuesta IPBCP). En el mensaje IPBCP-Request indica el primer elemento de red según el estándar existente su dirección de IP, así como un número de puerto UDP. Para indicar que se desea el transporte de un enlace de datos útiles a través de un enlace múltiplex, se introduce un atributo SDP formado como nuevo. Alternativamente, se utiliza un nuevo parámetro "MIME" para el tipo MIME del protocolo IuFP, definido en el TS 29.414.

En el caso de que el segundo elemento de red no apoye el transporte de enlaces de datos útiles a través de enlaces múltiplex, ignora el segundo elemento de red según el estándar SDP existente el nuevo atributo SDP que él desconoce o bien el nuevo parámetro MIME y establece según el estándar IPBCP existente un enlace de datos útiles transportado individualmente para la dirección de IP indicada y el número de puerto. Con ello se da la necesaria compatibilidad en sentido descendente.

En el caso de que el segundo elemento de red ciertamente apoye el transporte de enlaces de datos útiles a través de enlaces múltiplex, pero que decida no utilizar ningún multiplexado para el enlace de datos útiles dado, envía el segundo elemento de red igualmente un mensaje de respuesta IPBCP según el estándar existente sin ampliaciones correspondientes a la invención.

Un segundo elemento de red que apoya el multiplexado, elige al recibir el mensaje de solicitud IPBCP con la indicación de que se desea un multiplexado, un enlace múltiplex hacia la dirección de IP indicada en el mensaje de solicitud IPBCP. El enlace múltiplex puede conducir alternativamente también a otro puerto diferente al puerto indicado en el mensaje de solicitud IPBCP.

El segundo elemento de red comunica al primer elemento de red en el mensaje de respuesta IPBCP que se ha elegido el multiplexado e indica el enlace múltiplex elegido preferiblemente mediante el número de puerto UDP que utiliza el segundo elemento de red para recibir el enlace múltiplex. Para indicar que se ha elegido el multiplexado puede utilizarse un nuevo atributo SDP, por ejemplo el mismo nuevo atributo SDP que se utiliza en el mensaje de solicitud IPBCP para indicar que se desea multiplexado. Alternativamente se utiliza para indicar que se elige el multiplexado un nuevo parámetro "MIME" para el tipo MIME del IuFP definido en TS 29.414, por ejemplo el mismo parámetro nuevo que en el mensaje de solicitud IPBCP. La indicación del número de puerto utilizado para recibir el enlace múltiplex en MGW-B puede realizarse dentro de la llamada fila "Media" que describe el enlace de datos útiles, o bien con ayuda de un nuevo atributo SDP o parámetro tipo MIME.

Además, ventajosamente posibilita el procedimiento correspondiente a la invención la asignación de un distintivo inequívoco para el enlace de datos útiles dentro del enlace múltiplex. Este distintivo puede indicarse por ejemplo dentro de los paquetes de datos del enlace múltiplex, asignado en cada caso a un paquete de datos transportado del enlace de datos útiles, para expresar así a qué enlace de datos útiles pertenece el paquete de datos transportado.

Preferiblemente asigna el segundo elemento de red, tras la elección de un enlace múltiplex al nuevo enlace de datos útiles a él asignado, otro distintivo, que dentro del enlace múltiplex es inequívoco, y comunica para cada nuevo enlace de datos útiles asignado el distintivo adicional elegido al primer elemento de red en el mensaje en el que el segundo elemento de red indica para cada enlace de datos útiles si se asigna a un enlace múltiplex y a cuál.

Este distintivo puede indicarse entonces por ejemplo dentro de los paquetes de datos del enlace múltiplex en cada caso asignado a un paquete de datos transportado del enlace de datos útiles, para así expresar a qué enlace de datos útiles pertenece el paquete de datos transportado. Preferiblemente se utiliza aquí para un enlace de datos útiles el mismo distintivo tanto para paquetes de datos enviados desde el primer elemento de red al segundo elemento de red como para paquetes de datos enviados del segundo elemento de red al primer elemento red.

Para SDP, al igual que se ha utilizado para IPBCP, se realiza la indicación del distintivo preferiblemente con ayuda de un nuevo atributo SDP o parámetro tipo MIME, por ejemplo del atributo o bien parámetro que indica que se utilizará multiplexado.

Ventajosamente, tan pronto como finaliza un enlace de datos útiles, se asigna el distintivo utilizado hasta entonces para este enlace de datos útiles a otro enlace de datos útiles asignado como nuevo al enlace múltiplex. Para evitar que el mismo distintivo se asigne casualmente a la vez por el primer y por el segundo elemento de red a distintos nuevos enlaces de datos útiles dentro del mismo enlace múltiplex, es ventajoso que se asignen al primer y segundo elemento de red distintas gamas de valores para otorgar el distintivo. Por ejemplo, aquel elemento de red que primeramente asigna a un nuevo enlace multiplex un enlace de datos útiles, puede de esta manera obtener la asignación de la gama de valores inferior, mientras que el otro elemento de red que recibe del elemento de red mediante la asignación a este enlace de datos útiles un mensaje, recibe mediante este mensaje la asignación de la gama de valores
superior.

Además de ello, se apoya ventajosamente mediante el procedimiento correspondiente a la invención el establecimiento de nuevos enlaces múltiplex, en particular cuando aún no existe ningún enlace múltiplex adecuado para el enlace de datos útiles. Un tal establecimiento automático y dinámico de enlaces múltiplex simplifica considerablemente el funcionamiento de un sistema de comunicaciones.

Correspondientemente, es ventajoso al recibir el mensaje del primer elemento de red que contiene una dirección y que indica que se desea la asignación de enlace(s) a uno o varios enlace(s) múltiplex, que el segundo elemento de red, en el caso de que aún no exista ningún enlace múltiplex adecuado para la dirección indicada o que en los enlaces de datos existentes ya no exista ningún recurso, establezca un nuevo enlace múltiplex con la dirección indicada y lo asigne a los enlaces de datos útiles.

Preferiblemente se realiza el establecimiento del nuevo enlace múltiplex señalando el segundo elemento de red en el mensaje al primer elemento de red un enlace múltiplex aún no existente, por ejemplo mediante un número de puerto UDP aún no utilizado del segundo elemento de red. El primer elemento de red detecta al recibir el mensaje del segundo elemento de red, puesto que se utilizará una nueva información de dirección, que se utilizará un nuevo enlace múltiplex. Preferiblemente indica previamente el primer elemento de red en el mensaje al segundo elemento de red un número de puerto UDP libre del primer elemento de red, y el segundo elemento de red utiliza este número de puerto UDP para enviar datos en un nuevo enlace múltiplex establecido al primer elemento de red. Cuando el segundo elemento de red elige un enlace múltiplex ya existente, utiliza el segundo elemento de red por el contrario otro número de puerto del primer elemento de red que ya previamente estaba asignado a este enlace múltiplex. Preferiblemente se desconecta un enlace múltiplex tan pronto como finaliza el último enlace de datos útiles allí transportado.

La presente invención es adecuada también para otras redes que prevén como señalización el llamado "Session Initiation Protocol" o protocolo de iniciación de sesión (IETF RFC 3261), y en las cuales entre los mismos elementos de red se intercambian muchos enlaces de datos útiles, como por ejemplo el llamado "Internet Multimedia Subsystem" (IMS) o subsistema multimedia de Internet, de la forma estandarizada por ETSI TISPAN. Para describir los enlaces de datos útiles, se utiliza también aquí el protocolo SDP, que según el llamado mecanismo "SDP-offer-answer" u oferta-respuesta SDP (IETF RFC 32 64) se intercambia mediante un llamado mensaje SDP-offer (oferta SDP) y un mensaje SDP-answer (respuesta SDP) que sigue al anterior y que son comparables con los mensajes IPBCP-Request (solicitud IPBCP) e IPBCP-Response (respuesta IPBCP) respectivamente.

Otras configuraciones ventajosas del procedimiento correspondiente a la invención pueden tomarse de las otras reivindicaciones.

A continuación se describirá más en detalle el procedimiento correspondiente a la invención en base a un ejemplo de ejecución, así como a varias figuras. Se muestra en:

figura 1 a modo de ejemplo en un esquema de bloques de circuitos, los componentes de red de un sistema de comunicaciones móvil que interactúan para ejecutar el procedimiento correspondiente a la invención,

figura 2 a modo de ejemplo en representación esquemática, la estructura de un paquete de datos de un enlace múltiplex correspondiente a la invención,

figura 3 a modo de ejemplo en representación esquemática, una estructura alternativa de un paquete de datos de un enlace múltiplex correspondiente a la invención,

figura 4 a modo de ejemplo en un esquema de bloques de circuitos, la arquitectura de red de un sistema de comunicaciones basado en IMS.

En la figura 1 se representa a modo de ejemplo en un esquema de bloques de circuitos un primer elemento de red, en particular un nodo de red MSC-A y un segundo elemento de red, en particular un nodo de red MSC-B, de un sistema de comunicaciones móvil MKS, estando configurados el primer y el segundo nodo de red MSC-A, MSC-B en una forma de ejecución preferente como unidades de conmutación móviles.

El primer nodo de red MSC-A presenta por ejemplo en el ejemplo de ejecución representado en la figura 1 una primera unidad de servidor MSC, MSC-S-A, y una primera unidad de pasarela de medios (Media Gateway MGW-A. Análogamente a ello, presenta el segundo nodo de red MSC-B una segunda unidad de servidor MSC, MSC-S-B y una segunda unidad de pasarela de medios MGW-A, MGW-B. Las funcionalidades del servidor y de la pasarela de medios realizadas mediante unidades separadas, a saber, la primera y segunda unidades de servidor MSC MSC-A, así como la primera y segunda unidad de pasarela de medios MGW-A, MGW-B, pueden también alternativamente estar realizadas en cada caso en una unidad común.

El primer y segundo nodos de red MSC-A, MSC-B, o bien su primera y segunda unidad de pasarela de medios MGW-A, MG W-B están conectados entre sí en el presente ejemplo de ejecución mediante una interfaz "Nb", que para la transmisión de paquetes de datos DP de un enlace de datos útiles a establecer, utiliza el protocolo IP, UDP, RTP e IuFP.

En el marco de la invención se prevé en la interfaz "Nb" al menos un enlace múltiplex mv para la transmisión de al menos un enlace de datos útiles. Además, existe un enlace de señalización BICC entre la primera y la segunda unidades de servidor MSC MSC-S-A, MSC-S-B, estando la primera y segunda unidad de servidor MSC MSC-S-A, MSC-C-B unidas mediante un enlace de señalización basado en el protocolo ITU-T H.248 con la primera y segunda unidad de pasarela de medios MGW-A, MGW-B respectivamente y controlando éstas a su través. Tanto a través del enlace de señalización BICC como también a través del enlace de señalización H.248, se apoya el "BICC IP Bearer Control Protocol" protocolo de control del portador (IPBCP).

Además, el primer nodo de red MSC-A o bien la primera unidad de servidor MSC MSC-S-A y la primera unidad de pasarela de medios MGW-A están unidos mediante la llamada interfaz "Iu" o bien un enlace de datos "Iu" con un "Radio-Network-Controller" o controlador de la red de radio, unidad (RNC). También mediante el enlace de datos Iu se utiliza para la transmisión de los paquetes de datos de un enlace de datos útiles el protocolo IP, UDP, RTP e IuFP.

En la figura 2 se representa a modo de ejemplo la estructura de un paquete de datos DP de un enlace múltiplex mv correspondiente a la invención, que por ejemplo se transmite mediante el enlace de datos Nb o bien la interfaz Nb. El paquete de datos DP está previsto para la transmisión de datos múltiplex de por ejemplo un primer hasta un tercer enlace de datos útiles UC1, UC2, UC3.

El paquete de datos DP presenta para ello solamente un campo de datos IP, UDP y RTP, y por el contrario los datos útiles del primer hasta el tercer enlace de datos útiles UC1, UC2, UC3 se transmiten en cada caso en un campo de datos dispuesto separado de los demás IuFP1 a IuFP3, que contiene preferiblemente datos del IuFP, así como los datos útiles del primer, segundo y tercer enlace de datos útiles UC1, UC2, UC3 respectivamente. Los datos útiles pueden ser en cada caso, por ejemplo según el procedimiento AMR, informaciones de voz codificadas.

Preferiblemente se inserta para cada enlace de datos útiles UC1 a UC3 también en cada caso un campo de datos múltiplex MP1, MP2, MP3, que contienen al menos un primer hasta un tercer distintivo ID1, ID2, ID3 que designa dentro del enlace múltiplex el correspondiente enlace de datos útiles UC1, UC2 y UC3 respectivamente, así como dado el caso otras informaciones en cuanto a la longitud de los datos útiles transmitidos en cada caso y/o sello de tiempo. También pueden estar previstos un primer hasta un tercer campos de datos IuFP IuFP1, IuFP2, IuFP3.

A continuación se describirá más en detalle a modo de ejemplo un mensaje de solicitud (request) IPBCP y un mensaje de respuesta (response) IPBCP codificado mediante el "Session Description Protocol" o protocolo de descripción de sesión, protocolo (SDP), que por ejemplo se intercambian entre el primer y el segundo nodo de red MSC-A, MSC-B representados en la figura 1, en particular entre la primera y la segunda unidad de pasarela de medios (Media-Gateway) MGW-A, MGW-B

Mensaje IPBCP-Request (solicitud IPBCP) (MGW-A \rightarrow MGW-B):

Rq1: c=IN IP4 host.anywhere.com

Rq2: m=audio 49170 RTP/AVP 97

Rq3: a=rtpmap:97 VND.3GPP.IUFP/16000

Rq4: a=fmtp:97 multiplex

\vskip1.000000\baselineskip

Mensaje IPBCP-Response (respuesta IPBCP) (MGW-B \rightarrow MGW-A):

Rq1: c=IN IP4 host.example.com

Rq2: m=audio 49320 RTP/AVP 97

Rq3: a=rtpmap:97 VND.3GPP.IUFP/16000

Rq4: a=fmtp:97 multiplex; user_connection_id=11

\vskip1.000000\baselineskip

El mensaje de solicitud IPBCP se genera en la primera unidad de pasarela de medios MGW-A del primer nodo de red MSC-A y se transmite a la segunda unidad de pasarela de medios MGW-B del segundo nodo de red MGW-B. Mediante el distintivo múltiplex "multiplex" indicado en la cuarta fila Rq4 del mensaje de solicitud IPBCP del tipo MIME del protocolo IuFP, se indica mediante la primera unidad de pasarela de medios MGW-A a la segunda unidad de pasarela de medios MGW-B que se desea la asignación del enlace de datos útiles indicado en el mensaje de solicitud IPBCP a un enlace múltiplex mv.

En la primera fila Rq1 del mensaje de solicitud IPBCP, se indica mediante la primera unidad de pasarela de medios MGW-A una información de dirección asociada a la misma, por ejemplo su dirección de Ip como
"host.anywhere.com", a la que debe conducirse el enlace múltiplex.

En la segunda fila Rq2 del mensaje de solicitud IPBCP, se indica mediante la primera unidad de pasarela de medios MGW-A un número de puerto libre dispuesto en la primera unidad de pasarela de medios MGW-A, por ejemplo "49170", que puede utilizarse para establecer un enlace múltiplex mv aún no existente en el instante de la consulta, pero también según el estándar existente para establecer un enlace de datos útiles fuera de un enlace múltiplex.

Si no está previsto ningún distintivo múltiplex "multiplex" en la cuarta fila Rq4 del mensaje de solicitud IPBCP, se prevén según el estándar la dirección de IP indicada, así como el número de puerto para establecer un enlace de datos útiles sencillo, es decir, no multiplexado. En la primera unidad de pasarela de medios MGW-A se tiene ya en cuenta que la segunda unidad de pasarela de medios MGW-B posiblemente no apoya o bien no corresponde al deseo de asignación indicado mediante el distintivo múltiplex "multiplex", y utiliza la dirección de IP transmitida y el número de puerto para establecer un enlace de datos útiles sencillo, no multiplexado, con la primera unidad de pasarela de medios MGW-A.

Tras recibir el mensaje de solicitud IPBCP, se asigna mediante la segunda unidad de pasarela de medios MGW-B en el marco de invención un enlace múltiplex mv a la dirección de IP recibida "host.anywhere.com", con el número de puerto del enlace múltiplex deseado en la segunda unidad de pasarela de medios MGW-B, por ejemplo el enlace múltiplex con el número de puerto "49320".

En una forma de ejecución preferente, se asigna mediante la primera y segunda unidad de pasarela de medios MGW-B al enlace de datos útiles a establecer un distintivo dentro del enlace múltiplex mv asignado, en el presente ejemplo de ejecución el distintivo "11". Para evitar que el mismo distintivo se asigne casualmente a la vez por la primera y segunda unidad de pasarela de medios MGW-A, MGW-B a distintos nuevos enlaces de datos útiles dentro del mismo enlace múltiplex, se asignan a la primera y a la segunda unidad de pasarela de medios MGW-A, MGW-B preferiblemente distintas gamas de valores para la asignación del distintivo. Por ejemplo, puede asignarse de esta manera a aquella unidad de pasarela de medios MGW-B que asigna primero a un nuevo enlace múltiplex un enlace de datos útiles la gama de valores inferior, mientras que a la otra unidad de pasarela de medios MGW-A se le asigna la gama de valores superior.

Si detecta la segunda unidad de pasarela de medios MGW-B que para la dirección de IP deseada
"host.anywhere.com" aún no existe ningún enlace múltiplex mv, establece la misma mediante un mensaje de respuesta IPBCP un nuevo enlace múltiplex mv para la dirección IP "host.anywhere.com" y el número de puerto indicado "49170" en la primera unidad de pasarela de medios. En este caso, el número de puerto "49320" asignado es un número de puerto no utilizado hasta ahora en la segunda unidad de pasarela de medios MGW-B.

Si por el contrario se elige un enlace múltiplex mv existente, entonces corresponde el número de puerto "49320" asignado a la segunda unidad de pasarela de medios MGW-B al número de puerto del enlace multiplex existente mv al que en la primera unidad de pasarela de medios MGW-A está asignado el número de puerto "49170".

Las informaciones averiguadas mediante la segunda unidad de pasarela de medios MGW-B para establecer el enlace de datos útiles se indican mediante el mensaje de respuesta IPBCP a la primera unidad de pasarela de medios MGW-A.

Por ejemplo, mediante el distintivo múltiplex "multiplex" indicado en la cuarta fila Rp4 del mensaje de respuesta IPBCP del tipo "MIME" del protocolo IuFP, se indica a la primera unidad de pasarela de medios MGW-A que el enlace de datos útiles descrito en el mensaje de respuesta IPBCP ha sido asignado a un enlace múltiplex. Mediante el parámetro adicionalmente transmitido "user_connection_id" con el valor "11", se comunica a la primera unidad de pasarela de medios MGW-A el distintivo asociado por la segunda unidad de pasarela de medios MGW-B al enlace de datos útiles dentro del enlace múltiplex.

En la primera fila RP1 del mensaje de respuesta IPBCP se indica la dirección de IP asignada por la segunda unidad de pasarela de medios MGW-B, por ejemplo "host.example.com", a la que conduce el enlace múltiplex mv.

En la segunda fila Rp2 del mensaje de respuesta IPBCP se indica el número de puerto "49170" asignado mediante la segunda unidad de pasarela de medios MGW-B, a la que se ha conducido el enlace múltiplex mv en la segunda unidad de pasarela de medios MGW-B. Indirectamente, designa ésta con ello también el enlace múltiplex mv elegido. También puede provocar la segunda unidad de pasarela de medios MGW-B que la primera unidad de pasarela de medios MGW-A establezca, mediante indicación de un número de puerto no utilizado hasta ahora, un nuevo enlace multiplex mv.

La falta de un distintivo múltiplex "multiplex" en la cuarta fila Rp4 del mensaje de respuesta IPBCP indica a la primera unidad de pasarela de medios MGW-A que para establecer el enlace de datos útiles no se utiliza ningún enlace múltiplex, sino que se establece, análogamente al procedimiento actualmente estandarizado, mediante la dirección de IP transmitida y el correspondiente número de puerto, un enlace de datos útiles sencillo, no multiplexado. Un mensaje de respuesta IPBCP sin distintivo múltiplex "multiplex" sería enviado también por una unidad de pasarela de medios MGW-2 estandarizada hasta ahora que no entiende el distintivo múltiplex "multiplex" en la cuarta fila Rq4 del mensaje de solicitud IPBCP y por lo tanto lo ignora y sólo apoya el transporte de enlaces de datos útiles fuera de enlaces múltiplex.

Para explicar un caso de aplicación alternativo para el procedimiento correspondiente a la invención, se representa en la figura 4 de forma simplificada, en un esquema de bloques de circuitos, la arquitectura de red de un sistema de comunicaciones IMS o bien basado en (IMS) "Internet Multimedia Subsystem" (subsistema multimedia de Internet) o bien que ya mediante el organismo de estandarización "Telecoms & Internet converged Services & Protocols for Advanced Networks" (TISPAN), (servicios y protocolos convergentes de telecom e Internet para redes avanzadas), presenta ampliaciones estandarizadas así como protocolos utilizados.

El sistema de comunicaciones IMS presenta por ejemplo un primer hasta un tercer aparatos terminales de comunicaciones T1 a T3, que apoyan en cada caso el protocolo "Session Initiation Protocol" (SIP) o protocolo de iniciación de sesión SIP. El primer hasta tercero aparatos terminales de comunicaciones T1 a T3 están unidos mediante el protocolo SIP (SDP) con una llamada "Access Boarder Gateway" (ABG), unidad de pasarela de frontera de acceso ABG, y a su través conectados a la red núcleo SIP.

Según el estándar fijado por TISPAN, se realizan las funciones asignadas de manera estándar a la unidad ABG mediante varios elementos de red conectados entre sí, siendo las mismas una llamada unidad "Proxy Call Session Control Function" (P-CSCF) o unidad funcional de control de la sesión de llamadas del proxy, una unidad "Service-based Policy Decision Function" (SPDF) o unidad funcional de decisión de la política basada en el servicio y una unidad "Boarder Gateway Function" (BGF) o unidad funcional de pasarela de frontera. Al respecto controla la unidad P-CSCF, basándose en los datos de señalización SIP, la unidad SPDF, que por su parte controla a su vez la unidad BGF.

En el sistema de comunicaciones IMS pueden estar previstas también las llamadas unidades "Application Server" (AS) o unidades del servidor de aplicación, que proporcionan aplicaciones seleccionadas como por ejemplo un servicio de comunicaciones "Push-To-Talk" (pulsar para hablar).

Además pueden preverse unidades "Media Ressource Functions" (MRF) o unidades funcionales de recursos de medios, que sirven como puente de conferencia y que están constituidas por dos elementos de red, que son una llamada unidad (MRFC) de controlador MRF y una llamada unidad (MRFP) de procesador MRF.

Además puede estar conectado el sistema de comunicaciones IMS mediante una unidad (BG) "Boarder Gateway" o pasarela de frontera con otros sistemas de comunicaciones IP ó IMS. La unidad BG presenta para ello una unidad (IBCF) "Interconnection Boarder Control Function" (función de control de frontera de interconexión), una unidad SPDF y una unidad BGF.

Mediante una unidad de pasarela (PSTN-G) "PSTN Gateway", puede unirse el sistema de comunicaciones IMS con una "Public Switched Telephone Network" PSTN (red telefónica conmutada pública). Ésta presenta para ello una unidad (MGCF) "Media Gateway Control Function" (función de control de la pasarela de medios), así como una unidad (IM-MGW) "Internet Multimedia Mediagateway" (pasarela de medios multimedia de Internet).

La señalización SIP se retransmite en el sistema de comunicaciones IMS mediante una unidad (CSCF) "Call Session Control Functions" (funciones de control de la sesión de llamadas), intercambiando el primero al tercer aparato terminal de comunicaciones T1 a T3 mediante la unidad P-CSCF y ésta a su vez mediante la unidad CSCF con en cada caso la unidad IBCF, MGCF, MRFC y AS, datos de señalización, que se transmiten mediante el protocolo
SDP.

Para el transporte de datos útiles entre el primer al tercer aparato terminal de comunicaciones T1 a T3, las unidades BGF, la unidad IM-MGW, la unidad MRFP y la unidad AS, están unidos los mismos entre sí mediante el protocolo RTP, UDP e IP. Además de los datos útiles, se transmite también el protocolo (RTCP) "Real Time Control Protocol" de control del tiempo real, estandarizado en RFC 3550. A diferencia del ejemplo de ejecución representado en la figura 1 del dominio 3GPP CS, no se utiliza el protocolo IuFP en el sistema de comunicaciones IMS. Pero no obstante también aquí es de esperar que entre dos elementos de red de la red núcleo IMS (en cada caso BGF, IM-MGW, MRFP ó AS) se transmitan casi a la vez muchos enlaces de datos útiles, los cuales exigen la puesta a disposición de una gran anchura de banda. Para poder ahorrar anchura de banda, es adecuada la previsión de enlaces múltiplex para transmitir varios enlaces de datos útiles que presentan atributos similares.

En la figura 3 se representa a modo de ejemplo la estructura de un paquete de datos DP de un enlace múltiplex mv, mostrando el formato posible de un paquete de datos multiplexado, tal como el que podría estar previsto por ejemplo en las interfaces indicadas en la figura 4. La estructura se corresponde en gran medida con la representada en la figura 2. No obstante, a diferencia de ello, se prevé en lugar de los campos de datos IuFP IuFP1 a IuFP3, campos de datos RTP RTP1 y RTP2 que apoyan el protocolo RTP. Esto es necesario en particular debido a los enlaces de datos útiles realizados como enlace punto-a-punto, para poder prever un restablecimiento de los datos útiles directamente en la unidad codificadora o en la unidad decodificadora por ejemplo en el correspondiente aparato terminal de comunicaciones T1 a T3.

Además de los enlaces de datos útiles transmitidos según el protocolo RTP, pueden también están previstos enlaces de control RTCP asociados en un campo de datos del paquete de datos DP multiplexado. Para ello se asigna a éste, análogamente a los demás enlaces de datos útiles, un distintivo ID3.

Además, se prevé en la cabecera (header) del paquete de datos DP multiplexado igualmente un campo de datos RTP. En los datos transmitidos en el campo de datos RTP pueden obtenerse por ejemplo informaciones sobre jitter (variación irregular) y pérdidas de paquetes en el tramo de transmisión, que pueden existir entre los distintos elementos de red en la red núcleo (en cada caso BGF, IM-MGW, MRFP ó AS).

A continuación se explica a modo de ejemplo la estructura de un mensaje "SDP-Offer" (de oferta SDP) y de un mensaje "SDP-Answer" (de respuesta SDP) según el estándar IETF RFC 3264, que por ejemplo se intercambian mediante el protocolo de señalización SIP entre por ejemplo dos elementos de red o bien elementos de nodo de la red núcleo IMS y que contienen ampliaciones correspondientes a la invención.

Como elementos de nodo pueden estar previstos por ejemplo la unidad AS, la unidad BGF, la unidad ABG, la unidad PSTN-G o una unidad MRF. Se utiliza por ejemplo la estructura representada en la figura 3 de un paquete de datos DP multiplexado.

A diferencia de la estructura antes descrita de los mensajes IPBCP, sirve el intercambio de mensajes representado a continuación adicionalmente para asignar los procedimientos de codificación utilizados para la transmisión y puede estar referido a varios enlaces de datos útiles.

\underbar{Mensaje Offer-SDP (de oferta SDP) (nodo A -> nodo B)}:

01: c=In IP4 host.anywhere.com

02: m=audio 49170 RTP/AVP 98 3 96 97

03: a=rtpmap: 98 VND.3GPP.IUFP/16000

04: a=fmtp: 97 multiplex

05: a=rtpmap: 97 AMR

06: a=fmtp: 97 mode-set = 0,2,5,7; mode-change-period=2

07: a=rtpmap: 96 telephone-event

\vskip1.000000\baselineskip

\underbar{Mensaje SDP-Answer (de respuesta SDP) (nodo B -> nodo A)}:

A1: c=In IP4 host.example.com

A2: m=audio 49320 RTP/AVP 98

A3: a=rtpmap: 98 VND.3GPP.IUFP/16000

A4: a=fmtp: 98 multiplex; rtp_payload_types = 96, 97; user_connection_id = 11; rtcp_connection_id = 12

A5: a=rtpmap: 97 AMR

A6: a=fmtp: 97 mode-set=0,2,5,7; mode-change-period = 2

A7: a=rtpmap: 96 telephone-event

\vskip1.000000\baselineskip

El mensaje "Offer-SDP" se transmite para ello del primer nodo de red A al segundo nodo de red B. Por ejemplo, se indican en la segunda fila O2 del mensaje Offer-SDP distintos procedimientos de codificación, que son "GSM-FR", "AMR", así como "Telephone Event" (evento telefónico). Estos procedimientos de codificación se inscriben mediante el parámetro RTP "payload types" (tipos de carga útil) asignando los valores "3", "96" y "97" en la segunda fila O2 del mensaje Offer-SDP. Los otros parámetros previstos en la quinta, sexta y séptima fila O5, O6 y O7 según el protocolo SDP estandarizado, se describirán después. Además de ello, se asigna en la segunda fila O2 como RTP-Payload-Type el valor "98" que indica el protocolo IuFP multiplexado y que se describirá más en detalle mediante los otros parámetros previstos en la tercera y en la cuarta fila O3, O4.

Mediante el parámetro "multiplex" indicado en la cuarta fila O4 del tipo MIME del protocolo IuFP, se indica mediante el primer nodo de red nodo A que genera el mensaje SDP-Offer al segundo nodo de red nodo B que el mismo desea la asignación del o de los enlaces de datos descritos en la segunda fila O2 a un enlace múltiplex.

En la primera fila O1 del mensaje SDP-Offer se indica mediante el primer nodo de red nodo A la dirección de IP asignada al mismo, por ejemplo "host.anywhere.com" a la que debe ser conducido el enlace múltiplex mv.

En la segunda fila 02 del mensaje SDP-offer, se indica mediante el primer nodo de red nodo A un número de puerto libre asociado a éste, por ejemplo el 49170, que podría utilizarse para establecer un nuevo enlace múltiplex. Si en el mensaje SDD-offer no está incluido ningún parámetro "multiplex", entonces, análogamente al procedimiento antes descrito, han de preverse la dirección de IP indicada y el número de puerto para establecer un enlace de datos útiles sencillo, no multiplexado. En el caso de que no esté previsto un apoyo de una transmisión múltiplex y/o del RTP Payload Types por parte del protocolo IuFP en el segundo nodo de red nodo B, entonces puede igualmente tenerse la dirección de IP y número de puerto para establecer un enlace de datos útiles sencillo, no multiplexado, con el primer nodo de red nodo A.

Tras evaluar el mensaje SDP-Offer, elige el segundo nodo de red nodo B según la invención un enlace múltiplex para la dirección de IP "host.anywhere.com", por ejemplo el enlace múltiplex con el número de puerto "49320" en el segundo nodo de red nodo B.

El segundo nodo de red nodo B elige además de entre los procedimientos de codificación indicados mediante el mensaje SDP-Offer, por ejemplo "AMR" y "Telefone event" (evento telefónico) (RTP payboad types 96 y 97). Adicionalmente, se asigna mediante el segundo nodo de red nodo B en el enlace de datos útiles un primer distintivo, por ejemplo "11", y se asigna al enlace RTCP asociado otro distintivo para caracterizar los enlaces de datos útiles, por ejemplo "12".

En el caso de que aún no exista ningún enlace múltiplex para la dirección de IP "host.anywhere.com" indicada, se establece la misma mediante el mensaje SDP-Answer hacia el segundo nodo de red nodo B, y precisamente para la dirección de IP "host.anywhere.com" y para el número de puerto "49170" en el primer nodo de red nodo A. En este caso está configurado el puerto con el número "49320" como un puerto no utilizado hasta ahora del segundo nodo de red nodo B. En la elección de un enlace múltiplex mv ya existente, indica el número de puerto "49320" el número de puerto asignado en el segundo nodo de red nodo B del enlace múltiplex mv y el número de puerto "49170" el número de puerto ya asignado en el primer nodo de red nodo A a este enlace múltiplex.

El segundo nodo de red nodo B genera en el marco de la invención un mensaje de respuesta SPD y lo transmite al primer nodo de red nodo A, el cual contiene las siguientes informaciones.

En la segunda fila A2 del mensaje de respuesta SPD se indica el RTP-Payload-Type elegido para el protocolo IuFP, por ejemplo "98" y en la cuarta fila A4 se indica el parámetro "multiplex" del tipo MIME del protocolo IuFP, con lo que se le indica al primer nodo de red nodo A que el enlace de datos útiles descrito en el SDP línea de medios A2 está asociado a un enlace múltiplex mv.

Mediante el parámetro "rtp-payload-types" del tipo MIME del protocolo IuFP, se le indica al primer nodo de red nodo A mediante el segundo nodo de red nodo B los RTP Payload Types elegidos para este enlace de datos útiles, por ejemplo "96" para el procedimiento de codificación AMR y 97 para el procedimiento de codificación "Telefone-event". Los citados RTP-Payload-Types se definen más en detalle en las filas quinta a séptima 05 a 07.

En la cuarta fila A4 se inserta el parámetro "user_connection_id" del tipo MIME del protocolo IuFP, que indica al primer nodo de red nodo A que el enlace de datos útiles descrito en la segunda fila A2 lleva asignado el primer distintivo, por ejemplo "11". Mediante el parámetro "rtcp_connection_id" del tipo MIME del protocolo IuFP, indicado en la cuarta fila A4, se le indica al primer nodo de red nodo A que el enlace RTCP asociado al enlace de datos útiles descrito en la segunda fila A2, lleva asignado el segundo distintivo, por ejemplo "12".

En la primera fila A1 se asigna la dirección de IP asignada al segundo nodo de red nodo B, por ejemplo
"host.example.com" a través de la que conduce el enlace múltiplex mv y se indica en la segunda fila A2 el número de puerto, por ejemplo "49170", en el que se reciben los paquetes de datos DP transmitidos a través del enlace múltiplex.

El primer y el segundo nodo de red nodo A, nodo B pueden estar compuestos, tal como se representa en la figura 4, por respectivas unidades de control competentes para la señalización SIP, por ejemplo la unidad P-CSCF, IBCF, MGCF o MRCF, y una unidad de procesador competente para los enlaces de datos útiles, por ejemplo la unidad BGF, IM-MGW o MRFP. La unidad de procesador y la unidad de control se comunican entre sí en cada caso por ejemplo según el estándar ITU-T H.248. En una forma de ejecución preferente, la unidad del procesador es competente para la gestión de los enlaces múltiplex mv, así como la asignación de las informaciones de dirección de los enlaces de datos útiles.

Antes de la transmisión del mensaje SDP-Offer (de oferta SDP), intercambian la unidad de control y la unidad de procesador del correspondiente nodo de red nodo A, nodo B, según el estándar existente, mensajes entre sí. La unidad de procesador comunica a la unidad de control en particular su dirección de IP, por ejemplo "host.anywhere.com", así como el número del puerto que le ha sido designado, por ejemplo "49170". La señalización se amplía además en el sentido de que mediante la unidad de procesador se indica respecto a la unidad de control que la misma desea utilizar un enlace múltiplex. Por ejemplo puede transmitirse para ello el RTP-Payload en el protocolo IuFP según la segunda hasta la cuarta fila 02 a 04 mediante un mensaje H.248 elegido desde la unidad de procesador a la unidad de control.

Entre la recepción del mensaje de oferta SDP y la emisión del mensaje de respuesta SDP, se intercambian mensajes entre la unidad de control y la unidad de procesador del correspondiente nodo de red nodo A, nodo B, según el estándar existente. Por ejemplo, comunica la unidad de procesador allí ya la dirección de IP recibida en el mensaje de oferta SPD, así como el número de puerto recibido. En una forma de ejecución preferente, señaliza la unidad de control a la unidad del procesador también que se desea multiplexado. Esto se realiza por ejemplo mediante la retransmisión del RTP-Payload para el protocolo IuFP según la segunda hasta la cuarta fila 02 a 04 mediante un mensaje H.248 adecuado.

Mediante la unidad de procesador se elige a continuación el enlace múltiplex y a los enlaces de datos útiles se les asigna el correspondiente distintivo. La unidad de procesador comunica ya a la unidad de control su dirección de IP y el número del puerto que se le ha asignado.

En el caso de que se encuentre una SPDF entre la unidad de control y la unidad de procesador, retransmite ésta en cada caso las informaciones descritas.

La invención se ha descrito antes en base un ejemplo de ejecución. Se entiende que son posibles numerosas modificaciones así como desviaciones, sin que debido a ello se abandone la idea inventiva que sirve de base a la invención.

Lista de referencias

ABG: unidad de pasarela de frontera de acceso

AN1: primera red de acceso

AN2: segunda red de acceso

AS: unidades del servidor de aplicación

BG: unidad de pasarela de frontera

BGF: unidad funcional de pasarela de frontera

IBCF: unidad funcional de control de frontera de interconexión

ID1: primera información de dirección

ID2: segunda información de dirección

ID3: tercera información de dirección

IM-MGW: unidad de pasarela de medios multimedia de Internet

IMS: sistema de comunicaciones basado en IMS

IP: campo de datos de IP

Iu: enlace de datos Iu

IuFP1: primer campo de datos IuFP

IuFP2: segundo campo de datos IuFP

IuFP3: tercer campo de datos IuFP

KAT1: primer aparato terminal móvil de comunicaciones

KBT2: segundo aparato terminal móvil de comunicaciones

MKS: sistema móvil de comunicaciones

MGCF: unidad funcional de control de la pasarela de medios

MGW-A: primera unidad de pasarela de medios

MGW-B: segunda unidad de pasarela de medios

MGW-T: tercera unidad de pasarela de medios

MKD: servicio de comunicaciones

MKD: servicio de comunicaciones basado en datos multimedia

MP1: primer campo de datos múltiplex

MP2: segundo campo de datos múltiplex

MP3: tercer campo de datos múltiplex

MRF: unidades funcionales de recursos de medios

MRFC: unidad de controlador MRF

MRFP: unidad de procesador MRF

MSC-A: primera unidad de conmutación móvil

MSC-B: segunda unidad de conmutación móvil

MSC-S-A: primera unidad de servidor MSC

MSC-S-B: segunda unidad de servidor MSC

mv: enlaces múltiplex

Nb: enlace de datos Nb

P-CSCF: unidad funcional de control de la sesión de llamadas de proxy

PSTN: red telefónica conmutada pública

PSTN-G: unidad de pasarela PSTN

RAB: parámetro RAB

RNC: unidad de controlador de la red de radio

RTP: campo de datos RTP

SIP: protocolo de iniciación de sesión

SPDF: unidad funcional de decisión de la política basada en el servicio

T3: tercer aparato terminal de comunicaciones

UC1: primer enlace de datos útiles

UC2: segundo enlace de datos útiles

UC3: tercer enlace de datos útiles

UDP: campo de datos UDP

Claims

1. Procedimiento para la asignación de al menos un enlace de datos útiles a al menos un enlace múltiplex previsto entre un primer elemento de red (MSC-A) y un segundo elementos de red (MSC-B),

caracterizado porque el primer elemento de red (MSC-A) genera un primer mensaje de señalización y lo transmite al segundo elemento de red (MSC-B), indicándole mediante el primer mensaje de señalización al segundo elemento de red (MSC-A) la disponibilidad del primer elemento de red (MSC-A) para el transporte del enlace de datos útiles, de los que al menos hay uno, a través del respectivo enlace múltiplex,

porque en función de la disponibilidad indicada del primer elemento de red (MSC-A) y de si el transporte del enlace de datos útiles, de los que al menos hay uno, es apoyado a través de un enlace múltiplex por el segundo elemento de red (MSC-B), el segundo elemento de red (MSC-B) asigna a cada uno de los enlaces de datos útiles, de los que al menos hay uno, bien un enlace múltiplex entre el primer elemento de red (MSC-A) y el segundo elemento de red (MSC-B) o bien elige para este enlace de datos útiles un transporte fuera de un enlace múltiplex y

porque mediante un segundo mensaje de señalización generado en el segundo elemento de red (MSC-B) y transmitido al primer elemento de red (MSC-A), se le indica al primer elemento de red (MSC-A) la posible asignación del enlace de datos útiles, de los que al menos hay uno, a un enlace múltiplex (mv).

2. Procedimiento según la reivindicación 1,

caracterizado porque la disponibilidad del primer elemento de red (MSC-A) para el transporte del enlace de datos útiles, de los que al menos hay uno, a través de un enlace múltiplex, se señaliza mediante un distintivo múltiplex previsto en el primer mensaje de señalización.

3. Procedimiento según una de las reivindicaciones 1 ó 2,

caracterizado porque en el primer mensaje de señalización se transmite una primera información de dirección asignada al primer elemento de nodo de red (MSC-A).

4. Procedimiento según una de las reivindicaciones 1 a 3,

caracterizado porque el segundo elemento de red (MSC-B) elige el enlace múltiplex asociado con ayuda de la primera información de dirección contenida en el primer mensaje de señalización.

5. Procedimiento según una de las reivindicaciones 1 a 4,

caracterizado porque cuando existen varios enlaces múltiplex disponibles para establecer el enlace de datos útiles entre el primer elemento de red (MSC-A) y el segundo elemento de red (MSC-B), el segundo elemento de red (MSC-B) asigna uno de estos enlaces múltiplex que presenta suficientes recursos de transmisión libres para el transporte del enlace de datos útiles.

6. Procedimiento según una de las reivindicaciones 1 a 5,

caracterizado porque el enlace múltiplex se establece automática y dinámicamente.

7. Procedimiento según una de las reivindicaciones 1 a 6,

caracterizado porque mediante la asignación de un enlace múltiplex (mv) por parte del segundo elemento de red (MSC-B), se provoca el establecimiento dinámico de estos enlaces múltiplex.

8. Procedimiento según una de las reivindicaciones 1 a 7,

caracterizado porque al nuevo enlace múltiplex (mv) establecido dinámicamente, para recibir datos por parte del primer elemento de red (MSC-A), se le asigna un número del puerto UDP contenido en el primer mensaje de señalización, y

porque a un enlace múltiplex ya existente permanece asignado un número de puerto UDP ya asignado previamente.

9. Procedimiento según la reivindicación 1 a 8,

caracterizado porque la asignación del enlace de datos útiles, de los que al menos hay uno, a un enlace múltiplex, se le indica al primer elemento de red (MSC-A) mediante un distintivo múltiplex previsto en el segundo mensaje de señalización.

\newpage

10. Procedimiento según la reivindicación 1 a 9,

caracterizado porque en el segundo mensaje de señalización se indica el enlace múltiplex (mv) asignado, preferiblemente mediante un número de puerto UDP.

11. Procedimiento según una de las reivindicaciones 1 a 10,

caracterizado porque mediante el segundo elemento de red (MSC-B) se asigna un distintivo al enlace de datos útiles asignado a un enlace múltiplex (mv).

12. Procedimiento según la reivindicación 11,

caracterizado porque el distintivo se indica en el segundo mensaje de señalización al primer elemento de red (MSC-A).

13. Procedimiento según la reivindicación 11 ó 12,

caracterizado porque el distintivo se transmite en cada caso en un campo de datos de un paquete de datos (DP) del enlace múltiplex (mv).

14. Procedimiento según una de las reivindicaciones 1 a 13,

caracterizado porque para establecer un enlace de datos útiles en un sistema de telefonía móvil (MKS), se intercambian un mensaje IPBCP-Request (de solicitud IPBCP) y un mensaje IPBCP-Response (de respuesta IPBCP) entre los elementos de red configurados en cada caso como unidad de conmutación móvil (MSC-A, MSC-B) y conectados entre sí a través de un enlace de señalización BICC.

15. Procedimiento según una de las reivindicaciones 11 a 14,

caracterizado porque como distintivo múltiplex se transmite un atributo "Session Description Protocol" (SDP) o protocolo de descripción de sesión, o bien un parámetro "Multimedia Internet Message Extension" (MIME), de extensión del mensaje de Internet multimedia configurado según el estándar TS 29. 414.

16. Procedimiento según una de las reivindicaciones 9 a 15,

caracterizado porque cuando la segunda unidad de conmutación móvil (MSC-B), no apoya el establecimiento del enlace de datos útiles a través de un enlace múltiplex se establece un enlace de datos sencillo entre las direcciones de IP y números de puerto indicados.

17. Procedimiento según una de las reivindicaciones 1 a 16,

caracterizado porque para establecer un enlace de datos útiles en un sistema de comunicaciones (IMS) basado en IMS, se intercambian un mensaje SDP-Offer (de oferta SDP) y un mensaje SDP-Answer (de respuesta SDP) entre los elementos de red conectados entre sí mediante un enlace de señalización SIP.

18. Procedimiento según la reivindicación 17,

caracterizado porque como distintivo múltiplex se transmite un atributo "Session Description Protocol" (SDP) o protocolo de descripción de la sesión o un parámetro "Multimedia Internet Message Extensión" (MIME) de extensión del mensaje de Internet multimedia, configurado según el estándar TS 29. 414.

19. Procedimiento según una de las reivindicaciones 1 a 18,

caracterizado porque el correspondiente enlace múltiplex (mv) se termina mediante en cada caso el primer y el segundo elemento de red (MSC-A, MSC-B).