ES2364793A1 - Fijación de la ruta de flujos portadores de ip en una red de próxima generación. - Google Patents
Fijación de la ruta de flujos portadores de ip en una red de próxima generación. Download PDFInfo
- Publication number
- ES2364793A1 ES2364793A1 ES200990004A ES200990004A ES2364793A1 ES 2364793 A1 ES2364793 A1 ES 2364793A1 ES 200990004 A ES200990004 A ES 200990004A ES 200990004 A ES200990004 A ES 200990004A ES 2364793 A1 ES2364793 A1 ES 2364793A1
- Authority
- ES
- Spain
- Prior art keywords
- message
- carrier
- sip
- network
- segment
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 claims abstract description 83
- 230000011664 signaling Effects 0.000 claims abstract description 82
- 238000004891 communication Methods 0.000 claims abstract description 18
- 230000004044 response Effects 0.000 claims description 35
- 238000013519 translation Methods 0.000 claims description 15
- 230000002457 bidirectional effect Effects 0.000 claims description 6
- 230000000977 initiatory effect Effects 0.000 claims description 6
- 238000013507 mapping Methods 0.000 abstract 2
- 230000006870 function Effects 0.000 description 53
- 238000011282 treatment Methods 0.000 description 32
- 239000003795 chemical substances by application Substances 0.000 description 30
- 230000007246 mechanism Effects 0.000 description 25
- 238000010586 diagram Methods 0.000 description 16
- 230000008901 benefit Effects 0.000 description 12
- 230000014616 translation Effects 0.000 description 11
- CVXBEEMKQHEXEN-UHFFFAOYSA-N carbaryl Chemical compound C1=CC=C2C(OC(=O)NC)=CC=CC2=C1 CVXBEEMKQHEXEN-UHFFFAOYSA-N 0.000 description 8
- 239000000969 carrier Substances 0.000 description 8
- 239000000543 intermediate Substances 0.000 description 8
- 238000012546 transfer Methods 0.000 description 7
- 238000011161 development Methods 0.000 description 6
- 230000018109 developmental process Effects 0.000 description 6
- 238000009434 installation Methods 0.000 description 6
- 238000013475 authorization Methods 0.000 description 5
- 230000006399 behavior Effects 0.000 description 5
- 230000008569 process Effects 0.000 description 5
- 230000008859 change Effects 0.000 description 4
- 238000007726 management method Methods 0.000 description 4
- 230000001105 regulatory effect Effects 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 230000004075 alteration Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 2
- 238000012790 confirmation Methods 0.000 description 2
- 230000001276 controlling effect Effects 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000000605 extraction Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000000007 visual effect Effects 0.000 description 2
- YOETUEMZNOLGDB-UHFFFAOYSA-N 2-methylpropyl carbonochloridate Chemical compound CC(C)COC(Cl)=O YOETUEMZNOLGDB-UHFFFAOYSA-N 0.000 description 1
- 235000008694 Humulus lupulus Nutrition 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 230000004888 barrier function Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004140 cleaning Methods 0.000 description 1
- 230000002860 competitive effect Effects 0.000 description 1
- 239000000470 constituent Substances 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000006073 displacement reaction Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 239000003999 initiator Substances 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000000873 masking effect Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000009131 signaling function Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000003245 working effect 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/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
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
-
- H04L29/06183—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/256—NAT traversal
- H04L61/2564—NAT traversal for a higher-layer protocol, e.g. for session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W40/00—Communication routing or communication path finding
- H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
- H04L12/1442—Charging, metering or billing arrangements for data wireline or wireless communications at network operator level
- H04L12/1446—Charging, metering or billing arrangements for data wireline or wireless communications at network operator level inter-operator billing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
- H04L12/1485—Tariff-related aspects
-
- 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/1016—IP multimedia subsystem [IMS]
-
- 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/80—Responding to QoS
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Telephonic Communication Services (AREA)
Abstract
Métodos y sistemas para extender la arquitectura de IMS/SIP de la NGN con el fin de proporcionar servicio de QoS a flujos portadores genéricos. Más particularmente, se proporciona un método para establecer un camino portador de extremo a extremo de una sesión de comunicación en una red de comunicación de múltiples dominios en la que se utiliza un protocolo de señalización fuera de banda para establecer sesiones de comunicaciones. El método comprende recibir un mensaje de señalización fuera de banda que incluye información representativa de al menos un punto de extremo opuesto de un primer segmento portador del camino de extremo a extremo. La información se utiliza para definir una relación de correspondencia de conexión cruzada a través de un nodo de la red entre respectivos puntos de extremo locales del primer segmento portador y del segundo segmento portador alojados por el nodo. Se inserta entonces información representativa de la relación de correspondencia de conexión cruzada en el mensaje de señalización fuera de banda, y se remite el mensaje de señalización fuera de banda.
Description
Fijación de la ruta de flujos portadores de IP
en una red de próxima generación.
\global\parskip0.870000\baselineskip
La presente invención se refiere a Redes de
Próxima Generación y, en particular, a la fijación de la ruta de
Flujos Portadores de Protocolo de Internet (IP -"Internet
Protocol") en una Red de Próxima Generación.
En el momento presente, diversos cuerpos y
consorcios normativos internacionales, tales como el Proyecto de
Sociedad de Tercera Generación (3GPP -"Third Generation
Partnership Project"), el Instituto de Normativa Europea de
Telecomunicaciones (ETSI - "European Telecommunications Standards
Institute") y la Unión Internacional de Telecomunicaciones (ITU
-"International Telecommunications Union"), están participando
en iniciativas para definir una Red de Próxima Generación. De
acuerdo con la ITU-T, la Red de Próxima Generación
(NGN -"Next Generation Network") es una red basada en paquetes
que es capaz de proporcionar servicios, incluyendo Servicios de
Telecomunicaciones, y de hacer uso de múltiples tecnologías de
transporte de banda ancha, de conformidad con la QoS, y en las que
las funciones relacionadas con los servicios son independientes de
las tecnologías relacionas con el transporte subyacentes. La NGN
ofrece un acceso sin restricciones por parte de los usuarios a
diferentes proveedores de servicios. También posibilita una
movilidad generalizada que permitirá una provisión consistente y
ubicua de servicios a los usuarios.
La Red de Próxima Generación está basada,
generalmente, en la arquitectura de Subsistema Multimedia de
Internet (IMS -"Internet Multi-Media
Sub-System"), y utiliza el Protocolo de Inicio de
Sesión (SIP -"Session Initiation Protocol") para gestionar el
establecimiento y la finalización de sesiones de comunicación entre
las partes. Esta disposición resulta ventajosa por cuanto que el
IMS/SIP proporciona un marco para redes de Protocolo de
Internet
(IP -"Internet Protocol"), a fin de establecer sesiones multimedia, incluyendo llamadas telefónicas de Voz por Protocolo de Internet (VoIP -"Voice over Internet Procol"), de un modo que es resistente al fraude, y que permite adoptar la subsiguiente contabilidad y acuerdos entre dominios utilizando métodos muy similares a los actualmente empleados por la Red de Telefonía Pública Conmutada (PSTN -"Public Switched Telephone Network") y los operadores de red celular. Es decir, puede facturarse a los usuarios por cada llamada/sesión individual con un cargo relacionado con el tipo de servicio suministrado, y estos cargos pueden distribuirse adecuadamente a cada una de las redes portadoras (o dominios administrativos) transitados por la llamada/sesión.
(IP -"Internet Protocol"), a fin de establecer sesiones multimedia, incluyendo llamadas telefónicas de Voz por Protocolo de Internet (VoIP -"Voice over Internet Procol"), de un modo que es resistente al fraude, y que permite adoptar la subsiguiente contabilidad y acuerdos entre dominios utilizando métodos muy similares a los actualmente empleados por la Red de Telefonía Pública Conmutada (PSTN -"Public Switched Telephone Network") y los operadores de red celular. Es decir, puede facturarse a los usuarios por cada llamada/sesión individual con un cargo relacionado con el tipo de servicio suministrado, y estos cargos pueden distribuirse adecuadamente a cada una de las redes portadoras (o dominios administrativos) transitados por la llamada/sesión.
Al igual que con la PSTN, se contempla que la
NGN consista en muchos dominios de operadores/administrativos, y que
la arquitectura de IMS proporcione la base para que un abonado de un
operador establezca una llamada de voz o una sesión multimedia con
un abonado de otro operador, de manera que ambos operadores (así
como cualesquiera operadores intermedios) se reserven los necesarios
recursos de red de sus dominios respectivos para la Calidad de
Servicio (QoS - "Quality of Service") requerida para los flujos
de paquetes portadores que portan las corrientes o flujos continuos
de voz o multimedia asociados con la sesión. Por otra parte, la
arquitectura de IMS habilita por completo el desplazamiento
itinerante de los usuarios finales, en el que la QoS de flujo
portador de soporte del dominio visitado es análoga a la que se
tendría en el dominio doméstico.
La Figura 1 ilustra esquemáticamente una
arquitectura de Red de Próxima Generación representativa. Como en la
PSTN y en la Internet, se espera que la NGN sea un conglomerado de
múltiples redes de dominios administrativos. Un negocio de un
dominio administrativo puede ser, fundamentalmente, el de dar
servicio a los usuarios finales o, básicamente, el de proporcionar
el tránsito a otros dominios administrativos. Para los propósitos de
esta Solicitud, se hace referencia a la red de un dominio
administrativo que proporciona el tránsito, como Red de Tránsito (TN
-"Transit Network") 2. Un dominio administrativo que da
servicio a los clientes finales consiste en dos tipos de red: una
red de IP de núcleo o troncal de IP (CN -"core IP network") y
una o más redes de enganche (o "acceso") (ANs -"access
networks") 6 que "enganchan" el equipo terminal (TEs
-"Terminal Equipments") 8 de los usuarios finales a la red
troncal 4, a través de una Pasarela de Enganche 10, de tal manera
que éstos pueden recibir el servicio de IMS. Se considera
normalmente que las ANs están en el mismo dominio administrativo que
la CN a la que se conectan, incluso cuando se hacen funcionar por
una entidad empresarial independiente (un operador de AN) de la que
el operador de CN adquiere el "acceso al por mayor". Nótese
que, si bien tanto las Redes de Tránsito como las Redes Troncales
encaminan paquetes de IP basándose en la dirección de IP de destino
de cada encabezamiento de paquete, las ANs transportan paquetes
entre TEs y el punto de enganche de la CN, con independencia de las
direcciones de IP. Si bien una red de enganche puede ser tan simple
como un hilo o un circuito multiplexado en el dominio del
tiempo
(TDM -"Time Domain Multiplexed"), habitualmente consiste en una primera red de Mile específica del medio, y una red de Backhaul en paquetes más general (en la terminología inalámbrica del 3GPP, esta red de Backhaul se denota por el término "troncal", pero sigue formando parte de la AN y no se debe confundir con la CN).
(TDM -"Time Domain Multiplexed"), habitualmente consiste en una primera red de Mile específica del medio, y una red de Backhaul en paquetes más general (en la terminología inalámbrica del 3GPP, esta red de Backhaul se denota por el término "troncal", pero sigue formando parte de la AN y no se debe confundir con la CN).
En la arquitectura de red que se ilustra en la
Figura 1, los paquetes son transportados entre las diversas redes
troncales y de tránsito por Enlaces de Intercambio 12 alojados por
Pasarelas de Frontera de Transporte (TBGs- "Transport Border
Gateways") 14 de cada red. Para cualquier par de redes, un Enlace
de Intercambio puede ser un enlace físico o alguna forma de circuito
virtual. Los expertos de la técnica constatarán que pueden
interconectarse también múltiples redes a través de una Red de
Intercambio (XN -"eXchange Network") sin conexiones. Una XN
puede encontrarse en un abanico que va desde un conmutador de
Ethernet individual a una red de IP global o una Red Privada
Virtual.
\global\parskip1.000000\baselineskip
Se específica que el IMS utiliza el Protocolo de
Inicio de Sesión (SIP) para establecer y poner fin a llamadas o
sesiones multimedia. La arquitectura de IMS específica un cierto
número de Funciones de Control del Estado de la Llamada (CSCFs
-"Cali State Control Functions"), distribuidas a través de la
red, que procesan los mensajes de SIP y actúan en ellos. En el
establecimiento de una sesión específica, la mensajería de SIP
necesita ser procesada o tratada por al menos una CSCF en Servicio
(S-CSCF -"Serving CSCF") de origen, asociada
con el iniciador de la sesión, y una S-CSCF de
destino, asociada con el objetivo o destino de la sesión
establecida. Habitualmente, sin embargo, los clientes de SIP no se
emparejan directamente con sus S-CSCFs asociadas, y
existen CSCFs intermedias que encaminan y remiten los mensajes de
SIP entre los clientes de SIP y sus S-CSCFs
asociadas, y entre las CSCFs de origen y de destino. Son de
particular relevancia para la presente Solicitud las CSCFs parejas
responsables de remitir mensajes de SIP entre dominios
administrativos. En la presente descripción, se designa cualquier
CSCF que sea la última de un dominio administrativo, para remitir un
mensaje de SIP a otro dominio, o que sea la primera de un dominio
administrativo, para recibir un mensaje de SIP desde otro dominio
administrativo, como CSCF de Frontera (b-CSCF
-"border CSCF"). Quienes están familiarizados con el 3GPP y/o
otras iniciativas normativas de NGN constarán que existe un debate
acerca del modo como estructurar la arquitectura de la capacidad
funcional del control de frontera. Es la intención que el término
"b-CSCF" que abarque componentes funcionales
tales como una CSCF de interrogación (I-CSCF
-"interrogating-CSCF"), una Función de Control
de Frontera de Interconexión
(IBCF -"Interconnection Border Control Function") y aspectos de una Función de Control de Pasarela de Interrupción (BGCF -"Breakout Gateway Control Function"). Incluso una S-CSCF puede ser una b-CSCF cuando el control de frontera no es un fuerte requisito del operador.
(IBCF -"Interconnection Border Control Function") y aspectos de una Función de Control de Pasarela de Interrupción (BGCF -"Breakout Gateway Control Function"). Incluso una S-CSCF puede ser una b-CSCF cuando el control de frontera no es un fuerte requisito del operador.
No existen CSCFs en redes de enganche -el par de
la denominada CSCF de representante (P-CSCF
-"proxy-CSCF") es, en realidad, la función de
cliente de SIP del equipo terminal. Puesto que un cliente de SIP,
particularmente el de un servidor de aplicación (AS - "application
server") 8b, podría emparejarse directamente con una
S-CSCF, en la presente descripción se utilizará la
expresión CSCF de perímetro (p-CSCF
-"perimeter-CSCF") para referirse a la CSCF que
es la primera/última que maneja mensajes de SIP desde/hacia clientes
de SIP 8. La Figura 1 ilustra las CSCFs relevantes en el
establecimiento de una sesión entre un TE 8 en desplazamiento
itinerante (enganchado a una red troncal visitada) y un Servidor de
Aplicación AS 8b, en el que las redes troncales domésticas están
separadas por una Red de Tránsito 2.
Una corriente o flujo continuo de medios de una
sesión es transportado a través de una red como un flujo portador
(paquetes). En un entorno de paquetes de IP, el recorrido o camino
del flujo portador no es automáticamente el mismo que el camino por
el que pasa la señalización de SIP, debido a que no se requiere que
el camino del flujo portador pase a través de nodos que alojan
funciones CSCF. Los flujos portadores entre dominios salen y entran
en dominios administrativos y nodos que aquí se designan como
Pasarelas de Frontera de Transporte (TBG -"Transport Border
Gateways") 14. De nuevo, la situación entre la red de enganche y
la red troncal es diferente: el nodo de la red troncal que actúa
como interfaz con la red de enganche recibe los diversos nombres de
Borde de Servicio, Borde de Red Troncal, Nodo de Frontera, Pasarela
de Medio de Acceso, Dispositivo de Encaminamiento de Acceso, o bien
términos específicos del tipo de red de acceso, tales como Nodo de
Soporte de Pasarela de GPRS (GGSN -"GPRS Gateway Support Node")
o Servidor de Acceso Remoto de Banda Ancha (BRAS - "Broadband
Remote Access Server"). En esta descripción se utilizará la
expresión Pasarela de Enganche (AG -"Attachment Gateway") 10.
La AG abarca los límites entre la AN 6 y la CN 4.
\vskip1.000000\baselineskip
Como es conocido en la técnica, los mensajes de
SIP que inician una sesión llevan una descripción del flujo portador
(o de múltiples flujos portadores, si es necesario) que se ha de
asociar a la sesión. Esta descripción adopta la forma de unos
parámetros de protocolo de Descripción de Sesión (SDP -"Session
Description protocol"). Véase, por ejemplo, la divulgación de
Handley, M. y V. Jacobson: "SDP: session description
protocol" ("SDP: protocolo de descripción de
sesión"), Request for Comments 2327, abril de 1998. En la
actualidad, la parte de SDP del mensaje de SIP proporciona una
descripción completa de lo que debe contener el flujo portador (esto
es, voz y vídeo, y qué codecs
[codificadores-descodificadores] se han de
utilizar). Esta información estaba inicialmente destinada a permitir
a los sistemas finales especificar cómo querían codificar los datos
de voz y de vídeo para obtener paquetes de protocolo en tiempo real
(RTP -"real time protocol").
En la solución de IMS, los parámetros de SDP
pueden también ser interpretados por CSCFs en los diversos dominios
de red interpuestos entre los sistemas finales, con el fin de
determinar cuáles son las características de red de los caminos
portadores. Habitualmente, esta información se obtiene de las líneas
de medio (comenzando por m=) con el SDP. Por ejemplo, el último
parámetro de:
indica un flujo portador de audio
que está codificado de acuerdo con el perfil audiovisual (AVP
-"audio visual profile") 9, que resulta ser el G.722, el cual
es una corriente de 64 kbits/s (el requisito de red tiene que
incluir encabezamientos de paquete, etc., así como su impulso hasta
que alcance en torno a 100
kb/s).
\vskip1.000000\baselineskip
Basándose en los parámetros de SDP, las CSCFs
llevan a cabo un procedimiento que lleva el nombre de control de
admisión de conexión (CAC -"connection admission control"), si
bien sería más preciso denominar el procedimiento Control de
Admisión de Sesión. El procedimiento de CAC determina los requisitos
de recursos del(de los) flujo(s)
portador(es), de tal manera que la(s) corriente(s) de medio incorporada(s) puede(n) ser entregada(s) con la QoS esperada. Si un dominio no tiene los recursos necesarios para dar soporte a un nuevo flujo portador, entonces la CSCF relevante interrumpirá el establecimiento de la sesión. Se proporciona una descripción de esto (para p-CSCFs y AGs) en el documento de 3GPP "3GPPP TS 23.207".
portador(es), de tal manera que la(s) corriente(s) de medio incorporada(s) puede(n) ser entregada(s) con la QoS esperada. Si un dominio no tiene los recursos necesarios para dar soporte a un nuevo flujo portador, entonces la CSCF relevante interrumpirá el establecimiento de la sesión. Se proporciona una descripción de esto (para p-CSCFs y AGs) en el documento de 3GPP "3GPPP TS 23.207".
\vskip1.000000\baselineskip
La clase de tráfico es un concepto algo difuso
que es recogido por diferentes términos de diferentes modelos de
gestión del tráfico. En el modelo IntServ de IETF existen tres
clases de tráfico: "garantizado" ("guaranteed"), "carga
controlada" ("controlled load") y "mejor esfuerzo"
("best effort"). De forma algo similar, el Modelo DiffServ de
IETF proporciona tres tipos de comportamientos de remisión del
tráfico: Remisión Expedita (EF -"Expedited Forwarding"),
Remisión Asegurada (AF -"Assured Forwarding") (aunque puede
haber hasta 4 clases de tráfico de la AF), y por Defecto
("Default") o Mejor Esfuerzo ("Best Effort"). Grupos de
estudio de la ITU definen las clases de tráfico para servicios en
términos de retardo y fluctuación (así como capacidad de
transferencia), además de factores tales como la proporción de
pérdida de paquetes y la gestión de los paquetes que no cumplen las
especificaciones o que llegan tarde.
En los desarrollos prácticos de la NGN existirá
una clase de tráfico en la que tanto el retardo como la fluctuación
serás los mínimos posibles, destinada a ser utilizada para
conversaciones en tiempo real (o bien un operador podrá optar por
varias de tales clases, una para conversaciones de voz, una para
videotelefonía y una para juegos), así como otra clase que garantice
la capacidad de transferencia con una fluctuación limitada que
resulte adecuada para la corriente de medio en curso (de nuevo, un
operador puede escoger distinguir entre voz y vídeo). Puesto que no
hay nunca recursos dedicados al tráfico de mejor esfuerzo, no es de
gran utilidad utilizar el SIP para establecer un flujo portador de
mejor esfuerzo, pero, atendiendo a la completitud, puede haberse
definido semejante punto de código.
\vskip1.000000\baselineskip
La Figura 2 ilustra un flujo portador 18
dividido en segmentos 20. Cada segmento 20 del flujo portador
atraviesa una única red 2-6 de transporte de
paquetes y está delimitado por un dispositivo de extremo o una
pasarela 14. Los segmentos 20 de flujo portador pueden denominarse
por el tipo de red en la que son transportados: segmento de
Enganche, para la parte del flujo portador que atraviesa la red de
enganche, etc.
La necesidad de proporcionar un tratamiento
especial a los paquetes de flujo portador puede no extenderse de
extremo a extremo. Está ampliamente aceptado que, si una red de
transporte de paquetes particular está aprovisionada o equipada en
exceso, entonces el tratamiento de QoS dado a todos los paquetes
será el adecuado para dar soporte a cualquier flujo portador
particular. Los expertos de la técnica constatarán también que el
DiffServ puede utilizarse para estimular el aprovisionamiento en
exceso para clases de tráfico específicas. Se contempla que algunas
redes troncales, o todas, estén aprovisionadas en exceso (o bien que
se use DiffServ para simular el aprovisionamiento en exceso para
paquetes de IMS), con la consecuencia de que no habrá necesidad de
reservar recursos para los segmentos nucleares de los flujos
portadores que atraviesan tales redes troncales aprovisionadas en
exceso. Sin embargo, es muy probable que deban reservarse recursos
para segmentos de enganche, a fin de garantizar que el transporte de
paquetes de flujo por estos segmentos no degrada la QoS del flujo de
extremo a extremo por debajo de lo que es aceptable para el servicio
al que el flujo está dando soporte.
\vskip1.000000\baselineskip
La función de reservar recursos para un flujo
portador está estrechamente relacionada con el control de admisión
para la sesión de la que es parte constituyente el flujo portador.
Si, dados los compromisos de corriente para las sesiones existentes,
hay una insuficiente capacidad de anchura de banda en los enlaces,
una insuficiente capacidad de remisión en los nodos, o una falta de
otros recursos necesarios para facilitar la QoS solicitada para un
flujo portador en una nueva sesión, entonces se interrumpe el
establecimiento de la sesión y todos los recursos que ya se hayan
reservado para esa sesión son liberados.
Más generalmente, antes de que se establezca una
sesión, es necesario adoptar un cierto número de decisiones de
criterio concernientes a si se ha de admitir o no la sesión. En la
arquitectura de IMS, estas decisiones se originan en las CSCFs,
disparadas o desencadenadas por el tratamiento del primer mensaje en
el establecimiento de una sesión: el mensaje INVITAR ("INVITE")
de SIP. La ejecución de algunas decisiones de criterio está
circunscrita a CSCF, pero las que conciernen a la QoS del flujo
portador se señalan a las pasarelas que se harán cargo del flujo
portador, por parte de las CSCFs que las controlan. La Figura 3
ilustra, para una sesión que implica dos dominios, el control de la
función RACF en las pasarelas de enganche (AGs) 10 y en pasarelas de
frontera de transporte (TBGs) 14b y p- CSCFs y
b-CSCFs, respectivamente. Quienes están
familiarizados con las normas de NGN constatarán que, en la
arquitectura de IMS, entre CSCFs y Pasarelas, existen Funciones de
Decisión de Criterio Intermedias (PDFs -"Policy Decisión
Functions"), que forman la capa de red del RACS (Subsistema de
Control de Recursos y Admisión - "Resource and Admission Control
Subsystem"). Además de arbitrar entre las diferentes aplicaciones
que solicitan flujos portadores de QoS, una PDF puede presentar a
CSCFs una visión atractiva de aspectos específicos de control de la
QoS de la red de enganche, así como ocultar la topología de AGs y
TBGs.
A pesar de sus ventajas, la NGN adolece de
limitaciones por cuanto que la(s) ruta(s)
recorrida(s) por los paquetes de Protocolo de Internet (IP)
de un flujo portador se determina(n) por técnicas
convencionales de remisión de paquetes, y, por tanto,
puede(n) o no seguir la ruta recorrida por la mensajería de
SIP utilizada para establecer el flujo. Esto proporciona una barrera
al desarrollo de la NGN, ya que es imposible para un proveedor de
red asociar apropiadamente paquetes de IP que atraviesan su dominio
de red con un flujo portador concreto, y esto, a su vez, impide unos
acuerdos de facturación similares a los que actualmente se emplean
por la Red de Telefonía Pública Conmutada (PSTN -"Public Switched
Telephone Network") y los operadores de redes celulares.
De acuerdo con ello, siguen siendo altamente
deseables métodos y técnicas que permitan la fijación de la ruta de
Flujos Portadores de Protocolo de Internet (IP) en una Red de
Próxima Generación.
Es un propósito de la presente invención
proporcionar métodos y técnicas que permitan la fijación de la ruta
para Flujos Portadores de Protocolo de Internet (IP -"Internet
Protocol") en una Red de Próxima Generación.
Así, pues, un aspecto de la presente invención
proporciona, en una red de comunicación de múltiples dominios en la
que se utiliza un protocolo de señalización fuera de banda para
establecer sesiones de comunicación, un método para establecer un
recorrido o camino de extremo a extremo de una sesión de
comunicación. El método comprende recibir un mensaje de señalización
fuera de banda que incluye información representativa de al menos un
punto de extremo opuesto de un primer segmento portador del camino
de extremo a extremo. La información se utiliza para definir una
relación de correspondencia de conexión cruzada a través de un nodo
de la red, entre respectivos puntos de extremo locales del primer
segmento portador y de un segundo segmento portador albergado por el
nodo. La información representativa de la relación de
correspondencia de conexión cruzada es insertada, a continuación, en
el mensaje de señalización fuera de banda, y se remite el mensaje de
señalización fuera de banda.
La presente invención no es específica de ningún
modelo de gestión de tráfico particular, sino que, en lugar de ello,
supone simplemente que habrá alguna pluralidad de clases de tráfico
acordadas por los operadores, y que la clase de tráfico deseada para
un flujo portador puede especificarse como un parámetro en el
SDP.
La presente invención supone que existe, para
cada AG, una p-CSCF (y, de la misma manera, para
cada TBG hay una b-CSCF) que puede solicitar el
tratamiento de QoS para los flujos portadores que pasan a través de
esa pasarela, con independencia del número, si los hay, de PDFs
intermedias, nodos y elecciones de protocolo específico para su
intercomunicación. El tratamiento de QoS de un segmento portador de
un flujo portador particular puede establecerse, en un modo de un
único extremo, empujando un criterio hacia la pasarela situada en
uno de los extremos del segmento, o bien puede establecerse en un
modo de extremo doble, empujando un criterio hacia las pasarelas
situadas en ambos extremos del segmento. Como se ha definido
anteriormente, una pasarela es el punto final de un segmento
portador de un flujo portador, y el principio de su siguiente
segmento: un único criterio empujado hacia la pasarela puede servir
para solicitar recursos de QoS para ambos segmentos.
Los expertos de la técnica constatarán que
existen varios métodos diferentes para solicitar a una pasarela que
proporcione QoS para un segmento portador: los denominados métodos
de "EMPUJE" ("PUSH") tienen como resultado que la pasarela
recibe directamente de la CSCF (o bien a través de una jerarquía de
funciones de decisión de criterio) una "decisión de criterio",
a fin proporcionar a un segmento portador una QoS especificada, y la
pasarela responde entonces a la CSCF que, bien tiene recursos para
"hacer valer" el criterio, o bien carece de esos recursos.
Las descripciones que siguen se han expresado en
términos del modelo de "EMPUJE" de RACS, pero es la intención
que la presente invención funcione independientemente del modo como
los requisitos de QoS son comunicados a las pasarelas. Ciertamente,
como constatarán los expertos de la técnica, un "saboteador de
anchura de banda" podría seguir la pista de los recursos de
anchura de banda a través de un enlace o red sin señalizarlo nunca a
las pasarelas situadas en los puntos de extremo. Sin embargo, dado
que los segmentos comienzan o terminan en límites entre dominios,
existen razones añadidas para que las pasarelas tengan la
especificación de un nuevo segmento portador señalado a ellas:
establecimiento de criterios para flujos portadores, cambio en las
marcaciones DiffServ, generación de registros de contabilidad. Si
bien es improbable que las reservas de recursos reales necesiten
efectuarse en enlaces o redes de intercambio, será probable que una
función de RAC sea invocada por b-CSCFs con el fin
de comprobar la adhesión a los criterios de cada dominio
administrativo por lo que respecta al tipo y cantidad de flujos que
está preparada para aceptar desde la otra.
Otras características y ventajas de la presente
invención se pondrán de manifiesto a partir de la siguiente
descripción detallada, tomada en combinación con los dibujos que se
acompañan, en los cuales:
la Figura 1 es un diagrama de bloques que
ilustra esquemáticamente una Red de Próxima Generación
representativa en la que se han implementado los métodos de la
presente invención;
la Figura 2 es un diagrama de bloques que
ilustra esquemáticamente segmentos de flujo portador en la red de la
Figura 1;
la Figura 3 es un diagrama de bloques que
ilustra esquemáticamente, par una sesión que implica dos dominios,
el control de la Función de Control de Recursos y Admisión;
la Figura 4 es un diagrama de bloques que
ilustra esquemáticamente el uso de Relaciones de Correspondencia de
Direcciones de Red para fijar segmentos portadores, de acuerdo con
un aspecto de la presente invención;
la Figura 5 es un diagrama de bloques que
ilustra esquemáticamente el uso de Relaciones de Correspondencia de
Direcciones de Red para fijar segmentos portadores en una red que
comprende múltiples segmentos portadores, de acuerdo con un aspecto
de la presente invención;
la Figura 6 es un diagrama de bloques que
ilustra el uso de Relaciones de Correspondencia de Direcciones de
Red para fijar segmentos portadores en una red que comprende
múltiples ámbitos o esferas de direcciones de IP, de acuerdo con un
aspecto de la presente invención;
la Figura 7 es un diagrama de bloques que
ilustra esquemáticamente un método para dar soporte a un cliente no
de SIP, de acuerdo con un aspecto de la presente invención;
la Figura 8 es un diagrama de bloques que
ilustra esquemáticamente un método para dar soporte a un cliente no
de SIP en una red que comprende múltiples esferas de direcciones de
IP, de acuerdo con un aspecto de la presente invención;
la Figura 9 es un diagrama de bloques que
ilustra esquemáticamente un método para colaborar con protocolos de
herencia, de acuerdo con un aspecto de la presente invención;
la Figura 10 es un diagrama de flujo de mensajes
que ilustra esquemáticamente un método para colaborar de RSVP a SIP,
de acuerdo con un aspecto de la presente invención;
la Figura 11 es un diagrama de flujo de mensajes
que ilustra esquemáticamente un método para colaborar de RTSP a SIP,
de acuerdo con un aspecto de la presente invención;
la Figura 12 es un diagrama de bloques que
ilustra esquemáticamente el funcionamiento de un servidor para dar
soporte a la colaboración con protocolos de herencia, de acuerdo con
un aspecto de la presente invención;
la Figura 13 es un diagrama de flujo de mensajes
que ilustra esquemáticamente el funcionamiento de un servidor para
dar soporte a la colaboración de RSVP a SIP, de acuerdo con un
aspecto de la presente invención; y
la Figura 14 es un diagrama de flujo de mensajes
que ilustra el funcionamiento de un servidor para dar soporte a la
colaboración de RTSP a SIP, de acuerdo con un aspecto de la presente
invención.
Se apreciará que, a lo largo de los dibujos que
se acompañan, se han identificad características similares por los
mismos números de referencia.
La presente invención proporciona métodos y
técnicas que hacen posible el Tratamiento de QoS de Flujos
Portadores Genéricos en una Red de Próxima Generación. Más adelante
se describen realizaciones de la presente invención, a modo de
ejemplo únicamente y con referencia a las Figuras
4-14.
En general, la presente invención proporciona
métodos y sistemas que pueden ser utilizados, ya sea solos o en
combinación, para extender la arquitectura de IMS/SIP de la NGN con
el fin de proporcionar servicio de QoS a flujos portadores
genéricos. Estos métodos y sistemas pueden dividirse, en un sentido
amplio, en cuatro categorías, a saber: extensión del SIP a flujos
portadores genéricos; fijación de un flujo portador de una sesión de
comunicación a AGs y TBGs atravesados por la señalización de SIP
utilizada para establecer la sesión; soporte de clientes no de SIP;
y capacidad funcional como pasarela para la señalización de IP de
herencia. Cada una de estas categorías será explicada, a modo de
ejemplo representativo, en la siguiente descripción.
Debe apreciarse que la presente Solicitud se
dirige fundamentalmente a técnicas para fijar un flujo portador a
AGs y TBGs atravesados por la señalización de SIP que se utiliza
para el establecimiento de la sesión. Las técnicas para dar soporte
a clientes no de SIP y a la capacidad funcional de señalización de
IP de herencia, respectivamente, son el objeto de las Solicitudes de
Patente norteamericanas conjuntamente dependientes, de este mismo
Solicitante, Nos. xx/xxx.xxx, titulada "Representantes de pasarela
en servicio para interlocutores no de SIP en una Red de Próxima
Generación" ("Serving Gateway Proxies for
Non-SIP Speakers in a Next Generation Network");
y yy/yyy-yyy, titulada "Aporte de colaboración de
SIP en una Red de Próxima Generación", ambas cuales se han
depositado de forma concurrente con la presente Solicitud.
\vskip1.000000\baselineskip
El SIP y el IMS, tal y como se definen en la
actualidad, adolecen de una limitación por cuanto que únicamente
tratan flujos portadores que son corrientes multimedia. Sin embargo,
muchas otras aplicaciones de utilidad podrían aprovechar la
infraestructura de IMS si sus flujos portadores fuesen reconocidos
por el IMS.
De acuerdo con un aspecto de la presente
invención, puede superarse esta limitación añadiendo parámetros de
especificación del tráfico ("T-Spec") que
describen los requisitos de QoS de flujos portadores genéricos para
el SDP en la señalización de SIP; y extendiendo los mecanismos de
RACS en IMS para interpretar los nuevos parámetros de
T-Spec. El hecho de añadir parámetros de
T-Spec en la parte de SDP de la señalización de SIP
permite que dos puntos de extremo de SIP soliciten que la red
realice el control de la asignación de recursos y/o de la admisión
de conexión para cualquier flujo arbitrario: un flujo portador
genérico. Así, mientras que para un flujo portador de RTP o
multimedia los elementos funcionales de IMS deducen los requisitos
de recursos a partir de los parámetros de codificación de medio y
otros parámetros de SDP descriptivos del medio, para flujos
portadores genéricos, las CSCFs utilizarán parámetros de
T-Spec explícitos como base para el procedimiento de
control de recursos y de admisión.
Considérese, por ejemplo, una red en la que se
ha adoptado la clase de designaciones de servicio de la
recomendación de la ITU Y.1541. En tal caso, siguiendo las líneas
maestras de RFC 2327, la T-Spec explícita puede
consistir en dos líneas de atributo de nivel de medio: una que
específica la clase según Y. 1541 del servicio y otra que específica
la capacidad o anchura de banda requerida. Así, pues:
pueden utilizarse para especificar
que el flujo portador requerido es 100 kb/s y una clase de servio 0
(es decir, un retardo de extremo a extremo de menos de 100 ms, etc.,
tal como para la
Y.1541).
\vskip1.000000\baselineskip
Pueden utilizarse, si se desea, otros métodos
para expresar los parámetros de T-Spec explícita.
Por ejemplo, en la implementación de la representación que se
describe más adelante, los operadores pueden escoger asignar nombres
a combinaciones de anchura de banda y clase de tráfico, lo que hace
posible que la T-Spec explícita se proporcione
utilizando un único atributo de SDP (es decir, el nombre
asignado).
\vskip1.000000\baselineskip
Una empleada de una empresa que está de viaje
utiliza un cliente de VPN para establecer un túnel de IPSec de
vuelta con su computadora portátil o con su servidor de VPN de la
empresa, incluyendo su PBX de IP para realizar y recibir llamadas
telefónicas. Se este túnel de IPSec por la Internet de mejor
esfuerzo, los retardos, fluctuación y proporción de pérdidas de los
paquetes encriptados o cifrados serían inciertos y podrían ser
inadecuados para dar soporte a una sesión de VoIP entre la cliente
ocasional en su computadora portátil y el PBX de IP de la empresa.
Con el fin de obtener una QoS garantizada adecuada para los paquetes
de voz en el túnel de IPSec, se requiere que el túnel de IPSec sea
tratado como un portador genérico.
Los operadores que dan soporte a portadores
genéricos pueden escoger tarifar un número limitado de anchuras de
banda (capacidad de transferencia) para cada clase de tráfico, y dar
a continuación un nombre estándar a cada combinación de capacidad de
transferencia y clase de tráfico. Un ejemplo podría ser:
votel = 100 kb/s, retardo mínimo, mínima
fluctuación, tarifa de 0,02 \textdollar por minuto;
vidtel = IMb/s, retardo mínimo, mínima
fluctuación, 0,10 \textdollar;
sdtv = 1,5 Mb/s, comunicación descendente,
capacidad de transferencia garantizada, 0,03 \textdollar;
hdtv = 8 Mb/s, comunicación descendente,
capacidad de transferencia garantizada, 0,06 \textdollar;
destinados, respectivamente, a telefonía de voz,
a videotelefonía, a corriente de vídeo de definición estándar y a
corriente de vídeo de alta definición. Se utilizará entonces el
nombre estándar como único parámetro de T-Spec en la
parte de SDP de los mensajes de SIP. En este ejemplo, asignar la QoS
"votel" al portador genérico será adecuado para dar soporte a
las sesiones de VoIP de los usuarios.
\vskip1.000000\baselineskip
El servidor de VPN situado en la ubicación de la
empresa es enganchado a alguna red NGN del operador y se registra
con ese dominio. Supóngase para la presente descripción que, si
existen múltiples dominios administrativos entre el cliente de VPN y
el servidor de VPN, el comportamiento de encaminamiento normal para
los paquetes de IP entre el cliente de VPN y el servidor de VPN,
atraviesa la misma cadena de dominios que la señalización de SIP, y
no hay ambigüedad por lo que respecta a qué TBGs 14 utilizan los
paquetes (la fijación de flujos portadores para utilizar TBGs
específicos se describe en detalle más adelante).
La parte 22 de cliente de SIP del cliente 8 de
VPN se registra en el dominio de IMS público. Como resultado de
ello, de acuerdo con el funcionamiento normal del IMS, una
s-CSCF doméstica puede enviar en ese momento al
cliente mensajes de señalización de SIP. (Nótese que la parte 22 de
cliente de SIP del cliente 8 de VPN es distinta del cliente de SIP
telefónico ocasional ubicado en la computadora portátil -pueden
compartir código común pero, en última instancia, el cliente de SIP
telefónico ocasional se registrará con el PBX de IP de la empresa.
Una realización alternativa podría utilizar un único cliente de SIP
que pueda estar doblemente registrado).
El establecimiento de una asociación de
seguridad entre el cliente 8 de VPN y el servidor de VPN prosigue
entonces de la forma habitual, utilizando la secuencia de protocolos
de IKE (Intercambio de Clave de Internet -"Internet Key
Exchange"), con la exigencia de que la identidad afirmada por el
cliente de VPN en sus mensajes de IKE debe ser traducible por el
Servidor de VPN en la identidad de SIP (URI - Identificador de
Recursos Universal ("Universal Resource Identifier")) del
cliente de VPN. Esto puede garantizarse al hacer que la identidad
del cliente de VPN sea su URI de SIP, pero, para una seguridad
incluso mayor, la dirección de SIP del cliente puede devolverse como
resultado del procedimiento de autorización (por ejemplo, como parte
de una respuesta de RADIO ("RADIUS") o DIÁMETRO
("DIAMETER")).
Una vez que el Servidor de VPN ha autentificado
al cliente (de hecho, una vez completadas las dos fases del IKE),
éste efectúa una "llamada" al cliente de VPN emitiendo un
mensaje INVITAR ("INVITE") de SIP en el dominio público. La
F-Spec del SDP identifica los puntos de extremo de
túnel que se han acordado. (Nótese que los paquetes de IPSec
estándar no tienen números de puerta en sus encabezamientos, sino,
en lugar de ello, un campo de índice de Parámetros de Seguridad que
es único para cada túnel entre un par dado de direcciones. Este
campo puede ser utilizado en la F-Spec, pero, de
hecho, debido a la existencia de NAT en las redes, el modo normal de
establecer puentes para el estilo de funcionamiento por acceso de
VPN, es que los paquetes de IPSec se encapsulen en diagramas de
datos o datagramas de UDP, y, por tanto, el estilo normal de
F-Spec sirve para identificar el flujo por túnel de
IPSec de los paquetes). En un modo de funcionamiento, la
T-Spec para un cliente de VPN se devuelve al
servidor de VPN como parte del procedimiento de autorización, es
decir, cada cliente de VPN tiene siempre un nivel de QoS fijo
establecido por el administrador. En este caso, la
T-Spec se incluye como parte del SDP en el mensaje
INVITAR procedente del Servidor de VPN.
En la forma normal de IMS, el mensaje de
señalización INVITAR de SIP es remitido, a través de CSCFs de IMS
público, a la parte de cliente de SIP del cliente de VPN.
El cliente necesita, en primer lugar, asociar la
señalización entrante con la asociación de seguridad (se supone que
el índice de Parámetros de Seguridad está incluido en el SDP incluso
si no forma parte de la F-Spec; véase lo anterior).
En un modo de funcionamiento en el que al usuario del cliente de VPN
le es dado escoger la clase de servicio requerida (por ejemplo, el
usuario puede especificar si pretenden realizar/recibir llamadas de
voz o llamadas de vídeo), el cliente de VPN creará una
T-Spec para el túnel y la incluirá en la respuesta
de SIP devuelta al servidor de VPN. (Presumiblemente, la repuesta
será un mensaje de CONFORMIDAD ("OK") 200).
El sistema de IMS establece la sesión,
informando a las AGs y a las TBGs de que el túnel de IPSec atraviesa
su F-Spec, e instruyéndolas para proporcionar el
tratamiento de QoS según se ha especificado por la
T-Spec. El sistema de IMS generará también los
registros de contabilidad requeridos, de tal manera que la empresa
pueda ser subsiguientemente facturada por el servicio.
El túnel de IPSec ente el servidor de VPN y el
cliente es ahora un camino portador genérico: se asegura para los
paquetes enviados por el cliente o por el servidor que satisfacen la
F-Spec, el tratamiento de QoS especificado en todos
los dominios que atraviesan. Nótese que, puesto que el cifrado
oculta los encabezamientos reales de los todos los paquetes en el
túnel, todos los paquetes obtienen un tratamiento de QoS uniforme.
También, debido a que la IPSec puede basarse en la integridad de la
secuencia, no es una buena idea transferir marcaciones de
dic-serv originales a los encabezamientos de los
paquetes de IPSec y utilizarlas para dar diferentes tratamientos de
QoS a diferentes clases de paquetes. En lugar de ello, si una
implementación desea restringir el tráfico en el portador genérico
de IPSec a sólo corrientes multimedia (cifradas), entonces tendrá
que establecer túneles de IPSec independientes para la corriente
multimedia y el tráfico de mejor esfuerzo -aquí, no hay necesidad de
solicitar tratamiento de QoS utilizando el SIP par un túnel de mejor
esfuerzo, sino que pueden establecerse diferentes túneles de PISec
para diferentes tipos de flujo, cada uno de ellos señalado con
parámetros de T-Sec independientes.
El servidor de VNP pone fin a la sesión de SIP
tan pronto como se pierde el establecimiento de la seguridad.
Los expertos de la técnica constatarán que
existen numerosas variaciones sobre lo anterior. En particular,
puede no ser el caso que se solicite el tratamiento de QoS para el
túnel de IPSec desde la red por la duración del establecimiento del
túnel, sino sólo cuando es iniciada realmente una llamada de voz, o
incluso sólo cuando el rendimiento supervisado del transporte de
mejor esfuerzo cae por debajo de algún umbral durante una llamada.
Otras mejoras adicionales podrían hacer que el servidor establezca
un flujo portador genérico con un tratamiento de QoS mínimo, tan
pronto como se iniciase el túnel IPSec, pero entonces el servidor
podría utilizar un reINVITAR de SIP para modificar la clase/anchura
de banda de servicio del flujo en respuesta a mensajes indagadores
dentro del túnel (tales como mensajes de SIP entre el cliente
telefónico ocasional y el PBX de IP) y/o ante la petición de
servidores dentro del dominio de la empresa.
\vskip1.000000\baselineskip
Como se muestra en la Figura 1, los puntos de
extremo de una sesión pueden ser enganchados a diferentes redes
(troncales) con la señalización de SIP y flujo(s)
portador(es) para una sesión que traviesa varios dominios. En
la actualidad, no se ha prestado mucha atención en el IMS al camino
que siguen los paquetes en un flujo portador -se supone generalmente
que siguen el camino determinado por el encaminamiento de IP. Por
otra parte, el encaminamiento de la señalización de SIP está
definido, al menos parcialmente, de manera que se hace a través de
una serie de CSCFs, de tal modo que las CSCFs son emparejamientos a
modo de par una con otra. En la NGN, las elecciones de remisión para
los mensajes de SIP en cada CSCF son dictadas por criterios (basados
en acuerdos comerciales para el tránsito, etc.). De esta forma,
ocurre que, en el caso de que la parte originaria y la parte
terminante se encuentren en dominios diferentes, los dominios
intermedios atravesados por la señalización de SIP no necesitan ser,
todos, los mismos dominios que los que un paquete de IP enviado
desde la parte originaria y dirigida a la parte terminante,
atravesará en el funcionamiento normal de las reglas de remisión de
IP.
Sin embargo, existen dos buenas razones por las
que el camino de un flujo portador no sólo debe estar determinado
por el encaminamiento de IP, sino que debe ser, en lugar de ello,
establecido explícitamente para que atreviese dominios específicos y
pasarelas de frontera de transporte específicas (TBGs). En primer
lugar, desde un punto de vista comercial, existe un requisito
probablemente fuerte de que un flujo portador de una sesión no
atraviese dominios que no participaron en la señalización para la
sesión, por la razón de que, si el dominio no sabe a qué sesión
pertenece un flujo, no puede generar registros de contabilidad para
ella. En segundo lugar, la entrega de QoS a un flujo portador
requiere habitualmente que los elementos de red situados en el
camino sean informados de la autorización del flujo portador para
recibir la QoS. En consecuencia, para QoS sobre las redes troncales
y/o sobre enlaces de intercambio, el camino del flujo portador tiene
que ser restringido al paso a través de (que se ha de fijar a) TBGs
escogidas por b-CSCFs en el momento del
establecimiento de la sesión, ya que las b-CSCFs
únicamente pueden enviar autorizaciones a TBGs que ellas
controlan.
Además de las dos razones anteriores para fijar
flujos portadores, una CSCF implicada en el establecimiento de una
sesión puede determinar que un flujo portador necesita pasar a
través de una pasarela multimedia de algún tipo. Puede requerirse
una pasarela de medio en el camino de flujo portador para llevar a
cabo una trans-codificación de muestras de medio,
debido a que los puntos de extremo de la sesión no tienen
codecs [codificadores-descodificadores]
comunes entre sí. Otro uso de las pasarelas de medio puede deberse a
que uno de los puntos de extremo está sometido a una orden de
interceptación legal (LI -"lawful intercept") y es necesario
que las corrientes de medio de la sesión se hagan pasar a través de
una pasarela de LI, de tal modo que pueda hacerse una copia de ellas
para ser remitida de manera segura a la autoridad legal de que se
trate.
Un segundo aspecto de la presente invención
proporciona un mecanismo de fijación de camino para los flujos
portadores de una sesión, a fin de hacer que los paquetes portadores
pasen a través de una cadena específica de pasarelas determinadas en
el establecimiento de la sesión. La siguiente descripción y las
Figuras 4-6 se concentran en la fijación de flujos
portadores para transportar pasarelas de frontera de transporte
(TBGs), si bien su extensión a la cobertura de la fijación a otras
pasarelas (traducción de medio, intercepción legal, etc.) será
directamente evidente para los expertos de la técnica, basándose en
la descripción que aquí se aporta. Como ya se ha descrito
anteriormente e ilustrado en la Figura 2, un flujo portador puede
ser dividido en una concatenación en serie de segmentos (de flujo)
portadores 20. Excepto para el comienzo del primer segmento de flujo
y el punto final del último segmento, estos segmentos portadores
comienzan y terminan en las pasarelas 14. Cuando se ha de fijar un
flujo portador a TBGs 14, los puntos de inicio y final de los
segmentos portadores intermedios 20 TBGs 14.
Nótese que, debido a que las redes de enganche 6
no siguen la remisión de IP, el tráfico para un terminal 8 ó
servidor 8b específico es fijado a una AG específica 10 para toda la
duración de su enganche a la red, es decir, los primer y último
segmentos portadores están siempre en su lugar. El mecanismo
descrito actúa para fijar caminos portadores entre AGs 10.
\vskip1.000000\baselineskip
El mecanismo para fijar flujos portadores se
describe más adelante en tres partes. En primer lugar, se describe
el modo como trabaja cuando todos los elementos de red se encuentran
en el mismo ámbito o esfera de direcciones de IP; a continuación, se
describe el modo como ha de trabajar cuando el TE de cliente se
encuentra en una esfera de direcciones de IP privadas, pero todos
los dominios de operador están en una única esfera de direcciones de
IP; y, finalmente, los funcionamientos para cuando las diferentes
redes troncales pertenecen a diferentes esferas de direcciones de
IP. En estos tres casos, se suponen las mismas capacidades, a
saber:
las pasarelas (incluyendo TBGs, AGs y pasarelas
de medio especiales) pueden llevar a cabo traducciones NAT en los
encabezamientos de los paquetes de flujo portador; y
las Pasarelas de Nivel de Aplicación (ALGs
-"Application Level Gateways") de SIP pueden traducir las
direcciones de IP y los números de puerta (F-Spec)
de los mensajes de SDP y de SIP, y pueden controlar las traducciones
NAT llevadas a cabo por las pasarelas que controlan. Como se muestra
en la Figura 1, es probable que las pasarelas de medio AGs de
control de p-CSCFs, TBGs de control de
b-CSCFs sean controladas por S-CSCFs
o un delegado.
\vskip1.000000\baselineskip
Existen dos posibles soluciones para coordinar
la alteración de la F-Spec por la CSCF y el
establecimiento de relaciones de correspondencia de NAT en la
pasarela. En una primera solución, la CSCF determina una relación de
correspondencia y la empuja o hace pasar hacia la pasarela, la cual,
bien la instala o bien devuelve una respuesta de error si la
relación de correspondencia no es factible (por ejemplo, las tablas
de traducción están llenas). Alternativamente, la CSCF puede
solicitar una relación de correspondencia desde la pasarela
facilitando la dirección y la puerta de IP iniciales, y recibiendo
las relaciones de correspondencia completadas como respuesta desde
la pasarela.
En la otra solución, la CSCF altera el componte
de F-Spec en el SPD antes de remitir el mensaje de
SIP a la siguiente CSCF. Nótese que la instalación de la relación de
correspondencia de NAT puede formar parte de un empuje de criterio
general más grande desde la CSCF a la pasarela (por ejemplo, la
instalación del criterio de QoS).
Nótese que esta descripción no está encaminada
al método de escoger qué TBGs específicas deben formar la cadena de
puntos de fijación (esto es parte del problema de encaminamiento de
SIP), sino que sólo describe el mecanismo por el que el
comportamiento normal del encaminamiento de IP es alterado para
asegurarse de que los paquetes del flujo portador pasan a través de
las TBGs escogidas.
\vskip1.000000\baselineskip
Esta sección describe un método para realizar la
fijación de flujos portadores para una confederación de dominios que
forman, todos ellos, parte del mismo ámbito o esfera de direcciones
de IP (por ejemplo, un dominio de direcciones públicas, ya sea el
IPv4 ó el IPv6). Como se ha descrito anteriormente, los parámetros
de SDP para un flujo portador incluyen implícitamente una
F-Spec para el flujo portador que identifica el
flujo por una dirección de IP de fuente y de destino, un tipo de
paquete y números de acceso o puerta de fuente y de destino.
Estrictamente hablando, una F-Spec identifica un
flujo unidireccional o en un solo sentido, pero, obviamente, la
F-Spec para el flujo inverso puede ser generada
trivialmente a partir de la F-Spec original, de tal
modo que, cuando se desea establecer un flujo bidireccional, o en
ambos sentidos, se seguirá hablando de una única
F-Spec. En esta primera realización, todas las
direcciones de IP de F-Spec pertenecen a la misma
esfera de direcciones de IP.
La esencia del método es que las CSCFs situadas
en el camino de la señalización de SIP dividen o fragmentan el flujo
portador en segmentos portadores mediante la alteración de la
F-Spec transmitida a la siguiente CSCF, de tal
manera que la F-Spec modificada describe únicamente
el segmento portador entre las pasarelas controladas por las CSCFs
implicadas. Las CSCFs instalan entonces en esas pasarelas una
relación de correspondencia de "conexión cruzada" bidireccional
o en ambos sentidos, de tal manera que los paquetes de un segmento
portador entrante son remitidos por la pasarela al siguiente
segmento portador. En la instalación específica que aquí se
describe, la relación de correspondencia de "conexión cruzada"
es una relación de correspondencia de NAT, y la remisión de los
paquetes al siguiente segmento portador se efectúa realizando la
traducción NAT de las direcciones y puertas de los encabezamientos
de los paquetes entrantes, a fin de convertirlos en paquetes del
siguiente segmento del camino portador, y remitiendo a continuación
los paquetes de acuerdo con los procedimientos normales de
encaminamiento de IP.
Haciendo referencia a la Figura 4, se describe
primeramente con mayor detalle el mecanismo para el inicio de una
sesión que implica dos dominios, mostrados, por conveniencia en la
notación, como el dominio de la izquierda y el dominio de la
derecha: en la Figura 4, el inicio de la sesión se origina en el
dominio de la izquierda por un TE 8 de cliente de SIP, y se le va a
poner fin en el dominio de la derecha, en un AS 8b de cliente de
SIP, de tal manera que mensajes INVITAR de SIP se desplazan de
izquierda a derecha y respuestas tales como CONFORMIDAD 200 se
desplazan de derecha a izquierda. El procedimiento que se va a
describir se aplica a todos los límites entre dominios, de tal
manera que, cuando existen más de dos dominios implicados, el
dominio de la izquierda es entonces el más cercano a la parte
originaria (remite mensajes de INVITAR al dominio de la derecha) y
el dominio de la derecha es el más cercano a la parte terminante
(remite mensajes de CONFORMIDAD 200 al dominio de la derecha).
En la Figura 4, en el flujo portador que ha de
establecer el inicio de la sesión, el extremo de TE del flujo
portador se específica como originario/terminante en la dirección de
IP A y la puerta a, para las que se utilizará la terminología Aa. Al
comienzo del inicio de la sesión de SIP, la dirección y el número de
puerta para el extremo de AS del flujo portador son desconocidos por
el TE 8, por lo que la F-Spec del SDP del mensaje
INVITAR 24 de SIP emitido por el TE 8 es incompleta y puede ser
representada como [Aa, ??].
Cuando el mensaje INVITAR de SIP emitido por el
TE 8 alcanza la b-CSCF 16 situada en la frontera del
dominio de la izquierda, esa b-CSCF escoge una TBG
14 para fijar el camino portador en su recorrido, y solicita o
genera una relación de correspondencia (según se indica por la
referencia 26) para esa TBG que se ha de aplicar a la Aa. Suponiendo
que el resultado es la relación de correspondencia Aa \Rightarrow
Bb, la b-CSCF modifica la F-Spec
reemplazando la dirección de IP originaria y la puerta Aa del TE por
la IP y la puerta Bb de la RGB, y remite el INVITAR (según se indica
por la referencia 28) a su par del dominio de la derecha. Cuando el
mensaje INVITAR llega a la b-CSCF pareja, esa
b-CSCF puede escoger la TBG 14 del borde del dominio
de la derecha que formará su extremo del segmento portador de
intercambio (nótese que, en la Figura 4, a diferencia de las otras
figuras, el transporte de paquetes entre dominios se muestra como un
XN de red de intercambio, en lugar de sólo como un enlace de
intercambio -si existe sólo un único enlace de intercambio entre
pares de TBGs parejas, entonces la elección de una TBG por la
b-CSCF del dominio de la izquierda determinará la
TBG en el dominio de la derecha).
La b-CSCF del dominio de la
derecha solicita o genera una relación de correspondencia (según se
indica por la referencia 30) para que la TBG 14 aplique a la Bb.
Suponiendo de nuevo que el resultado es Bb \Rightarrow Cc, la
F-Spec es modificada, pasando a [Cc, ??]. Con el
inicio de sesión que implica sólo dos dominios representado en la
Figura 4, el mensaje INVITAR de SIP proseguirá entonces (según se
indica por la referencia 32) a través de las CSCFs del dominio de la
derecha, hasta que alcance el cliente de SIP de destino 22 (mostrado
como un servidor de aplicación, AS, en la Figura 4). En situaciones
más generales, el INVITAR de SIP es remitido hacia una
b-CSCF que está emparejada con el siguiente
dominio.
Desde el punto de vista del AS 8b, el INVITAR de
SIP que recibe está solicitando un flujo portador con un punto de
extremo de Cc. Suponiendo que el AS responde con un mensaje de
CONFORMIDAD 200, especificará su extremo de la corriente portadora
(como, por ejemplo, Zz), de tal manera que la F-Spec
del SDL del mensaje 34 de CONFORMIDAD 200 será [Cc, Zz], (Los
expertos de la técnica constatarán que el mensaje de respuesta que
lleva la parte de F-Spec de destino puede ser el
mensaje de Timbre 180). El mensaje de CONFORMIDAD 200 recorre el
camino inverso del de INVITAR, y llega de vuelta a la
b-CSCF del dominio de la derecha. Esa
b-CSCF solicitará o generará otra relación de
correspondencia (por ejemplo, Yy \Rightarrow Zz) según se indica
por la referencia 36, y activará a continuación en la TBG 14 la
traducción completa de Dirección de Red bidireccional de
encabezamiento de IP de
Bb \Leftrightarrow Cc, Yy \Leftrightarrow Zz. Finalmente, la b-CSCF modifica la F-Spec en el mensaje de CONFORMIDAD 200 para mostrar la dirección y la puerta de fuente de flujo portador como Yy, y el destino como Bb, y la remite (según se indica por la referencia 38) a su par del dominio de la izquierda. En la b-CSCF pareja del dominio de la izquierda, la recepción del mensaje de CONFORMIDAD 200 provoca la petición, o la generación, de la relación de correspondencia Xx \Leftarrow Yy, la activación, en la TBG del dominio de la izquierda, de la relación de correspondencia bidireccional Aa \Leftrightarrow Bb,
Xx \Leftrightarrow Yy (según se indica por la referencia 40) y, por último, la propagación hacia el cliente de SIP de origen del mensaje de CONFORMIDAD 200 con una F-Spec de [Aa, Xx] (según se indica en la referencia 42). Desde el punto de vista del cliente 22 de SIP de TE, el otro punto de extremo del flujo portador para la sesión es el Xx, en la TBG 14 del Dominio de la Derecha.
Bb \Leftrightarrow Cc, Yy \Leftrightarrow Zz. Finalmente, la b-CSCF modifica la F-Spec en el mensaje de CONFORMIDAD 200 para mostrar la dirección y la puerta de fuente de flujo portador como Yy, y el destino como Bb, y la remite (según se indica por la referencia 38) a su par del dominio de la izquierda. En la b-CSCF pareja del dominio de la izquierda, la recepción del mensaje de CONFORMIDAD 200 provoca la petición, o la generación, de la relación de correspondencia Xx \Leftarrow Yy, la activación, en la TBG del dominio de la izquierda, de la relación de correspondencia bidireccional Aa \Leftrightarrow Bb,
Xx \Leftrightarrow Yy (según se indica por la referencia 40) y, por último, la propagación hacia el cliente de SIP de origen del mensaje de CONFORMIDAD 200 con una F-Spec de [Aa, Xx] (según se indica en la referencia 42). Desde el punto de vista del cliente 22 de SIP de TE, el otro punto de extremo del flujo portador para la sesión es el Xx, en la TBG 14 del Dominio de la Derecha.
Lo que hace el procedimiento antes descrito es,
de hecho, segmentar el flujo portador en tres segmentos de flujo
portador e instalar en TBGs las relaciones de correspondencia a los
paquetes "re-etiquetados", de tal forma que
éstos son remitidos al siguiente segmento. Cuando éste envía
paquetes portadores al AS 8b, el TE 8 pone en ellos una dirección de
destino de Xx, la dirección de destino que recibió en la
F-Spec de CONFOMIDAD 200. Xx es una dirección y un
número de puerta servidos por la TBG 14 en el dominio troncal del
TE; el primer segmento de flujo portador se encuentra entre el TE
(dirección A) y la TBG (anunciante de la dirección X en la red
troncal de la izquierda), una concatenación del segmento de enganche
y el segmento troncal más a la izquierda del mismo. El segundo
segmento es un segmento de intercambio entre la TBG de la izquierda
(dirección B en la red de intercambio) y la TBG de la derecha
(dirección Y en la red de intercambio). El tercer segmento, de nuevo
una concatenación de un segmento de enganche y un segmento troncal,
se encuentra entre la TBG de la derecha (anunciante de la dirección
C en la red troncal de la derecha) y el AS (dirección Z). Los
paquetes son remitidos a lo largo de cada segmento portador
individual hasta el punto de extremo del segmento portador de
acuerdo con las reglas normales de encaminamiento de IP, debido a
que la dirección de destino del encabezamiento de paquete es la
dirección de IP del punto de extremo del segmento. En las TBGs, el
encabezamiento de paquete se reinscribe para colocar el paquete al
comienzo del siguiente segmento portador. Quienes están
familiarizados con los caminos de etiquetas intercambiadas pueden
constatar que ésta es una forma de intercambio de etiquetas en la
que el campo de etiqueta es toda la fuente de encabezamiento de IP y
los campos de dirección y puerta de destino. Este enfoque para
considerar el presente mecanismo puede ser aplicado para interpretar
el resultado de aplicación cuando existen múltiples dominios entre
los dominios originario y terminante. La Figura 5 aumenta la Figura
2 con relaciones de correspondencia de NAT que definen cada segmento
portador.
Puede observarse también que, cuando se opera
sobre una única esfera de direcciones de IP, sólo es necesario
establecer una nueva relación de correspondencia con la dirección de
destino, ya que la dirección de fuente en paquetes no afecta a su
encaminamiento. Sin embargo, como la dirección de fuente se utiliza
en diversas comprobaciones de seguridad, tales como en cortafuegos,
y para la instalación de criterios de QoS, es necesario un enfoque
consistente. Cuando están implicadas múltiples esferas de
direcciones (véase más adelante), debe establecerse una nueva
relación de correspondencia con la dirección de fuente, de tal modo
que se adopta la solución que siempre deberá ser.
Debe apreciarse también que, en la esfera de
direcciones de IP individual, tan sólo se requiere el "intercambio
de etiquetas" en los nodos en los que no puede confiarse en la
remisión de IP para la remisión de paquetes al siguiente segmento
portador. Los flujos portadores tan sólo necesitan ser segmentados
en pasarelas que pueden no siempre encontrarse en el camino de flujo
de remisión de IP. Generalmente, una topología contenida de los
enlaces de intercambio entre dominios puede permitir la garantía de
que una pasarela se encuentre siempre en el camino de flujo de
remisión de IP y, por tanto, no requiera ser un punto de extremo de
segmento portador. Como ejemplo, si existe un único par de TBGs que
interconectan dos dominios y está garantizado que el camino más
corto entre ellos no atraviesa un tercer dominio, entonces bastará
un único segmento portador del TE al AS para asegurarse de que los
paquetes siempre pasan a través del par de TBGs.
\vskip1.000000\baselineskip
La organización de NGN anteriormente descrita no
requiere que todos los dominios administrativos sean parte de la
misma esfera de direcciones de IP. En lugar de ello, debido a que la
parte llamada se ha identificado en mensajes de SIP por un URI, y no
por una dirección de IP, la cadena de CSCFs puede remitir mensajes
de SIP hacia la parte llamada a través de los límites de la esfera
de direcciones de IP. Esto no requiere que las
b-CSCFs puedan adaptar la señalización de SIP a su
propia esfera de direcciones de IP cuando la reciben de sus pares
que no se encuentran en la misma esfera de direcciones; por ejemplo,
en la Figura 6, la b-CSCF de la esfera de IPv6
recibirá mensajes de SIP en formato IPv6 desde su par existente en
la esfera Pública IPv4, y tendrá que reformatear los mensajes en la
forma IPv6 antes de remitirlos a otras CSCFs existentes en su propio
dominio. Como se destacó anteriormente, los mensajes de SIP
contienen en la parte de SDP especificaciones de flujo implícitas
(F-Specs) para los flujos portadores que se van a
establecer. Cuando los flujos portadores han de atravesar múltiples
esferas de direcciones, es necesario cambiar las
F-Specs de los mensajes de SIP en los límites de las
esferas de direcciones con el fin de reflejar las nuevas
traducciones de dirección y de puerta de red que se van a efectuar
en los flujos portadores. El reformateado de mensajes de SIP y la
alteración de las F-Specs reciben a menudo el nombre
de Función ALG (Pasarela de Capa de Aplicación -"Application Layer
Gateway") de SIP.
La Figura 6 ilustra dos dominios administrativos
que utilizan tres esferas de direcciones de IP: el dominio
administrativo que sirve a los terminales (TEs) asigna direcciones
de IPv4 privadas a los terminales (quizá debido a que no tiene,
asignadas a él, las suficientes direcciones de IPv4 públicas como
para dar a cada terminal su propia dirección de IP pública), pero
utiliza direcciones públicas en la red troncal mientras que el otro
dominio administrativo utiliza direcciones de IPv6 públicas en todo
momento. La red de intercambio que interconecta los dos dominios de
NGN se muestra en la Figura 6 como una red de IPv4, que es parte del
ámbito o esfera de direcciones de IPv4 públicas. Esto es una
elección arbitraria y la red de intercambio bien podría, igualmente,
haber formado parte de la esfera de direcciones de IPv6.
Comparando la Figura 4 con la Figura 6, se
observará que existe un límite de la esfera de direcciones en la AG
del lado de la izquierda. Esta AG necesita llevar a cabo una función
de NAT en paquetes conforme éstos cruzan entre la Red de Enganche y
la Red Troncal. Así, la p-CSCF que controla la AG,
que es la p-CSCF 16 que está emparejada con el
cliente 22 de SIP de los TEs 8 enganchados a la AG 10, necesita
traducir la F-Spec del SDP en mensajes de SIP (de
tal manera que el (los) flujo(s) portador(es) parezcan
originarse en la AG), e instalar en la AG la relación de
correspondencia requerida para poner fin al segmento portador de
enganche y dar origen al segmento portador troncal. Específicamente,
la dirección Aa mostrada en la Figura 6 es una dirección de IP y una
asignación de puerta privadas, en tanto que la Bb es una dirección
de IP (y número de puerta) pública, anunciada en la Red Troncal por
la AG 10. De nuevo, se observará por quienes están familiarizados
con el encaminamiento de IPv4 privado y público y el encaminamiento
por defecto, que la relación de correspondencia Ww \Leftarrow Xx
mostrada no es estrictamente necesaria, puesto que las direcciones
de IPv4 privadas y públicas no se solapan y una red de enganche
remitirá paquetes a la AG en cualquier caso. Sin embargo, no
establecer una nueva relación de correspondencia de encabezamientos
de IP completos en los paquetes portadores producirá una asimetría
en las particiones, en sentido directo y de vuelta del flujo
portador, en segmentos portadores, y esto podría causar sutiles
problemas de mantenimiento.
El otro límite de esfera de direcciones de la
Figura 6 se encuentra en la TBG del dominio de la derecha. Esta TBG
tiene una o más interfaces que operan en la esfera de direcciones de
IPv4 y, específicamente, la dirección Y es una dirección (una de las
direcciones) de IPv4 de la(s) interfaz (interfaces). Tiene
también una o más interfaces que operan en la esfera de direcciones
de IPv6, en la que la dirección D es una dirección de interfaz de
IPv6 de la TBG. Como se ha destacado anteriormente, los mensajes de
SIP que llegan a la b-CSCF del dominio de la derecha
desde la b-CSCF del dominio de la izquierda, estarán
en el formato IPv4, con los encabezamientos de IPv4 y todas las
direcciones de IP incorporadas en v4. La b-CSCF ha
de traducir estos mensaje para tener encabezamientos de IPv6 y
direcciones de IP incorporadas, antes de remitir el mensaje a la
siguiente CSCF. Para la F-Spec del SDP de los
mensajes INVITAR de SIP, la traducción tiene que coincidir con la
relación de correspondencia de NAT que se instalará en la TBG, es
decir, no hay cambios con respecto al procedimiento de fijación de
la ruta descrito.
\vskip1.000000\baselineskip
Quienes están al corriente de los aspectos de
desarrollo práctico de servicios de VoIP públicos constatarán que,
con frecuencia, hay una función de NAT que se lleva a cabo entre un
TE y la red de enganche (AN). Esta función entra en juego en la
frontera de una residencia o empresa con una esfera de direcciones
de IP privadas. Hoy en día, esta función de NAT no está al corriente
de SIP (es decir, no incluye una Pasarela de Capa de Aplicación
(ALG) de SIP). Sin embargo, este fenómeno no afecta materialmente al
anterior mecanismo; pueden seguir utilizándose las mismas soluciones
que permiten a la VoIP funcionar en la actualidad. Así, pues, o bien
el cliente "fija" la señalización de SIP al determinar qué
relación de correspondencia de NAT se está aplicando, preguntando en
primer lugar a un servidor de STUN (Transversal Simple de UDP a
través de NAT) (véase la RFC 3489); o bien la p-CSCF
detecta que se ha llevado a cabo una traducción de NAT en la
señalización de SIP desde el Cliente (debido a que la dirección de
IP de los clientes incorporada en el SDP de los mensajes de INVITAR
o de respuesta, no coincide con la dirección de fuente de IP del
encabezamiento del mensaje), y da instrucciones a la AG para
compensar esto cuando se está encargando del flujo portador.
En el futuro, la pasarela residencial de un
equipo de borde de consumidor que lleva a cabo la función de NAT,
puede mejorarse de manera que incluya funciones
p-CSCF o sea controlada por una
p-CSCF, de tal modo que el segmento del (de los)
flujo(s) portador(es) situado dentro de la residencia
esté completamente bajo el control del procedimiento de
establecimiento de sesión de SIP.
\vskip1.000000\baselineskip
La ventaja del mecanismo de fijación de
encaminamiento anteriormente descrito es que utiliza una capacidad
(NAT) que está frecuentemente presente en TBGs (y en AGs) y que no
requiere ningún soporte por parte de otros dispositivos de
encaminamiento de la red troncal. El mecanismo tiene como resultado
que se apliquen las funciones de NAT a todos los caminos portadores
que cruzan un dominio administrativo. También hace posible que se
aplique una función de NAT en una AG incluso cuando la red de
enganche se encuentra en el mismo ámbito o esfera de direcciones de
IP que la red troncal. Más adelante se describen brevemente dos
beneficios adicionales de someter siempre a NAT los flujos
portadores, que lo convierten en el método preferido para la
fijación del camino de los flujos portadores en IMS.
\vskip1.000000\baselineskip
En la PSTN, un llamante puede solicitar que a la
parte a la que llama no se le presente el número de teléfono del
llamante. La señalización de SIP da soporte o permite la supresión
de la dirección de SIP de la parte llamante, pero la dirección de IP
de fuente de los paquetes portadores puede ser suficiente para que
la parte llamada identifique al llamante o la posición del llamante.
Como poco, el hecho de tener la dirección de IP del llamante
permitirá a la parte llamada que así lo pretenda, emprender un
ataque de rechazo del servicio contra el llamante o llevar a cabo
alguna otra forma de acoso por Internet. Si, según el curso de las
cosas, el flujo portador se rompe en segmentos portadores y cada
parte ve sólo una dirección de IP de su AG local, entonces el hecho
de realizar o recibir una llamada de SIP no revelará a ninguna de
las partes la dirección de IP de la otra parte, ni dejará abierto
ninguna forma de comunicación con esa parte, fuera del marco de IMS
de unas partes completamente autentificadas.
\vskip1.000000\baselineskip
Es un requisito de los métodos para realizar una
Intercepción Legal que el objetivo de la intercepción no sea capaz
de detectar que sus comunicaciones han sido interceptadas. Otra
obligación para realizar una Intercepción Legal es que el personal
operario distinto de quienes están directamente encargados de llevar
a cabo la intercepción, no sea capaz de detectar que se está
produciendo una intercepción -esta obligación conduce habitualmente
al despliegue de pasarelas de medio de intercepción específicas para
ese propósito en la red troncal doméstica del objetivo. Cuando se
utiliza la NAT según se ha descrito anteriormente, la descripción de
SDP y los encabezamientos reales de los paquetes de los flujos
portadores que están presentes en un cliente final, no contienen la
dirección de IP de la otra parte, sino, en lugar de ello, la de una
pasarela intermedia, y entonces el usuario no puede afirmar (del
examen de las direcciones de IP) si su camino portador ha sido
desviado a una pasarela de medio de intercepción con el fin de
realizar una copia de los paquetes de camino portador.
\vskip1.000000\baselineskip
El IMS se ha desarrollado bajo la suposición de
las entidades situadas en ambos extremos de una sesión, por ejemplo,
el cliente y el servidor de aplicación de la Figura 1, utilizan el
control de SIP (SIP de habla) para poder establecer un flujo
portador. Los métodos anteriormente descritos extienden la
aplicabilidad del IMS a aplicaciones que requieren tratamiento de
QoS para flujos portadores que no son, necesariamente, corrientes
multimedia, si bien la aplicación sigue necesitando tener capacidad
para SIP. Aunque es razonable suponer que un servidor de aplicación
tiene capacidad funcional para SIP, es deseable tener la posibilidad
de establecer flujos portadores para clientes que no son hablantes
de SIP. Tal capacidad abrirá más rápidamente el abanico de servicios
y aplicaciones útiles a los que da soporte una red de IMS NGN, de lo
que ocurriría si los clientes de aplicación (que son mucho más
numerosos que los servidores) tuvieran que ser modernizaos para
tener capacidad funcional de SIP antes de que la aplicación pudiera
sacar partido del transporte de QoS proporcionado por la nueva
NGN.
De acuerdo con un tercer aspecto de la presente
invención, un representante de cliente ignorante de la aplicación
está asociado con la CSCF que controla la pasarela de enganche 10 a
través de la cual se engancha a la red un cliente que no es de SIP.
El representante de cliente responde a un mensaje de INVITAR de SIP
procedente del servidor de aplicación, en representación del
cliente, de manera que puede proporcionarse el tratamiento de QoS de
los flujos portadores a través de al menos el segmento de enganche.
En la realización que se describe en lo que sigue, el servidor de
aplicación puede ser un servidor que esté al corriente de SIP y que
sea capaz de apelar a los mecanismos que aquí se describen.
Alternativamente, puede desplegarse un representante de servidor de
aplicación con la capacidad funcional requerida, en vez de
actualizar o modernizar el servidor de aplicación. En cualquier
caso, la presente técnica elimina la necesidad de desplegar un
representante específico al corriente de la aplicación para todos
los tipos de clientes de aplicación posibles (lo que resultaría ser
un procedimiento muy difícil en una red de múltiples dominios). La
presente invención puede ser implementada mediante la mejora de la
p-CSCF que controla la AG a la que está enganchado
un cliente de aplicación, a fin de proporcionar una función de
representante general, independiente de la aplicación, para los
clientes.
En lo que sigue se describen dos realizaciones
representativas de la invención: 1) cuando sólo se asegura el
tratamiento de QoS al segmento de enganche de extremo de cliente de
la aplicación, y 2) cuando se ha de proporcionar el tratamiento de
QoS a todo el flujo portador. La primera realización es,
probablemente, muy útil para muchas instalaciones, ya que, en
comparación con la red troncal, la anchura de banda está mucho más
limitada en las redes de enganche, en particular, en aquellas con un
primer tramo inalámbrico.
\vskip1.000000\baselineskip
En esta realización, lo que se busca es
proporcionar tratamiento de QoS únicamente para el segmento portador
de enganche de cliente de aplicación (véase la Figura 7). Se supone
que el AS (servidor de aplicación o su representante) 8b es un
hablante registrado con una S-CSCF en un cierto
dominio de IMS: el dominio doméstico del Servidor. El cliente de
aplicación está enganchado a la red troncal de un cierto dominio
(designando como el dominio en servicio del Cliente en la Figura 7),
de la cual recibe la capacidad de conexión de IP a la red NGN.
Puesto que el cliente de aplicación 8 no está al corriente de SIP,
no está registrado con ninguna CSCF. Sin embargo, se supone que el
punto de enganche del cliente de aplicación es una AG bajo el
control de una p-CSCF en el dominio en servicio del
Cliente. Esta AG se recibe el nombre de Pasarela en Servicio para el
TE.
Si bien la Figura 7 muestra el dominio en
servicio del Cliente como separado por un enlace de tránsito con
respecto al dominio doméstico del Servidor, por cero o más dominios
de tránsito que los interconectan, la presente invención es también
aplicable a redes en las que el servidor de aplicación y el cliente
se encuentran en el mismo dominio. En aras de la claridad, la
descripción que sigue supone, en primer lugar, que los dominios
(doméstico del Servidor, servidor del Cliente y cualesquiera
dominios de tránsito) son, todos ellos, parte de la misma esfera de
direcciones de IP -al final de esta sección se describen mecanismos
adicionales para encargarse de los dominios que se encuentran en
esferas de direcciones de IP independientes.
Puesto que el servidor de aplicación 8b va a
enviar paquetes (en el flujo portador) al cliente 8, ha de ser capaz
de generar una F-Spec para el flujo portador (en
caso contrario, no sería capaz de generar el encabezamiento de IP de
los paquetes). Habitualmente, ya habrá habido algunas interacciones
entre el cliente y el servidor antes de que haya necesidad de
establecer un flujo portador: ejemplos de ello son las interacciones
de Intercambio de Clave de Internet (IKE -"Internet Key
Exchange") antes de que se establezca un túnel de IPSec, o la
navegación o desplazamiento para seleccionar un clip de vídeo
[grabación corta de vídeo] antes de suministrarlo como corriente de
datos al cliente. A partir de los encabezamientos de IP del
intercambio inicial, el servidor obtendrá las direcciones de IP y
los números de puerta del extremo del cliente del flujo portador. La
dirección de IP del cliente que el Servidor aprende es una dirección
anunciada por la AG 10, a través de la cual el cliente 8 es
enganchado a la red troncal 4. En efecto, la F-Spec
describe un segmento portador que va del Servidor de Aplicación 10 a
la AG 8b. La AG 10 utiliza la dirección de IP del cliente de los
paquetes entrantes para dirigirlos hacia el segmento portador de
enganche que completa el camino de flujo al cliente 8.
La presente invención contempla una nueva forma
de URI (Identificador de Recursos Universal -"Universal Resource
Identifier"), que recibe el nombre de URI de Pasarela en
Servicio, destinado a ser utilizado como parámetro de destino de
INVITAR (e insertado en la cláusula "A" ("TO")) del
mensaje INVITAR de SIP generado por el servidor de aplicación 8b. El
identificador de este URI es una representación de una dirección de
IP: la semántica que se pretende para este URI es que el destino
(denominado parte) nombrado por este URI es la p-CSF
16 que puede empujar criterios a la AG 10 que anuncia la dirección
de IP en el URI.
Existe un cierto número de mecanismos que pueden
ser utilizados para encaminar mensajes de INVITAR de SIP que tienen
como destino este nuevo URI de Pasarela en Servicio. Como ejemplo,
si están asociadas b-CSCFs con el AS (subsistema
autónomo) en el que se encuentran, y se ha aportado ese número de AS
en sus tablas de remisión de las b-CSCFs parejas,
entonces, cuando una b-CSCF recibe un mensaje de
INVITAR, tan sólo precisa determinar el AS del "siguiente
salto" para la ruta BGP-4 hacia la dirección de
IP de objetivo, a fin de identificar a qué nuevo dominio
administrativo y b-CSCF pareja enviar el INVITAR.
Una que el INVITAR ha alcanzado el dominio administrativo de
destino, puede ser remitido a una S-CSCF
especialmente designada, con la que todas las
p-CSCFs del dominio habían registrado los intervalos
de direcciones de las pasarelas que controlan. La
S-CSCF designada coincide entonces con el URI de
Pasarela en Servicio para encaminar intervalos para determinar la
p-CSCF a la que remitir el mensaje de INVITAR.
Pueden también utilizarse otros métodos de remisión, según se
desee.
\newpage
Bajo las suposiciones anteriores, el
establecimiento de un flujo portador entre un servidor de aplicación
y un cliente se desarrolla como sigue:
En una primera etapa, el servidor de aplicación
8b envía a su S-CSCF, en su Dominio doméstico (a
través de su p-CSCF), un INVITAR de SIP con la
cláusula A ("TO"), que contiene un URI de Pasarela en Servicio
que específica la dirección de IP del cliente y que incluye, en la
parte de SDP, la F-Spec para el flujo portador hacia
el cliente, y una T-Spec que el servidor quiere que
se aplique. (Como es el servidor el que será facturado por la
sesión, es la prerrogativa del servidor especificar la
T-Spec).
Una vez que la S-CSCF ha llevado
a cabo el procedimiento normal de creación del INVITAR, ésta remite
el INVITAR hacia el dominio en servicio del cliente. Si el dominio
en servicio del cliente es distinto del Domino doméstico del
servidor, entonces el INVITAR será remitido, a través de las
b-CSCFs, cruzando, posiblemente, varios límites de
dominio hasta que llegue a una b-CSCF situada en la
frontera del dominio en servicio del cliente, por ejemplo, con el
uso del procedimiento de decisión de remisión esbozado
anteriormente.
Una vez que el INVITAR llega a una
b-CSCF situada en el dominio en servicio del
cliente, ha de ser remitido a la p-CSCF que controla
(apela a la función de decisión de criterio de) la AG 10 a la que
está enganchado, en realidad, el cliente 8. De nuevo, puede
utilizarse el mecanismo ejemplar anteriormente esbozado, pero los
expertos de la técnica constatarán que son posibles muchos
mecanismos.
Al recibir el mensaje INVITAR, la
p-CSCF solicita (la RACF de) la AG 10 con el fin de
instalar un criterio de QoS en la red de enganche que se adecue a la
T-Spec especificada para el flujo portador
identificado por la F-Spec en el SDP del mensaje
INVITAR. Es en este punto cuando entra en juego el comportamiento
modificado de la p-CSCF, desencadenado por la
cláusula A que contiene un URI de Pasarela en Servicio, y los
resultados del intento de instalar el criterio de QoS. En un sistema
convencional, la p-CSCF remitiría el INVITAR al
cliente 8, que, en el presente caso (el cliente es un cliente no de
SIP), no sabría qué hacer con él. Así, de acuerdo con la presente
invención, un representante genérico 44, instado por el cliente 8
(o, de forma equivalente, por la p-CSCF, que actúa
con las facultades de un representante genérico), envía una
respuesta de SIP apropiada de vuelta al Servidor de Aplicación 8b en
representación del cliente 8. Si el intento de instaurar el criterio
de QoS en la AG ha tenido éxito, el representante genérico envía un
mensaje de aceptación (por ejemplo, una "CONFORMIDAD 200") de
vuelta al Servidor de Aplicación 8b, a lo largo del camino inverso
del de INVITAR. Alternativamente, si la petición de instalación del
criterio de QoS no ha tenido éxito, entonces el mensaje de retorno
desde el representante genérico 44 será, en su lugar, un mensaje de
ADIOS ("BYE"), a fin de indicar al servidor 8b que no había
recursos suficientes en la red de enganche como para dar soporte a
la T-Spec solicitada para el flujo portador. Se
apreciará que, en esta operación, el tratamiento de QoS se aplica al
segmento portador de enganche, y a la señalización de SIP generada
para completar el establecimiento del flujo portador, sin que la
b-CSCF (o representante genérico 44) tenga ninguna
constancia de la aplicación del cliente. Como tal, el representante
genérico 44 es ciertamente genérico; puede utilizarse para
establecer flujos portadores con tratamiento de QoS, para cualquier
aplicación de cliente.
Una vez que el Servidor de Aplicación 8b ha
completado el establecimiento de la sesión de SIP, los paquetes que
envía al cliente 8 que conforma la F-Spec
atravesarán los diversos dominios intermedios en la forma de mejor
esfuerzo, pero atravesarán la red de acceso/enganche 6 con la QoS
especificada.
Una vez que el Servidor de Aplicación 8b ha
terminado de dar servicio al cliente 8, puede liberar los recursos
de QoS enviando un mensaje de ADIOS de SIP a lo largo del camino del
INVITAR inicial. Cuando éste llega a la p-CSCF, el
mensaje de ADIOS provocará la liberación del criterio de QoS para el
flujo portador de la manera normal, pero de nuevo será la
p-CSCF (o el representante genérico 44), en lugar de
la propia aplicación de cliente, la que genere los mensajes de
confirmación de SIP.
Nótese que el mecanismo anteriormente descrito
no trabajará con clientes de aplicación no modificada cuando se
instalen criterios de QoS en una red de enganche por medio de un
mecanismo también denominado "de extracción", ya que los
mecanismos de "extracción" requieren que el cliente esté
implicado en el procedimiento, y la esencia del método descrito es
instalar un criterio de QoS en la red de enganche sin la implicación
del cliente.
\vskip1.000000\baselineskip
Como se ha descrito anteriormente, existen dos
casos que considerar cuando el TE 8 y el AS 8b no son esferas de
direcciones de IP diferentes. El primero de estos casos se da cuando
el TE 88 está en una esfera de direcciones de IP privadas y las
redes de núcleo son parte de una única esfera de direcciones de IP.
La AG 8b lleva a cabo una función NAT, traduciendo los
encabezamientos de IP en paquetes que van a la red troncal 4, de tal
manera que la dirección de fuente de los paquetes procedentes del
cliente 8 es una dirección pública anunciada por la AG 10 cuando los
paquetes llegan Servidor de Aplicación 8b. Siempre y cuando el
Servidor de Aplicación 8b utilice esta dirección pública en la
construcción del URI de Pasarela en Servicio y la
F-Spec (y no una dirección sin traducir dentro de un
paquete de control), llegará entonces el mensaje INVITAR a la
p-CSCF de control, según se ha descrito
anteriormente. La p-CSCF hace su petición de RACF
utilizando la F-Spec de la esfera de direcciones de
IP públicas; la AG 10, al corriente de que está sometiendo a NAT el
tráfico procedente del cliente 8, necesita establecer una relación
de correspondencia de la dirección de IP del cliente con la
F-Spec antes de instalar ningún "portal" de
capa de IP en la red de enganche.
Cuando existe un límite de esferas de
direcciones de IP entre las redes troncales 14, las cosas se
complican un poco: el camino del flujo portador es, en efecto,
segmentado en dos partes en la TBG 14 que lleva a cabo la NAT entre
esferas de direcciones. En la Figura 8, se ha mostrado que la
frontera entre la esfera Izquierda de direcciones de IP y la esfera
Derecha de direcciones de IP se encuentra en el borde del dominio
doméstico del Servidor (si bien podría estar en la frontera de
cualquiera de los dominios), y la TBG 14 que hay allí es la que
lleva a cabo la NAT en todo el tráfico. Desde el punto de vista del
Servidor de Aplicación 8b que genera un URI de Pasarela en Servicio,
esa TBG 14 es la Pasarela en Servicio (es decir, la anunciante de la
dirección de fuente en paquetes que llega desde el cliente de TE; en
la Figura 8, el Servidor de Aplicación ve una dirección de fuente de
B, que es una dirección de la esfera Derecha de direcciones de
IP).
Puede encaminarse un mensaje INVITAR de SIP a la
b-CSCF que controla la TBG 14 de NAT, utilizando,
por ejemplo, el mismo mecanismo que se ha descrito anteriormente.
Como se ha destacado antes, las b-CSCFs que
controlan las TBGs de límite de esfera de direcciones, tienen que
ser capaces de llevar a cabo una función de ALG de SIP. En este
caso, la relación de correspondencia de NAT para la
F-Spec de interés ya habrá sido instalada en la TBG
de NAT antes de que el mensaje INVITAR de SIP llegue a la pasarela
que está controlando. La primera acción de la b-CSCF
debe ser interrogar a la TBG 14 para averiguar la relación de
correspondencia de NAT, de tal manera que pueda entonces construir
el mensaje INVITAR para la esfera (Izquierda) de direcciones de IP
del lado del cliente, con un URI de Pasarela en Servicio para la AG
10 a la que está enganchado el TE 8, y una F-Spec
para el segmento portador del lado del cliente. En la Figura 8, el
nuevo URI de Pasarela en Servicio contendrá la dirección A. Desde
este momento en adelante, el procedimiento prosigue según se ha
descrito anteriormente, de manera que la b-CSCF
lleva a cabo las funciones de ALG requeridas en los mensajes de SIP
de respuesta.
Hay una reserva a la hora de tratar los límites
de las esferas de direcciones de IP entre redes troncales. Como se
ha destacado anteriormente, el camino de IP determinado como ruta
para un flujo portador puede no atravesar los mismos dominios que la
señalización de SIP. En particular, puede haber redes en las que el
camino de IP determinado como ruta puede transitar a través de
dominios que no son partícipes en la NGN. Si la traducción NAT se
produce en una pasarela de frontera que no forma parte de la NGN (es
decir, que no está bajo el control de una b-CSCF),
entonces el mecanismo anterior fallará. El procedimiento para esta
situación es utilizar una fijación completa de la ruta según se
describe en la siguiente parte.
\vskip1.000000\baselineskip
Un ejemplo típico del uso de esta invención
sería para un servicio de vídeo en corriente o flujo continuo de
herencia (es decir, previa al SIP). Un proveedor de servicios de
vídeo puede desear suministrar un vídeo en flujo continuo con un
nivel de calidad que sea mayor que el que pueden soportar
fiablemente la mayoría de las redes de acceso/enganche en el nivel
de servicio de "mejor esfuerzo". Una vez desplegada esta
invención en la NGN, el Proveedor de Servicios de Vídeo modernizará
sus servidores para que tengan capacidad para SIP (incluyendo que
sean capaces de generar URIs de Pasarela en Servicio), y negociará
entonces un servicio de IMS desde un operador local. El operador
local establecerá una tarifa, que puede ser por película, o basada
en el tiempo, o por megabyte transferido en una clase de QoS
concreta. Esta forma de tarifación dependerá de factores
competitivos y será, probablemente, más baja para las sesiones que
sigan "en la red" (el cliente está enganchado a la propia red
del operador) que para las sesiones en las que el operador tenga que
compartir el importe con uno o más operadores diferentes. La tarifa
puede ser también específica del tipo de red de enganche que está
utilizando el cliente de la aplicación, de manera que sea más alta
para una inalámbrica que para una por cable. El SLA entre el
Proveedor de Servicios de Vídeo y el operador de NGN cubrirá también
el aspecto del restablecimiento cuando se ha producido un fallo en
una sesión.
Los clientes potenciales del servicio de vídeo
proceden de la forma habitual, interactuando con el(los)
servidor(es)
de aplicación de vídeo para buscar y seleccionar una película. Como parte de las presentaciones visuales de respuesta a la búsqueda, se presentará al usuario el precio del visionado de la película: presumiblemente, el Proveedor de Servicios de Vídeo establecerá el precio de manera que cubra el coste de la tarifa de suministro. Quizá la película llegue con diferentes resoluciones, a distintos precios, y sea adecuada para diferentes redes de enganche de cliente. Una vez completada la selección por parte del usuario, el Servidor de Vídeo inicia una sesión de SIP con la cláusula A ("TO") del INVITAR que contiene un URI de Pasarela en Servicio con la dirección de IP de cliente y una T-Spec para la corriente o flujo continuo de vídeo. Esto tendrá como resultado que la AG que está dando servicio al cliente instale un criterio de QoS en la red de enganche que está utilizando en ese momento el cliente, de tal manera que los paquetes con contenido de vídeo destinados al cliente desde el servidor reciben el tratamiento de QoS que el servidor de vídeo solicitó en el mensaje INVITAR.
de aplicación de vídeo para buscar y seleccionar una película. Como parte de las presentaciones visuales de respuesta a la búsqueda, se presentará al usuario el precio del visionado de la película: presumiblemente, el Proveedor de Servicios de Vídeo establecerá el precio de manera que cubra el coste de la tarifa de suministro. Quizá la película llegue con diferentes resoluciones, a distintos precios, y sea adecuada para diferentes redes de enganche de cliente. Una vez completada la selección por parte del usuario, el Servidor de Vídeo inicia una sesión de SIP con la cláusula A ("TO") del INVITAR que contiene un URI de Pasarela en Servicio con la dirección de IP de cliente y una T-Spec para la corriente o flujo continuo de vídeo. Esto tendrá como resultado que la AG que está dando servicio al cliente instale un criterio de QoS en la red de enganche que está utilizando en ese momento el cliente, de tal manera que los paquetes con contenido de vídeo destinados al cliente desde el servidor reciben el tratamiento de QoS que el servidor de vídeo solicitó en el mensaje INVITAR.
\vskip1.000000\baselineskip
Como se ha descrito anteriormente, la red NGN
puede proporcionar un tratamiento de QoS a todos los segmentos del
flujo portador, de tal manera que el flujo portador es "fijado"
por medio de TBGs de los dominios administrativos que participaron
en el intercambio de señalización de SIP. Este mecanismo y la
capacidad de QoS de Extremo a Extremo resultante pueden combinarse
con el uso de URIs de Pasarela en Servicio cuando los clientes de TE
no son hablantes de SIP. Comparado con el mecanismo para suministrar
QoS sólo en el segmento de enganche, el mecanismo combinado tiene
cada p- y b-CSCF (que procesan el mensaje INVITAR
del Servidor conforme éste es encaminado a la p-CSCF
que controla la Pasarela en Servicio del TE) también como pasarelas
principales para efectuar las traducciones NAT con el fin de fijar
el flujo portador de manera que reciba el tratamiento de QoS
solicitado.
Además de las condiciones y suposiciones
necesarias para la QoS, en el segmento de enganche existe una
exigencia añadida necesaria para suministrar QoS de extremo a
extremo: cuando se envían paquetes que forman parte del flujo
portador, el servidor de aplicación debe utilizar la dirección de
destino y el número de puerta deducidos de la F-Spec
final recibida en el mensaje de respuesta de SIP "CONFORMIDAD
200", en lugar de la dirección y el número de puerta iniciales
del cliente, que aprendió del protocolo de herencia (que puso en la
F-Spec inicial).
Debido a que la F-Spec final
generada por las CSCFs define el segmento portador de enganche para
el Servidor de Aplicación, utilizar sus direcciones en los
encabezamientos de los paquetes garantiza que: incluso cuando el
servidor de aplicación tiene en posición múltiples enlaces de
enganche de red, el servidor de aplicación remitirá los paquetes
portadores hacia la AG que ha sido "primada" por la
señalización de SIP, a fin de suministrar QoS y establecer una
relación de correspondencia con los encabezamientos de los paquetes
de tal manera que se remitan los paquetes al siguiente segmento
portador; y, cuando hay más de una esfera de direcciones de IP que
atravesar, la operación de fijación de la ruta tiene como resultado
el uso de las pasarelas de NAT que tienen establecidas sus
relaciones de correspondencia de NAT por el control de las
b-CSCFs.
\vskip1.000000\baselineskip
El beneficio de los presentes métodos puede
verse desde el ejemplo anterior de un Servicio de Vídeo en corriente
o flujo continuo de herencia. Sin la participación de la presente
invención, la única manera de que un proveedor de servicios de vídeo
garantice la QoS a una cliente de herencia (es decir, no de SIP)
sería que el proveedor de servicios de vídeo entrase en una relación
especial con cada proveedor de red de enganche que utilizan sus
abonados, de tal manera que se acuerde una QoS mejorada para todo el
tráfico procedente de sus servidores de vídeo a través de esas redes
de enganche. Esto tiene la desventaja de que o bien el servicio va a
estar limitado en su ámbito geográfico, o bien el proveedor de
servicios de vídeo tiene que negociar con cada proveedor de red de
enganche que cualquiera de sus consumidores pudiera querer utilizar.
Con la presente invención, el proveedor de servicios de vídeo
únicamente necesita negociar con un operador que forme parte de la
NGN y pueda, por tanto, dar servicio a abonados enganchados a
cualquier red del operador de NGN. Está también, entonces, el
aspecto de la reserva estática de recursos en la red de acceso, por
lo que el proveedor de red de acceso podría, razonablemente, desear
ser pagado, los utilice o no el proveedor de servicios de vídeo.
Esto conduciría probablemente a que el Proveedor de Servicios de
Vídeo fuera conservador en cuanto a la capacidad/número de sesiones
de vídeo que reservaría en cada red de enganche; el servidor de
vídeo tendría que poner en marcha su propio RAC contra estos
recursos reservados/preasignados, a fin de asegurarse de que no los
niveles de tráfico de SLA no se vean perturbados.
Quienes están familiarizados con el
funcionamiento de SIP constataran que existen otros beneficios de la
posibilidad de utilizar el SIP para establecer un camino portador,
incluso cuando no de los extremos no está al corriente de SIP. Por
ejemplo, puede suceder que, en el curso de una sesión, la red de
enganche no pueda ya dar soporte a la T-Spec con la
que se puso de acuerdo en el inicio de la sesión -por ejemplo, un
terminal móvil puede haberse alejado más de una estación de base y
haberse reducido la velocidad de transmisión disponible entre los
dos. En el funcionamiento adecuado de un subsistema de RAC, la p-
CSCF que está controlado será informada de que el criterio de QoS
que promovió ya no puede ser satisfecha. Puede entonces iniciar una
secuencia de señalización de SIP de nueva invitación de vuelta a la
parte originaria, que incluye el envío de vuelta de una
T-Spec que refleje las características del enlace de
enganche vigente en ese momento. Corresponde entonces a la
aplicación decidir si restablecer la sesión en la QoS más baja o
ponerle fin.
\vskip1.000000\baselineskip
Se ha afirmado anteriormente que la alternativa
a los métodos descritos de suministrar QoS a aplicaciones de
hablante no de SIP a través de la NHN, era desarrollar
representantes de hablante de SIP específicos para clientes y
servidores. El problema de esta solución es el amplio abanico de
aplicaciones potenciales que deberían atenderse. Sin embargo,
algunas aplicaciones pueden ya utilizar alguna forma de protocolo de
reserva de recursos (señalización de IP de herencia), y el número de
estos protocolos es muy limitado. Probablemente, los dos únicos que
es necesario considerar son el RSTP [H. Schulzrinne et al.:
"Real Time Streaming Protocol" ("Protocolo de
suministro de corriente en tiempo real"), RFC 2326, abril de
1998] y el RSVP [R. Braden (ed.) et al.: "Resource
ReSerVation Protocol (RSVP)" ("Protocolo de Reserva de
Recursos (RSVP)"), RFC 2205, septiembre de 1997], Un cuarto
aspecto de la presente invención proporciona un dispositivo de
pasarela que proporciona señalización de IP de herencia a la
cooperación de señalización de SIP. Así, puede proporcionarse una
pasarela de cooperación que albergue una función de señalización de
cooperación (SIWF -"signalling inter-working
function") que ponga fin a la señalización de RTSP y/o RSVP en el
borde de la red y genere mensajes de SIP a través de la red de
núcleo para establecer caminos portadores de extremo a extremo
(habilitados en QoS).
La Figura 9 es una ilustración del despliegue de
las pasarelas de cooperación. En esta Figura, la función de
cooperación de señalización (SIWF) se muestra albergada en las AGs
en servicio para las dos entidades de aplicación (Cliente en TE y
Servidor en AS) que se han de interconectar con un flujo portador.
Las AGs, al estar siempre en el camino de los paquetes hacia y desde
los sistemas de extremo, son las elecciones preferidas para albergar
la función de cooperación de señalización, ya que, utilizando una
profunda inspección de los paquetes, pueden detectar los paquetes de
señalización de herencia dentro de la banda ("dentro de la
banda" quiere decir que los paquetes de señalización son
mezclados con otro tráfico). Sin embargo, las AGs no son la única
elección posible. Otro desarrollo probable restringiría el papel de
las AGs a la detección de paquetes de señalización y a su remisión,
en alguna forma de túnel, a la función de cooperación de
señalización conjuntamente ubicada en la misma plataforma que la
p-CSCF de control de las AGs.
El funcionamiento de las SIWFs puede resumirse
brevemente como sigue:
Cada SIWF establece una asociación con una
p-CSCF y se registra a sí misma como el cliente de
SIP para los sistemas de extremo a los que da servicio. Como en el
caso de las Pasarelas de Servicio (invención 3), las direcciones de
cliente registradas pueden ser sólo las direcciones de IP anunciadas
por la AG para sistemas de extremo que están enganchados a ella.
Alternativamente, y más en sintonía con las consideraciones
comerciales, los Servidores de Aplicación pueden tener nombres
asignados por un procedimiento administrativo cuando se les
autoriza, por parte de una portadora, a utilizar la capacidad
funcional de SIWF para establecer caminos portadores habilitados en
QoS a través de una red NGN.
Cuando detecta un mensaje de señalización de
herencia que es una solicitud para establecer un flujo portador
originario de un extremo portador al que sirve, una SIWF extrae del
mensaje tanto una F-Spec como una
T-Spec para el flujo portador, y construye un
mensaje INVITAR de SIP, dirigido a la misma entidad a la que se
dirigió el mensaje de herencia. Sin embargo, en lugar de que la
parte de esquema del URI de petición de INVITAR sea "sip:",
puede utilizarse el nombre del protocolo de señalización de herencia
como la primera parte del URI, a fin de indicar al destino que el
mensaje INVITAR llega realmente desde una SIWF. También el mensaje
de señalización de herencia de IP original puede transportarse como
un campo en el cuerpo del mensaje de SIP, de la misma manera que los
mensajes de ISUP son transportados en SIP-I (también
denominado SIP-T).
La red NGN remite el mensaje INVITAR de SIP
hacia la SIWF que registró el nombre de su URI de destino
(suponiendo que el destino está enganchado a la NGN a través de una
AG que da soporte a una función SIWF que registró su nombre o su
dirección de IP). Cuando el mensaje INVITAR llega a la SIWF que
registró el destino, esa SIWF reconstruye el mensaje de señalización
de herencia (ya sea directamente a partir de una versión encapsulada
del mensaje portado en el INVITAR, ya sea invirtiendo el proceso que
generó la F-Spec y la T-Spec en el
INVITAR). El mensaje de herencia reconstituido es entonces remitido
a la entidad de destino. En una realización de la invención, la SIWF
abandonará la fuente aparente del mensaje de herencia como la
verdadera entidad de origen, pero, en otras realizaciones,
particularmente aquéllas en las que las entidades de origen y de
destino se encuentran en diferentes esferas de direcciones, la SIWF
aparecerá como la parte originaria del mensaje de señalización de
herencia. (Esta última solución facilita a la SIWF la recepción de
la respuesta de señalización de herencia, puesto que ésta estará
dirigida a ella, pero, ya que se trata de una forma de NAT sin ALG,
puede también causar la ruptura de las aplicaciones).
En el curso normal de las cosas, la entidad de
destino generará una respuesta de protocolo de herencia. Esta será
captada por la AG en servicio y dirigida a la SIWF. La SIWF hará
corresponder la respuesta con el mensaje original reconstruido y con
el INVITAR original. La SIWF convierte la repuesta de herencia en
una respuesta de SIP (por ejemplo, CONFORMIDAD 200), y la remite por
el camino de señalización de retorno a la SIWF que da servicio a la
parte originaria. Algunos de los campos de SDP de la respuesta de
SIP pueden ser extraídos de los campos contenidos en la respuesta de
herencia, mientras que otros lo serán del SDP transportado en el
INVITAR. Basándose en la F-Spec y en la
T-Spec del SDP, las CSCFs del camino de señalización
reservarán los recursos para el camino portador.
Cuando la respuesta de SIP llega a la SIWF que
da servicio a la parte originaria, de nuevo reconstruye el mensaje
de respuesta de herencia y lo remite a la parte originaria
verdadera.
Como el RSVP y el RTSP son protocolos muy
diferentes, se proporciona la descripción más detallada de los
procedimientos de SIWF independientemente para cada protocolo.
\vskip1.000000\baselineskip
El protocolo RSVP está destinado a reservar
recursos de una red para dar soporte a un flujo portador
unidireccional (denominado, simplemente, "flujos de datos" en
los RFCs de RSVP). Si bien el RSVP puede ser utilizado para reservar
recursos para flujos de emisión múltiple y sesiones de conferencia
generales entre varios participantes, la presente descripción se
limita a su uso para flujos portadores de una única emisión o de
punto a punto entre sólo dos entidades, tales como el AS y el TE en
la Figura 9. Bajo el modo de funcionamiento de RSVP, la fuente del
flujo inicia el procedimiento de reserva con un mensaje de
"camino", que contiene una forma de F-Spec
(denominada spec de
filtro -"filterspec") y una T-Spec. Para flujos portadores de emisión única, la F-Spec es una matriz completa de direcciones de IP de fuente y de destino y números de puerta (y protocolo), llamada filtro fijo, lo que significa que la dirección de IP de destino y el número de puerta necesitan ser conocidos por la fuente antes de que ésta dé salida al mensaje de "camino".
filtro -"filterspec") y una T-Spec. Para flujos portadores de emisión única, la F-Spec es una matriz completa de direcciones de IP de fuente y de destino y números de puerta (y protocolo), llamada filtro fijo, lo que significa que la dirección de IP de destino y el número de puerta necesitan ser conocidos por la fuente antes de que ésta dé salida al mensaje de "camino".
El mensaje de "camino" es dirigido al
receptor que se desea para el flujo portador, y sigue, de esta
forma, el camino de IP determinado como ruta entre el emisor y el
receptor. En el caso simple de emisión única, el efecto principal
del mensaje de "camino" es grabar en los dispositivos de
encaminamiento con capacidad para RSVP atravesados la dirección del
salto previo, de tal manera que el mensaje de retorno, el mensaje de
"resv" pueda transitar por el mismo camino de vuelta desde el
receptor al emisor. El receptor replica con un mensaje de
"resv" que sigue, a la inversa, el camino salto a salto del
mensaje de "camino". A medida que procesa o trata el mensaje de
"resv", cada dispositivo de encaminamiento con capacidad para
RSVP compromete recursos de red para el flujo portador basándose en
la T-Spec (denominada, de forma algo confusa, spec
de filtro) del mensaje de "resv".
\vskip1.000000\baselineskip
La Figura 10 es un esbozo de diagrama de
secuencia de mensajes, que muestra la cooperación de señalización en
el establecimiento de un flujo portador desde el servidor de
aplicación (AS) al equipo de terminal (TE) del cliente, a través de
la NGN, de tal manera que tanto el AS como el TE utilizan el RSVP
para solicitar a la red que proporcione QoS al flujo portador. Unas
funciones SIWF están situadas en el primer salto de IP tanto desde
el AS como desde el TE, lo que, en términos de la arquitectura de
NGN descrita en la Figura 1, implica que la capacidad funcional de
SIWF está alojada en pasarelas de enganche (AGs). (Como se ha
destacado anteriormente, este primer salto puede extenderse al hacer
que la AG reconozca y comunique mediante un túnel los mensajes de
señalización de RSVP a una función SIWF albergada adicionalmente en
la red, por ejemplo, en la misma plataforma que alberga la
p-CSCF que controla la AG).
Se supone que la aplicación que el AS
proporciona al SE TE inicia por un intercambio de mensajes entre
ellos. En algún momento (por ejemplo, se ha seleccionado una
película y se relacionan los detalles del pago), el AS determina que
necesita suministrar un flujo en paquetes (flujo portador) al TE y
construye un mensaje de "camino" que específica las direcciones
de IP de fuente y de destino y los números de puerta
(F-Spec) del flujo, así como la
T-Spec para el flujo. Dirige este mensaje al TE y le
da salida en S2. El mensaje de "camino" es interceptado por la
SIWF y convertido en un mensaje INVITE de SIP S4. La
F-Spec y la T-Spec del flujo
portador son convertidas en parámetros de SDP (utilizando la
invención 1 para la T-Spec) y, dado que el TE se
identifica por una dirección de IP, el URI de destino de SIP será un
URI de Pasarela en Servicio (según se ha descrito anteriormente).
Además de traducir la F-Spec y la
T-Spec del formato de RSVP al formato de SIP, es
posible que el mensaje de RSVP original se añada al mensaje de SIP.
En una realización de los mecanismos de SIWF, todo el mensaje de
"camino" de RSVP podría ser encapsulado y transportado como un
campo opaco en el mensaje INVITAR. En otra realización, sólo los
campos internos del mensaje de "camino", y no su
encabezamiento, serán transportados en el mensaje INVITAR. Como
también se ha destacado anteriormente, una realización de la
invención puede escoger cambiar el "esquema" del URI, lo que
tiene como resultado una primera línea del mensaje INVITAR algo así
como:
- INVITAR rsvp:xxx.xxx.xxx.xxx SIP/2.y
- donde xxx.xxx.xxx.xxx. es una dirección de IP (v4).
\vskip1.000000\baselineskip
La red NGN remitirá el mensaje INVITAR de SIP a
la p-CSCF que da servicio a la AG que sirve al TE,
de la manera que se ha descrito anteriormente. A partir de la
función de registro que había llevado a cabo la SIWF registrando las
direcciones de IP (o intervalo de direcciones) para las que es capaz
de realizar sus funciones de cooperación, la p-CSCF
será capaz. En realizaciones en las que el esquema del URI se ha
cambiado, eso bastará para alterar la p-CSCF para
que remita el INVITAR a la SIWF en servicio.
La SIWF regenera entonces, a partir del mensaje
INVITAR, un mensaje de "camino" de RSVP utilizando encapsulados
(partes) del mensaje de camino original, si estuvieran incluidos, y
añade su propia dirección de IP dentro del mensaje como "salto
previo". Remite el mensaje de "camino" al TE 8 (según se
indica por la referencia S6). El TE 8 responderá con un mensaje de
"resv" S8, dirigido al nodo que alberga la función SIWF (su
nodo previo). La función SIWF hará corresponder el mensaje de
"resp" (S8) con el estado que instaló al recibir el mensaje
INVITAR, y a partir de éste generará la respuesta al INVITAR, por
ejemplo, un mensaje de CONFORMIDAD 200, S10. Como las reglas del
RSVP permiten al TE cambiar los parámetros de la
T-Spec en la "resp" a valores diferentes de los
que recibió en el mensaje de "camino", la SIWF tendrá que
regenerar la parte de T-Spec del SDP para la
respuesta, en lugar de sólo devolver como un eco los mismos valores
que recibió en el INVITAR. El mensaje de CONFORMIDAD 200 se lleva de
vuelta, a través de la NGN, a la SIWF que da servicio al AS, de
manera que las CSCF's que hay en el camino del mensaje empujan los
criterios apropiados hasta las pasarelas, de forma tal, que el flujo
portador descrito por la F-Spec en el SDP recibirá
el tratamiento de QoS especificado por la T-Spec en
el SDP. Una vez que la SIWF ha regenerado el mensaje de "resv",
S12, y lo ha remitido al AS, el AS puede comenzar a enviar los
paquetes de flujo portador, S14.
El RSVP es un protocolo de estado "blando",
mientras que el SIP es un protocolo "duro". Esto significa que
el Emisor (AS en la Figura 10) y el Receptor (TE en la Figura 10)
emiten periódicamente, de forma respectiva, mensajes de
"camino" y de "resv" para "refrescar" las reservas de
recursos de red para el camino portador. Los dispositivos de
encaminamiento habilitados en RSVP liberarán recursos si no ven
estos mensajes de "refrescar" dentro de un intervalo de
"expiración para limpieza". Obviamente, las funciones SIWF sólo
deberán convertir los nuevos mensajes de RSVP en mensajes de SIP y
utilizar sólo mensajes de "refresco" para restablecer o poner a
cero los temporizadores. Si no se recibe un mensaje de
"refrescar" en un intervalo suficientemente largo, entonces una
SIWF debe emitir un mensaje de ADIOS ("BYE") de SIP para poner
fin a la sesión. También mientras está en curso la sesión de SIP,
las SIWFs tienen que generar los mensajes de refresco en
correspondencia, de tal manera que el ni el Emisor ni el Receptor
piensen que el camino portador ha perdido sus reservas.
Al igual que se dejan expirar las reservas de
recursos, el RSVP hace posible una interrupción o corte explícito.
En la Figura 10, el Emisor se ha representado poniendo fin al camino
portador, como final de la sesión con el receptor, mediante la
emisión de un mensaje de "interrupción de camino", SI6. Cuando
una SIWF recibe un mensaje de "interrupción de camino" (o de
"interrupción de resv") desde un Emisor (o un Receptor) de
RSVP, emite un mensaje de ADIOS de SIP, SI8. Los mensajes de ADIOS
son confirmados (con una respuesta de CONFORMIDAD 200, S20), en
tanto que los mensajes de "interrupción" de RSVP no son
confirmados.
Los expertos de la técnica constatarán que no es
un requisito que el TE y el AS se encuentren alejados un solo salto
de IP De sus SIWFs en servicio. En particular, el AS y/o el TE
pueden ser conectados a redes de soporte de RSVP (por ejemplo, redes
de empresa con dispositivos de encaminamiento habilitados en RSVP),
y la función SIWF de la frontera de la NGN podría retirarse varios
saltos de IP.
\vskip1.000000\baselineskip
El RTSP es, como el SIP, un protocolo de
aplicación basado en texto. Y, como el SIP, utiliza SDP para
describir corrientes de medio. Existe un solapamiento considerable
en la semántica. Sin embargo, al ser un desarrollo más temprano que
el SIP, está enfocado a un subconjunto de las aplicaciones a las que
da soporte el SIP. El área de aplicación principal del RTSP son las
presentaciones multimedia, tanto almacenadas como en directo. Las
emisiones de web en directo, así como su subsiguiente reproducción
desde el almacenamiento, son uno de los usos del RTSP; el otro uso
lo constituye el suministro corrientes o flujos por Internet de
audio o vídeo. La semántica de los mensajes de RTSP no coincide
directamente con el SIP. Uno de los tipos de mensaje, el mensaje de
respuesta DESCRIBIR ("DESCRIBE"), porta el SDP que describe una
presentación de, potencialmente, varios flujos portadores (y a
partir de la cual se ha de deducir la T-Spec para
cada flujo), en tanto que otro tipo de mensaje, el mensaje de
ESTABLECER ("SETUP"), lleva la F-Spec para uno
de los flujos portadores. Se requiere un mensaje de ESTABLECER
independiente para cada flujo portador. Para empeorar las cosas, el
RSTP no requiere el uso de mensajes de DESCRIBIR: un cliente de
aplicación puede aprender los parámetros de inicialización de medio
para un flujo portador por medio de cualquier técnica.
Debe admitirse entonces que será difícil
producir una SIWF de SIP-RTSP que maneje todos los
posibles usos del RTSP. Puesto que, de hecho, un número muy pequeño
de servidores y reproductores de medio de RTSP (esto es, REAL,
Quicktime, Windows) dominan los usos del RTSP en la Internet, una
SIWF que esté diseñada para hacer frente a sus configuraciones de
flujo de RTSP será la más beneficiosa.
En lo que sigue se describe una realización de
la invención enfocada a aplicaciones que establecen flujos
portadores en una sesión tras haber intercambiado mensajes de
DESCRIBIR.
\vskip1.000000\baselineskip
La Figura 11 ilustra el flujo de mensajes para
un cliente o reproductor de RTSP (albergado en un TE) que solicita
una corriente de medio desde un Servidor de Aplicación de hablante o
interlocutor de RTSP, a través de una NGN que tiene en sus bordes
funciones SIWF de RTSP a SIP que interceptan mensajes procedentes de
TE y AS.
Un cliente de RTSP que desea iniciar una sesión
de RTSP conocerá el URL del servidor de aplicación, de tal manera
que puede generar el URI de petición para un mensaje de petición de
DESCRIBIR y enviar ese mensaje (según se indica por la referencia
S22) al servidor. En la Figura 11, el mensaje de petición de
DESCRIBIR se muestra pasando directamente a través de los nodos que
albergan las funciones SIWF. Únicamente la CONFORMIDAD 200 de RTSP
(S24) es de interés para ellos y, de hecho, tan sólo la SIWF que da
servicio al cliente necesita intervenir la parte de cuerpo de SDP de
la respuesta para el DESCRIBIR. Ha de apreciarse que no es necesario
que el Servidor de Aplicación que describe las corrientes de medio
de la sesión sea la misma entidad que da servicio a las corrientes
de medio, y, por tanto, no habrá ninguna garantía de que la SIWF que
da servicio al servidor de aplicación sea la misma que la que da
servicio a los servidores de medio.
La SIWF de cliente (es decir, al SIWF alojada en
la AG a la que está enganchado el TE) necesita ser capaz de detectar
los mensajes de CONFORMIDAD 200 de RTSP contenidos en la corriente
de mensajes dirigida al cliente. En particular, es necesario que
detecte e intervenga o capture la descripción de las corrientes de
medio portadas en el cuerpo de mensaje. De hecho, la SIWF puede
diseñarse para examinar todas las formas de mensajes de CONFORMIDAD
200 para una línea de "Tipo-Contenido:
aplicación/sdp" ("Content-Type:
application/sdp") e intervenir los contenidos del cuerpo contra
posibles peticiones de ESTABLECER de RTSP futuras procedentes del
cliente. En particular, esto cubriría el caso en que los parámetros
de SDP para la sesión fuesen transportados utilizando una respuesta
de HTTP.
\newpage
Los parámetros de SDP recibidos por el cliente
describen una o más fuentes de corrientes de medio que constituyen
la sesión. El URI está incluido para cada fuente. De esta forma, el
cliente emite peticiones de ESTABLECER a cada fuente de corriente de
medio con el URI de petición que ha aprendido de la respuesta
DESCRIBIR (la Figura 11 muestra una petición de ESTABLECER que es
emitida por una fuente de medio que es el AS). En el mensaje de
ESTABLECER está incluido el número de acceso o puerta en que el
cliente desea recibir el flujo portador (los expertos de la técnica
constatarán que, con los flujos portadores de perfil de rtp/avp, son
realmente un par de números de puerta los que se especifican, pero
que el segundo de éstos es para el tráfico de RTSP que no es
probable que se beneficie de un mejor tratamiento de QoS que el de
"mejor esfuerzo").
Cuando la SIWF del cliente reconoce una petición
de ESTABLECER S26, tiene primero que casarla o hacerla corresponder
con una descripción de corriente de medio contenida en el SDP
intervenido de una respuesta de DESCRIBIR previa. Tiene dos claves
para hacerlo: la dirección de IP del cliente, en el campo de fuente
del encabezamiento de paquete del mensaje de ESTABLECER y el campo
de destino de la respuesta de DESCRIBIR, y el URI de petición del
mensaje de ESTABLECER que deberá coincidir con el URI de fuente de
corriente de medio procedente del SDP de la respuesta de DESCRIBIR.
(Simplemente bastará, habitualmente, con hacer coincidir el URI de
fuente de corriente de medio, pero puede haber circunstancias en que
diferentes clientes estén servidos por distintas codificaciones, y,
por tanto, es más seguro hacer coincidir también los clientes).
Cuando se encuentra una coincidencia o correspondencia, la SIWF es
capaz de construir la parte de T-Spec del SDP para
un mensaje de INVITAR de SIP S28. El extremo receptor de la
F-Spec (es decir, el tipo de paquete), así como la
dirección de IP de Cliente y el número de puerta, se codifican
también en el SDP- Puesto que existe un URI de petición en el
mensaje de ESTABLECER, hay dos opciones para el URI de
petición/destino en el mensaje INVITAR, a saber: si el servidor de
medio ha sido registrado administrativamente con un URI distintivo
(es decir, uno que la SIWF puede reconocer como susceptible de ser
encaminado por el SIP), y ha devuelto ese URI como parte de la
respuesta DESCRIBIR, entonces este URI, copiado del mensaje de
ESTABLECER, puede ser utilizado como el URI de petición para el
INVITAR; en caso contrario, la dirección de IP de destino del
mensaje ESTABLECER puede ser utilizada para construir un URI de
Pasarela en Servicio (según se ha descrito anteriormente y
similarmente al caso anterior para RSVP).
El mensaje de INVITAR es remitido por la NGN, de
la manera anteriormente descrita, hacia el servidor y llega a la
SIWF del servidor (es decir, la SIWF asociada con la AG a la que el
servidor está enganchado). Suponiendo que las comprobaciones de
criterio son satisfechas (véase más adelante), la SIWF regenera la
petición de ESTABLECER S30 y la remite al servidor de medio. De
nuevo, como en el caso del RSVP, una realización de la invención
puede, en realidad, transportar una copia del mensaje de ESTABLECER
encapsulado en el mensaje INVITAR, pero la información contenida en
el mensaje INVITAR, exclusiva de éste, bastará para hacer posible la
generación de un mensaje de ESTABLECER semánticamente idéntico al
enviado por 1 cliente.
El Servidor, cuando emite su respuesta S32 al
mensaje de ESTABLECER, incluye en ella el número puerta de la
fuente, de tal manera que, cuando la SIWF del servidor intercepta el
mensaje, puede completar la parte de F-Spec del SDL
contenido en la respuesta S34 al mensaje INVITAR. El resto del
mensaje de respuesta S34 de CONFORMIDAD 200 de SIP se construye a
partir del contenido del mensaje INVITAR. A medida que la respuesta
de CONFORMIDAD 200 viaja de vuelta por el camino inverso al del
INVITAR, las diversas CSCFs instalan los criterios de QoS en
Pasarelas con el fin de asegurarse de que el camino portador
descrito por la F-Spec recibe el tratamiento de QoS
indicado por la T-Spec.
La SIWF del Cliente convierte la respuesta S34
de CONFORMIDAD 200 de SIP en una respuesta al mensaje de ESTABLECER
original (una respuesta S36 de CONFORMIDAD 200 de RTSP) y envía esa
respuesta al cliente. A diferencia del SIP, el RTSP tiene también un
conjunto o juego de métodos (órdenes) para controlar el
comportamiento de las corrientes de medio (por ejemplo, para iniciar
un rápida secuencia de remisión). Estas órdenes sólo implican al
servidor y no es necesario que sean interpretadas por las SIWFs.
Incluida en este conjunto de órdenes se encuentra la petición de
REPRODUCIR; el servidor no envía realmente ningún paquete de
corriente portadora hasta que ha recibido una petición de
REPRODUCIR. Una petición de INTERRUMPIR S38 es, sin embargo,
interceptada por la SIWF y traducida en un mensaje de ADIOS de SIP
S40. Tanto el mensaje de INTERRUMPIR de RTSP como el mensaje de
ADIOS de SIP requieren una aceptación (CONFIRMACIÓN 200) S42,
S44.
\vskip1.000000\baselineskip
Uno de los beneficios principales de la
arquitectura de IMS es que los usuarios (en forma de clientes de
SIP) son autentificados (durante la etapa de REGISTRO) y la NGN
genera información de contabilidad que vincula a los usuarios con
los flujos portadores de QoS que ellos generan. El hecho de
proporcionar pasarelas de SIWF en la NGN, como se ha descrito
anteriormente, debilita estos controles, ya que permiten que puntos
de extremo no registrados soliciten y utilicen recursos de red. En
la práctica, los desarrollos comerciales y los operadores
necesitarán autorizar por adelantado uno de los extremos de los
flujos portadores, probablemente, los servidores de aplicación,
debido a que, de ellos, hay muchos menos con los que negociar
acuerdos de facturación. Los operadores aprovisionarán
administrativamente una dirección de servidor de aplicación en su
SIWF en servicio, y habilitarán explícitamente la función de
cooperación. La SIWF podrá aprovisionarse con un URL del servidor
que registra con una s-CSCF, de tal manera que los
mensajes de SIP pueden ser encaminados a la SIWF utilizando el URL
como el URI de destino, en lugar del método de dirección de IP de
Pasarela en Servicio.
\vskip1.000000\baselineskip
Sin embargo, incluso cuando el servidor de
aplicación se identifica de forma segura y está en curso una
disposición comercial para facturarlo por los flujos portadores de
QoS que establece, el servidor no tiene la posibilidad de escoger si
un cliente particular recibe tratamiento de QoS o tratamiento de
"mejor esfuerzo" en el flujo que se le envía. (Esto puede
depender de si el usuario de cliente tiene una suscripción con el
proveedor del servidor de aplicación). Un refinamiento adicional de
la presente invención, aplicable para protocolos de herencia tales
como el RTSP que identifican corrientes de medio por el URI, hará
que la aplicación utilice URIs diferentes para identificar de otro
modo corrientes de medio idénticas, dependiendo de si están
destinadas a recibir tratamiento de QoS o no. Todas las SIWFs de la
NGN deberán ser capaces de distinguir los dos tipos de URI. Haciendo
referencia a la Figura 11, cuando llega un mensaje de ESTABLECER a
la SIWF que da servicio a los clientes, ésta debe inspeccionar el
URI de destino y sólo convertir el mensaje de ESTABLECER en un
mensaje INVITAR de SIP si el URI indica que el tratamiento de QoS
fue "solicitado" por el servidor de aplicación. En caso
contrario, la función SIWF ignora el mensaje de ESTABLECER y
prosigue hasta el servidor de aplicación de una manera estándar de
herencia, sin que haya implicación adicional de la red. Los expertos
de la técnica constatarán que existen muchos esquemas que pueden
utilizarse para diferenciar URIs: un ejemplo sería utilizar el
nombre de dominio de IMS del dominio en servicio del servidor como
parte de dominio del URI anexada tras el propio URL de los
servidores de aplicación.
En el tercer aspecto de la invención
anteriormente descrita, con el fin de establecer un flujo portador
de QoS, es necesario que el servidor sea un hablante o interlocutor
de SIP, pero el protocolo entre el servidor y el cliente es
ignorado. Por otra parte, en el cuarto aspecto que se ha descrito
anteriormente, el protocolo entre el cliente y el servidor se
convierte en SIP. Como puede apreciarse, es posible combinar estos
dos métodos. La Figura 12 ilustra una realización de NGN que hace
posibles caminos portadores de QoS entre servidores de aplicación y
clientes, en los que el servidor de aplicación utiliza un protocolo
de señalización de herencia para que una pasarela de SIWF local
solicite QoS, y la pasarela de SIWF convierte la señalización en
mensajes de SIP para la pasarela en servicio del TE de cliente (que
controla la p-CSCF).
Existen dos casos que considerar.
En uno de los casos, el cliente no es un
hablante o interlocutor del protocolo de señalización de herencia.
El servidor utiliza el protocolo de señalización de herencia porque
es más fácil de implementar que el SIP. Esto se ilustra en la Figura
13 para el caso de RSVP. Nótese que, si bien en este caso, cuando se
utiliza el RSVP, la función SIWF (o al menos la detección de
mensajes de RSVP) debe ser alojada en la AG en servicio del
Servidor, para otros protocolos, tales como el RTSP, que hace
posible que sea configurado un representante (es decir, que los
mensajes sean dirigidos en IP al representante), la función SIWF no
necesita encontrarse en el camino directo de los paquetes entre el
servidor y el cliente. En particular, la función SIWF podría estar
incluida en el servidor que da servicio a la
p-CSCF.
En el otro caso, el protocolo de señalización de
herencia es intercambiado entre el cliente y el servidor, pero
también es inspeccionado, aunque no modificado, por la SIWF del
servidor. Esto se ilustra por la Figura 14 para el caso del RTSP. En
este caso, la función de SIWF está actuando como representante
transparente (es decir, los paquetes de RTSP no son dirigidos a
ella) y debe ser parte del AG en servicio.
Los métodos y sistemas que se han descrito aquí
superan, por tanto, la limitación del IMS actual, que únicamente
maneja multimedia que se suministra por RTP entre puntos de extremo
de hablante o interlocutor de SIP. Las invenciones que se describen
y reivindican aquí permiten, conjuntamente, el suministro de
cualquier contenido sobre flujos portadores de QoS desde cualquier
fuente de contenidos a cualquier destino, al tiempo que conservan el
marco de seguridad y de carga de los IMS, abriendo nuevas fuentes de
ingresos para los operadores de redes de próxima generación desde
los consumidores y los proveedores de servicios de aplicación.
Las realizaciones de la invención que se han
descrito anteriormente se pretende que sean sólo ilustrativas. Es la
intención que el ámbito de la invención esté limitado únicamente por
el ámbito de las realizaciones que se acompañan.
Claims (26)
1. Un método para establecer, en una red de
comunicación de múltiples dominios en la que se utiliza un protocolo
de señalización fuera de banda para establecer sesiones de
comunicaciones, un camino portador de extremo a extremo de una
sesión de comunicación, de tal modo que el método comprende las
etapas de:
recibir un mensaje de señalización fuera de
banda, que incluye información representativa de al menos un punto
de extremo opuesto de un primer segmento portador del camino de
extremo a extremo;
utilizar la información para definir una
relación de correspondencia de conexión cruzada a través de un nodo
de la red entre respectivos puntos de extremo locales del primer
segmento portador y un segundo segmento portador albergado por el
nodo;
insertar información representativa de la
relación de correspondencia de conexión cruzada en el mensaje de
señalización fuera de banda; y
remitir el mensaje de señalización fuera de
banda.
\vskip1.000000\baselineskip
2. Un método de acuerdo con la reivindicación 1,
que comprende adicionalmente, cuando el mensaje fuera de banda es un
mensaje de fase en sentido directo del protocolo de señalización
fuera de banda, las etapas de:
recibir un mensaje de fase de retorno del
protocolo de señalización fuera de banda desde un punto de extremo
opuesto del segundo segmento portador, de tal manera que el mensaje
de fase de retorno es generado por un punto de extremo opuesto del
camino de extremo a extremo, en respuesta a la recepción del mensaje
de señalización fuera de banda;
definir una relación de correspondencia de
conexión cruzada de fase inversa a través del nodo entre respectivos
puntos de extremo locales del segundo segmento portador y del primer
segmento portador; y
remitir el mensaje de fase de retorno al punto
de extremo opuesto del primer segmento portador;
de tal manera que se establece un camino
portador bidireccional, o en ambos sentidos, de extremo a
extremo.
\vskip1.000000\baselineskip
3. Un método de acuerdo con la reivindicación 2,
en el cual el protocolo de señalización fuera de banda es un
Protocolo de Inicio de Sesión (SIP), y en el que:
el mensaje de fase en sentido directo es un
mensaje de INVITAR de SIP; y el mensaje de señalización de fase de
retorno es un mensaje de respuesta de SIP, generado por un extremo
lejano del camino de extremo a extremo.
\vskip1.000000\baselineskip
4. Un método de acuerdo con la reivindicación 1,
en el cual la etapa de definir una relación de correspondencia de
conexión cruzada comprende las etapas de:
identificar respectivos puntos de extremo
locales de los primer y segundo segmentos portadores; y
definir una relación de correspondencia a través
del nodo entre los puntos de extremo locales identificados.
\vskip1.000000\baselineskip
5. Un método de acuerdo con la reivindicación 1,
en el cual la etapa de insertar información representativa de la
relación de correspondencia de conexión cruzada en el mensaje de
señalización fuera de banda comprende una etapa de insertar
información que identifica el punto de extremo local del segundo
segmento portador.
6. Un método de acuerdo con la reivindicación 5,
en el cual la información que identifica el punto de extremo local
del segundo segmento portador, reemplaza la información que
identifica el punto de extremo opuesto del primer segmento
portador.
7. Un método de acuerdo con la reivindicación 1,
en el que el mensaje de señalización fuera de banda es un mensaje de
INVITAR de SIP que es recibido en una Función de Control de Estado
de Llamada (CSCF) que controla el nodo, y en el cual la etapa de
definir una relación de correspondencia de conexión cruzada
comprende una etapa de instalar la relación de correspondencia de
conexión cruzada como política o criterio de remisión de ese
nodo.
8. Un método de acuerdo con la reivindicación 7,
en el cual la etapa de remitir el mensaje fuera de banda comprende
una etapa de remitir el mensaje INVITAR de SIP a una CSCF
pareja.
\newpage
9. Un método de acuerdo con la reivindicación 1,
en el cual el nodo es uno cualquiera de: una pasarela de frontera
entre dominios de la red; y un servidor dentro de un dominio de la
red.
10. Un método de acuerdo con la reivindicación
1, en el cual la información es codificada en un Protocolo de
Descripción de Sesión (SDP).
11. Un método de acuerdo con la reivindicación
1, en el cual la información comprende una especificación de flujo
de IP que incluye una dirección de IP respectiva de al menos un
punto de extremo del segmento portador.
12. Un método de acuerdo con la reivindicación
1, en el cual la etapa de utilizar la información para definir una
relación de correspondencia de conexión cruzada, comprende una etapa
de definir una relación de correspondencia de Traducción de
Dirección de Red (NAT), destinada a traducir un encabezamiento de
paquetes de IP recibidos por el nodo a través del primer segmento
portador, en un encabezamiento para el segundo segmento
portador.
13. Un método de acuerdo con la reivindicación
2, en el cual la etapa de utilizar la información para definir una
relación de correspondencia de conexión cruzada de fase inversa,
comprende una etapa de definir una relación de correspondencia de
Traducción de Dirección de Red (NAT) de fase inversa
correspondiente, a fin de traducir un encabezamiento de paquetes de
IP recibidos por el nodo a través del segundo segmento portador, en
un encabezamiento para el primer segmento portador.
14. Una red de comunicación de múltiples
dominios en la que se utiliza un protocolo de señalización fuera de
banda para establecer sesiones de comunicaciones, un medio legible
por computadora, que incluye código de software, para controlar una
Función de Control de Estado de Llamada (CSCF) de la red con el fin
de establecer un camino portador de extremo a extremo de una sesión
de comunicación, de tal manera que el código de software controla la
CSCF
para:
para:
recibir un mensaje de señalización fuera de
banda, que incluye:
información representativa de al menos un punto
de extremo opuesto de un primer segmento portador del camino de
extremo a extremo;
utilizar la información para definir una
relación de correspondencia de conexión cruzada a través de un nodo
de la red entre respectivos puntos de extremo locales del primer
segmento portador y de un segundo segmento portador albergado por el
nodo;
insertar información representativa de la
relación de correspondencia de conexión cruzada en el mensaje de
señalización fuera de banda; y remitir el mensaje de señalización
fuera de banda.
\vskip1.000000\baselineskip
15. Un medio legible por computadora de acuerdo
con la reivindicación 14, en el cual, cuando el mensaje fuera de
banda es un mensaje de fase en sentido directo del protocolo de
señalización fuera de banda, el código de software controla
adicionalmente la CSCF para:
recibir un mensaje de fase de retorno del
protocolo de señalización fuera de banda desde un punto de extremo
opuesto del segundo segmento portador, de tal manera que el mensaje
de fase de retorno es generado por un punto de extremo opuesto del
camino de extremo a extremo, en respuesta a la recepción del mensaje
de señalización fuera de banda;
definir una relación de correspondencia de
conexión cruzada de fase inversa a través del nodo entre respectivos
puntos de extremo locales del segundo segmento portador y del primer
segmento portador; y
remitir el mensaje de fase de retorno al punto
de extremo opuesto del primer segmento portador;
de tal manera que se establece un camino
portador bidireccional, o en ambos sentidos, de extremo a
extremo.
\vskip1.000000\baselineskip
16. Un medio legible por computadora de acuerdo
con la reivindicación 15, en el que el protocolo de señalización
fuera de banda es un Protocolo de Inicio de Sesión (SIP), y en el
cual:
el mensaje de fase en sentido directo es un
mensaje de INVITAR de SIP; y
el mensaje de fase de señalización de retorno es
un mensaje de respuesta de SIP generado por un extremo lejano de un
camino de extremo a extremo.
\newpage
17. Un medio legible por computadora de acuerdo
con la reivindicación 14, en el cual el código de software que
define una relación de correspondencia de conexión cruzada,
comprende código de software para:
identificar respectivos puntos de extremo
locales de los primer y segundo segmentos portadores; y
definir una relación de correspondencia a través
del nodo entre puntos de extremo locales identificados.
\vskip1.000000\baselineskip
18. Un medio legible por computadora de acuerdo
con la reivindicación 14, en el cual el código de software que
inserta información representativa de la relación de correspondencia
de conexión cruzada en el mensaje de señalización fuera de banda,
comprende código de software para insertar información que
identifica el punto de extremo local del segundo segmento
portador.
19. Un medio legible por computadora de acuerdo
con la reivindicación 18, en el cual la información que identifica
el punto de extremo local del segundo segmento portador, reemplaza
la información que identifica el punto de extremo opuesto del primer
segmento portador.
20. Un medio legible por computadora de acuerdo
con la reivindicación 14, en el que el mensaje de señalización fuera
de banda es un mensaje de INVITAR de SIP, recibido en una Función de
Control de Estado de Llamada (CSCF) que controla el nodo, y en el
cual la etapa de definir una relación de correspondencia de conexión
cruzada comprende una etapa de instalar la relación de
correspondencia de conexión cruzada como política o criterio de
remisión de ese nodo.
21. Un medio legible por computadora de acuerdo
con la reivindicación 14, en el cual la etapa de remitir el mensaje
fuera de banda comprende una etapa de remitir el mensaje de INVITAR
de SIP a una CSCF pareja.
22. Un medio legible por computadora de acuerdo
con la reivindicación 14, en el cual el nodo es uno cualquiera de:
una pasarela de frontera entre dominios de una red; y un servidor
dentro de un dominio de la red.
23. Un medio legible por computadora de acuerdo
con la reivindicación 14, en el cual la información es codificada en
un Protocolo de Inicio de Sesión (SDP).
24. Un medio legible por computadora de acuerdo
con la reivindicación 14, en el cual la información comprende una
especificación de flujo de IP que incluye una dirección de IP
respectiva de al menos un punto de extremo del segmento
portador.
25. Un medio legible por computadora de acuerdo
con la reivindicación 14, en el cual el código de software para
utilizar la información con el fin de definir una relación de
correspondencia de conexión cruzada, comprende código de software
para controlar la CSCF, con el fin de definir una relación de
correspondencia de Traducción de Dirección de Red (NAT) destinada a
traducir un encabezamiento de paquetes de IP recibidos por el nodo a
través del primer segmento portador, en un encabezamiento para el
segundo segmento portador.
26. Un medio legible por computadora de acuerdo
con la reivindicación 25, en el cual la etapa de utilizar la
información para definir una relación de correspondencia de conexión
cruzada de fase inversa, comprende una etapa de definir una relación
de correspondencia de Traducción de Dirección de Red (NAT) destinada
a traducir un encabezamiento de paquetes de IP recibidos por el nodo
a través del segundo segmento portador, en un encabezamiento para el
primer segmento portador.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US11/610,794 | 2006-12-14 | ||
| US11/610,794 US7649881B2 (en) | 2006-12-14 | 2006-12-14 | Pinning the route of IP bearer flows in a next generation network |
| PCT/CA2007/002045 WO2008070957A1 (en) | 2006-12-14 | 2007-11-15 | Pinning the route of ip bearer flows in a next generation network |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| ES2364793A1 true ES2364793A1 (es) | 2011-09-14 |
| ES2364793B2 ES2364793B2 (es) | 2012-04-20 |
Family
ID=39511180
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES200990004A Active ES2364793B2 (es) | 2006-12-14 | 2007-11-15 | Fijación de la ruta de flujos portadores de ip en una red de próxima generación. |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US7649881B2 (es) |
| EP (1) | EP2095564B1 (es) |
| KR (1) | KR101096364B1 (es) |
| CN (1) | CN101601224B (es) |
| CA (1) | CA2671899C (es) |
| ES (1) | ES2364793B2 (es) |
| HK (1) | HK1136709A1 (es) |
| WO (1) | WO2008070957A1 (es) |
Families Citing this family (209)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9015467B2 (en) * | 2002-12-05 | 2015-04-21 | Broadcom Corporation | Tagging mechanism for data path security processing |
| DE602005018121D1 (de) * | 2005-10-21 | 2010-01-14 | Ericsson Telefon Ab L M | Handhabung von dienstgüte in einem kommunikationssystem |
| US7822046B2 (en) * | 2006-10-13 | 2010-10-26 | Cisco Technology, Inc. | Triggering bandwidth reservation and priority remarking |
| US10122862B2 (en) * | 2006-12-29 | 2018-11-06 | Ubiquity Software Corporation Limited | Systems and methods for connecting heterogeneous networks |
| US8024429B2 (en) * | 2007-01-18 | 2011-09-20 | Telefonaktiebolaget L M Ericsson (Publ) | Method and apparatus for remote access to a home network |
| US7809002B2 (en) * | 2007-04-16 | 2010-10-05 | Alcatel-Lucent Usa Inc. | Method and apparatus for priority services management |
| US7899039B2 (en) * | 2008-02-15 | 2011-03-01 | Cisco Technology, Inc. | System and method for providing location and access network information support in a network environment |
| US8264958B1 (en) * | 2008-05-23 | 2012-09-11 | Sprint Communications Company L.P. | Tiered subscriber service with advanced header compression methods in a VOIP system |
| US8462768B2 (en) * | 2008-06-11 | 2013-06-11 | Verizon Patent And Licensing Inc. | Providing session initiation protocol (SIP) call control functions to public switched telephone network (PSTN)-based call controller |
| US8493984B2 (en) * | 2008-06-13 | 2013-07-23 | Cisco Technology, Inc. | System and method for establishment of a multiprotocol label switching (MPLS) tunnel |
| EP2146465A1 (en) | 2008-07-15 | 2010-01-20 | Deutsche Thomson OHG | A method for managing data transmission according to a quality of service in a network assembly and a computer network system |
| US8570870B2 (en) * | 2008-08-08 | 2013-10-29 | Alcatel Lucent | Incremental addition and scale-back of resources adapting to network resource availability |
| US8159941B2 (en) * | 2008-08-28 | 2012-04-17 | Alcatel Lucent | In-band DPI media reservation modifications to RFC 3313 |
| US8135850B2 (en) * | 2008-11-25 | 2012-03-13 | Citrix Systems, Inc. | Systems and methods for load balancing real time streaming |
| US8325732B2 (en) | 2008-12-22 | 2012-12-04 | Rockstar Consortium Us Lp | Method for operating multi-domain Provider Ethernet networks |
| US8077704B2 (en) * | 2009-01-06 | 2011-12-13 | Oracle International Corporation | Web service assisted real-time session peering between enterprise VoIP networks via internet |
| US9185184B2 (en) | 2009-03-31 | 2015-11-10 | Match.Com, L.L.C. | System and method for providing calendar and speed dating features for matching users in a network environment |
| US8621090B2 (en) * | 2009-05-07 | 2013-12-31 | Match.Com, L.L.C. | System and method for providing sequenced anonymous communication sessions over a network |
| US8885012B2 (en) * | 2009-05-07 | 2014-11-11 | Match.Com, L.L.C. | System and method for providing anonymity in a video/multimedia communications session over a network |
| US9148333B2 (en) | 2009-03-31 | 2015-09-29 | Match.Com, L.L.C. | System and method for providing anonymity in a session initiated protocol network |
| US8392581B2 (en) * | 2009-06-09 | 2013-03-05 | Verizon Patent And Licensing Inc. | Intelligent IMS SIP session setup optimization |
| US8305962B2 (en) * | 2009-06-22 | 2012-11-06 | Nokia Siemens Networks Gmbh & Co. Kg | Optimization in heterogeneous networks |
| US8638760B2 (en) * | 2009-11-17 | 2014-01-28 | Palm, Inc. | System and method for dynamically establishing and managing connections |
| JP5441158B2 (ja) | 2009-11-25 | 2014-03-12 | 日本電気株式会社 | 管理装置、制御装置、通信システム、制御方法及びプログラム |
| CN102143352A (zh) * | 2010-02-02 | 2011-08-03 | 捷达世软件（深圳）有限公司 | 监控视频播放系统及方法 |
| US8340292B1 (en) | 2010-04-01 | 2012-12-25 | Sprint Communications Company L.P. | Lawful intercept management by an authorization system |
| CN102215155B (zh) * | 2010-04-02 | 2016-06-08 | 中兴通讯股份有限公司 | 一种家庭网络的资源接纳控制方法及系统 |
| US9215588B2 (en) * | 2010-04-30 | 2015-12-15 | Cisco Technology, Inc. | System and method for providing selective bearer security in a network environment |
| US9107140B2 (en) * | 2010-08-13 | 2015-08-11 | At&T Mobility Ii Llc | Carrier-driven bearer path selection |
| US9444854B2 (en) | 2010-09-07 | 2016-09-13 | T-Mobile Usa, Inc. | Session initiation protocol (SIP) router |
| US8838156B2 (en) * | 2010-10-22 | 2014-09-16 | Motorola Solutions, Inc. | Multi-bearer rate control for transporting user plane data |
| US8538439B2 (en) | 2011-02-11 | 2013-09-17 | Blackberry Limited | Communications system configured to correct an association mismatch and related methods |
| US9712592B2 (en) * | 2011-04-21 | 2017-07-18 | Arris Enterprises, Inc. | Classification of HTTP multimedia traffic per session |
| US8559309B2 (en) * | 2011-04-25 | 2013-10-15 | Verizon Patent And Licensing Inc. | Tagging VoIP originated traffic |
| US8787358B2 (en) * | 2011-06-28 | 2014-07-22 | Cisco Technology, Inc. | System for ad-hoc communication sessions |
| US20130137469A1 (en) * | 2011-11-30 | 2013-05-30 | Intel Mobile Communications GmbH | Method for transmitting an opportunistic network related message |
| US9871713B2 (en) * | 2012-05-15 | 2018-01-16 | Telefonaktiebolaget Lm Ericsson (Publ) | Session based nettrace and test call |
| US9300570B2 (en) * | 2012-05-22 | 2016-03-29 | Harris Corporation | Multi-tunnel virtual private network |
| US9042252B2 (en) * | 2012-11-13 | 2015-05-26 | Netronome Systems, Incorporated | Inter-packet interval prediction learning algorithm |
| US9113347B2 (en) | 2012-12-05 | 2015-08-18 | At&T Intellectual Property I, Lp | Backhaul link for distributed antenna system |
| US10009065B2 (en) | 2012-12-05 | 2018-06-26 | At&T Intellectual Property I, L.P. | Backhaul link for distributed antenna system |
| US9762628B2 (en) | 2013-02-19 | 2017-09-12 | Avaya Inc. | Implementation of the semi-attended transfer in SIP for IP-multimedia subsystem environments |
| EP3005612B1 (en) * | 2013-05-28 | 2019-02-06 | Telefonaktiebolaget LM Ericsson (publ) | Methods and apparatus for allocating service costs in a telecommunications network |
| US9999038B2 (en) | 2013-05-31 | 2018-06-12 | At&T Intellectual Property I, L.P. | Remote distributed antenna system |
| US9525524B2 (en) | 2013-05-31 | 2016-12-20 | At&T Intellectual Property I, L.P. | Remote distributed antenna system |
| US9485186B2 (en) * | 2013-07-23 | 2016-11-01 | Cisco Technology, Inc. | Network congestion control with awareness of random packet losses |
| US8897697B1 (en) | 2013-11-06 | 2014-11-25 | At&T Intellectual Property I, Lp | Millimeter-wave surface-wave communications |
| US9467570B2 (en) * | 2013-11-20 | 2016-10-11 | Avaya Inc. | Call transfer with network spanning back-to-back user agents |
| US9209902B2 (en) | 2013-12-10 | 2015-12-08 | At&T Intellectual Property I, L.P. | Quasi-optical coupler |
| US9692101B2 (en) | 2014-08-26 | 2017-06-27 | At&T Intellectual Property I, L.P. | Guided wave couplers for coupling electromagnetic waves between a waveguide surface and a surface of a wire |
| US9768833B2 (en) | 2014-09-15 | 2017-09-19 | At&T Intellectual Property I, L.P. | Method and apparatus for sensing a condition in a transmission medium of electromagnetic waves |
| US10063280B2 (en) | 2014-09-17 | 2018-08-28 | At&T Intellectual Property I, L.P. | Monitoring and mitigating conditions in a communication network |
| US9628854B2 (en) | 2014-09-29 | 2017-04-18 | At&T Intellectual Property I, L.P. | Method and apparatus for distributing content in a communication network |
| US9615269B2 (en) | 2014-10-02 | 2017-04-04 | At&T Intellectual Property I, L.P. | Method and apparatus that provides fault tolerance in a communication network |
| US9685992B2 (en) | 2014-10-03 | 2017-06-20 | At&T Intellectual Property I, L.P. | Circuit panel network and methods thereof |
| US9503189B2 (en) | 2014-10-10 | 2016-11-22 | At&T Intellectual Property I, L.P. | Method and apparatus for arranging communication sessions in a communication system |
| US9762289B2 (en) | 2014-10-14 | 2017-09-12 | At&T Intellectual Property I, L.P. | Method and apparatus for transmitting or receiving signals in a transportation system |
| US9973299B2 (en) | 2014-10-14 | 2018-05-15 | At&T Intellectual Property I, L.P. | Method and apparatus for adjusting a mode of communication in a communication network |
| US9312919B1 (en) | 2014-10-21 | 2016-04-12 | At&T Intellectual Property I, Lp | Transmission device with impairment compensation and methods for use therewith |
| US9653770B2 (en) | 2014-10-21 | 2017-05-16 | At&T Intellectual Property I, L.P. | Guided wave coupler, coupling module and methods for use therewith |
| US9780834B2 (en) | 2014-10-21 | 2017-10-03 | At&T Intellectual Property I, L.P. | Method and apparatus for transmitting electromagnetic waves |
| US9577306B2 (en) | 2014-10-21 | 2017-02-21 | At&T Intellectual Property I, L.P. | Guided-wave transmission device and methods for use therewith |
| US9769020B2 (en) | 2014-10-21 | 2017-09-19 | At&T Intellectual Property I, L.P. | Method and apparatus for responding to events affecting communications in a communication network |
| US9627768B2 (en) | 2014-10-21 | 2017-04-18 | At&T Intellectual Property I, L.P. | Guided-wave transmission device with non-fundamental mode propagation and methods for use therewith |
| US9564947B2 (en) | 2014-10-21 | 2017-02-07 | At&T Intellectual Property I, L.P. | Guided-wave transmission device with diversity and methods for use therewith |
| US9520945B2 (en) | 2014-10-21 | 2016-12-13 | At&T Intellectual Property I, L.P. | Apparatus for providing communication services and methods thereof |
| US9954287B2 (en) | 2014-11-20 | 2018-04-24 | At&T Intellectual Property I, L.P. | Apparatus for converting wireless signals and electromagnetic waves and methods thereof |
| US9544006B2 (en) | 2014-11-20 | 2017-01-10 | At&T Intellectual Property I, L.P. | Transmission device with mode division multiplexing and methods for use therewith |
| US9680670B2 (en) | 2014-11-20 | 2017-06-13 | At&T Intellectual Property I, L.P. | Transmission device with channel equalization and control and methods for use therewith |
| US10243784B2 (en) | 2014-11-20 | 2019-03-26 | At&T Intellectual Property I, L.P. | System for generating topology information and methods thereof |
| US10340573B2 (en) | 2016-10-26 | 2019-07-02 | At&T Intellectual Property I, L.P. | Launcher with cylindrical coupling device and methods for use therewith |
| US9800327B2 (en) | 2014-11-20 | 2017-10-24 | At&T Intellectual Property I, L.P. | Apparatus for controlling operations of a communication device and methods thereof |
| US9742462B2 (en) | 2014-12-04 | 2017-08-22 | At&T Intellectual Property I, L.P. | Transmission medium and communication interfaces and methods for use therewith |
| US9654173B2 (en) | 2014-11-20 | 2017-05-16 | At&T Intellectual Property I, L.P. | Apparatus for powering a communication device and methods thereof |
| US9461706B1 (en) | 2015-07-31 | 2016-10-04 | At&T Intellectual Property I, Lp | Method and apparatus for exchanging communication signals |
| US9997819B2 (en) | 2015-06-09 | 2018-06-12 | At&T Intellectual Property I, L.P. | Transmission medium and method for facilitating propagation of electromagnetic waves via a core |
| US10009067B2 (en) | 2014-12-04 | 2018-06-26 | At&T Intellectual Property I, L.P. | Method and apparatus for configuring a communication interface |
| US10144036B2 (en) | 2015-01-30 | 2018-12-04 | At&T Intellectual Property I, L.P. | Method and apparatus for mitigating interference affecting a propagation of electromagnetic waves guided by a transmission medium |
| US9876570B2 (en) | 2015-02-20 | 2018-01-23 | At&T Intellectual Property I, Lp | Guided-wave transmission device with non-fundamental mode propagation and methods for use therewith |
| US9749013B2 (en) | 2015-03-17 | 2017-08-29 | At&T Intellectual Property I, L.P. | Method and apparatus for reducing attenuation of electromagnetic waves guided by a transmission medium |
| US10224981B2 (en) | 2015-04-24 | 2019-03-05 | At&T Intellectual Property I, Lp | Passive electrical coupling device and methods for use therewith |
| US9705561B2 (en) | 2015-04-24 | 2017-07-11 | At&T Intellectual Property I, L.P. | Directional coupling device and methods for use therewith |
| US9948354B2 (en) | 2015-04-28 | 2018-04-17 | At&T Intellectual Property I, L.P. | Magnetic coupling device with reflective plate and methods for use therewith |
| US9793954B2 (en) | 2015-04-28 | 2017-10-17 | At&T Intellectual Property I, L.P. | Magnetic coupling device and methods for use therewith |
| US9871282B2 (en) | 2015-05-14 | 2018-01-16 | At&T Intellectual Property I, L.P. | At least one transmission medium having a dielectric surface that is covered at least in part by a second dielectric |
| US9490869B1 (en) | 2015-05-14 | 2016-11-08 | At&T Intellectual Property I, L.P. | Transmission medium having multiple cores and methods for use therewith |
| US9748626B2 (en) | 2015-05-14 | 2017-08-29 | At&T Intellectual Property I, L.P. | Plurality of cables having different cross-sectional shapes which are bundled together to form a transmission medium |
| US10650940B2 (en) | 2015-05-15 | 2020-05-12 | At&T Intellectual Property I, L.P. | Transmission medium having a conductive material and methods for use therewith |
| US10679767B2 (en) | 2015-05-15 | 2020-06-09 | At&T Intellectual Property I, L.P. | Transmission medium having a conductive material and methods for use therewith |
| US9917341B2 (en) | 2015-05-27 | 2018-03-13 | At&T Intellectual Property I, L.P. | Apparatus and method for launching electromagnetic waves and for modifying radial dimensions of the propagating electromagnetic waves |
| US10348391B2 (en) | 2015-06-03 | 2019-07-09 | At&T Intellectual Property I, L.P. | Client node device with frequency conversion and methods for use therewith |
| US9866309B2 (en) | 2015-06-03 | 2018-01-09 | At&T Intellectual Property I, Lp | Host node device and methods for use therewith |
| US10154493B2 (en) | 2015-06-03 | 2018-12-11 | At&T Intellectual Property I, L.P. | Network termination and methods for use therewith |
| US9912381B2 (en) | 2015-06-03 | 2018-03-06 | At&T Intellectual Property I, Lp | Network termination and methods for use therewith |
| US10103801B2 (en) | 2015-06-03 | 2018-10-16 | At&T Intellectual Property I, L.P. | Host node device and methods for use therewith |
| US10812174B2 (en) | 2015-06-03 | 2020-10-20 | At&T Intellectual Property I, L.P. | Client node device and methods for use therewith |
| US9913139B2 (en) | 2015-06-09 | 2018-03-06 | At&T Intellectual Property I, L.P. | Signal fingerprinting for authentication of communicating devices |
| US10142086B2 (en) | 2015-06-11 | 2018-11-27 | At&T Intellectual Property I, L.P. | Repeater and methods for use therewith |
| US9608692B2 (en) | 2015-06-11 | 2017-03-28 | At&T Intellectual Property I, L.P. | Repeater and methods for use therewith |
| US9820146B2 (en) | 2015-06-12 | 2017-11-14 | At&T Intellectual Property I, L.P. | Method and apparatus for authentication and identity management of communicating devices |
| US9667317B2 (en) | 2015-06-15 | 2017-05-30 | At&T Intellectual Property I, L.P. | Method and apparatus for providing security using network traffic adjustments |
| US9865911B2 (en) | 2015-06-25 | 2018-01-09 | At&T Intellectual Property I, L.P. | Waveguide system for slot radiating first electromagnetic waves that are combined into a non-fundamental wave mode second electromagnetic wave on a transmission medium |
| US9640850B2 (en) | 2015-06-25 | 2017-05-02 | At&T Intellectual Property I, L.P. | Methods and apparatus for inducing a non-fundamental wave mode on a transmission medium |
| US9509415B1 (en) | 2015-06-25 | 2016-11-29 | At&T Intellectual Property I, L.P. | Methods and apparatus for inducing a fundamental wave mode on a transmission medium |
| US10033108B2 (en) | 2015-07-14 | 2018-07-24 | At&T Intellectual Property I, L.P. | Apparatus and methods for generating an electromagnetic wave having a wave mode that mitigates interference |
| US9882257B2 (en) | 2015-07-14 | 2018-01-30 | At&T Intellectual Property I, L.P. | Method and apparatus for launching a wave mode that mitigates interference |
| US10170840B2 (en) | 2015-07-14 | 2019-01-01 | At&T Intellectual Property I, L.P. | Apparatus and methods for sending or receiving electromagnetic signals |
| US10341142B2 (en) | 2015-07-14 | 2019-07-02 | At&T Intellectual Property I, L.P. | Apparatus and methods for generating non-interfering electromagnetic waves on an uninsulated conductor |
| US10205655B2 (en) | 2015-07-14 | 2019-02-12 | At&T Intellectual Property I, L.P. | Apparatus and methods for communicating utilizing an antenna array and multiple communication paths |
| US10320586B2 (en) | 2015-07-14 | 2019-06-11 | At&T Intellectual Property I, L.P. | Apparatus and methods for generating non-interfering electromagnetic waves on an insulated transmission medium |
| US10033107B2 (en) | 2015-07-14 | 2018-07-24 | At&T Intellectual Property I, L.P. | Method and apparatus for coupling an antenna to a device |
| US10044409B2 (en) | 2015-07-14 | 2018-08-07 | At&T Intellectual Property I, L.P. | Transmission medium and methods for use therewith |
| US9853342B2 (en) | 2015-07-14 | 2017-12-26 | At&T Intellectual Property I, L.P. | Dielectric transmission medium connector and methods for use therewith |
| US9836957B2 (en) | 2015-07-14 | 2017-12-05 | At&T Intellectual Property I, L.P. | Method and apparatus for communicating with premises equipment |
| US9628116B2 (en) | 2015-07-14 | 2017-04-18 | At&T Intellectual Property I, L.P. | Apparatus and methods for transmitting wireless signals |
| US9722318B2 (en) | 2015-07-14 | 2017-08-01 | At&T Intellectual Property I, L.P. | Method and apparatus for coupling an antenna to a device |
| US10148016B2 (en) | 2015-07-14 | 2018-12-04 | At&T Intellectual Property I, L.P. | Apparatus and methods for communicating utilizing an antenna array |
| US9847566B2 (en) | 2015-07-14 | 2017-12-19 | At&T Intellectual Property I, L.P. | Method and apparatus for adjusting a field of a signal to mitigate interference |
| US9793951B2 (en) | 2015-07-15 | 2017-10-17 | At&T Intellectual Property I, L.P. | Method and apparatus for launching a wave mode that mitigates interference |
| US10090606B2 (en) | 2015-07-15 | 2018-10-02 | At&T Intellectual Property I, L.P. | Antenna system with dielectric array and methods for use therewith |
| US9608740B2 (en) | 2015-07-15 | 2017-03-28 | At&T Intellectual Property I, L.P. | Method and apparatus for launching a wave mode that mitigates interference |
| US9749053B2 (en) | 2015-07-23 | 2017-08-29 | At&T Intellectual Property I, L.P. | Node device, repeater and methods for use therewith |
| US9948333B2 (en) | 2015-07-23 | 2018-04-17 | At&T Intellectual Property I, L.P. | Method and apparatus for wireless communications to mitigate interference |
| US10784670B2 (en) | 2015-07-23 | 2020-09-22 | At&T Intellectual Property I, L.P. | Antenna support for aligning an antenna |
| US9912027B2 (en) | 2015-07-23 | 2018-03-06 | At&T Intellectual Property I, L.P. | Method and apparatus for exchanging communication signals |
| US9871283B2 (en) | 2015-07-23 | 2018-01-16 | At&T Intellectual Property I, Lp | Transmission medium having a dielectric core comprised of plural members connected by a ball and socket configuration |
| US10020587B2 (en) | 2015-07-31 | 2018-07-10 | At&T Intellectual Property I, L.P. | Radial antenna and methods for use therewith |
| US9735833B2 (en) | 2015-07-31 | 2017-08-15 | At&T Intellectual Property I, L.P. | Method and apparatus for communications management in a neighborhood network |
| US9967173B2 (en) | 2015-07-31 | 2018-05-08 | At&T Intellectual Property I, L.P. | Method and apparatus for authentication and identity management of communicating devices |
| US9904535B2 (en) | 2015-09-14 | 2018-02-27 | At&T Intellectual Property I, L.P. | Method and apparatus for distributing software |
| US10079661B2 (en) | 2015-09-16 | 2018-09-18 | At&T Intellectual Property I, L.P. | Method and apparatus for use with a radio distributed antenna system having a clock reference |
| US10009901B2 (en) | 2015-09-16 | 2018-06-26 | At&T Intellectual Property I, L.P. | Method, apparatus, and computer-readable storage medium for managing utilization of wireless resources between base stations |
| US10051629B2 (en) | 2015-09-16 | 2018-08-14 | At&T Intellectual Property I, L.P. | Method and apparatus for use with a radio distributed antenna system having an in-band reference signal |
| US9705571B2 (en) | 2015-09-16 | 2017-07-11 | At&T Intellectual Property I, L.P. | Method and apparatus for use with a radio distributed antenna system |
| US10009063B2 (en) | 2015-09-16 | 2018-06-26 | At&T Intellectual Property I, L.P. | Method and apparatus for use with a radio distributed antenna system having an out-of-band reference signal |
| US10136434B2 (en) | 2015-09-16 | 2018-11-20 | At&T Intellectual Property I, L.P. | Method and apparatus for use with a radio distributed antenna system having an ultra-wideband control channel |
| US9769128B2 (en) | 2015-09-28 | 2017-09-19 | At&T Intellectual Property I, L.P. | Method and apparatus for encryption of communications over a network |
| US9729197B2 (en) | 2015-10-01 | 2017-08-08 | At&T Intellectual Property I, L.P. | Method and apparatus for communicating network management traffic over a network |
| US9876264B2 (en) | 2015-10-02 | 2018-01-23 | At&T Intellectual Property I, Lp | Communication system, guided wave switch and methods for use therewith |
| US9882277B2 (en) | 2015-10-02 | 2018-01-30 | At&T Intellectual Property I, Lp | Communication device and antenna assembly with actuated gimbal mount |
| US10074890B2 (en) | 2015-10-02 | 2018-09-11 | At&T Intellectual Property I, L.P. | Communication device and antenna with integrated light assembly |
| US10665942B2 (en) | 2015-10-16 | 2020-05-26 | At&T Intellectual Property I, L.P. | Method and apparatus for adjusting wireless communications |
| US10051483B2 (en) | 2015-10-16 | 2018-08-14 | At&T Intellectual Property I, L.P. | Method and apparatus for directing wireless signals |
| US10355367B2 (en) | 2015-10-16 | 2019-07-16 | At&T Intellectual Property I, L.P. | Antenna structure for exchanging wireless signals |
| US9912419B1 (en) | 2016-08-24 | 2018-03-06 | At&T Intellectual Property I, L.P. | Method and apparatus for managing a fault in a distributed antenna system |
| US9860075B1 (en) | 2016-08-26 | 2018-01-02 | At&T Intellectual Property I, L.P. | Method and communication node for broadband distribution |
| US10291311B2 (en) | 2016-09-09 | 2019-05-14 | At&T Intellectual Property I, L.P. | Method and apparatus for mitigating a fault in a distributed antenna system |
| US11032819B2 (en) | 2016-09-15 | 2021-06-08 | At&T Intellectual Property I, L.P. | Method and apparatus for use with a radio distributed antenna system having a control channel reference signal |
| US10135147B2 (en) | 2016-10-18 | 2018-11-20 | At&T Intellectual Property I, L.P. | Apparatus and methods for launching guided waves via an antenna |
| US10135146B2 (en) | 2016-10-18 | 2018-11-20 | At&T Intellectual Property I, L.P. | Apparatus and methods for launching guided waves via circuits |
| US10340600B2 (en) | 2016-10-18 | 2019-07-02 | At&T Intellectual Property I, L.P. | Apparatus and methods for launching guided waves via plural waveguide systems |
| US9876605B1 (en) | 2016-10-21 | 2018-01-23 | At&T Intellectual Property I, L.P. | Launcher and coupling system to support desired guided wave mode |
| US10374316B2 (en) | 2016-10-21 | 2019-08-06 | At&T Intellectual Property I, L.P. | System and dielectric antenna with non-uniform dielectric |
| US10811767B2 (en) | 2016-10-21 | 2020-10-20 | At&T Intellectual Property I, L.P. | System and dielectric antenna with convex dielectric radome |
| US9991580B2 (en) | 2016-10-21 | 2018-06-05 | At&T Intellectual Property I, L.P. | Launcher and coupling system for guided wave mode cancellation |
| US10312567B2 (en) | 2016-10-26 | 2019-06-04 | At&T Intellectual Property I, L.P. | Launcher with planar strip antenna and methods for use therewith |
| US10291334B2 (en) | 2016-11-03 | 2019-05-14 | At&T Intellectual Property I, L.P. | System for detecting a fault in a communication system |
| US10224634B2 (en) | 2016-11-03 | 2019-03-05 | At&T Intellectual Property I, L.P. | Methods and apparatus for adjusting an operational characteristic of an antenna |
| US10498044B2 (en) | 2016-11-03 | 2019-12-03 | At&T Intellectual Property I, L.P. | Apparatus for configuring a surface of an antenna |
| US10225025B2 (en) | 2016-11-03 | 2019-03-05 | At&T Intellectual Property I, L.P. | Method and apparatus for detecting a fault in a communication system |
| US10090594B2 (en) | 2016-11-23 | 2018-10-02 | At&T Intellectual Property I, L.P. | Antenna system having structural configurations for assembly |
| US10340601B2 (en) | 2016-11-23 | 2019-07-02 | At&T Intellectual Property I, L.P. | Multi-antenna system and methods for use therewith |
| US10178445B2 (en) | 2016-11-23 | 2019-01-08 | At&T Intellectual Property I, L.P. | Methods, devices, and systems for load balancing between a plurality of waveguides |
| US10535928B2 (en) | 2016-11-23 | 2020-01-14 | At&T Intellectual Property I, L.P. | Antenna system and methods for use therewith |
| US10340603B2 (en) | 2016-11-23 | 2019-07-02 | At&T Intellectual Property I, L.P. | Antenna system having shielded structural configurations for assembly |
| US10305190B2 (en) | 2016-12-01 | 2019-05-28 | At&T Intellectual Property I, L.P. | Reflecting dielectric antenna system and methods for use therewith |
| US10361489B2 (en) | 2016-12-01 | 2019-07-23 | At&T Intellectual Property I, L.P. | Dielectric dish antenna system and methods for use therewith |
| US10694379B2 (en) | 2016-12-06 | 2020-06-23 | At&T Intellectual Property I, L.P. | Waveguide system with device-based authentication and methods for use therewith |
| US9927517B1 (en) | 2016-12-06 | 2018-03-27 | At&T Intellectual Property I, L.P. | Apparatus and methods for sensing rainfall |
| US10819035B2 (en) | 2016-12-06 | 2020-10-27 | At&T Intellectual Property I, L.P. | Launcher with helical antenna and methods for use therewith |
| US10382976B2 (en) | 2016-12-06 | 2019-08-13 | At&T Intellectual Property I, L.P. | Method and apparatus for managing wireless communications based on communication paths and network device positions |
| US10439675B2 (en) | 2016-12-06 | 2019-10-08 | At&T Intellectual Property I, L.P. | Method and apparatus for repeating guided wave communication signals |
| US10755542B2 (en) | 2016-12-06 | 2020-08-25 | At&T Intellectual Property I, L.P. | Method and apparatus for surveillance via guided wave communication |
| US10135145B2 (en) | 2016-12-06 | 2018-11-20 | At&T Intellectual Property I, L.P. | Apparatus and methods for generating an electromagnetic wave along a transmission medium |
| US10637149B2 (en) | 2016-12-06 | 2020-04-28 | At&T Intellectual Property I, L.P. | Injection molded dielectric antenna and methods for use therewith |
| US10727599B2 (en) | 2016-12-06 | 2020-07-28 | At&T Intellectual Property I, L.P. | Launcher with slot antenna and methods for use therewith |
| US10326494B2 (en) | 2016-12-06 | 2019-06-18 | At&T Intellectual Property I, L.P. | Apparatus for measurement de-embedding and methods for use therewith |
| US10020844B2 (en) | 2016-12-06 | 2018-07-10 | T&T Intellectual Property I, L.P. | Method and apparatus for broadcast communication via guided waves |
| US10168695B2 (en) | 2016-12-07 | 2019-01-01 | At&T Intellectual Property I, L.P. | Method and apparatus for controlling an unmanned aircraft |
| US9893795B1 (en) | 2016-12-07 | 2018-02-13 | At&T Intellectual Property I, Lp | Method and repeater for broadband distribution |
| US10243270B2 (en) | 2016-12-07 | 2019-03-26 | At&T Intellectual Property I, L.P. | Beam adaptive multi-feed dielectric antenna system and methods for use therewith |
| US10547348B2 (en) | 2016-12-07 | 2020-01-28 | At&T Intellectual Property I, L.P. | Method and apparatus for switching transmission mediums in a communication system |
| US10446936B2 (en) | 2016-12-07 | 2019-10-15 | At&T Intellectual Property I, L.P. | Multi-feed dielectric antenna system and methods for use therewith |
| US10359749B2 (en) | 2016-12-07 | 2019-07-23 | At&T Intellectual Property I, L.P. | Method and apparatus for utilities management via guided wave communication |
| US10389029B2 (en) | 2016-12-07 | 2019-08-20 | At&T Intellectual Property I, L.P. | Multi-feed dielectric antenna system with core selection and methods for use therewith |
| US10139820B2 (en) | 2016-12-07 | 2018-11-27 | At&T Intellectual Property I, L.P. | Method and apparatus for deploying equipment of a communication system |
| US10027397B2 (en) | 2016-12-07 | 2018-07-17 | At&T Intellectual Property I, L.P. | Distributed antenna system and methods for use therewith |
| US10530505B2 (en) | 2016-12-08 | 2020-01-07 | At&T Intellectual Property I, L.P. | Apparatus and methods for launching electromagnetic waves along a transmission medium |
| US10326689B2 (en) | 2016-12-08 | 2019-06-18 | At&T Intellectual Property I, L.P. | Method and system for providing alternative communication paths |
| US10069535B2 (en) | 2016-12-08 | 2018-09-04 | At&T Intellectual Property I, L.P. | Apparatus and methods for launching electromagnetic waves having a certain electric field structure |
| US9911020B1 (en) | 2016-12-08 | 2018-03-06 | At&T Intellectual Property I, L.P. | Method and apparatus for tracking via a radio frequency identification device |
| US10777873B2 (en) | 2016-12-08 | 2020-09-15 | At&T Intellectual Property I, L.P. | Method and apparatus for mounting network devices |
| US10389037B2 (en) | 2016-12-08 | 2019-08-20 | At&T Intellectual Property I, L.P. | Apparatus and methods for selecting sections of an antenna array and use therewith |
| US10103422B2 (en) | 2016-12-08 | 2018-10-16 | At&T Intellectual Property I, L.P. | Method and apparatus for mounting network devices |
| US10411356B2 (en) | 2016-12-08 | 2019-09-10 | At&T Intellectual Property I, L.P. | Apparatus and methods for selectively targeting communication devices with an antenna array |
| US10938108B2 (en) | 2016-12-08 | 2021-03-02 | At&T Intellectual Property I, L.P. | Frequency selective multi-feed dielectric antenna system and methods for use therewith |
| US9998870B1 (en) | 2016-12-08 | 2018-06-12 | At&T Intellectual Property I, L.P. | Method and apparatus for proximity sensing |
| US10601494B2 (en) | 2016-12-08 | 2020-03-24 | At&T Intellectual Property I, L.P. | Dual-band communication device and method for use therewith |
| US10916969B2 (en) | 2016-12-08 | 2021-02-09 | At&T Intellectual Property I, L.P. | Method and apparatus for providing power using an inductive coupling |
| US9838896B1 (en) | 2016-12-09 | 2017-12-05 | At&T Intellectual Property I, L.P. | Method and apparatus for assessing network coverage |
| US10340983B2 (en) | 2016-12-09 | 2019-07-02 | At&T Intellectual Property I, L.P. | Method and apparatus for surveying remote sites via guided wave communications |
| US10264586B2 (en) | 2016-12-09 | 2019-04-16 | At&T Mobility Ii Llc | Cloud-based packet controller and methods for use therewith |
| US9973940B1 (en) | 2017-02-27 | 2018-05-15 | At&T Intellectual Property I, L.P. | Apparatus and methods for dynamic impedance matching of a guided wave launcher |
| US10298293B2 (en) | 2017-03-13 | 2019-05-21 | At&T Intellectual Property I, L.P. | Apparatus of communication utilizing wireless network devices |
| CN111512654B (zh) * | 2017-10-30 | 2023-06-13 | 瑞典爱立信有限公司 | 支持对于VoLTE的人工漫游 |
| US11005715B2 (en) | 2018-12-21 | 2021-05-11 | T-Moblle USA, Inc. | Latency-sensitive network-traffic quality of service |
| US11044194B2 (en) * | 2019-02-28 | 2021-06-22 | T-Mobile Usa, Inc. | QoS for latency-sensitive network-traffic flows |
| CN111132147A (zh) * | 2019-12-11 | 2020-05-08 | 上海欣方智能系统有限公司 | 一种加密通话在移动终端上的实现方法 |
| US11936694B2 (en) | 2021-11-18 | 2024-03-19 | T-Mobile Usa, Inc. | Cross-domain routing based on session initiation protocol information |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050265278A1 (en) * | 2004-04-13 | 2005-12-01 | Hsu Raymond T | Multimedia communication using co-located care of address for bearer traffic |
| US20060039397A1 (en) * | 2004-08-18 | 2006-02-23 | Lucent Technologies Inc. | Sagacious routing engine, method of routing and a communications network employing the same |
| US20060251043A1 (en) * | 2005-04-18 | 2006-11-09 | Lila Madour | Method for controlling the quality of service in an IP multimedia system |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6373817B1 (en) * | 1999-12-30 | 2002-04-16 | At&T Corp. | Chase me system |
| US6621793B2 (en) * | 2000-05-22 | 2003-09-16 | Telefonaktiebolaget Lm Ericsson (Publ) | Application influenced policy |
| US7133923B2 (en) * | 2000-12-11 | 2006-11-07 | Acme Packet, Inc. | System and method for assisting in controlling real-time transport protocol flow through multiple networks via screening |
| US7072303B2 (en) * | 2000-12-11 | 2006-07-04 | Acme Packet, Inc. | System and method for assisting in controlling real-time transport protocol flow through multiple networks |
| US7068598B1 (en) | 2001-02-15 | 2006-06-27 | Lucent Technologies Inc. | IP packet access gateway |
| US7414981B2 (en) * | 2001-04-25 | 2008-08-19 | Qwest Communications International, Inc. | Method and system for event and message registration by an association controller |
| US6987765B2 (en) | 2001-06-14 | 2006-01-17 | Nortel Networks Limited | Changing media sessions |
| US7383048B2 (en) * | 2002-12-04 | 2008-06-03 | Nokia Corporation | Transmission of data packets by a node |
| WO2004084502A1 (en) | 2003-03-17 | 2004-09-30 | Orange Sa | Radio network for communicating internet data packets containing different types of data |
| US7385946B2 (en) * | 2004-06-03 | 2008-06-10 | Nokia Corporation | Service based bearer control and traffic flow template operation with mobile IP |
| US8194640B2 (en) * | 2004-12-31 | 2012-06-05 | Genband Us Llc | Voice over IP (VoIP) network infrastructure components and method |
| CN103763446B (zh) * | 2005-03-10 | 2016-01-20 | 朗迅科技公司 | 使用既有设备的ims网络接入 |
| US8064452B2 (en) * | 2005-04-19 | 2011-11-22 | At&T Intellectual Property Ii, L.P. | Method and apparatus for routing calls to an alternative endpoint during network disruptions |
| EP1720365A1 (en) | 2005-05-06 | 2006-11-08 | Siemens S.p.A. | Method to exchange capability information between UMTS users |
-
2006
- 2006-12-14 US US11/610,794 patent/US7649881B2/en active Active
-
2007
- 2007-11-15 CN CN2007800511912A patent/CN101601224B/zh active Active
- 2007-11-15 EP EP07845515.1A patent/EP2095564B1/en active Active
- 2007-11-15 KR KR1020097014562A patent/KR101096364B1/ko active IP Right Grant
- 2007-11-15 WO PCT/CA2007/002045 patent/WO2008070957A1/en active Application Filing
- 2007-11-15 ES ES200990004A patent/ES2364793B2/es active Active
- 2007-11-15 CA CA2671899A patent/CA2671899C/en active Active
-
2010
- 2010-02-24 HK HK10101931.8A patent/HK1136709A1/xx unknown
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050265278A1 (en) * | 2004-04-13 | 2005-12-01 | Hsu Raymond T | Multimedia communication using co-located care of address for bearer traffic |
| US20060039397A1 (en) * | 2004-08-18 | 2006-02-23 | Lucent Technologies Inc. | Sagacious routing engine, method of routing and a communications network employing the same |
| US20060251043A1 (en) * | 2005-04-18 | 2006-11-09 | Lila Madour | Method for controlling the quality of service in an IP multimedia system |
Also Published As
| Publication number | Publication date |
|---|---|
| CA2671899C (en) | 2016-01-19 |
| ES2364793B2 (es) | 2012-04-20 |
| HK1136709A1 (en) | 2010-07-02 |
| EP2095564B1 (en) | 2018-08-15 |
| WO2008070957A1 (en) | 2008-06-19 |
| CN101601224A (zh) | 2009-12-09 |
| CA2671899A1 (en) | 2008-06-19 |
| US20080144615A1 (en) | 2008-06-19 |
| KR20090098885A (ko) | 2009-09-17 |
| CN101601224B (zh) | 2012-08-15 |
| EP2095564A1 (en) | 2009-09-02 |
| EP2095564A4 (en) | 2013-08-07 |
| KR101096364B1 (ko) | 2011-12-20 |
| US7649881B2 (en) | 2010-01-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2364793B2 (es) | Fijación de la ruta de flujos portadores de ip en una red de próxima generación. | |
| ES2365782B1 (es) | Servicio de representantes de pasarela para hablantes no de sip en una red de próxima generación. | |
| US20080144602A1 (en) | Providing sip interworking in a next generation network | |
| US9060047B2 (en) | Media stream management | |
| US20020181462A1 (en) | System and method for providing end-to-end quality of service (QoS) across multiple internet protocol (IP) networks | |
| US20080069086A1 (en) | Mobile Communication System Based On Ip And Session Initiation Method Thereof | |
| CN101114985B (zh) | 编解码转换系统及方法 | |
| US8428074B2 (en) | Back-to back H.323 proxy gatekeeper | |
| CN101360057B (zh) | 一种路由处理的方法、ims业务处理的方法及相关设备 | |
| Bates et al. | Converged multimedia networks | |
| CN116319709A (zh) | 预测通话质量的方法及通话质量预测服务装置 | |
| JP4621183B2 (ja) | Ｉｐ通信網の相互接続システム及びｉｐ通信網の相互接続方法 | |
| Paliwal | Convergence: the next big step | |
| Zhang et al. | A Framework for Traffic Engineering In a SIP-over-MPLS based network | |
| Vergados et al. | IP-based Convergence of Fixed and Cellular Networks and Services in the Light of Liberalization | |
| Jujjuru | An Overview of Internet Protocol Multimedia Subsystems (IMS) Architecture | |
| Wisely et al. | SIP—THE SESSION INITIATION PROTOCOL | |
| Lehtinen | Department of Electrical and Communications Engineering Networking Laboratory |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FG2A | Definitive protection |
Ref document number: 2364793 Country of ref document: ES Kind code of ref document: B2 Effective date: 20120420 |