ES2329420T3 - Procedimiento para asignar al menos un enlace de datos utiles a al menos un enlace multiplex. - Google Patents
Procedimiento para asignar al menos un enlace de datos utiles a al menos un enlace multiplex. Download PDFInfo
- Publication number
- ES2329420T3 ES2329420T3 ES07704106T ES07704106T ES2329420T3 ES 2329420 T3 ES2329420 T3 ES 2329420T3 ES 07704106 T ES07704106 T ES 07704106T ES 07704106 T ES07704106 T ES 07704106T ES 2329420 T3 ES2329420 T3 ES 2329420T3
- Authority
- ES
- Spain
- Prior art keywords
- link
- msc
- multiplex
- network element
- useful data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 45
- 230000011664 signaling Effects 0.000 claims abstract description 31
- 238000004891 communication Methods 0.000 claims description 23
- 230000005540 biological transmission Effects 0.000 claims description 20
- 230000004044 response Effects 0.000 claims description 16
- 230000000977 initiatory effect Effects 0.000 description 5
- YOETUEMZNOLGDB-UHFFFAOYSA-N 2-methylpropyl carbonochloridate Chemical compound CC(C)COC(Cl)=O YOETUEMZNOLGDB-UHFFFAOYSA-N 0.000 description 4
- 238000010295 mobile communication Methods 0.000 description 4
- 230000003044 adaptive effect Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 102000018059 CS domains Human genes 0.000 description 1
- 108050007176 CS domains Proteins 0.000 description 1
- 102100021467 Histone acetyltransferase type B catalytic subunit Human genes 0.000 description 1
- 101000898976 Homo sapiens Histone acetyltransferase type B catalytic subunit Proteins 0.000 description 1
- 101000857634 Homo sapiens Receptor-transporting protein 1 Proteins 0.000 description 1
- 101000635752 Homo sapiens Receptor-transporting protein 2 Proteins 0.000 description 1
- 102100025426 Receptor-transporting protein 1 Human genes 0.000 description 1
- 102100030850 Receptor-transporting protein 2 Human genes 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000001788 irregular Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000008569 process Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/102—Gateways
- H04L65/1033—Signalling gateways
- H04L65/104—Signalling gateways in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/102—Gateways
- H04L65/1023—Media gateways
- H04L65/103—Media gateways in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/102—Gateways
- H04L65/1043—Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/164—Adaptation or special uses of UDP protocol
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Security & Cryptography (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Time-Division Multiplex Systems (AREA)
- Telephonic Communication Services (AREA)
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.
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.
"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.
"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.
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.
"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.
- 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 (19)
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).
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP06001745 | 2006-01-27 | ||
| EP06001745A EP1814278B1 (de) | 2006-01-27 | 2006-01-27 | Verfahren zur Zuordnung von zumindest einer Nutzdatenverbindung zu zumindest einer Multiplexverbindung |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2329420T3 true ES2329420T3 (es) | 2009-11-25 |
Family
ID=36608694
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES07704106T Active ES2329420T3 (es) | 2006-01-27 | 2007-01-24 | Procedimiento para asignar al menos un enlace de datos utiles a al menos un enlace multiplex. |
Country Status (10)
| Country | Link |
|---|---|
| US (2) | US8089867B2 (es) |
| EP (4) | EP1814278B1 (es) |
| JP (1) | JP5185827B2 (es) |
| CN (2) | CN101375577A (es) |
| AT (2) | ATE428253T1 (es) |
| DE (2) | DE502006003374D1 (es) |
| EA (2) | EA020306B1 (es) |
| ES (1) | ES2329420T3 (es) |
| PL (1) | PL2073480T3 (es) |
| WO (1) | WO2007085606A1 (es) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2008098501A1 (fr) * | 2007-02-02 | 2008-08-21 | Huawei Technologies Co., Ltd. | Procede, appareil et systeme de reglage de relevement gsm |
| WO2009129861A1 (en) * | 2008-04-25 | 2009-10-29 | Nokia Siemens Networks Oy | Network entity selection |
| JP5390632B2 (ja) * | 2008-12-22 | 2014-01-15 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | 多数のｉｐホストからのｉｐ多重化 |
| US9712341B2 (en) * | 2009-01-16 | 2017-07-18 | Tekelec, Inc. | Methods, systems, and computer readable media for providing E.164 number mapping (ENUM) translation at a bearer independent call control (BICC) and/or session intiation protocol (SIP) router |
| US9219677B2 (en) | 2009-01-16 | 2015-12-22 | Tekelec Global, Inc. | Methods, systems, and computer readable media for centralized routing and call instance code management for bearer independent call control (BICC) signaling messages |
| JP5935622B2 (ja) * | 2012-09-18 | 2016-06-15 | 富士通株式会社 | 情報処理装置，監視装置，情報処理方法，及び監視プログラム |
| EP2785001B1 (en) * | 2013-03-27 | 2017-09-27 | Unify GmbH & Co. KG | Method of negotiation of media between a source communication device and a destination communication device for multiplexing multiple media types on an IP transport address, a computer program product for executing the method, and a source communication device for negotiating of the media between the source communication device and a destination communication device |
| CN104345510B (zh) * | 2014-09-26 | 2017-10-03 | 京东方科技集团股份有限公司 | 液晶面板以及液晶面板的制造方法 |
| CN104301551B (zh) * | 2014-10-11 | 2017-11-28 | 新华三技术有限公司 | 一种音乐播放的方法和设备 |
| CN108353072B (zh) * | 2015-11-09 | 2021-08-10 | 诺基亚通信公司 | web实时通信场景中的增强媒体平面优化 |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FI101924B1 (fi) * | 1995-12-18 | 1998-09-15 | Nokia Telecommunications Oy | Matkapuhelinkeskusten välinen kanavanvaihto suurnopeusdatasiirrossa |
| US6014378A (en) * | 1996-11-22 | 2000-01-11 | Sprint Communications Company, L.P. | Telecommunications tandem system for circuit-based traffic |
| CA2284023C (en) * | 1997-03-21 | 2007-07-03 | Canal + Societe Anonyme | Broadcast and reception system, and conditional access system therefor |
| US6195353B1 (en) * | 1997-05-06 | 2001-02-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Short packet circuit emulation |
| JP3663893B2 (ja) * | 1998-03-12 | 2005-06-22 | 株式会社日立製作所 | データ中継システム |
| JPH11267648A (ja) | 1998-03-24 | 1999-10-05 | Tokai Carbon Co Ltd | 電気化学的水処理装置 |
| DE19827056A1 (de) | 1998-06-18 | 1999-12-23 | Bosch Gmbh Robert | Mikromechanischer Magnetfeldsensor |
| US6366961B1 (en) | 1999-03-03 | 2002-04-02 | Nokia Telecommunications, Oy | Method and apparatus for providing mini packet switching in IP based cellular access networks |
| US6993021B1 (en) * | 1999-03-08 | 2006-01-31 | Lucent Technologies Inc. | Lightweight internet protocol encapsulation (LIPE) scheme for multimedia traffic transport |
| CN101917745B (zh) * | 1999-05-17 | 2013-05-01 | 艾利森电话股份有限公司 | 用于电信网络中的能力协商的系统、设备和方法 |
| AU4919700A (en) | 1999-05-17 | 2000-12-05 | Telefonaktiebolaget Lm Ericsson (Publ) | Capability negotiation in a telecommunications network |
| DE10122419B4 (de) * | 2001-05-09 | 2007-11-08 | Siemens Ag | Verfahren zur dynammischen Kanalzuordnung |
| AUPR754001A0 (en) * | 2001-09-06 | 2001-09-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and system of enabling a generic telecommunications service in gateway control protocols |
| CN101180866B (zh) * | 2005-05-19 | 2010-11-10 | Ut斯达康通讯有限公司 | 基于sip fork的语音服务应用中多回铃音的一种处理方法 |
| CN100459518C (zh) * | 2005-09-02 | 2009-02-04 | 华为技术有限公司 | 资源接纳控制处理方法 |
-
2006
- 2006-01-27 EP EP06001745A patent/EP1814278B1/de not_active Not-in-force
- 2006-01-27 AT AT06001745T patent/ATE428253T1/de not_active IP Right Cessation
- 2006-01-27 EP EP09001907A patent/EP2058996A1/de not_active Withdrawn
- 2006-01-27 DE DE502006003374T patent/DE502006003374D1/de active Active
-
2007
- 2007-01-24 US US12/162,281 patent/US8089867B2/en active Active
- 2007-01-24 WO PCT/EP2007/050674 patent/WO2007085606A1/de active Application Filing
- 2007-01-24 EA EA200900848A patent/EA020306B1/ru not_active IP Right Cessation
- 2007-01-24 EP EP09005128.5A patent/EP2073480B1/de not_active Not-in-force
- 2007-01-24 DE DE502007001133T patent/DE502007001133D1/de not_active Expired - Fee Related
- 2007-01-24 CN CNA2007800034006A patent/CN101375577A/zh active Pending
- 2007-01-24 ES ES07704106T patent/ES2329420T3/es active Active
- 2007-01-24 JP JP2008551778A patent/JP5185827B2/ja not_active Expired - Fee Related
- 2007-01-24 CN CN201210197788.0A patent/CN102710654B/zh active Active
- 2007-01-24 EA EA200870203A patent/EA012519B1/ru not_active IP Right Cessation
- 2007-01-24 PL PL09005128T patent/PL2073480T3/pl unknown
- 2007-01-24 EP EP07704106A patent/EP1994714B1/de not_active Not-in-force
- 2007-01-24 AT AT07704106T patent/ATE437520T1/de active
-
2011
- 2011-10-31 US US13/285,509 patent/US8811162B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| EP1994714B1 (de) | 2009-07-22 |
| US8089867B2 (en) | 2012-01-03 |
| US8811162B2 (en) | 2014-08-19 |
| DE502006003374D1 (de) | 2009-05-20 |
| PL2073480T3 (pl) | 2014-09-30 |
| EA012519B1 (ru) | 2009-10-30 |
| CN101375577A (zh) | 2009-02-25 |
| JP5185827B2 (ja) | 2013-04-17 |
| EA200900848A1 (ru) | 2010-02-26 |
| WO2007085606A1 (de) | 2007-08-02 |
| EA020306B1 (ru) | 2014-10-30 |
| EP2073480A1 (de) | 2009-06-24 |
| EP1814278B1 (de) | 2009-04-08 |
| JP2009524960A (ja) | 2009-07-02 |
| EP2058996A1 (de) | 2009-05-13 |
| US20090010217A1 (en) | 2009-01-08 |
| EP1814278A1 (de) | 2007-08-01 |
| DE502007001133D1 (de) | 2009-09-03 |
| ATE428253T1 (de) | 2009-04-15 |
| EP1994714A1 (de) | 2008-11-26 |
| CN102710654B (zh) | 2015-05-06 |
| US20120113916A1 (en) | 2012-05-10 |
| EA200870203A1 (ru) | 2009-02-27 |
| CN102710654A (zh) | 2012-10-03 |
| EP2073480B1 (de) | 2014-04-16 |
| ATE437520T1 (de) | 2009-08-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2329420T3 (es) | Procedimiento para asignar al menos un enlace de datos utiles a al menos un enlace multiplex. | |
| JP5384934B2 (ja) | パケット無線ネットワーク及び通信方法 | |
| JP4970422B2 (ja) | パケット無線ネットワーク及び通信方法 | |
| ES2584455T3 (es) | Sistema, aparato y método para establecer comunicaciones de conmutación de circuitos mediante señalización de red de conmutación de paquetes | |
| CN101094171B (zh) | 实现媒体流交互方法和系统及媒体网关控制器和媒体网关 | |
| KR101031470B1 (ko) | 무선 통신에 대한 서비스 품질 구성 | |
| US8582566B2 (en) | Method and system of forwarding capability information of user equipment in internet protocol multimedia subsystem network | |
| ES2749222T3 (es) | Terminal y procedimiento de selección de modo de codificación | |
| JP4680890B2 (ja) | インターネットデータパケットの通信の通信装置及び通信方法 | |
| ES2365510T3 (es) | Negociación de portadores de conversación. | |
| US9356973B2 (en) | Method for the transmission of signalling data in a network interface unit and in a control unit and corresponding devices | |
| ES2380385T3 (es) | Equipo de usuario que tiene una función de transferencia de medios, entidad que tiene una función de transferencia de medios y método para asegurar la continuidad de una llamada multimedia | |
| CN100440850C (zh) | 多媒体业务网络地址转换穿越的方法及其系统 | |
| EP1760986B1 (en) | Communication method and device for preventing media stream circuity (tromboning) | |
| PT1510090E (pt) | Método para controlar as partes das comunicações de grupos de dados em tempo real usando pacotes de recepção | |
| US8325707B2 (en) | Session initiation from application servers in an IP multimedia subsystem | |
| US20100070632A1 (en) | Method for transmitting information in wireless communication system and terminal supporting the method | |
| JP2007511971A (ja) | Ｉｐアドレス結合に基づいてマルチメディアトラフィックをフィルタリングする方法及びシステム | |
| JP2008205698A (ja) | インターワーキング装置 | |
| US11388202B2 (en) | Network entity selection | |
| KR101453971B1 (ko) | 무선 네트워크와 유선 네트워크의 연동을 위한 장치 및방법 | |
| ES2407479T3 (es) | Comunicaciones en tiempo real entre un teléfono y usuarios de Internet | |
| KR100929083B1 (ko) | 이종망간 서비스 제공 방법 | |
| JP2007318707A (ja) | Ｉｐ通信網の相互接続システム及びｉｐ通信網の相互接続方法 | |
| JP4756007B2 (ja) | 複数のｉｐアドレス体系を持つｉｐ通信網における第三者呼制御（３ｐｃｃ）システム及び３ｐｃｃ実現方法 |