ES2437133T3

ES2437133T3 - Procedimiento para la optimización de una transmisión de datos orientada a paquetes y producto de programa informático

Info

Publication number: ES2437133T3
Application number: ES11160636.4T
Authority: ES
Inventors: Jörg Prof. Dr. Ott; Nils Seifert; Carsten Prof. Dr. Bormann
Original assignee: Nomad Spectrum Ltd
Current assignee: Nomad Spectrum Ltd
Priority date: 2008-05-15
Filing date: 2009-05-15
Publication date: 2014-01-09
Anticipated expiration: 2029-05-15
Also published as: EP2385682A3; EP2385682A2; WO2009138076A3; PT2385682E; DE112009001718A5; WO2009138076A2; EP2385682B1; EP2294791A2

Abstract

Procedimiento para la optimización de una transmisión de datos entre puntos terminales de comunicación en una red con puntos terminales de comunicación, comprendiendo el procedimiento las etapas siguientes: - establecer una relación de comunicación o intentar establecer una relación de comunicación entre un punto terminal de comunicación y un punto terminal de comunicación adicional, estando prevista para la relación de comunicación una transmisión de datos orientada a paquetes, en la que se forma o debe formarse un flujo de datos que comprende paquetes de datos intercambiados, - proporcionar una disposición de optimizador asociada a la relación de comunicación, que se forma con al menos un optimizador, y - optimizar la transmisión de datos orientada a paquetes entre el punto terminal de comunicación y el punto terminal de comunicación adicional simulando, para la relación de comunicación, por medio de la disposición de optimizador, para el punto terminal de comunicación y/o el punto terminal de comunicación adicional, una continuación o una iniciación de la relación de comunicación durante una interrupción de la transmisión, concretamente un periodo, en el que entre el punto terminal de comunicación y el punto terminal de comunicación adicional no pueden intercambiarse paquetes de datos, en el que durante la simulación se continúa o se comienza una transmisión de paquetes de datos desde la disposición de optimizador al punto 20 terminal de comunicación y/o al punto terminal de comunicación adicional.

Description

Procedimiento para la optimización de una transmisión de datos orientada a paquetes y producto de programa informático.

La invención se encuentra en el campo de la transmisión de datos orientada a paquetes.

Antecedentes de la invención

Se considera una relación de comunicación entre dos o más instancias, que funcionan como origen y/o sumidero de datos útiles en el marco de esta relación de comunicación. En cada caso un origen transmite datos útiles a uno o varios sumideros. Los datos útiles son unidades de información aleatorias. Además el origen y/o el sumidero pueden transmitir entre sí de manera aleatoria informaciones de control. Los datos útiles transmitidos representan, de manera análoga a la carga útil de un vehículo, las informaciones, para cuya transmisión las instancias se comunican entre sí en realidad. Las informaciones de control representan según el protocolo utilizado informaciones de características diferentes, que son necesarias para el desarrollo del protocolo correcto y/o satisfactorio y/o eficiente y/o que cumpla con otros requisitos (y de este modo para la transmisión de los datos útiles). La relación de informaciones de control necesarias con respecto a la carga útil real se denomina sobrecarga. La sobrecarga se produce también, cuando los datos útiles o informaciones de control, directa o indirectamente, se transmiten de manera múltiple, como puede ocurrir en el caso de repeticiones de emisión (ARQ), corrección de errores hacia delante (FEC), codificación de red o procedimientos similares.

Los datos útiles pueden transmitirse según la aplicación y/o función realizada sólo en una dirección (unidireccional) o en varias direcciones (bidireccional). Lo mismo se aplica para informaciones de control. Mientras que la mayoría de redes permiten en principio la transmisión en ambos sentidos, existen tecnologías de red (por ejemplo DVB-S/C/T) que, independientemente de las aplicaciones, sólo permiten una transmisión unidireccional y/o por motivos de coste u otros motivos hacen que sea útil una transmisión unidireccional y/o en las que la dirección de retorno se realiza por separado mediante los mismos y/u otros procedimientos de transmisión y/o redes; estas limitaciones y/o condiciones proceden por regla general del diseño del sistema. En algunos casos los datos de control y los datos útiles pueden transmitirse sólo en una dirección o para la dirección de retorno se utilizan otros procedimientos de transmisión y/o redes, pudiendo intercambiarse también datos útiles y/o informaciones de control o subcantidades de datos útiles y/o informaciones de control por diferentes redes.

Generalmente en la actualidad los datos ya no se transmiten de manera analógica y tampoco sólo como secuencia de bits o secuencia de bytes por líneas de datos, sino que para la transmisión y el procesamiento se dividen en paquetes de datos individuales, esto se denomina a menudo también transmisión de datos orientada a paquetes. Un paquete de datos contiene informaciones (también denominadas informaciones de control), que son o pueden ser necesarias para el desarrollo del protocolo de transmisión y opcionalmente datos útiles.

Un paquete de datos contiene a este respecto por ejemplo una o varias cabeceras de paquete o cabecera de protocolo y/o cola de paquete o protocolo. Todas éstas se denominarán a continuación simplemente “cabeceras”. Estas cabeceras contienen las informaciones de control, que por ejemplo pueden ser informaciones de direccionamiento. A las cabeceras les siguen en parte los datos útiles reales (datos de voz, partes de texto, partes de archivos, etc.). Pero también los datos de control de capas de protocolo más altas, también a menudo incluyendo las propias cabeceras, se denominan desde el punto de vista de las capas de protocolo situadas por debajo con frecuencia datos útiles. Para dentro de una cabecera poder identificar y/o interpretar las informaciones de control, una cabecera está compuesta por un o a menudo varios “campos”, en los que están contenidas las informaciones de control. Esta disposición de campos dentro de una cabecera se denomina a continuación también estructura de cabecera de una cabecera. Sirve entre otros para identificar y/o interpretar los campos individuales y así también las informaciones de control dentro de una cabecera.

Así, con frecuencia se obtiene un modelo de varias capas de protocolo, que se sitúan una sobre otra: una pila de protocolos o una jerarquía de protocolos, tal como se describe entre otros en

[1] International Standard ISO/IEC 7498-1, “Information technology, Open Systems Interconnection, Basic Reference Model: The Basic Model, (Second edition 1994-11-15 Corrected and reprinted 1996-06-15).

El Internet actual se basa en una transmisión de datos orientada a paquetes. También en este caso se utilizan protocolos y por regla general se forma una jerarquía de protocolos (similar pero no idéntico a lo descrito en [1]).

Las bases de una forma original del protocolo de Internet IP así como algunas jerarquías de protocolos posibles (“Relaciones de protocolo”) se describen entre otros en

[2] IETF RFC 0791, Internet Protocol DARPA Internet Program, Protocol Specification septiembre de 1981. Existiendo para este protocolo IP (Version 4/IPv4) un gran número de normas adicionales/relacionadas y bibliografía relacionada. Entre tanto también la normalización e introducción de nuevas versiones del protocolo IP ha progresado mucho. Las bases de la versión 6 del protocolo IP (IPv6) se describen entre otros en

[3] IETF RFC 2460, Internet Protocol, Version 6 (IPv6), Specification, S. Deering, R. Hinden, diciembre de 1998.

Dentro de una pila de protocolos pueden distinguirse diferentes capas de protocolo. A este respecto los protocolos de las capas de protocolo individuales a menudo se agregan, aunque también paralelos unos al lado de otro en capas de protocolo individuales o pilas de protocolos secundarias pueden realizar funciones propias o también relacionadas entre sí. Según el caso de aplicación concreto o el modelo seleccionado de jerarquías de protocolos también varios protocolos pueden considerarse de manera concurrente o también situarse unos sobre otros como una capa de protocolo.

Una posible perspectiva de usuario de la transmisión de datos es la realización de servicios de datos. Entre éstos se encuentran entre otros la telefonía, videotelefonía y (vídeo) conferencias a través de Internet (a continuación resumido

con el término “VoIP”), presentación en flujo continuo de audio/vídeo, el acceso a páginas web (“navegación por la web”), transferencias de archivos, correo electrónico, chat, aplicaciones de igual a igual etc. A continuación, sin limitación de la generalidad, a menudo se utilizan VoIP y navegación por la web como ejemplos para servicios de datos.

1er ejemplo: navegación por la web

A continuación a menudo se utiliza la navegación por la web (con los protocolos HTTP y HTTPS) en el Internet actual como escenario de ejemplo o aplicación de ejemplo. Al mismo tiempo sirve como ejemplo para jerarquías de protocolos. La selección de estos ejemplos se produce entre otros, porque la bibliografía existente de esta área temática a menudo se refiere directamente al caso de aplicación de la navegación por la web, al mismo tiempo estos escenarios de ejemplo también son adecuados para explicar tanto la problemática como la invención; sin embargo, estos escenarios de ejemplo sólo representan un gran número de otros posibles campos de aplicación. Del mismo modo a continuación con frecuencia se utiliza el protocolo de Internet (IP), un protocolo de la capa de red (capa 3 del modelo OSI [1]), como ejemplo. Sin embargo, la presente invención también es independiente de la utilización del protocolo de Internet.

La navegación por la web (o también el acceso a la web en general) se produce en el Internet actual en gran parte con

ayuda de los protocolos HTTP (“protocolo de transferencia de hipertexto”) y HTTPS (“HTTP seguro”). Las bases de

HTTP y HTTPS se describen entre otros en

[4] IETF RFC 2616, Hypertext Tranfer Protocol, HTTP/1.1, R. Fielding, J. Gettys, ..., junio de 1999

[5] IETF RFC 2818, HTTP Over TLS, E. Rescorla, mayo de 2000.

En la utilización de HTTP, HTTPS en el Internet actual se produce igualmente con frecuencia una jerarquía de protocolos ya bastante amplia:

HTTP, HTTPS en sí mismos se clasifican con frecuencia como protocolos de aplicación. A este respecto por ejemplo el HTTP se inserta por regla general por encima del protocolo TCP (protocolo de control de transmisión [RFC 793]), al que se asocia la capa de transporte. El TCP a su vez se inserta por regla general por encima de IP, un protocolo de la capa de red (capa 3 ISO/OSI según [1]). Por debajo de IP siguen igualmente con frecuencia otros protocolos por ejemplo en

función del medio de transmisión utilizado (como por ejemplo una red local con “Ethernet” IEEE 802.3, que

correspondería a las capas de protocolo 1 y 2 ISO/OSI según [1]).

2º ejemplo: VoIP

A continuación también se utiliza la transmisión de datos de voz (“voz sobre IP”, “VoIP”) en el Internet actual como

ejemplo para una jerarquía de protocolos. Esto se produce entre otros, porque la bibliografía existente para la compresión de cabeceras a menudo se refiere directamente al caso de aplicación de VoIP. Del mismo modo a continuación con frecuencia se utiliza el protocolo de Internet (IP), un protocolo de la capa de red (capa 3 del modelo OSI [1]), como ejemplo. Sin embargo, la presente invención también puede utilizarse independientemente del caso de aplicación VoIP, también independientemente de la utilización del protocolo de Internet y también para protocolos de otras capas diferentes de la capa de red.

En el Internet actual la transmisión de datos basada en VoIP se realiza a menudo entre otros utilizando el protocolo RTP (“protocolo de transporte en tiempo real”). El RTP se describe entre otros en

[6]: IETF RFC 3550, RTP: A Transport Protocol for Real-Time Applications, H. Schulzrinne, S. Casner, R. Frederick,

V.: Jacobson, julio de 2003.

En la utilización de RTP en el Internet actual se produce con frecuencia una jerarquía de protocolos ya bastante amplia:

el RTP en sí mismo es un protocolo de la capa de transporte (capa 4 ISO/OSI según [1]). El RTP se utiliza a este respecto por regla general por encima del protocolo UDP (protocolo de datagrama de usuario [RFC 768]), que igualmente se asocia a la capa de transporte. UDP a su vez se inserta por regla general por encima de IP, un protocolo de la capa de red (capa 3 ISO/OSI según [1]). Por debajo de IP siguen con frecuencia otros protocolos por ejemplo en

correspondería a las capas de protocolo 1 y 2 ISO/OSI según [1]).

Los servicios de datos requieren para su realización con frecuencia servicios de directorio o servicios de nombres adicionales.

Un protocolo, que puede utilizarse en este contexto, es el protocolo DNS. Los usuarios no pueden acordarse bien de las direcciones IP, por ello los protocolos como HTTP utilizan en sus URI (identificador de recursos uniforme, identificador, frente a cuya entrada los servidores web proporcionan objetos de datos y que en el caso de VoIP sirven para la identificación sencilla de usuarios, de manera comparable a direcciones de correo electrónico o números de teléfono) en general los denominados nombres de dominio, nombres legibles, que en primer lugar tienen que convertirse por un servicio de nombres mediante una denominada resolución de nombres en direcciones IP. A continuación los servicios de nombres de este tipo se explican con más detalle en el ejemplo de DNS, un servicio de nombres conocido en general y extendido en Internet. Como el funcionamiento y la construcción jerárquica de DNS son conocidos (véase la referencia [7]), en este caso sólo se habla con abstracción de un servidor (DNS) o servidor de servicios de nombres de nivel n (en la jerarquía). El experto en la materia conoce otros servicios de directorio y también otros servicios de nombres así como en cada caso su configuración y funcionamiento, de los que más abajo se mencionan algunos, cuyo modo de trabajo sin embargo no tiene que explicarse en detalle. Para esta resolución de nombres con frecuencia se utiliza el protocolo DNS, que entre otros se describe en

[7] IETF RFC 1035, Domain Names, Implementation and Specification, P. Mockapetris, noviembre de 1987.

Para el servicio de nombres DNS descrito en este caso como ejemplo por ejemplo los navegadores web utilizan los denominados interpretadores, que utilizan el protocolo DNS, para dirigir consultas a uno o varios servidores DNS configurados directamente y/o asociados al sistema terminal del navegador web. Estos servidores DNS del primer nivel dirigen a su vez con frecuencia consultas a otros servidores DNS. La respuesta necesaria no se produce necesariamente en la primera consulta de este tipo; los servidores DNS de los niveles siguientes también pueden responder a las consultas de manera incompleta y a este respecto proporcionar referencias a otros servidores DNS. El servidor DNS del primer nivel (o también de los niveles siguientes) realiza consultas adicionales a los mismos, hasta que se produce una respuesta de un servidor DNS, que conoce la respuesta necesaria. Como en el caso del protocolo DNS, las respuestas pueden estar dotadas de una vida útil (tiempo de vida, TTL), por ejemplo un número entero, que indica (en segundos), cuánto tiempo esta respuesta será todavía válida. Basándose en esto los interpretadores y/o servidores DNS implementan las denominadas memorias intermedias o memorias caché, a partir de las que puede responderse a una consulta repetida para la misma conversión sin consultar los niveles siguientes, siempre que lo permita la vida útil de la respuesta almacenada. El protocolo DNS puede situarse sobre el protocolo de transporte UDP

o también al das protocolo de transporte TCP, ambos protocolos se agregan a su vez por regla general como se describió anteriormente a IP y otros protocolos situados por debajo.

Otros protocolos del área de los servicios de directorio y en parte también de los servicios de nombres más especiales son, por ejemplo, Microsoft WINS, Sun NIS, ARP y la norma LDAP. También estos protocolos adicionales realizan resoluciones de nombres (por ejemplo, de un nombre a otro y/o de una dirección a otra y/o de un nombre a una dirección y/o de una dirección a un nombre).

Los protocolos individuales y/o sus implementaciones/instalaciones específicas pueden estar configurados a este respecto de manera diferente a DNS: no tienen que comunicarse obligatoriamente a través de un servidor de servicios de nombres, pueden estar formados ningún nivel, un nivel o varios niveles de servidores de servicios de nombres.

Como resolución de nombres el DNS convierte por regla general un denominado nombre DNS (con frecuencia un nombre de ordenador) en una dirección IP. Sin embargo, los servicios de directorio y servicios de nombres también pueden realizar otras resoluciones de nombres, que no contienen obligatoriamente nombres o direcciones clásicos. Así, un servicio de directorio también podría responder en general a una consulta de por ejemplo un valor de datos/estado de ordenador y los servicios de directorio por ejemplo podrían devolver adicionalmente o en lugar de direcciones por ejemplo certificados, claves, o también números de teléfono. A continuación en general también estos servicios de directorio, así como servicios de infraestructura en general, que realizan funciones correspondientes, se denominan servicios de nombres y las consultas/conversiones realizadas se denominan de manera uniforme resolución de nombres.

Los detalles de la resolución de nombres pueden distinguirse según el servicio de datos. Ejemplos para servicios de datos con otras resoluciones de nombres diferentes de DNS o resoluciones de nombres que se complementan con DNS son entre otros el protocolo de inicio de sesión (RFC 3261 y RFC 3263), ITU-T H.323 y H.225.0. La función de los servicios de nombres puede estar acoplada además directamente con los servicios de datos.

Los servicios de nombres se utilizan en parte también para soportar movilidad, por ejemplo en redes de radiotelefonía móvil o para la realización de portabilidad de números, números de llamada personales, números de llamada de servicios (por ejemplo, 0800, 0900) etc. en la red de telefonía (móvil).

A continuación el término servidor de servicios de nombres representa un servidor, que realiza las tareas de servicios de nombres. Un servidor de servicios de nombres de este tipo debe entenderse a este respecto como una función lógica. No requiere obligatoriamente un sistema de hardware o software separado para la realización de la función del servidor de servicios de nombres. Si bien puede estar formada como componente separado, no obstante también puede estar desarrollada como parte constitutiva del sistema operativo, de uno o varios componentes de aplicación, sistemas del mismo nivel, otros elementos de red, etc. Esto se aplica a servidores de servicios de nombres de cualquier nivel; en particular no puede estar presente ningún servidor de servicios de nombres identificable de manera independiente como componente separado.

Los servicios de nombres también pueden estar desarrollados como específicos para el servicio de datos: así, para VoIP en parte adicionalmente a o en lugar de un servicio de nombres general como DNS se realiza una función adicional en el servicio VoIP, que con respecto a nombres de usuario (por ejemplo representado como URI) proporciona su dirección de contacto actual (normalmente una o también varias direcciones IP) y así posibilita la accesibilidad del usuario. La resolución del nombre de usuario en una dirección de contacto puede producirse como se describió anteriormente en una o varias etapas y requerir uno o varios niveles.

Los escenarios de aplicación como la navegación por la web y VoIP pertenecen en la actualidad al estado de la materia y se utilizan ampliamente. A menudo, en particular en redes locales o redes solamente con poca carga en relación con su ancho de banda, puede realizarse un rendimiento y una realización muy satisfactoria para los usuarios de navegación por la web y VoIP con componentes convencionales (aplicaciones, componentes de red como conmutadores y encaminadores,...). A continuación en lugar de sobre la realización de por ejemplo navegación por la web u otros campos de aplicación también se habla de servicios y una calidad de servicio conseguida correspondientemente buena/alta o mala/baja. No obstante, el rendimiento y/o satisfacción del usuario pueden ser en otros escenarios de aplicación claramente menos buenos y representan problemas. A este respecto los problemas según el escenario de aplicación puede llevar a desde en parte sólo pequeñas influencias molestas (como breves interrupciones, un rendimiento algo menor y/o de vez en cuando a una conexión que se corta) hasta una inoperabilidad amplia del servicio. La calidad de servicio conseguida es correspondientemente subóptima, dado el caso incluso insuficiente.

A este respecto con frecuencia una influencia directa y/o indirecta sobre la calidad de servicio conseguida la tiene el retardo de transmisión en la red. El retardo de transmisión en la red depende a este respecto de un gran número de factores. A esto pertenecen por ejemplo con frecuencia los tiempos de ejecución de señal reales, la tasa de transmisión de datos de red o en el caso de tramos de transmisión individuales la tasa de transmisión de datos del tramo de transmisión correspondiente, el tamaño de un paquete de datos en relación con la tasa de transmisión de datos (siempre que por ejemplo la retransmisión de paquetes sólo/esencialmente sólo se produzca tras la recepción de todo el paquete de datos), retardos en los componentes de red de retransmisión, almacenamiento intermedio en los componentes individuales, retardos en los componentes que evalúan/implementan un protocolo, etc. Este retardo de transmisión se mide a menudo en ambos sentidos de una relación de comunicación en conjunto y a continuación

también se denomina RTT (“tiempo de ida y vuelta”).

RTT representa por regla general el tiempo que transcurre en total desde el envío de un primer paquete por el emisor pasando por la recepción del primer paquete por el receptor, pasando por el envío de un segundo paquete potencial como reacción al primer paquete por el receptor del primer paquete hasta la recepción de este segundo paquete por el emisor del primer paquete. En algunas redes existe la posibilidad de medir con protocolos especiales un RTT actual. En las redes basadas en IPv4 esto se realiza con frecuencia con ayuda de un comando PING, que envía paquetes ICMP (“protocolo de mensaje de control de Internet” - RFC 792) y espera paquetes de respuesta ICMP correspondientes del lado contrario. Las optimizaciones de esta invención pueden aplicarse a este respecto con frecuencia al flujo de datos en uno o también en ambos sentidos de datos. Las optimizaciones de esta invención con frecuencia también pueden aplicarse cuando los datos sólo se envían en una dirección. Sin embargo, para simplificar las descripciones, a continuación en todos estos casos aun así se habla de manera uniforme de RTT.

a) Pérdidas de paquetes

Las pérdidas de paquetes son una de las causas potenciales, que pueden llevar a una reducción de la calidad de servicio. Como pérdidas de paquetes se denominan a continuación tanto paquetes de datos perdidos completamente como paquetes de datos, que se falsearon o retrasaron desproporcionadamente durante la transmisión y por tanto no pueden utilizarse. De momento por regla general los paquetes perdidos presentan el mismo significado que datos útiles y/o informaciones de control perdidos.

Repeticiones de emisión (ARQ):

Hay muchos protocolos (como por ejemplo el protocolo TCP utilizado en la navegación por la web con frecuencia para los servicios de datos y en ocasiones para los servicios de nombres), que compensan las pérdidas de paquetes que se producen con medidas adecuadas como confirmaciones de recepción positivas y/o negativas o peticiones para la repetición de la transmisión o tiempos límite y nueva transmisión a continuación de las informaciones perdidas. Así, a menudo los protocolos de capas situadas más altas y/o los propios usuarios ni siquiera se dan cuenta directamente de que se han producido pérdidas de paquetes. Sin embargo, especialmente en el caso de servicios de nombres una pérdida de paquetes también se percibe por la no aparición de una respuesta en un intervalo de tiempo esperado por capas situadas más altas; entonces la función de las capas situadas más altas, repeticiones de la transmisión (en determinadas circunstancias también utilizando proveedores de servicios alternativos).

Sin embargo, una nueva transmisión de paquetes de este tipo por regla general no es posible en un tiempo cero. En muchos protocolos para ello el receptor en primer lugar tiene que enviar de vuelta informaciones al emisor o el emisor espera la ausencia de tales informaciones. A continuación por regla general el emisor debe enviar de nuevo un paquete de datos completo (o también directamente y/o indirectamente una parte del mismo). Ambas cosas requieren tiempo, que depende del RTT de la red y/o del/de los protocolo/s de transmisión y/o de su/s parámetro/s.

Hay muchos procedimientos para reducir la influencia negativa de pérdidas de paquetes sobre la calidad de servicio.

El protocolo TCP por ejemplo envía (expresado muy en general) a menudo varios paquetes, antes de que espere las confirmaciones de recepción de los receptores. Así, a menudo puede compensar pérdidas de paquetes por el nuevo envío de los paquetes perdidos, sin que se impida que el emisor entretanto envíe (otros) paquetes nuevos. Por tanto en el caso de pérdidas de paquetes que se producen al menos en parte no se producen pausas completas en el envío de datos.

Corrección de errores hacia delante (FEC) para tramo de transmisión/extremo a extremo:

Otro enfoque conocido es reducir la probabilidad de pérdidas de paquetes en tramos de transmisión o compensar pérdidas de paquetes. Para ello se utilizan a menudo procedimientos para la corrección de errores hacia delante (FEC). En estos procedimientos a menudo (expresado muy en general) se insertan informaciones de redundancia en los datos enviados. Entonces a partir de estas informaciones de redundancia un receptor puede intentar reconstruirse por pérdidas de datos producidas por pérdidas de paquetes. A este respecto hay muchas posibilidades conocidas de cómo puede ser el aspecto de estas informaciones adicionales/informaciones de redundancia de FEC, cómo se crean/calculan, cómo un receptor puede/debe utilizar estas informaciones, para reconstruir datos que faltan, etc. Del mismo modo FEC puede calcularse tanto para bloques de datos como para paquetes o grupos de paquetes y/o también para flujos de bits/bytes. A los procedimientos de FEC conocidos pertenecen entre otros los procedimientos basados en la matriz de Vandermonde y otros que utilizan cuerpos de Galois, Reed-Solomon, Golay, BCH, Hamming, Turbo Coding, procedimientos sencillos y complejos/anidados basados en exclusión o XOR, por nombrar sólo algunos ejemplos. También los procedimientos de redundancia muy sencillos como el envío doble o múltiple de informaciones controlado pueden denominarse procedimiento de corrección de errores hacia delante (FEC).

Los procedimientos basados en FEC se utilizan a menudo en tramos de transmisión individuales (por ejemplo un radioenlace, enlace de satélite, pero también tramos de transmisión por cable). A menudo a este respecto son parte constitutiva directa de los protocolos de capa de enlace y se utilizan para todas las informaciones transmitidas en el tramo de transmisión correspondiente.

El segundo caso de aplicación habitual de procedimiento de FEC es extremo a extremo. A este respecto por el emisor real de los datos se incluyen informaciones FEC en el flujo de datos/flujo de paquetes.

Los procedimientos basados en FEC con respecto a las repeticiones de emisión presentan la ventaja de que por regla general posibilitan a los receptores la reconstrucción de informaciones perdidas, sin que por ejemplo primero un RTT tenga que esperar la aparición de repeticiones de emisión. Por tanto la utilización de procedimientos basados en FEC es adecuada para escenarios de aplicación, en los que son importantes los retardos de transmisión. A éstos pertenecen entre otros también las transmisiones de vídeo en tiempo real y VoIP, en las que la espera a repeticiones de emisión por lo demás llevaría a menudo a “interrupciones” o en general a un retardo mayor de la reproducción.

Otro enfoque, que también se utiliza con frecuencia en la transmisión de datos de voz e imagen es seleccionar una codificación de contenido adecuada (Codec/codificación, compresión por ejemplo de los datos de voz/imagen reales en sí mismos = los datos útiles que van a transmitirse desde el punto de vista de las capas situadas por debajo). Ésta podría contener por ejemplo procedimientos de FEC enfoques de procedimientos de FEC. Sin embargo, sobre todo una codificación de contenido también puede seleccionarse de tal modo que las pérdidas de paquetes (también las no corregidas) sólo tengan efectos muy limitados sobre la reproducción (es decir, por ejemplo sólo se vean afectados datos de voz de un periodo de 20 ms y la pérdida de datos no tenga ningún efecto o sólo uno efecto reducido sobre la reproducción de voz consecutiva).

Además de la configuración (previa) de la utilización de una codificación de contenido adecuada a este respecto también es posible adaptar la codificación de contenido de manera dinámica a una situación de pérdida de paquetes determinada y/o a retardos de transmisión determinados (véase para ello también las realizaciones en b)). También se conoce una denominada transcodificación (es decir, una adaptación de una codificación de contenido original mediante recodificación por ejemplo de los datos útiles de voz/imagen en una codificación de contenido más adecuada para por ejemplo una red/una situación de transmisión en la red.

A menudo la causa de pérdidas de paquetes que se producen se explica también, o incluso sobre todo, por una utilización común de tramos de transmisión y/o redes para la transmisión casi simultánea/paralela de datos potencialmente muy diferentes de potencialmente varias/varios/muchas/muchos aplicaciones y/o usuarios. A este respecto puede suceder por ejemplo que otra aplicación de otros usuarios de repente genere claramente más datos y por tanto de repente aumente considerablemente la tasa de pérdida de paquetes, porque se superan las capacidades de transmisión de la red y/o de un tramo de transmisión.

Por los documentos JP 2006-054561 A así como WO 2008/013528 A1 se conocen procedimientos para la utilización de procedimientos basados en FEC.

En el documento US 2001/0047401 A1 se describen un procedimiento así como un software para establecer una conexión con un servidor a través de una red para la transmisión de contenidos multimedia.

QoS/priorización/catalogación de tráfico:

Para evitar tales pérdidas de paquetes, o para distinguir al menos datos importantes completa o parcialmente de aquéllas pérdidas de paquetes generadas por sobrecarga, existen procedimientos conocidos para la reserva de ancho de banda en redes, para el marcado de datos importantes (por ejemplo mediante la utilización del campo TOS en cabeceras IP) y/o mecanismos QoS, que por ejemplo dividen el ancho de banda disponible para usuarios y/o aplicaciones individuales. La puesta en práctica de este procedimiento se produce por regla general mediante

encaminadores y/o “catalogadores de tráfico” específicos, que en/antes de la retransmisión de paquetes de datos

evalúan estas informaciones y de este modo pueden retransmitir determinados paquetes de datos casi con prioridad, mientras que se rechazan otros paquetes de datos por ejemplo más bien en caso de sobrecarga y/o de momento se almacenan de manera intermedia. A este respecto se realiza una priorización correspondiente para el respectivo tramo de transmisión. También pueden realizarse reservas de ancho de banda en parte también extremo a extremo para todos los tramos de transmisión intermedios, realizando entonces por ejemplo encaminadores/catalogadores de tráfico para cada uno de estos tramos de transmisión la priorización resultante.

a) Retardo de transmisión/RTT

El RTT tiene, como ya se mencionó, a menudo una influencia esencial sobre la calidad de servicio resultante.

A esto pertenecen evidentemente también escenarios de aplicación como por ejemplo llamadas de teléfono VoIP, en las que para los usuarios con cada vez más retardo de transmisión se vuelve más difícil interactuar, sin interrumpirse involuntariamente.

Sin embargo, a menudo el RTT presenta en una medida sorprendente también una gran influencia sobre otros escenarios de aplicación.

Por ejemplo los protocolos (como también TCP) utilizan en parte ventanas deslizantes, es decir, por ejemplo en general una cantidad de datos máxima, que puede enviarse antes de tener que esperar una confirmación de recepción. Así, desafortunadamente en caso de un RTT elevado a menudo también se limita la tasa de transmisión máxima en por ejemplo 1x el tamaño de la ventana deslizante por RTT.

En los protocolos con frecuencia se utilizan los denominados tiempos límite. Así podría ocurrir por ejemplo, que por ejemplo con un RTT de variación muy rápida y en particular de crecimiento muy rápido los protocolos partan del hecho de que se han perdido paquetes muy retardados y por su cuenta ponen en marcha repeticiones de la transmisión. En este caso por tanto los paquetes que para su respectivo fin llegan demasiado tarde llevan en parte a reacciones similares y también a una calidad de servicio reducida de manera similar como una pérdida de paquetes.

En capas de protocolo más altas esto afecta por ejemplo también a aplicaciones de bases de datos. En las que menudo para la construcción/para la visualización de una única página de usuario en la pantalla en segundo plano tienen que realizarse muchas consultas de bases de datos (con frecuencia anidadas), en las que con frecuencia al menos en parte una consulta de bases de datos depende del resultado de la consulta de bases de datos anterior y/o muchas consultas de bases de datos sólo pueden realizarse en paralelo de manera limitada. Entonces, como resultado, para la construcción/para la visualización de una única página de usuario en la pantalla en la práctica con frecuencia puede ser necesario no sólo un RTT, sino un gran número de RTT.

Un resultado muy similar se produce con frecuencia en la navegación por la web por ejemplo en caso de utilizar HTTP. A través de HTTP se solicitan objetos de datos, que en relación con la utilización por navegadores web también pueden denominarse objetos web. Sin embargo, por regla general, una página web visualizada en la pantalla para un usuario contiene varios de estos objetos (en parte también docenas o >100) (como páginas HTML, HTML-Framesets; imágenes, hojas de estilo, secuencias de comandos; objetos de texto HTML integrados por secuencias de comandos,

datos XML, objetos JSON (“Ajax”), etc.). También en este caso un navegador web utilizado debe aprender a menudo

en primer lugar mediante evaluación de los objetos web obtenidos, qué otros objetos web son necesarios para la visualización de una página web y/o el navegador web pide sólo un número limitado de objetos web en paralelo. A este respecto a menudo tienen que interrumpirse las consultas DNS, a cuya respuesta ha de esperarse, antes de que puedan construirse las conexiones TCP. Entonces como resultado también para la navegación por la web para la construcción/para la visualización de una única página web en la pantalla en la práctica con frecuencia puede ser necesario no sólo un RTT, sino un gran número de RTT, a menudo también varios/diferentes RTT para servidores diferentes.

Como ya se describió anteriormente hay un gran número de magnitudes de influencia, que presentan efectos sobre el RTT resultante.

Una magnitud de influencia a menudo no irrelevante son las memorias intermedias de retransmisión (colas) utilizadas entre otros en los componentes de red (como encaminadores de retransmisión, catalogadores de tráfico, controladores de interfaz, etc.). Los paquetes de datos entrantes a menudo se almacenan de manera intermedia en primer lugar en colas. Mediante este almacenamiento intermedio se produce a este respecto a menudo un retardo de transmisión en parte no irrelevante, en parte incluso dramático adicional, con lo que aumenta el RTT resultante.

A menudo, a este respecto, las colas sobre todo en caso de aparecer picos de transmisión y un caso de sobrecarga general se llenan claramente más que en caso de una carga reducida. Si, por ejemplo, un encaminador utiliza para un tramo de transmisión conectado de 1 Mbit/s una cola, que puede presentar un tamaño de hasta 1 MByte, así, por ejemplo, en caso de sobrecarga a través de esta cola (con una utilización/configuración correspondiente del encaminador) podría aparecer un retardo de transmisión adicional en el orden de magnitud de 1.000.000 bytes x 8 bits/bytes/1.000.000 bits/s = 8 segundos. Sin embargo, los RTT en el orden de magnitud de 8 segundos son para por ejemplo llamadas de teléfono VoIP, pero también muchas otras aplicaciones, como también navegación por la web, una limitación considerable de la calidad del servicio.

Configuración/magnitudes de cola:

Siempre que se apliquen correspondientemente y al menos en su mayor parte se utilicen de manera continua, los procedimientos y configuraciones de cola pueden ser útiles. Así, una magnitud de cola no sólo podría configurarse como una cantidad fija de bytes, sino por ejemplo en función de la tasa de transmisión de datos del tramo de transmisión en cuestión, o directamente como un tiempo de cola máximo en lugar de una magnitud de cola en bytes. Sin embargo, ha de observarse que aun así el retardo resultante aumenta con el número de “saltos” = componentes de red por los que se ha pasado.

QoS/priorización/catalogación de tráfico:

Los procedimientos basados en QoS/priorización/catalogadores de tráfico ya mencionados anteriormente incluyendo las reservas de ancho de banda también pueden utilizarse con respecto a la utilización de cola por ejemplo en componentes de red de retransmisión. Así, por ejemplo, los paquetes a los que se va a dar prioridad ni siquiera podrían colocarse o no podrían colocarse en el extremo final de la cola y así experimentarían un retardo claramente menor.

En general se aplica en este caso, anteriormente y también a continuación en relación con la invención descrita, que estos procedimientos basados en QoS/priorización/catalogadores de tráfico incluyendo las reservas de ancho de banda para reconocer los paquetes de datos a los que se va a dar prioridad pueden utilizar muchos procedimientos diferentes. Entre éstos se encuentran las direcciones de origen/destino configuradas, paquetes marcados (por ejemplo el campo

“TOS” en cabeceras IP), determinados protocolos (por ejemplo reconocidos mediante el campo “Protocolo” en

cabeceras IP y/o números de puerto en cabeceras de protocolos de transporte), la evaluación de protocolos de señalización para determinar las direcciones de origen/destino y/o también procedimientos para el reconocimiento (heurístico) de determinadas clases de datos/aplicaciones (por ejemplo mediante intervalos/tamaños de paquetes, determinados campos como números de versión y/o sellos de tiempo, números de secuencia en cabeceras de paquetes, etc.).

c) Interrupciones de transmisión

Las interrupciones de la transmisión, es decir, periodos en los que no pueden intercambiarse paquetes de datos entre un emisor y un receptor, son otra causa potencial para la reducción de la calidad de servicio. Una interrupción de la transmisión puede afectar a una o varias capas de protocolo y percibirse en diferentes capas de protocolo de manera diferente o no de manera uniforme. En particular una transmisión de paquetes de datos (temporalmente) lenta y/o retardada y/o sujeta a pérdidas a través de las capas de protocolo más bajas en las capas de protocolo más altas puede percibirse como interrupción. Igualmente, en ciertas circunstancias una breve interrupción en las capas de protocolo más bajas incluso puede no percibirse por las capas de protocolo superiores.

La causa de interrupciones de la transmisión puede ser variada. En el caso de una transmisión de datos inalámbrica por ejemplo podría estar afectada la recepción (por ejemplo, porque el emisor y/o receptor se han alejado de la zona de recepción, han entrado obstáculos en el trayecto o también por situaciones meteorológicas tales como fuerte lluvia y/o nubosidad y/o niebla). Pero también en general podría suprimirse la red o un tramo de transmisión y/o por ejemplo debido a sobrecarga o alta carga por otros flujos de datos dado el caso de mayor prioridad puede no ser posible (de manera limitada en el tiempo) el intercambio de datos entre un emisor y un receptor. También por ejemplo unaselección del recorrido (modificada) en la red puede llevar a interrupciones. Éste puede ser el caso por ejemplo cuando un usuario móvil cambia de un punto de acceso (por ejemplo punto de acceso, mástil de radioemisión, estación base) de una red inalámbrica a otro (lo que también se denomina traspaso).

En algunos casos (como por ejemplo en el cambio de un terminal de una red de radio a otro) se produce no sólo una interrupción de la transmisión (dado el caso breve, dado el caso con zonas de red de solapamiento prácticamente no presente en el tiempo), sino un cambio del terminal de una red a otra red y así a menudo a un cambio de la dirección de red utilizada por este terminal. Para afectar, mediante un cambio de red de este tipo, lo menos posible a las aplicaciones y/o protocolos, hay procedimientos conocidos tales como IP móvil, que hacen transparentes estos cambios de red al menos parcialmente para las aplicaciones y/o protocolos utilizados. Mobile IPv4 se describe entre otros en

[8] IETF RFC 3344, Mobility Support in IPv4, C. Perkins, Ed., agosto de 2002. (IETF RFC 3775 describe Mobility Support in IPv6.)

Muchos protocolos y aplicaciones pueden salvar interrupciones de la transmisión breves, sin que se haga necesaria una intervención por el usuario y/o amplias repeticiones de la transmisión.

Sin embargo, generalmente, esto depende de determinados parámetros de protocolo y ajustes (entre otros tiempos límite).

Una interrupción de la transmisión puede tener un efecto negativo sobre una relación de comunicación entre puntos terminales, que del mismo modo entonces pueden denominarse puntos terminales de comunicación, cuando aparece:

-: después de que los puntos terminales hayan iniciado una relación de comunicación, donde mediante la interrupción de la transmisión el intercambio de datos se ve afectado o impedido al menos brevemente o

-: mientras un punto terminal intenta establecer una relación de comunicación con otro punto terminal, donde la interrupción de la transmisión de la construcción de la relación de comunicación se retarda o impide (temporal o completamente).

En ambos casos los puntos terminales pueden percibir una reducción de la calidad de servicio o una situación de error.

d) Sobrecarga de cabecera

Como se describió anteriormente los servicios de datos utilizan jerarquías de protocolos, para VoIP por ejemplo que se componen por IP, UDP y RTP, para la navegación por la web por ejemplo por IP, TCP, opcionalmente TLS/SSL y HTTP.

La jerarquía de protocolos resultante sólo de RTP, UDP, IPv4 se representa en general y a modo de ejemplo en la figura 5. La jerarquía de protocolos que se obtiene de HTTP, TCP e IPv4 se representa a modo de ejemplo en la figura

6. El “tamaño” de las capas individuales proporciona un índice general para la sobrecarga, que puede producirse por

las cabeceras de protocolo de las capas individuales.

Cada uno de estos protocolos utiliza a este respecto una propia cabecera de protocolo, que en el caso de utilizar varios protocolos o una jerarquía de cabeceras se suman muy rápidamente a una gran sobrecarga.

Aunque los tamaños de cabecera a menudo sean variables, en el caso de un paquete VoIP utilizando RTP, UDP e IPv4 solamente para estos tres protocolos por ejemplo en total puede producirse un tamaño de cabecera de 12 bytes RTP + 8 bytes UDP + 20 bytes IPv4 = 40 bytes en la suma. Adicionalmente podría considerarse que por regla general por debajo de IP se utilicen otros protocolos y por ejemplo en caso de utilizar IPv6 en lugar de IPv4 solamente la cabecera IP se aumenta de nuevo en 20 bytes más a 40 bytes. En función de la cantidad de datos útiles por paquete, se produce también de manera porcentual una sobrecarga considerable mediante las informaciones de cabecera que van a transmitirse adicionalmente a los datos útiles. Como los paquetes VoIP a menudo sólo contienen relativamente pocos datos útiles (datos de voz) (por ejemplo sólo 40 u 80 bytes), entre otros para este campo de aplicación se elaboraron posibilidades para la compresión de cabeceras y en parte también se normalizaron. Ejemplos de esto se describen entre otros en los siguientes documentos:

[9] IETF RFC 2508, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links, Casner et al. , febrero de 1999

[10] IETF RFC 3545, Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering, Koren et al., julio de 2003

[11] IETF RFC 3095, Robust Header Compression (ROHC): Framework for four profiles: RTP, UDP, ESP, and uncompressed., Bormann et al., julio de 2001

[12] IETF RFC 3544, IP Header Compression over PPP, Koren et al., julio de 2003

Compresión de cabeceras para tramos de transmisión individuales:

Las posibilidades existentes para la compresión de cabeceras se utilizan a este respecto por regla general sólo para tramos de transmisión individuales (por ejemplo en un caso sencillo entre dos encaminadores conectados directamente a través de un medio de transmisión físico o una red de capa 2). Sin embargo, en este caso reducen la sobrecarga de cabecera sólo en el tramo de transmisión correspondiente.

La compresión de cabeceras descrita en [9] (a menudo denominada CRTP), permite así por ejemplo para la utilización a través de un tramo de transmisión comprimir las cabeceras de los protocolos RTP, UDP e IP en conjunto y permite así comprimir las cabeceras situadas en la suma en un orden de magnitud de 40 de estos protocolos a un orden de magnitud de 2-4 bytes.

Compresión de cabeceras de extremo a extremo sólo de cabeceras de protocolo seleccionadas:

Alternativamente las posibilidades existentes para la compresión de cabeceras permiten sólo comprimir cabeceras individuales de las cabeceras en cuestión. Así, el documento [9] describe que alternativamente a la compresión en conjunto de RTP, UDP, IP para sólo un tramo de transmisión también puede comprimirse sólo la cabecera RTP. Siempre que sólo se comprima la cabecera RTP, esta compresión de cabeceras también puede utilizarse extremo a extremo (es decir, por ejemplo directamente de un teléfono hasta otro teléfono).

La conservación sin comprimir de las cabeceras UDP e IPv4 posibilita en este caso, que componentes de red intercalados (como por ejemplo encaminadores) puedan retransmitir los paquetes a pesar de la cabecera RTP comprimida.

Sin embargo, mediante la conservación sin comprimir de las cabeceras UDP e IPv4, por ejemplo de manera correspondiente al documento [9], se reduce la eficacia de la reducción también de manera correspondiente. En este ejemplo las cabeceras UDP e IP sin comprimir presentarían además un tamaño en el orden de magnitud de 28 bytes. Mientras que la cabecera RTP en el orden de magnitud de 12 bytes se reduce a aproximadamente 2 a 4 bytes. La eficacia del protocolo disminuye.

Sumario de la invención

El objetivo de la invención es proporcionar tecnologías mejoradas para la optimización de una transmisión de datos orientada a paquetes entre puntos terminales de comunicación en una red con puntos terminales de comunicación.

El objetivo se soluciona mediante un procedimiento según la reivindicación 1.

La optimización se dirige en particular a uno o varios de los aspectos siguientes: Reducción de los efectos de retardos de transmisión, reducción de los efectos de pérdidas de paquetes, reducción de los efectos de interrupciones de la transmisión y reducción de los efectos y/o de la sobrecarga de la transmisión de datos sobre todas o algunas de las redes utilizadas.

Como se describió anteriormente, las interrupciones de la transmisión son periodos, en los que por ejemplo desde el punto de vista de una determinada capa de protocolo no pueden intercambiarse paquetes de datos entre dos puntos terminales de comunicación, por ejemplo un emisor y un receptor. Las interrupciones de la transmisión pueden aparecer al inicio, durante o fuera de una relación de comunicación existente. Como se describió anteriormente, pueden presentar varias causas. La simulación prevista de la continuación de una relación de comunicación puede aplicarse a una relación de comunicación ya existente, pero también en particular a una relación de comunicación que va a establecerse. En este último caso a pesar de la interrupción de la transmisión se simula una iniciación de la relación de comunicación.

Una configuración preferida de la invención prevé aplicar las optimizaciones sólo para la construcción de una relación de comunicación o aplicar las optimizaciones sólo durante una relación de comunicación existente o aplicar las optimizaciones para la construcción de una relación de comunicación y durante una relación de comunicación existente.

Pueden utilizarse uno o varios mecanismos de optimización aleatorios para la aplicación.

Un aspecto adicional de la invención se refiere a un producto de programa informático con un código de programa, que opcionalmente está almacenado en un medio de almacenamiento legible por ordenador y, cuando se ejecuta en un dispositivo informático, es apto para realizar un procedimiento según al menos uno de los aspectos.

Configuraciones ventajosas de la invención son objeto de las reivindicaciones dependientes.

A continuación se explican en más detalle configuraciones ventajosas con respecto al primer aspecto de la invención.

Preferentemente, un perfeccionamiento de la invención prevé que la optimización de la transmisión de datos orientada a paquetes comprenda una etapa para retener datos del flujo de datos de la transmisión de datos orientada a paquetes.

En una configuración ventajosa de la invención puede estar previsto que la optimización de la transmisión de datos orientada a paquetes comprenda etapas para generar localmente datos en la disposición de optimizador y para enviar los datos generados localmente al punto terminal de comunicación y/o al punto terminal de comunicación adicional.

Una configuración ventajosa prevé además que los datos retenidos o generados localmente se envíen durante una interrupción de la transmisión. En una configuración ventajosa este envío durante la interrupción de la transmisión con respecto a retardo temporal y/o tasas de transmisión de datos y/o números de paquetes y/o pausas entre los paquetes puede estar configurado para salvar una duración que va a esperarse de una interrupción de la transmisión o también para poder salvarla el mayor tiempo posible y/o poder salvar sucesiones de interrupciones de la transmisión. Además puede ser ventajoso pasar los datos retenidos de manera uniforme o no uniforme durante una interrupción de la transmisión, pudiendo referirse la uniformidad y/o no uniformidad al volumen de datos pasado y/o el número de paquetes y/o los intervalos de tiempo. Una configuración ventajosa prevé determinar la cantidad de los datos pasados por unidad de tiempo en función de la cantidad retenida en total y/o la aparición de datos adicionales (cantidad por intervalo de tiempo) y/o la duración esperada o calculada o predicha de la interrupción de la transmisión. También puede ser ventajoso variar la cantidad pasada a través del tiempo.

Un perfeccionamiento preferido de la invención prevé que en el caso de estos datos retenidos desde el punto de vista de las capas de protocolo optimizadas se trate de datos útiles y/o datos de control. Un desarrollo de la invención prevé que en el caso de los datos retenidos o generados localmente desde el punto de vista del/de los protocolo/s incluido/s en la optimización se trate de datos útiles. Un desarrollo adicional de la invención prevé que en el caso de los datos retenidos o generados localmente desde el punto de vista del/de los protocolo/s incluido/s en la optimización se trate de datos de control.

Un perfeccionamiento preferido de la invención prevé también que la cantidad de datos retenidos esté adaptada a la longitud de las interrupciones de la transmisión esperadas y/o que van a tolerarse. Además un perfeccionamiento preferido de la invención es que la cantidad de datos retenidos se adapte a un retardo de retención aceptable. A este respecto un perfeccionamiento preferido de la invención es determinar y/o influir en la longitud de las interrupciones de la transmisión esperadas y/o retardos de retención aceptables mediante ajustes de configuración de los optimizadores, señales de control o valores de control, heurísticas, por ejemplo basándose en valores pasados y/o medidos en otras situaciones y/o en otras redes y/o por otros optimizadores. Otro perfeccionamiento preferido prevé que en lugar de y/o adicionalmente para retener datos por el optimizador se soliciten datos adicionales y/o se soliciten datos de manera anticipada.

Un perfeccionamiento preferido de la invención prevé que la optimización de la transmisión de datos orientada a paquetes comprenda una etapa para predecir propiedades de interrupción de la interrupción de la transmisión de la relación de comunicación.

Una configuración preferida de la invención prevé que la optimización comprenda una etapa para solicitar de manera adicional y/o anticipada datos del flujo de datos de la transmisión de datos orientada a paquetes.

A continuación se explican en más detalle configuraciones ventajosas con respecto al segundo aspecto de la invención.

En una configuración conveniente de la invención puede estar previsto que la optimización de la transmisión de datos orientada a paquetes comprenda una etapa para la compresión relacionada de cabeceras de varios paquetes de datos del flujo de datos de la transmisión de datos orientada a paquetes. En configuraciones ventajosas adicionales se comprimen varias cabeceras de un paquete de datos individual de manera relacionada o se comprime una cabecera de

varios paquetes de datos de manera relacionada. Por “compresión relacionada” se entiende la consideración en

conjunto, sucesiva o simultánea, de las cabeceras mencionadas para la compresión. Esto puede ocurrir independientemente de la relación temporal de los paquetes de datos y/o de la disposición espacial de la cabecera.

Una forma de realización ventajosa de la invención prevé que la compresión de la al menos una cabecera sólo se realice para una parte de los paquetes de datos del flujo de datos de la transmisión de datos orientada a paquetes.

Preferentemente, un perfeccionamiento de la invención prevé que la optimización de la transmisión de datos orientada a paquetes comprenda una etapa para intercambiar informaciones adicionales, que comprenden uno o varios paquetes seleccionados del siguiente grupo de paquetes: paquetes de control existentes, paquetes de control adicionales y paquetes de datos adicionales.

En una configuración ventajosa de la invención puede estar previsto que la compresión de la al menos una cabecera del al menos un paquete de datos comprenda una etapa para sustituir al menos parcialmente la al menos una cabecera por uno o varios identificadores de contexto.

Un perfeccionamiento preferido de la invención prevé que la compresión de la al menos una cabecera del al menos un paquete de datos comprenda una etapa para la compresión al menos parcial de al menos una cabecera seleccionada del siguiente grupo de cabeceras: cabecera IPv4, cabecera IPv6, cabecera de Ethernet, cabecera UDP, cabecera RTP y cabecera TCP.

En una configuración conveniente de la invención puede estar previsto que la compresión de la al menos una cabecera del al menos un paquete de datos comprenda una etapa para la inclusión de informaciones en la compresión, que se seleccionan del siguiente grupo de informaciones: información de dirección de origen e información de dirección de destino. Un perfeccionamiento conveniente puede prever que se conviertan direcciones de un tipo en direcciones de otro tipo.

Una forma de realización ventajosa de la invención prevé que la optimización de la transmisión de datos orientada a paquetes comprenda una etapa para seleccionar un algoritmo mediante el compresor para un recorrido de transmisión unidireccional entre el compresor y el descompresor.

Preferentemente, un perfeccionamiento de la invención prevé que la optimización de la transmisión de datos orientada a paquetes comprenda una etapa para la compresión de datos útiles del al menos un paquete de datos.

En una configuración ventajosa de la invención puede estar previsto que la optimización de la transmisión de datos orientada a paquetes comprenda una etapa para aplicar un procedimiento de mejora de protocolo. La aplicación de un procedimiento de mejora de protocolo puede estar prevista como perfeccionamiento ventajoso también en relación con los demás aspectos de la invención.

Un perfeccionamiento preferido de la invención prevé que la optimización comprenda una etapa para la optimización anidada de la transmisión de datos orientada a paquetes con ayuda de varios optimizadores de la disposición de optimizador.

A continuación se explican en más detalle configuraciones ventajosas con respecto al tercer aspecto de la invención.

En una configuración conveniente se aplica como optimización una compresión y se forma la disposición de optimizador con un compresor y un descompresor. La compresión puede realizarse preferentemente según una de las configuraciones descritas anteriormente en relación con el tercer aspecto de la invención.

En una configuración conveniente de la invención puede estar previsto que el reconocimiento de la posibilidad de optimización comprenda además al menos una etapa seleccionada del siguiente grupo de etapas:

-: observar pasivamente el flujo de datos de la transmisión de datos orientada a paquetes,

-: enviar activamente paquetes de datos de prueba,

-: utilizar un protocolo de señalización explícito para elementos de red en la red con puntos terminales de comunicación y

-: evaluar información de indicación de una gestión de red en la red con puntos terminales de comunicación.

Una forma de realización ventajosa de la invención prevé que la posibilidad de optimización se reconozca durante la aplicación de una optimización anterior y comprendida por un mecanismo de optimización. Esto incluye en particular el reconocimiento de otra posibilidad de optimización que la anterior; el reconocimiento de la modificación de la posibilidad de optimización; el reconocimiento, de que la optimización puede seguir aplicándose; el reconocimiento, de que la aplicación de una optimización consigue resultados mejores o peores que la anterior; el reconocimiento de la pérdidas de una posibilidad de optimización; y/o la determinación de los parámetros de una posibilidad de optimización.

En una configuración conveniente de la invención puede estar previsto que la optimización de la transmisión de datos orientada a paquetes comprenda además al menos una etapa seleccionada del siguiente grupo de etapas:

-: transmitir informaciones redundantes para al menos un paquete de datos del flujo de datos,

-: introducir una información de corrección de errores hacia delante por medio de un paquete de datos adicional en el flujo de datos de la transmisión de datos orientada a paquetes, o que opcionalmente se realiza tras una consulta,

-: añadir una información de corrección de errores hacia delante a un paquete de datos desde el flujo de datos de la transmisión de datos orientada a paquetes, lo que opcionalmente se realiza tras una consulta,

-: entrelazar para al menos una parte de los paquetes de datos del flujo de datos de la transmisión de datos orientada a paquetes y

-: restablecer al menos parcialmente un nivel de paquetes de datos para los paquetes de datos del flujo de datos de la transmisión de datos orientada a paquetes.

La transmisión redundante se produce opcionalmente como reacción a una consulta anterior. En particular una configuración ventajosa de la invención puede prever que de manera lógica entre al menos dos de los optimizadores o entre un optimizador y el punto terminal de comunicación adicional se encuentre al menos un sistema no implicado en la optimización en la/las capa(s) de protocolos considerada(s). Puede estar previsto que los optimizadores detecten una parte lo más grande posible de la transmisión de datos en la red y/o detecten la/las subzona(s) de la red, que son especialmente problemáticas para la calidad de servicio de la transmisión de datos.

Preferentemente un perfeccionamiento de la invención prevé que el reconocimiento de la posibilidad de optimización comprenda además al menos una etapa seleccionada del siguiente grupo de etapas:

-: evaluar una tasa de errores para paquetes de datos optimizados de la transmisión de datos orientada a paquetes,

-: evaluar una información de tiempo de vida para paquetes de datos de la transmisión de datos orientada a paquetes y

-: evaluar pruebas con paquetes de datos de prueba.

En una configuración ventajosa de la invención puede estar previsto que la selección de la optimización comprenda una etapa para seleccionar una compresión de cabeceras.

Un perfeccionamiento preferido de la invención prevé que esté prevista una etapa para someter a prueba cabeceras compresibles. Una configuración preferida de la invención prevé que se repita una etapa para someter a prueba sistemáticamente con cabeceras comprimidas de manera diferente. Una configuración ventajosa de la invención prevé que a partir del sometimiento a prueba de cabeceras comprimidas se concluya qué mecanismos pueden encontrar aplicación para la compresión de cabeceras.

En una configuración conveniente de la invención puede estar previsto que la optimización comprenda una etapa para la optimización anidada de la transmisión de datos orientada a paquetes de varios optimizadores de la disposición de optimizador. Un anidamiento de este tipo puede presentar preferentemente dos o más anidados. En una configuración ventajosa las disposiciones de optimizador también pueden estar dispuestas en fila/en serie y/o en paralelo. También puede ser ventajoso, combinar disposiciones de optimizador paralelas, en serie y/o anidadas. Una configuración ventajosa prevé que al menos dos optimizadores de estas disposiciones de optimizador intercambien informaciones y/o utilicen en conjunto informaciones contenidas en un flujo de datos optimizado (para al menos una de sus funciones de optimización). De este modo se forma una configuración que puede utilizarse en los diferentes aspectos de la invención.

A continuación se explican en más detalle otras configuraciones ventajosas, que pueden utilizarse en todos los aspectos de la invención.

Una forma de realización ventajosa de la invención prevé que la optimización de la transmisión de datos orientada a paquetes comprenda una etapa para aplicar el mecanismo de optimización sobre paquetes de datos seleccionados del flujo de datos, seleccionándose los paquetes de datos seleccionados incluyendo al menos un criterio de selección del siguiente grupo de criterios de selección:

-: configuración de los puntos terminales de comunicación,

-: regla de selección estática,

-: regla de selección dinámica,

-: propiedad de paquete de datos,

-: secuencia de paquete de datos e

-: información de tiempo relativa al flujo de datos.

Preferentemente, un perfeccionamiento de la invención prevé que la optimización de la transmisión de datos orientada a paquetes comprenda una etapa para la aplicación en conjunto del mecanismo de optimización a varios paquetes de datos del flujo de datos.

En una configuración ventajosa de la invención puede estar previsto que la optimización de la transmisión de datos orientada a paquetes comprenda además las etapas siguientes: determinar, si cabe esperar un fallo o interrupción de la transmisión de datos orientada a paquetes con respecto a la disposición de optimización en un trayecto de comunicación asociado al punto terminal de comunicación o en un trayecto de comunicación asociado al punto terminal de comunicación adicional, y adaptar el mecanismo de optimización al trayecto de comunicación determinado.

Un perfeccionamiento preferido de la invención prevé que la optimización de la transmisión de datos orientada a paquetes comprenda además las etapas siguientes: determinar un tipo de paquetes de datos intercambiados y adaptar el mecanismo de optimización al tipo determinado de paquetes de datos intercambiados.

En una configuración conveniente de la invención puede estar previsto que la optimización de la transmisión de datos orientada a paquetes comprenda además las etapas siguientes: determinar una carga actual para la relación de comunicación y adaptar el mecanismo de optimización a la carga determinada.

Una forma de realización ventajosa de la invención prevé que la optimización de la transmisión de datos orientada a paquetes comprenda además al menos una de las etapas siguientes: optimización unidireccional, sin canal de retorno y optimización bidireccional.

Preferentemente un perfeccionamiento de la invención prevé que la optimización de la transmisión de datos orientada a paquetes se realice combinada con al menos una etapa del siguiente grupo de etapas: procedimiento de mejora de rendimiento, compresión/descompresión de datos, cifrado de datos y transcodificación de datos.

En una configuración ventajosa de la invención puede estar previsto que la relación de comunicación se configure comprendiendo una comunicación de datos punto a multipunto o multipunto a multipunto.

Un perfeccionamiento preferido de la invención prevé que la optimización de la transmisión de datos orientada a paquetes comprenda una etapa para seleccionar un optimizador como representante para uno, varios o todos los optimizadores de la disposición de optimizador.

En una configuración conveniente de la invención puede estar previsto que la selección del optimizador comprenda una etapa para la selección dinámica temporal y/o espacial del optimizador como representante.

Una forma de realización ventajosa de la invención prevé que la optimización de la transmisión de datos orientada a paquetes comprenda una etapa para utilizar varios trayectos de red de la red para transmitir informaciones redundantes.

Preferentemente, un perfeccionamiento de la invención prevé que la optimización de la transmisión de datos orientada a paquetes comprenda una etapa para utilizar varios trayectos de red de la red para formar una distribución de carga de datos para la transmisión de datos orientada a paquetes.

En una configuración ventajosa de la invención puede estar previsto que la optimización de la transmisión de datos orientada a paquetes comprenda una etapa para utilizar varios trayectos de red de la red para transmitir informaciones redundantes.

Un perfeccionamiento preferido de la invención prevé que la optimización de la transmisión de datos orientada a paquetes comprenda una etapa para controlar una funcionalidad de optimización del mecanismo de optimización en función de señales de red.

Una configuración conveniente de la invención prevé que la comunicación entre dos optimizadores tenga lugar mediante un túnel formado por medio de otro protocolo. Una forma de realización preferida utiliza IP, UDP, TCP, IPsec, SSH, SSL, SCTP, DCCP, ICMP, HTTP, HTTP, SIP, RTSP, SOAP y/o una superposición de igual a igual como túnel.

En una configuración conveniente de la invención puede estar previsto que la optimización se aplique a redes y/o subredes y/o trayectos de comunicación difíciles, formándose las redes y/o subredes por al menos una de las redes siguientes: redes de área amplia (WAN), redes de área metropolitana (MAN, DVB-C), “redes de Internet” como redes IP

o redes con tolerancia al retardo (DTN), redes locales (LAN) como Ethernet y WLAN, redes PDH, SDH, DVB-C y/o ATM, redes de teléfono, redes de radio (como por ejemplo radiotelefonía móvil, WiMax, 3G, UMTS, HS(D)PA, DVB-T, LTE, UWB, OFDM, 802.11b/a/g/n/s, ...), redes satelitales (como por ejemplo DVB-S/S2, DVB-RCS, banda S, conexiones por satélite propietarias, redes de radio en el espacio), también en redes por cable (de difusión) (como redes por cable, DSL, fibra hasta tu casa, ...) etc., pero también redes de superposición como por ejemplo redes de igual a igual) y también combinaciones de cualquier red de diferentes tipos.

Una configuración adicional conveniente de la invención prevé que en el caso del o de los servicios de datos optimizados mediante la optimización se trate de al menos uno de los servicios siguientes: telefonía, videotelefonía y (vídeo)conferencias a través de Internet (a continuación resumido con el término “VoIP”), presentación en flujo continuo de audio/vídeo, el acceso a páginas web (“navegación por la web”), transmisión de datos basada en HTTP, transmisión

de datos basada en HTTPS, WAP, servicios web, gestión de red, accesos a un sistema de archivo, procesamiento en conjunto de documentos, presentaciones, transferencias de archivos, envío, recepción y/o procesamiento (incluyendo la eliminación, clasificación, archivo) de correo electrónico, chat, aplicaciones de igual a igual, acceso remoto al ordenador, control remoto de sistemas, etc.

Un perfeccionamiento preferido de la invención prevé que el mecanismo de optimización se realice en al menos una capa de protocolo seleccionada del siguiente grupo de capas de protocolo del modelo de capas de protocolo: capa de red, capa de transporte y capa de aplicación.

Una forma de realización ventajosa de la invención prevé que está prevista una etapa para adaptar dinámicamente el mecanismo de optimización a la transmisión de datos orientada a paquetes. En particular una adaptación dinámica puede considerar las propiedades pasadas, actuales y/o futuras que van a esperarse de la transmisión de datos orientada a paquetes y/o del trayecto de datos y/o de partes seleccionadas del trayecto de datos. Así, la optimización sólo puede aplicarse a partes del trayecto de datos. También puede adaptarse el alcance a la optimización (por ejemplo la cantidad y/o el tipo de redundancia y/o el procedimiento FEC y/o ARQ utilizado o utilizados y/o la aplicación y/o configuración de entrelazado). Además puede ser ventajoso, reconocer los tipos de paquetes de datos y/o los protocolos de comunicación utilizados y/o el tipo de relación de comunicación y adaptar la optimización según éste. Así puede estar previsto, optimizar los protocolos de transporte “fiables” (por ejemplo TCP, SCTP) de manera diferente a los “no fiables” (por ejemplo UDP, DCCP, RTP). Reconocer los flujos/paquetes de datos multimedia o flujos/paquetes

de datos RTP, RTCP, Flash, skype y/o VoIP y/o vídeo y aplicar una optimización a los mismos o adaptar la optimización a los mismos. En particular para estos flujos de datos puede estar prevista una optimización mediante procedimientos FEC.

Preferentemente un perfeccionamiento de la invención prevé que la adaptación dinámica comprenda una etapa para medir propiedades de transmisión para la relación de comunicación así como una etapa para adaptar el mecanismo de optimización en función de las propiedades de transmisión medidas. En particular pueden considerarse la tasa de pérdida de paquetes medida y/o el retardo de transmisión medido y/o la tasa de transmisión medida. El perfeccionamiento de la invención descrito en este caso puede encontrar aplicación no sólo en relación con el primero sino también con los demás aspectos de la invención.

En una configuración ventajosa de la invención puede estar previsto que la optimización de la transmisión de datos orientada a paquetes comprenda una etapa para dar prioridad a los paquetes de datos del flujo de datos de la transmisión de datos orientada a paquetes. Una configuración preferida de la invención prevé que el optimizador marque los paquetes según su prioridad. En otra configuración preferida el optimizador administra en lugar de adicionalmente al marcado de paquetes según su prioridad al menos una cola de espera propia para los paquetes de datos y lo utiliza para realizar la propia priorización de los paquetes de datos, lo que puede ocurrir antes de o durante el envío o durante/tras la recepción de los paquetes de datos. La configuración de la invención descrita en este caso puede encontrar aplicación no sólo en relación con el primero sino también con los demás aspectos de la invención.

Un perfeccionamiento preferido de la invención prevé que esté prevista una etapa para el procesamiento sin reconversión de un flujo de datos optimizado, formado en la optimización de la transmisión de datos orientada a paquetes a través de un punto terminal de comunicación de recepción. En particular las informaciones redundantes pueden complementarse o formarse y/o transmitirse de tal manera que para el punto terminal de comunicación de recepción no pueda distinguirse un flujo de datos no optimizado de paquetes de datos. También puede estar previsto que las informaciones redundantes se complementen o formen y/o transmitan de tal manera que al menos partes de las informaciones redundantes a través del punto terminal de comunicación de recepción no se perciban o no se perciban como molestas.

En una configuración conveniente de la invención puede estar previsto que la optimización de la transmisión de datos orientada a paquetes comprenda una etapa para la compresión de una o varias cabeceras para uno o varios paquetes de datos del flujo de datos de la transmisión de datos orientada a paquetes. En particular puede estar previsto que la cantidad de informaciones redundantes transmitidas se seleccione de tal manera que no sobrepase o no sobrepase esencialmente la cantidad de los datos ahorrados por la compresión, pudiendo realizarse la comparación para un paquete individual, para varios paquetes en conjunto y/o por un intervalo de tiempo.

Según las diferentes configuraciones de la invención en sus diferentes aspectos un dispositivo o un sistema para una transmisión de datos orientada a paquetes puede estar previsto entre puntos terminales de comunicación en una red con puntos terminales de comunicación, que dispone de una disposición de optimizador, que está configurada para realizar un mecanismo de optimización para la transmisión de datos orientada a paquetes según un procedimiento en una de las configuraciones mencionadas anteriormente.

Descripción de ejemplos de formas de realización preferidas de la invención

A continuación se explican en más detalle los aspectos de la invención mediante ejemplos de formas de realización haciendo referencia a las figuras de un dibujo. A este respecto muestran:

la figura 1, con respecto a las optimizaciones descritas a continuación en I. una representación esquemática de varios sistemas para la transmisión de datos entre dos puntos terminales A y B así como disposiciones de optimizadores,

la figura 2, con respecto a las optimizaciones descritas a continuación en I. una representación esquemática de varios sistemas para la transmisión de datos entre dos puntos terminales A y B para escenarios de aplicación especiales en los que puede utilizar la optimización introducida directamente del punto terminal B y/o los protocolos y/o aplicaciones utilizados en el mismo, sin necesidad de un optimizador X-2,

las figuras 3 y 4, con respecto a las optimizaciones descritas a continuación en II. las representaciones

esquemáticas como en las figuras 1 y 2, aunque con una configuración específica de los “optimizadores” como “compresor” y “descompresor” y las “optimizaciones” descritas anteriormente como “compresiones”, como un

desarrollo específico de una optimización, que también puede enlazarse de manera aleatoria con otras optimizaciones y sus disposiciones,

la figura 5, en general una jerarquía de protocolos para RTP, UDP e IP y

la figura 6, en general una jerarquía de protocolos para HTTP, TCP e IP.

A continuación se representan en detalle aspectos de la invención, pudiendo ser importantes las características de los diferentes aspectos tanto de manera individual como en cualquier combinación en la realización de la invención en sus diferentes formas de realización. En particular los diferentes aspectos dan lugar en cada caso en sí mismos a una mejora esencial del estado de la materia.

Para simplificar la representación a continuación se habla de “optimización (optimizaciones)” como función y/o

procedimiento, que se realiza por los componentes de sistema mencionados en cada caso. Un optimizador puede ser

un componente, que introduce una optimización en los datos intercambiados (entendiéndose por “introducir” en este

caso y a continuación también la realización general de una optimización en los datos intercambiados). De manera análoga en las disposiciones y los ejemplos de formas de realización mencionados hay uno o varios componentes de optimizador, que evalúan/utilizan la optimización introducida y en la mayoría de los casos restablecen el flujo de datos original por completo o con frecuencia en grandes partes y/o restablecen el efecto semántico deseado del flujo de datos previsto originalmente con frecuencia en grandes partes. La comunicación con el/los dos componentes de optimizador se describe a continuación sólo en cada caso para una dirección de comunicación, para hacer la descripción más clara. Evidentemente también es posible la optimización en el sentido opuesto, siempre que lo requieran las aplicaciones y redes de transmisión, parezca ventajoso y/o la disposición y/o componentes estén configurados de manera correspondiente.

Desde el punto de vista de puntos terminales que se comunican un optimizador puede ser un componente de una parte constitutiva de las relaciones de comunicación conocida para uno de los puntos terminales, por ejemplo un

encaminador, un servidor, un proxy u otro sistema intermedio, o puede intervenir “de manera transparente” en las

relaciones de comunicación, es decir sin que tenga que comunicarse su existencia a los puntos terminales o también sólo tenga que ser conocida. Los puntos terminales que se comunican se denominan de manera sinónima también puntos terminales de comunicación. A continuación para simplificar se utiliza la denominación punto terminal.

Un optimizador puede estar distribuido en varios componentes lógicos y/o físicos. Un optimizador también puede ser parcial o completamente parte constitutiva de uno o varios de los sistemas terminales o puede realizarse en uno o varios de los sistemas terminales. En particular un optimizador o una parte del mismo como software y/o hardware puede convertirse en parte constitutiva adicional de otros componentes de sistema (encaminadores, servidores, proxys, sistemas intermedios, etc.).

Desarrollos específicos de optimizaciones (y los optimizadores que las realizan) son por ejemplo compresión de cabeceras (realizada mediante compresores adecuados), optimizaciones de transmisión para el manejo de retardos, pérdidas de paquetes y/o interrupciones. Estas formas según la invención de estas optimizaciones se describen más abajo. Pueden realizarse individualmente o en cualquier combinación.

En este texto los términos paquete y paquete de datos se utilizan como sinónimos y también independientemente de si en un paquete/paquete de datos están presentes datos útiles y/o informaciones de control. Estos paquetes de datos siguen un recorrido/trayecto de transmisión (también denominado trayecto de comunicación, trayecto de datos o brevemente trayecto), que por ejemplo se ha seleccionado de manera dinámica por un protocolo de encaminamiento en la capa de red, se ha configurado de manera estática o se ha determinado de otro modo. De un punto terminal al otro un trayecto de este tipo lleva con frecuencia por uno o varios sistemas intermedios (por ejemplo encaminadores, nodos de red, proxys) y a este respecto por una o varias redes de transmisión. Un trayecto puede ser simétrico: entonces los paquetes recorren de un punto terminal A al otro punto terminal B los mismos sistemas intermedios que los paquetes del punto terminal B al punto terminal A, sin embargo en orden inverso. O el trayecto puede ser asimétrico, cuando se distinguen los sistemas intermedios que se recorren en sentidos opuestos. Una simetría de este tipo también puede observarse, a un nivel más general, para redes de transmisión. Un trayecto está compuesto en el

caso más sencillo por una sucesión de tramos/tramos de transmisión (en inglés: “hops”), conectando entre sí un tramo

dos sistemas intermedios contiguos en el nivel de abstracción considerado en cada caso (por ejemplo con respecto a una capa de protocolo). Una subzona o la totalidad de varias subzonas, también sin relación, de una sucesión de este tipo se denomina igualmente trayecto. Un trayecto también puede contener varios trayectos alternativos, que potencial

o realmente se siguen en cada caso por una parte de los paquetes de datos que siguen el trayecto. En este texto se utilizan como sinónimos también el término trayecto de comunicación o trayecto de datos en lugar de y de manera equivalente al término trayecto.

Existe la posibilidad de que para la relación de comunicación entre dos puntos terminales A y B existan uno o varios trayectos de comunicación difíciles (SKP). Un trayecto de comunicación difícil es una parte constitutiva de los trayectos de comunicación entre A y B, cuyas propiedades en ciertas circunstancias con un empeoramiento pueden influir en la calidad de servicio alcanzable, como se describió anteriormente en los ejemplos de retardo de transmisión, pérdidas de paquetes e interrupciones. Estas propiedades del trayecto de comunicación pueden remitirse a las propiedades de un componente de red individual y/o de un tramo de red individual y/o a la combinación de las propiedades de varios componentes de red y/o tramos de red; en particular ninguno de los componentes de red/tramos de red implicados debe dar lugar en sí mismo ya un trayecto de comunicación difícil. En el recorrido de A a B pueden encontrarse ningún, un o varios trayectos de comunicación difíciles. Con respecto a cada uno de estos trayectos de comunicación difíciles los optimizadores, que con respecto a flujos de datos posibles o reales se encuentran preferentemente en el lado dirigido hacia el punto terminal A del trayecto de comunicación difícil considerado en cada caso, pueden desempeñar otro papel que los optimizadores, que con respecto a flujos de datos posibles o reales se encuentran preferentemente en el lado dirigido hacia el otro punto terminal B del trayecto de comunicación difícil considerado en cada caso.

La invención se refiere a optimizaciones para servicios de datos y/o servicios de nombres. Para una mejor lectura del documento las siguientes realizaciones están divididas en dos apartados principales, que consideran aspectos de la invención complementarios y que pueden combinarse entre sí de manera aleatoria: I. Optimizaciones generales para el manejo de pérdidas de paquetes, retardos de transmisión elevados (RTT), interrupciones etc., así como II. Optimizaciones adicionales mediante compresión de cabeceras de protocolo.

I. Optimizaciones generales

La división realizada en este apartado en a), b) y c) sirve para estructurar mejor el apartado. Sin embargo, no tiene que respetarse obligatoriamente y algunos aspectos se tratan abarcando varios apartados o en contra de esta división ya en otros apartados.

En la figura 1 y la figura 2 se representan algunas posibles disposiciones para la aplicación de las tecnologías según la invención y se explican a continuación.

Las figura 1 y la figura 2 muestran varias configuraciones de sistema según la invención con dos puntos terminales A y B que se comunican, que pueden ser el origen y/o sumidero para datos útiles. Los dos puntos terminales están

conectados entre sí a través de una sucesión de redes de transmisión. “Conectados” significa que A y B pueden

intercambiar paquetes de datos. Estos paquetes de datos siguen un trayecto/trayecto de comunicación (también denominado brevemente trayecto), que por ejemplo se ha seleccionado de manera dinámica por un protocolo de encaminamiento en la capa de red, se ha configurado de manera estática o se ha determinado de otro modo.

La figura 1 y la figura 2 muestran además a modo de ejemplo diferentes puntos en algunos sistemas intermedios y/o los puntos terminales, en los que los optimizadores pueden realizar optimizaciones. En detalle:

La figura 1 a) representa una disposición con dos puntos terminales (A y B) y dos optimizadores separados de los mismos (X-1 y X-2). Los puntos terminales envían y reciben paquetes de datos sin modificación. Los paquetes de datos enviados por un punto terminal (por ejemplo de A a B) pueden capturarse por X-1 y optimizarse antes de su retransmisión a X-2, de modo que para la red de transmisión N-X puede utilizarse la optimización O1. Los paquetes de datos optimizados se reconocen por X-2, en caso necesario se aprovecha la optimización y los paquetes de datos se restablecen en gran parte o totalmente en su forma original (como se enviaron por A) y a continuación se transmiten a

B. Con respecto a la función que va a realizarse en total para B los paquetes de datos enviados a través de X-2 no pueden distinguirse o no pueden distinguirse esencialmente de los enviados por A o no tienen que distinguirse especialmente de éstos. La optimización de los paquetes de datos en el tramo de trayecto a través de la red N-X es transparente para los puntos terminales. La optimización puede aplicarse a todos los paquetes de datos y/o todos los paquetes de datos, que se intercambian entre dos o más puntos terminales y/o dos o más instancias mediante una determinada aplicación y/o en el marco de una relación de comunicación.

Se indica que en este caso y en general para una mejor lectura en el texto se habla de manera simplificada de

“paquetes de datos optimizados”. Sin embargo, aquí no sólo entra una adaptación por paquete de datos, sino también

en general cualquier adaptación del flujo correspondiente a paquetes de datos. Esto puede producirse de varias maneras por ejemplo mediante modificación de los paquetes individuales, modificación de paquetes seleccionados, introducción de paquetes adicionales u otra transmisión de informaciones adicionales, pero también por ejemplo mediante un tratamiento especial y/o priorización y/o retardo menor (por ejemplo mediante puesta en cola) y/o también un retardo controlado y/o supresión y/o duplicación/multiplicación y/o una de las otras optimizaciones de los paquetes descritas a continuación. También se habla de una transmisión transparente para los puntos terminales (o por ejemplo las aplicaciones correspondientes) o paquetes de datos restablecidos en su mayor parte o similar cuando en la relación de optimización correspondiente se refiere sólo a los datos útiles transmitidos (es decir, entre otros, no necesariamente a informaciones de control de los protocolos y/o límites de paquetes implicados).

En la figura 1 b) uno de los optimizadores (X-1) está integrado en un punto terminal (A). Las funciones lógicas del punto terminal A y el optimizador X-1 pueden no estar modificados. De este modo no es necesario ningún componente externo en el lado de A, y desde el punto de vista de la optimización O1 las redes de transmisión N-A y N-X coinciden. Cómo se produce la integración de X-1 en A, corre a cuenta de la implementación local. Es concebible que las dos funciones también estén realizadas independientemente entre sí, por ejemplo que un proceso independiente y/o un controlador del sistema operativo implemente la función de optimización. También es posible que una tarjeta insertable y/o el firmware en la unidad sobre la placa realicen estas funciones. Como anteriormente el optimizador puede ejecutarse para una, varias y/o todas las aplicaciones y/o una, varias y/o todas las relaciones de comunicación de una, varias y/o todas las aplicaciones. La pieza complementaria (el optimizador X-2) corresponde al de la figura 1 a).

La figura 1 c) representa una disposición, en la que ambos optimizadores X-1 y X-2 están integrados en los puntos terminales, como acaba de describirse para el optimizador X-1. Las realizaciones para el optimizador X-1 se aplican de manera análoga al optimizador X-2. Las realizaciones en los dos puntos terminales pueden corresponder entre sí o estar configuradas distintas en partes o totalmente.

La figura 1 d) muestra una disposición, en la que entre los puntos terminales A y B tienen lugar dos optimizaciones independientes entre sí (O1 y O2) de manera secuencial en diferentes tramos de red (N-X1 y N-X2). Los paquetes de datos enviados por el punto terminal A se transmiten en primer lugar a través de la red de transmisión N-A al optimizador X1-1 y a continuación se optimizan por el optimizador X1-1. Los paquetes de datos optimizados se envían a través de la red de transmisión N-X1 al optimizador X1-2 y se reciben por el mismo y se restablecen parcial o totalmente y a continuación se transmiten a través de la red M al optimizador X2-1. Aquí vuelven a optimizarse los paquetes de datos y se envían a través de la red NX2 al optimizador X2-2, que recibe los paquetes de datos y los retransmite parcial o totalmente restablecidos al punto terminal B. Las dos optimizaciones O1 y O2 pueden utilizar los mismos procedimientos y algoritmos o procedimientos y algoritmos parcial o totalmente diferentes, que operan sobre los mismos y/o (en parte) diferentes (partes de) paquetes y/o cabeceras de paquetes y/o datos útiles o datos de control.

Mientras que en la figura 1 d) sólo se representan dos optimizaciones independientes entre sí, en una disposición concreta puede estar presente cualquier número de tales optimizaciones. También el mismo optimizador puede estar implicado en más de una optimización. Por ejemplo, los optimizadores X1-2 y X2-1 pueden estar implementados en el mismo sistema, no estando presente entonces de hecho ninguna red de transmisión M. Además el número de optimizaciones puede variar con el trayecto seleccionado a través de la red de transmisión o las redes de transmisión: entre dos puntos terminales A y B esto puede ocurrir por ejemplo temporalmente cuando por ejemplo debido a las decisiones de encaminamiento cambia el trayecto durante una relación de comunicación existente. Correspondientemente a la figura 1 b) y la figura 1 c) también uno o varios de los optimizadores pueden estar integrados en los puntos terminales.

En lugar de una disposición secuencial los optimizadores también pueden estar dispuestos en paralelo. Éste puede ser el caso por ejemplo (como acaba de describirse), cuando cambia la selección del recorrido a través de la red/las redes, pero también cuando el encaminamiento divide los paquetes de datos de una relación de comunicación en varios trayectos (por ejemplo para la distribución de carga en el marco de la ingeniería de tráfico). En tal caso diferentes paquetes de datos adoptan diferentes recorridos y pueden verse afectados por diferentes optimizaciones; también puede ser que sobre por ejemplo uno de estos trayectos no se realice ninguna optimización.

Como se muestra en la figura 1 e), dos o más optimizaciones pueden estar anidadas. En la disposición representada la red de transmisión N-X2 se rodea por los optimizadores X2-1 y X2-2, que realizan la optimización O2. El tramo de red compuesto por las redes de transmisión N-X1a, N-X2 y N-X1b se rodea por los optimizadores X1-1 y X1-2, que implementan la optimización O1. Como la optimización O2 se produce dentro de O1, los optimizadores X2-1 y X2-2 trabajan con paquetes de datos parcialmente optimizados. Un paquete de datos P, que se envía por un punto terminal A, se transmite en primer lugar sin optimizar a través de la red de transmisión N-A y a continuación se optimiza en el optimizador X1-1 según la optimización O1. El paquete de datos así optimizado P’ (también en este caso y a continuación de manera análoga el flujo de datos optimizado) se envía entonces a través de la red de transmisión N-X1a al optimizador X2-1. El optimizador X2-1 realiza ahora una optimización adicional O2, de la que sale el paquete de datos P”. Para esta optimización O2 puede recurrirse a los mismos y/u otros criterios que para O1. En O2 pueden utilizarse los mismos y/u otros algoritmos que en O1. El paquete de datos P’’ se transmite a través de la red de transmisión N-X2 y se recibe por el optimizador X2-2, reconstruyéndose P’ o un paquete de datos que corresponde esencialmente a partes de P’. Este paquete de datos reconstruido se transmite entonces a través de la red de

transmisión N-X1b al optimizador X1-2. Éste recibe el paquete de datos y reconstruye así un paquete de datos, que corresponde a P totalmente o en partes esenciales. Este paquete de datos reconstruido por X1-2 se transmite entonces al punto terminal B a través de la red N-B.

Con referencia a la figura 1 e) para O2 la optimización O1 puede mantenerse completamente y/o incluso quedar sin interpretar por los componentes X2-1 y/o X2-2 total/parcialmente. Alternativamente por ejemplo X2-1 también podría suprimir la optimización O1 total o parcialmente o al menos interpretarla, para por ejemplo en combinación con los procedimientos aplicados para O2 utilizar algunos aspectos ya optimizados en O1 por ejemplo de manera más eficaz u optimizarlos de manera más eficaz para los siguientes tramos de red/redes y/o para ambos procedimientos utilizar algunos de los aspectos de optimización total o parcialmente en conjunto. Aunque en la figura 1 e) sólo se represente un anidamiento sencillo de optimizaciones, el número de optimizaciones anidadas en principio no está limitado. También pueden estar presentes optimizaciones secuenciales, como se ha descrito con referencia a la figura 1 d), en cada nivel de anidamiento. Y pueden estar implementados optimizadores de diferentes anidados en un sistema, es decir, por ejemplo X1-1 y X2-1 coinciden (suprimiéndose entonces prácticamente la red de transmisión N-X1a). Además pueden estar implementados optimizadores individuales o varios optimizadores directamente en puntos terminales (de manera análoga a la figura 1 b) y la figura 1 c). Como se describe con respecto a la figura 1 d), la composición de los optimizadores puede cambiar temporal y/o espacialmente; también varias optimizaciones pueden operar en paralelo.

En las siguientes descripciones se indica que algunas de las configuraciones de la invención también pueden realizarse según la figura 2 con opcionalmente sólo un componente de optimizador en un lado (en la figura 2 optimizador X-1). De manera análoga a las disposiciones en la figura 1 a este respecto el optimizador X-1 puede estar integrado en el punto terminal (figura 2 b)) o estar dispuesto separado del punto terminal en el trayecto de datos de los paquetes en la red (figura 2 a)). En estos casos también son posibles por ejemplo optimizaciones múltiples con varios optimizadores utilizados sólo en un lado y/o en combinación con pares de componentes de optimizador como se describe por ejemplo en la figura 1.

Las disposiciones mencionadas anteriormente y representadas en la figura 1 y la figura 2 sólo se muestran a modo de ejemplo y deben entenderse como ilustración. Son posibles cualquier combinación de estas disposiciones y las disposiciones derivadas de ello. Aunque a continuación se hable por ejemplo de disposiciones según la figura 1 y/o la figura 2, también se hace referencia a las disposiciones combinadas y derivadas a partir de ello.

En particular por motivos de claridad sólo se representan dos instancias que se comunican en las figuras 1 y 2. No obstante, del mismo modo también pueden aparecer más de dos instancias como orígenes y/o sumideros de datos útiles y/o como emisor y/o receptor de informaciones de control.

Según escenarios de aplicación concretos, requisitos generales y/o redes seleccionadas también puede ser ventajoso, permitir la comunicación de puntos terminales/componentes de sistema individuales o en grupo en primer lugar utilizando procedimientos de optimización con instancias intermedias seleccionadas y a partir de aquí funcionar con

otros puntos terminales/componentes de sistema “externos” sin procedimientos de optimización, con otros

procedimientos de optimización o sólo con una parte de las optimizaciones utilizadas. Estas instancias intermedias se utilizarían entonces casi como pasarela. En última instancia tales escenarios de aplicación se atribuirán no obstante a combinaciones o ligeras ampliaciones de las disposiciones representadas en la figura 1 y la figura 2.

Las aplicaciones pueden transmitir en todas las disposiciones datos útiles de manera unidireccional y/o bidireccional. Del mismo modo redes individuales, algunas redes y/o todas las redes pueden estar diseñadas para la transmisión unidireccional y/o bidireccional.

Una red de transmisión o red tal como se representa en la figura 1 y/o la figura 2 puede estar compuesta por varios/muchos tramos de transmisión con sistemas intercalados (puentes, conmutadores, encaminadores, pasarelas, proxys, etc.), puede estar compuesta sólo por tramos de transmisión individuales (por ejemplo una línea “interconectada” o una conexión física directa mediante cable eléctrico, conductor de fibra óptica, acoplamiento acústico, ondas electromagnéticas, etc.), aunque también puede estar compuesta por varias subredes conectadas entre sí (que por ejemplo utilizan el protocolo de Internet). Del mismo modo las redes mostradas también pueden estar compuestas por conexiones locales o una red local (en particular, éste será el caso con frecuencia en la red N-A y N-B, aunque también puede afectar a las demás redes).

Las redes explicadas anteriormente pueden ser cualquier red (por ejemplo redes IP, redes con tolerancia al retardo (DTN), redes locales como Ethernet y WLAN, redes PDH, SDH y/o ATM, redes de teléfono, redes de radio (como por ejemplo radiotelefonía móvil, WiMax, 3G, UMTS, HS(D)PA, DVB-T, LTE, UWB, OFDM, 802.11b/a/g/n/s, ...), conexiones por satélite (como por ejemplo DVB-S/S2, DVB-RCS, conexiones por satélite propietarias, redes de radio en el espacio), también en redes por cable (de difusión) (como redes por cable, DSL, fibra hasta tu casa, ...) etc., pero también redes de superposición como por ejemplo redes de igual a igual) y también combinaciones de cualquier red de diferentes tipos. Las funciones de optimización no están limitadas a la utilización mediante protocolos de una determinada capa, aplicación y/o tipo de aplicación, aunque pueden serlo, o especialmente estar diseñadas para ello. Las optimizaciones pueden funcionar en/para capas individuales o también abarcando varias capas. La optimización puede depender de las peculiaridades de las redes de alrededor o de los trayectos a través de la red y/o de la función y/o la existencia de determinados elementos de red: así, por ejemplo, una función de optimización puede funcionar de otra manera cuando los paquetes en su recorrido tienen que pasar por otros elementos de red como encaminadores, NAT y/o cortafuegos. Diferentes optimizaciones (y optimizadores) pueden estar adaptadas entre sí y/o funcionar independientemente una de otra.

A continuación se explican aspectos de la invención más en detalle. Sin embargo ha de tenerse en cuenta que también se han descrito ya anteriormente configuraciones y aspectos de la invención que pueden utilizarse, tomados por sí solos y/o en combinación con uno/varios de los siguientes (sub)aspectos.

I.a) Reducción de los efectos de pérdidas de paquetes

Como se describió anteriormente, las pérdidas de paquetes presentan a menudo efectos negativos sobre la calidad de servicio resultante. Sin embargo, los procedimientos conocidos para la reducción de los efectos de las pérdidas de paquetes sobre la calidad de servicio presentan entre otros la desventaja, de que o bien presuponen una codificación de contenido determinada modificada o recodificada (lo que, entre otros, requiere un cálculo intenso y para los optimizadores utilizados presupone que implementan procedimientos correspondientes para la codificación de contenido y/o incluso los presupone, que los optimizadores han implementado las codificaciones de contenido concretas utilizadas por una aplicación) y/o que las optimizaciones se utilizan específicamente para y con ayuda de un protocolo de capa de enlace (por ejemplo de un enlace de radiotelefonía móvil, de un enlace por satélite, etc.). Sin embargo, para la calidad de servicio resultante depende en total de la transmisión a través de toda la red. Además, en muchos casos en la realización de un servicio no es posible integrar componentes de optimizador en cualquier punto de una red, es decir, por ejemplo en ambos lados de un tramo de transmisión determinado utilizado en el trayecto de datos (por ejemplo debido a limitaciones/posibilidades de acceso/entrada administrativas y/o técnicas).

Por tanto, es ventajoso realizar optimizadores que también puedan utilizarse en su mayor parte independientemente de tramos de transmisión/protocolos de capa de enlace individuales y también en su mayor parte independientemente de una codificación de contenido seleccionada y/o las aplicaciones y/o terminales utilizados. También es ventajoso, que los optimizadores realizados puedan realizar su optimización al menos opcionalmente también en su mayor parte sin estar separados de medidas de soporte administrativas amplias de la red como las reservas de ancho de banda de extremo a extremo.

Por tanto, partiendo de las disposiciones descritas en la figura 1 y la figura 2 o derivadas de las mismas puede realizarse una optimización según la invención por ejemplo mediante los optimizadores X-1 y X-2, que en su mayor parte pueden disponerse de manera libre en el trayecto de datos entre los puntos terminales A y B.

A este respecto el objetivo puede ser abarcar una parte lo más grande posible de la red con la optimización O1.

Sin embargo, en función del escenario de aplicación concreto también puede ser suficiente incluir zonas de red especialmente problemáticas en la optimización O1.

Igualmente en función de escenarios de aplicación concretos a la inversa también puede ser útil no incluir determinadas zonas de red y/o enlaces individuales en la optimización O1, por ejemplo cuando la optimización O1 lleva a un aumento del volumen de transmisión y por ejemplo determinadas zonas de red y/o enlaces individuales precisamente por este aumento del volumen de transmisión provocarían de manera aumentada pérdidas de paquetes. Por ejemplo, esto podría realizarse con una disposición más similar a la representada en la figura 1 d). En este caso, las optimizaciones O1 y O2 pueden ser opcionalmente idénticas por completo, en parte y/o estar diseñadas específicamente según las zonas de red N-X1 y N-X2 abarcadas por las mismas.

Por tanto la optimización según la invención realizada por los optimizadores puede introducir por ejemplo redundancia como corrección de errores hacia delante en los datos transmitidos. Esto puede producirse independientemente de las aplicaciones utilizadas concretas, independientemente de las codificaciones de contenido concretas e independientemente de los procedimientos de FEC dado el caso existentes en los protocolos de capa de enlace de tramos de transmisión individuales, evidentemente de manera opcional la optimización introducida también puede funcionar conjuntamente con uno y/o varios procedimientos de FEC integrados en y/o realizados por estos otros componentes y/o aprovecharse del conocimiento/reconocimiento de estos procedimientos.

Así, en el ejemplo de VoIP y en una disposición según la figura 1 a) por ejemplo la conversación de VoIP podría realizarse con una calidad de servicio mejorada, aunque una red N-X sujeta a pérdidas de paquetes en el trayecto de datos se encuentra entre los puntos terminales A y B. Para conseguir este aumento de la calidad de servicio, se utilizan los optimizadores X-1 y X-2. Así, por ejemplo, X-1 recibiría desde el punto terminal A paquetes de datos de VoIP, añadir redundancia de FEC (o bien en los paquetes o bien como paquetes/informaciones de control adicionales) y retransmitir los paquetes de datos resultantes a través de la red N-X. El optimizador X-2 recibe el flujo de datos optimizado, puede compensar todas o al menos partes de las pérdidas de paquetes producidas mediante la evaluación de la redundancia de las redundancias de FEC y retransmite todo o casi todo el flujo de datos al punto terminal B total o parcialmente restablecido.

En el caso de la red N-X podría tratarse por ejemplo de Internet. Y los optimizadores X-1 y X-2 en cada caso en la retransmisión/recepción de los datos a partir de redes de empresas o redes domésticas N-A y N-B podrían introducir/evaluar en Internet N-X la optimización O1.

La red N-X podría ser por ejemplo también un acceso a Internet utilizado en conjunto por varios usuarios y/o aplicaciones por ejemplo a una zona activa pública de Internet (o también zonas activas de Internet especiales como se ofrecen en trenes, aviones, etc.). Aquí, dado el caso, precisamente en este acceso a Internet utilizado en conjunto aparecen con más frecuencia pérdidas de paquetes. Mientras que también en este caso en principio pueden utilizarse todas las disposiciones mostradas en la figura 1, este escenario de aplicación puede describirse bien mediante la disposición de la figura 1 b). Entonces, el terminal A podría ser por ejemplo un portátil, que a través de WLAN y una zona activa en conjunto con otros usuarios y/o aplicaciones propias utiliza un acceso a Internet. Cuando este acceso a Internet está sobrecargado y esto lleva a pérdidas de paquetes, el usuario del terminal A por ejemplo para sus datos de VoIP (y/o todos sus datos de aplicación con respecto al punto terminal B) puede introducir redundancias de FEC con ayuda de un optimizador X-1 (que por ejemplo está realizado localmente sobre su portátil) en sus flujos de datos. El optimizador X-2 se encuentra o bien de todos modos en el trayecto de datos al punto terminal B o bien por ejemplo el optimizador X-1 por ejemplo mediante direccionamiento de destino adecuado de los paquetes generados garantiza que los paquetes generados se retransmitan a través de N-X a X-2. Entonces, por ejemplo X-2 podría encontrarse por ejemplo en la red doméstica del usuario del punto terminal A, o en la red de empresa del usuario del punto terminal A, o el optimizador X-2 se hace funcionar por un proveedor de servicios, que así permite a los usuarios de servicios (como en este ejemplo al usuario del punto terminal A), transmitir sus datos con la optimización O1 a X-2. Entonces por ejemplo X-2 se une por ejemplo a una red de transmisión N-B, a través de la que puede alcanzarse el punto terminal B. Opcionalmente, en el caso de la red N-B también podría tratarse (de nuevo) de Internet, a donde se proporcionan (de vuelta) los datos restablecidos total/parcialmente utilizando O1 y a continuación pueden alcanzar el punto terminal B.

Cuál de los procedimientos de FEC conocidos o desarrollados también especialmente se utilizan para la generación de redundancia, puede seleccionarse en la realización por ejemplo mediante la capacidad de la CPU, los requisitos de memoria, las tasas de pérdida de paquetes esperadas y/o medidas de manera dinámica, la sobrecarga tolerada generada por las redundancias de FEC y no en última instancia en función del retardo adicional generado potencialmente por la evaluación de los procedimientos de FEC en el optimizador recibido en su mayor parte adaptado libremente al escenario de aplicación concreto. Además de procedimientos de FEC más complejos como por ejemplo procedimientos basados en matrices de Vandermonde, en este caso también son concebibles por ejemplo procedimientos basados en XOR muy sencillos.

Para escenarios de aplicación así como para la aplicación de ejemplo VoIP según el escenario de aplicación concreto podría ser útil no generar obligatoriamente paquetes de datos adicionales para la FEC (entre otros, porque los paquetes de datos adicionales por regla general también requieren cabeceras adicionales y así generan una sobrecarga adicional). Aquí podría ser adecuado agregar las informaciones de redundancia de FEC total y/o parcialmente a los paquetes de datos individuales, por ejemplo de VoIP.

Según el escenario de aplicación también puede ser ventajoso, diseñar las informaciones de redundancia de FEC introducidas de tal manera, que también puedan utilizarse directamente por uno de los puntos terminales (por ejemplo

el punto terminal B) o por la aplicación implicada y “evaluarse”. Con esto, en una configuración según la invención no

quiere decirse que por ejemplo las aplicaciones utilizadas implementen directamente de extremo a extremo las informaciones de redundancia de FEC en por ejemplo sus protocolos de transmisión de aplicación. Más bien, con ello se hace referencia a la introducción de informaciones de redundancia de FEC mediante un optimizador X-1 separado en su mayor parte de la aplicación como se muestra por ejemplo en las figuras 2 a) y b).

El optimizador X-1 en muchos escenarios de aplicación en el caso más sencillo puede enviar los paquetes de datos entrantes por duplicado (o más en general siempre y/o con por ejemplo pérdidas de paquetes que se producen, determinadas de manera dinámica, por duplicado o más en general de manera múltiple). Como muchos protocolos de transmisión (entre otros el protocolo IP ampliamente utilizado) no aseguran que los paquetes durante la transmisión no se dupliquen o multipliquen, muchos protocolos de recepción y aplicaciones toleran (dado el caso, ignoran) paquetes recibidos por duplicado. Así, adicionalmente a las disposiciones de la figura 1 también se hacen posibles disposiciones según la figura 2, en las que opcionalmente sólo se utiliza un componente de optimizador X-1. Aun así por ejemplo en caso de duplicación de paquetes según el escenario de aplicación y por ejemplo posibilidades de disposición administrativas y/o técnicas también puede ser útil utilizar un optimizador X-2, que antes de la retransmisión a través de redes posteriores al punto terminal B vuelva a revertir las duplicaciones de paquetes para ahorrar capacidad de

transmisión en las redes/tramos de red siguientes (siempre que ya no se hayan “revertido” total/parcialmente por

pérdidas de paquetes producidas).

Aprovechando el conocimiento de los protocolos utilizados para la transmisión la introducción de redundancias puede realizarse convenientemente a menudo también de modo que se produzca menos sobrecarga de lo que es posible en una mera operación a nivel de paquete sin consideración de los protocolos individuales. Esto puede ilustrarse nuevamente en el ejemplo de VoIP. Muchas aplicaciones de VoIP utilizan el protocolo RTP para la transmisión de datos (véase también [6]). RTP se utiliza por regla general por encima de UDP e IP, por tanto los paquetes RTP en comparación con el volumen a menudo relativamente reducido de los datos de voz contenidos en un RTP presentan una sobrecarga de cabecera de RTP, UDP, IP, etc. muy elevada. Al mismo tiempo los paquetes de RTP contienen sellos de tiempo y una parte de datos de voz (parte de datos útiles) de tamaño variable. Por tanto, una realización según la invención en un escenario de aplicación con por ejemplo VoIP y RTP podría introducir redundancia en RTP, en el que el optimizador X-1 en cada paquete de datos de RTP recibido por el punto terminal A introduce de nuevo antes de los datos útiles recibidos nuevos también los datos útiles del paquete de datos de RTP recibido anteriormente (es decir, envía por ejemplo la cantidad de datos útiles doble por RTP) y adapta los sellos de tiempo (que en el ejemplo de RTP indican por ejemplo el sello de tiempo de los primeros datos útiles contenidos en un paquete) de manera correspondiente. Una realización correspondiente generaría claramente menos sobrecarga que una duplicación completa de los paquetes de RTP. Al mismo tiempo las implementaciones de aplicación y/o protocolo de RTP VoIP a menudo entenderían sin problemas también sin la utilización de un optimizador X-2 estos paquetes de RTP modificados e independientemente (en su mayor parte de manera transparente) podrían utilizar las informaciones de redundancia entrantes para compensar pérdidas de paquetes. Por tanto, también en este ejemplo son posibles también disposiciones según la figura 2.

En caso de no saber si está disponible un optimizador X-2 para la interpretación (reconversión) del flujo de datos optimizado durante la duración de la relación de comunicación optimizada, entonces el optimizador X-1 también puede configurar el flujo de datos optimizado de tal manera que las informaciones necesarias para la optimización sólo sean “visibles” para el optimizador X-2, aunque no se perciban por el punto terminal B (en el ejemplo anterior). Para ello por ejemplo las informaciones necesarias para la optimización pueden transmitirse en paquetes separados y éstos direccionarse por ejemplo de otro modo (por ejemplo al optimizador X-2). Las informaciones necesarias para la

optimización también pueden estar “escondidas” en los paquetes determinados para el punto terminal B. Por ejemplo en una jerarquía de protocolos un paquete “más grande” de una capa (por ejemplo de la capa de red) puede contener un paquete “más pequeño” de una capa más alta (por ejemplo la capa de transporte), concretamente de modo que tras el “fin” del paquete de la capa de transporte todavía haya espacio para informaciones adicionales. En la capa de red puede tratarse en particular de IP (por ejemplo IPv4 o IPv6), en la capa más alta de IP, UDP, TCP, ICMP, DCCP, SCTP así como otros protocolos de transporte o tunelización basados en IP.

En cada uno de estos casos de aplicación puede producirse una configuración estática por ejemplo de la cantidad de las informaciones de redundancia introducidas y/o una adaptación dinámica por ejemplo con respecto a una tasa de pérdida de paquetes medida y/o estimada de manera dinámica. Además de la cantidad de informaciones de redundancia introducidas también opcionalmente por ejemplo puede modificarse y/o cambiarse el procedimiento de FEC utilizado en sí mismo.

Según el escenario de aplicación puede ser ventajoso, reducir las pérdidas de paquetes como optimización y/o parte de una optimización también mediante repeticiones de la transmisión (por ejemplo según un protocolo de ARQ). A este respecto por ejemplo pueden utilizarse los protocolos basados en ARQ habituales como TCP y por ejemplo entre otros con este fin tunelizar los paquetes que van a transmitirse mediante una y/o varias conexiones de TCP. Sin embargo, por ejemplo también sería posible y según el escenario de aplicación ventajoso, concebir para ello por ejemplo protocolos especiales y/o integrar esta funcionalidad en los protocolos utilizados por los optimizadores.

También puede ser ventajoso según el escenario de aplicación utilizar una combinación de repeticiones de la transmisión (como el procedimiento de ARQ) y utilizar el procedimiento de FEC. Así, por ejemplo, un optimizador receptor de un flujo de datos optimizado podría evaluar en primer lugar las informaciones FEC y para el caso de que aun así no se hayan recibido o restablecido todos los paquetes/informaciones, solicitar una correspondiente repetición de la transmisión.

Como las repeticiones de la transmisión, cuando se hacen necesarias, llevan a menudo a un retardo adicional, según el escenario de aplicación puede ser ventajoso, realizar una optimización correspondiente por ejemplo sólo para redes/subredes y/o tramos de transmisión, que presentan tasas de errores de transmisión relativamente altas y/o en general tasas de pérdida de paquetes relativamente altas. Por tanto también puede ser ventajoso, por ejemplo realizar individualmente optimizaciones basadas en repeticiones de la transmisión para redes/subredes y/o tramos de transmisión individuales y dado el caso así combinar varias optimizaciones, por ejemplo para este fin de manera secuencial similar a lo que muestra la figura 1 d). También puede ser ventajoso según el escenario de aplicación por ejemplo utilizar una optimización basada en repeticiones de la transmisión para una red/subred y/o tramo de transmisión (esto podría ser por ejemplo en una disposición según la figura 1 e) la optimización O1) y utilizar una optimización que por ejemplo la sobrepasara por encima de ésta (esto podría ser por ejemplo en una disposición según la figura 1 e) la optimización O2). Según el escenario de aplicación podría ser ventajoso que se utilizaran optimizaciones basadas en repeticiones de la transmisión en redes/subredes y/o tramos de transmisión con un RTT al menos relativamente pequeño. Entre otros ante estos antecedentes también puede ser ventajoso, combinar un procedimiento/disposición correspondiente con los procedimientos descritos en b) para la reducción de los RTT.

Siempre que como parte constitutiva de la optimización se utilicen repeticiones de la transmisión/procedimientos de ARQ, según el escenario de aplicación puede ser ventajoso por ejemplo realizar la solicitud de repeticiones de la

transmisión sólo cuando el retardo que resulta de ello y/ el que cabe esperar no adquiere un tamaño “inaceptable”. A partir de cuándo un retardo de transmisión es de un tamaño “inaceptable” depende entre otros del escenario de aplicación concreto y/o los protocolos utilizados y/o las aplicaciones. Los valores límite correspondientes por ejemplo podrían configurarse, medirse, derivarse de los protocolos y/o aplicaciones utilizados y/o sus parámetros. También podrían indicarse de manera absoluta y/o relativa (por ejemplo en relación con un RTT).

Como entre otros mediante repeticiones de la transmisión y/o la utilización de informaciones FEC para el restablecimiento de paquetes que faltan y/o la puesta en cola y/u otros mecanismos durante la transmisión puede cambiarse el orden de los paquetes, según el escenario de aplicación puede ser ventajoso introducir un número de secuencia y/o sellos de tiempo en la optimización y/o utilizarlos de cabeceras existentes. En este caso para un optimizador que recibe y retransmite el flujo de datos optimizado puede ser ventajoso restablecer al menos parcialmente el orden de paquetes en la transmisión. Para la reducción de retardos de transmisión según el escenario de aplicación puede ser ventajoso transmitir determinados paquetes de datos/determinadas informaciones a través de otros recorridos de transmisión (redes/subredes y/o tramos de transmisión). Por ejemplo podría ser ventajoso que estos otros recorridos de transmisión presentaran un RTT relativamente corto y/o tasas de pérdida de paquetes reducidas, por ejemplo porque de este modo los optimizadores que reciben los flujos de datos optimizados obtienen estas informaciones más rápido por ejemplo en caso de pérdidas de paquetes que se producen y así se retarda menos la transmisión de los paquetes y/o informaciones (restablecidos). Por motivos similares también puede ser ventajoso según el escenario de aplicación, transmitir determinados paquetes de datos/determinadas informaciones (como por ejemplo FEC y/o repeticiones de la transmisión) con una prioridad más alta y así, por ejemplo, reducir el retardo de transmisión y/o las tasas de pérdida para estos paquetes de datos/informaciones.

Según el escenario de aplicación puede ser ventajoso, relacionar la optimización y/o sus procedimientos utilizados de manera interna a relaciones de comunicación individuales, grupos de relaciones de comunicación y/o también todo el flujo de datos.

I.b) Reducción de retardos de transmisión

Como se describió anteriormente, a menudo una parte constitutiva esencial de los retardos de transmisión en la transmisión conmutada por paquetes se produce por la acumulación de paquetes en colas de espera en cuellos de botella. Estas colas de espera se producen con frecuencia en elementos de red y/o capas de implementación, sobre las que puede influirse poco directamente con respecto a la realización de algoritmos de QoS adecuados. Un optimizador, que se encuentra en un trayecto antes del cuello de botella, a menudo puede contribuir a evitar o limitar tal estado, al aplicar por ejemplo los procedimientos descritos anteriormente de optimización, es decir, por ejemplo al suprimir, reordenar, retener o comprimir paquetes, o también influir de otro modo en el flujo de datos de tal manera que por ejemplo el comportamiento de los sistemas terminales implicados contribuya a una regulación de las colas de espera.

A este respecto una dificultad es la falta de información del optimizador sobre el estado actual del cuello de botella, como por ejemplo la tasa de transmisión de bits alcanzable, el tamaño actual y la estructura de la cola de espera, los algoritmos de priorización utilizados así como la proporción del flujo de datos que pasa por el optimizador con respecto al flujo de datos total a través del cuello de botella y el comportamiento (y el comportamiento que cabe esperar adicionalmente) de la proporción que no pasa por el optimizador. A este respecto puede ser ventajoso que el optimizador mediante observaciones de los flujos de paquetes determine un conocimiento, aunque también con frecuencia incompleto, posterior sobre estos parámetros de estado. Por ejemplo el optimizador podría medir tasas de transmisión de bits y/o a partir de la aparición de repeticiones de la transmisión (o, en caso de utilizar ECN según RFC

3168, señales relacionadas tales como “congestión experimentada” o eco de ECN y CWR en el nivel de transporte)

deducir propiedades de transmisión y/o utilizar otras señales de realimentación como la realimentación de RTCP o ROHC y a partir de aquí deducir por ejemplo que a partir de determinadas tasas de transmisión de bits se producen pérdidas provocadas por congestión. Del mismo modo puede ser ventajoso que el optimizador utilice mensajes sobre el desarrollo del RTT, para su relación con la tasa de transmisión de bits observada e influida y a partir de aquí determinar parámetros del cuello de botella. Además puede ser ventajoso que el optimizador incluya el comportamiento que cabe esperar de los sistemas terminales en su predicción, por ejemplo puede evitarse una repetición de la transmisión que cabe esperar mediante la priorización a tiempo de un paquete de datos, y/o también puede influirse sobre la misma de manera controlada, por ejemplo mediante la supresión de repeticiones de la transmisión innecesarias y/o mediante la supresión y/o el retardo de paquetes de ACK o de datos y una detención de este modo controlada de un emisor, que por ejemplo amenaza con sobrecargar el cuello de botella.

Otras medidas de optimización ventajosas según el escenario de aplicación de un optimizador y/o en combinación con este procedimiento utilizado como prebúsqueda de HTTP pueden controlarse (mediante control de la iniciación, pero también mediante control del respectivo desarrollo de las conexiones de transporte de accesos individuales) de tal manera, que la capacidad predicha del cuello de botella en cada caso por ejemplo se convierta en lo mejor posible, pero no se aproveche demasiado, al mismo tiempo a este respecto también podrían obtenerse informaciones adicionales sobre el cuello de botella. Finalmente según el escenario de aplicación puede ser ventajoso que el optimizador sondee activamente el cuello de botella mediante comunicación con una estación remota también sin utilización de red directo de la transmisión de datos iniciada, por ejemplo con las técnicas de ICMP mencionadas anteriormente (petición de eco/respuesta de eco, “ping”) y/o también agregando informaciones combinadas a los datos útiles y/o mediante la utilización de una/varias interfaces de gestión, diagnóstico y/o medición con uno y/o varios/todos los elementos de red implementen las colas y/o las originen y/o puedan retransmitir informaciones correspondientes. Muchas de estas medidas pueden realizarse con una observación/influencia unidireccional como también con una observación/influencia bidireccional de en cada caso al menos una parte de los datos que fluyen a través del cuello de botella.

Medidas individuales y/o combinaciones de las mismas pueden utilizarse por un optimizador para influir en la cola de espera producida antes de un cuello de botella y así en total conseguir una mejora de la calidad de servicio. A este respecto según el escenario de aplicación podrían utilizarse especificaciones adecuadas (por ejemplo, un RTT deseado máximo o también otro objetivo a partir de valores característicos tales como una combinación de tasa de pérdida, RTT y varianza/variabilidad de RTT, que por ejemplo según la ecuación de Padhye-Firoiu lleva a determinados valores de tasa de transmisión de conexiones TCP). Sin embargo, el objetivo según el escenario de aplicación también puede ser en cada caso poner a disposición de no (sólo) la suma de los flujos de datos y/o grupos de flujos de datos, sino dado el caso sólo/también flujos de datos preferidos (como VoIP hablado de manera interactiva) la calidad de servicio necesaria con una fiabilidad mayor de lo que sería posible sin estas medidas.

Por tanto, por ejemplo partiendo de las disposiciones descritas en las figuras 1 y 2 o derivadas de las mismas una optimización según la invención puede realizarse por ejemplo mediante los optimizadores X-1 y X-2, que en su mayor parte pueden disponerse libres en el trayecto de datos entre los puntos terminales A y B. Por ejemplo en la disposición representada en la figura 1 a) los dos optimizadores optimizan en conjunto la utilización de un cuello de botella en la red N-X. Por ejemplo a este respecto X-1 y/o X-2 podrían utilizar un algoritmo realizado posiblemente distribuido para la obtención de parámetros caracterizadores relevantes del/de los cuello(s) de botella en la red N-X. Así, X-1 y X-2 pueden enviarse mutuamente paquetes de sondeo activos y/o sobre paquetes ya enviados disponer informaciones combinadas y a este respecto estimar por ejemplo el RTT y dado el caso también su desarrollo.

En caso de observar sin limitación de la generalidad como uno de los muchos posibles ejemplos de realización el recorrido de A a B y la cola de espera que se produce en este recorrido en N-X, entonces X-1 puede incluir la entrada y X-2 la salida de paquetes de datos en los cálculos y así emitir un mensaje mejorado sobre el tamaño actual de la(s) cola(s) de espera. La salida que se hace visible en X-2 de paquetes de datos puede proporcionar por lo demás mensajes sobre la tasa de transmisión de bits alcanzable y la tasa de pérdida de paquetes actual. X-1 puede reaccionar a los parámetros caracterizadores determinados en conjunto con X-2 influyendo (por ejemplo mediante retardo, supresión, duplicación, reordenación, reescritura de los campos de paquetes, por ejemplo modificación de la ventana ofrecida) sobre los paquetes de datos enviados en la dirección hacia delante (en el ejemplo descrito por tanto del punto terminal A a B). X-2 también puede hacerlo; sin embargo, entonces la influencia se transmite indirectamente por los retornos de B a A; estas influencias pueden influir tanto B como A aún directamente.

Según el escenario de aplicación puede ser ventajoso que un optimizador en una configuración alternativa o en combinación con uno/varios de los procedimientos mencionados anteriormente también utilice acuses de recibo/realimentación y/o informaciones (por ejemplo sobre informaciones de cola de componentes posteriores y/o anchos de banda para tipos/grupos individuales de flujos de datos. Estas informaciones podrían indicar por ejemplo cuántos bytes pueden enviarse para determinados tipos de datos y/o en general aún por ejemplo a componentes posteriores sin por ello provocar una puesta en cola, o para por ejemplo provocar una puesta en cola relativamente reducida y/o en relación con informaciones siguientes sobre tamaños de cola y/o niveles en ese momento y que por ejemplo resultan o existen según el tipo de datos y/o la prioridad. Tipos de transmisión e interfaces ventajosos para este intercambio de información/esta realimentación podrían ser informaciones de control locales/transmitidas y/u otras interfaces como por ejemplo las utilizadas en el sistema operativo de Linux con frecuencia por los controladores /interfaz de sistema de archivos proc.

I.c) Reducción de los efectos de las interrupciones de transmisión

Como se describió anteriormente, con frecuencia las interrupciones de transmisión tienen como consecuencia la pérdida y/o el retardo de paquetes de datos, lo que puede afectar al establecimiento y/o el desarrollo y/o la finalización de una relación de comunicación. Puede aparecer un retardo por ejemplo cuando los paquetes enviados durante la interrupción de la transmisión por ejemplo se almacenaron de manera intermedia en un encaminador (es decir su cola), hasta que ha pasado la interrupción de la transmisión. Un almacenamiento intermedio de este tipo se refiere no obstante en general sólo a (relativamente) pocos paquetes y a un periodo de interrupción (relativamente) corto. A su vez, las pérdidas de paquetes pueden tener efecto sobre el retardo de transmisión, cuando por ejemplo se utiliza un protocolo de transporte fiable y/o que mantiene el orden (por ejemplo TCP, SCTP). En caso de que la interrupción dure más que un intervalo de tiempo determinado (por ejemplo a través del protocolo de transporte y sus parámetros) (tiempo límite), puede ocurrir que la relación de comunicación se finalice por el protocolo correspondiente. Entre otros cuando esto se produce por debajo del protocolo de aplicación (por ejemplo en la capa IP o de transporte), se extrae del protocolo de aplicación a menudo la base de comunicación, y la relación de comunicación entre las aplicaciones no se inicia o no puede continuarse o debe reinstaurarse de nuevo posteriormente (tras la pérdida de la interrupción).

También una nueva dirección de un participante de la comunicación puede llevar a la interrupción (temporal) o a la suspensión de una relación de comunicación.

A lo largo del tiempo se propusieron diferentes soluciones para conservar la relación de comunicación de la aplicación, aunque se modifique la dirección de red o aparezca una interrupción de la transmisión. Para ello por ejemplo pueden utilizarse sistemas intermedios (según el escenario de aplicación podrían ser por ejemplo los optimizadores en sí mismos y/o componentes/procedimientos utilizados combinados con los mismos y/o por ejemplo pero no obligatoriamente implementarse en los mismos aparatos que los optimizadores). A este respecto entonces a menudo la relación de comunicación visible o transparente para la aplicación, se divide en varios tramos. Este modo de proceder se denomina a menudo división de conexiones o también conexión dividida, cuando se aplica en la capa de transporte

o aplicación; sin embargo, la invención aquí descrita no se limita a conexiones, ni siquiera tienen que reconocerse conexiones como tales, sino que, como se explica en parte adicionalmente más abajo, también pueden utilizarse paquetes, capas de enlace u otras tramas u otras unidades de información transmitidas como base. A este respecto pueden considerarse en conjunto relaciones de comunicación individuales o también grupos de relaciones de comunicación. Los procedimientos ventajosos descritos a continuación para la invención según el escenario de aplicación se aplican para todas las disposiciones de las figuras 1 y 2 y combinaciones aleatorias de las mismas (es decir, entre otras también para el caso de que exista un optimizador). La división en varios tramos puede producirse en cualquier capa del modelo de referencia OSI. A menudo una división de este tipo tiene lugar en la capa de IP, HIP, transporte o de aplicación. Puede utilizarse una solución según la invención en una y/o varias capas.

Las soluciones que acaban de indicarse prevén por ejemplo que el al menos un optimizador X proteja el tramo de un optimizador a un punto terminal frente a posibles interrupciones de la transmisión del optimizador X a otro optimizador y/o a otro punto terminal. Así, por ejemplo según la figura 2 a) puede conservarse una conexión de transporte (por ejemplo TCP) entre el punto terminal A y el optimizador X-1 y/o entre el optimizador X-2 y el punto terminal B, aunque se interrumpa la conexión de transporte entre los optimizadores X-1 y X-2.

Mientras que este modo de proceder permite conservar principalmente la relación de comunicación en una o varias capas, al conservar por ejemplo como en IP móvil las direcciones IP, actualizar como en HIP las direcciones de contacto o conservar como en la división de conexión TCP las conexiones de transporte en los tramos a un/los punto(s) terminal(es), sin embargo este procedimiento para aplicaciones a menudo es insuficiente. Porque las aplicaciones y/o los protocolos de aplicación y/o los servicios de nombres utilizados por las aplicaciones para resoluciones de nombres disponen de ventanas de tiempo propias (tiempos límite). En caso de que una operación (por ejemplo una consulta) iniciada por una instancia de una aplicación (por ejemplo en un punto terminal A) no se finalice en esta ventana de tiempo (por ejemplo mediante una respuesta correspondiente), esta operación puede declararse como fallida, dado el caso tras uno o varios intentos repetidos. Entonces, dado el caso, no se consigue el efecto deseado, y en tal caso puede presentarse al usuario un aviso de error. Por ejemplo en la utilización de un navegador web para llamar a una página web puede proporcionarse el mensaje de que el nombre del servidor es desconocido y/o que el servidor en ese momento no está accesible y/o que no puede encontrarse o cargarse una página. En otros casos la página web solicitada puede visualizarse de manera incompleta (por ejemplo falta texto, faltan imágenes). En tales casos de error se delega la responsabilidad para la nueva carga de una página web en principio disponible en el usuario: puede decidir iniciar de nuevo la operación correspondiente (dado el caso de manera repetida), y puede decidir cuándo y con qué frecuencia lo intentará. Lo que se describió anteriormente para páginas web, puede aplicarse del mismo modo para otras aplicaciones y también puede afectar a aplicaciones que se ejecutan en segundo plano y no disponen de una interfaz de usuario.

Los procedimientos descritos a continuación en muchos escenarios de aplicación pueden solucionar el problema de que las operaciones no comiencen o se interrumpan de manera anticipada total o parcialmente, y así pueden llevar en general a una mejora de la operabilidad y/o del funcionamiento y/o de la eficacia y/o de la efectividad de las aplicaciones de comunicación y/o de la calidad de servicio.

En una disposición según la invención a modo de ejemplo un optimizador (por ejemplo X1) obtiene informaciones (por ejemplo datos útiles o informaciones de control) en el marco de una o varias relaciones de comunicación de un tramo (por ejemplo X1-X2 en la red de transmisión N-X), por ejemplo de otro optimizador u otro punto terminal, y retransmite estas informaciones a través de otro tramo (por ejemplo A-X1) a un punto terminal (por ejemplo A). Para evitar que una aplicación durante una interrupción temporal tras el transcurso de una ventana de tiempo interrumpa una operación y/o una secuencia de operaciones, el optimizador no retransmite todas las informaciones, una vez que están a disposición. En su lugar el optimizador transmite las informaciones sólo de manera retardada, de modo que (por ejemplo antes de finalizar una operación) todavía queden partes de las informaciones en el optimizador. En caso de que aparezca una interrupción de la transmisión, el optimizador puede retransmitir estas informaciones restantes en unidades pequeñas de manera aleatoria (bits y/o bytes y/o secuencias de bits y/o secuencias de bytes y/o paquetes y/o secuencias de paquetes y/o fragmentos de paquetes y/o secuencias de fragmentos de paquetes y/o tramas y/o secuencias de tramas) a los puntos terminales. Esto puede llevar a que la aplicación en el punto terminal se suministre permanentemente con informaciones, de modo que para la misma no sea visible ninguna interrupción de la transmisión, sino que por ejemplo sólo exista una transmisión más lenta. De este modo puede evitarse que se dispare un tiempo límite, porque la aplicación recibe informaciones de manera continua. Este mecanismo puede producirse en una o varias capa(s) de protocolos aleatoria(s) (en particular, pero no de manera limitada en la capa 2 y/o 3 y/o 3,5 y/o 4 y/o 5 y/o 6 y/o 7).

En la retransmisión de informaciones puede ser ventajoso que la retransmisión no se produzca en bits o bytes individuales u otras unidades mencionadas anteriormente, sino que la estructura siga a las capas de protocolo másaltas. Éstas pueden ser las estructuras de datos (por ejemplo, formatos de paquetes, formatos de datos, operadores, parámetros, consultas, respuestas, documentos de HTML, XML y/u otros documentos, etc.) y/o cabeceras y/o datos útiles. En caso de que por ejemplo una aplicación utilice conjuntos de datos propios o que la comunicación se produzca en unidades enteras de estos datos, en algunos casos puede ser útil o incluso necesario, retransmitir estos conjuntos de datos en su totalidad. En otros casos puede ser necesario retransmitir estos conjuntos de datos sólo por partes. También puede ser necesarias o ventajosas combinaciones. En qué casos es adecuado qué modo de proceder depende de las aplicaciones y/o los protocolos de aplicación.

Puede ser ventajoso que al menos uno de los optimizadores genere informaciones adicionales para la retransmisión al punto terminal y las introduzca en la sucesión de las informaciones retransmitidas. Para ello puede ser necesario un conocimiento sobre los protocolos utilizados en las capas en cuestión. Por ejemplo pueden introducirse elementos de “ninguna operación” específicas de la aplicación (NOP, No-Operation), cuando el protocolo lo permite. También pueden introducirse elementos vacíos (por ejemplo secuencias de líneas en blanco = CRLF y/o caracteres en blanco en HTTP, por ejemplo antes de que comience una nueva respuesta).

En caso de que un protocolo prevea un tiempo límite ajustable y/o negociable puede ser ventajoso que un optimizador lo modifique mediante la generación de elementos de protocolo adecuados y/o mediante la complementación, modificación y/o retención selectiva correspondiente de informaciones retransmitidas. Por ejemplo en caso de aparecer una interrupción de la transmisión puede ajustarse un tiempo límite superior. A este respecto puede seleccionarse un tiempo límite nuevo de modo que corresponda a la duración esperada de retardo de interrupción o sea superior. Puede establecerse en un valor fijo o determinado de otro modo de manera dinámica. También puede adaptarse de manera correspondiente a las informaciones que van a retransmitirse aún disponibles en el al menos un optimizador. La selección puede determinarse también mediante cualquier combinación de un, algunos o todos los parámetros mencionados anteriormente y/u otros.

Puede ser ventajoso que el optimizador genere elementos de protocolo (por ejemplo como respuesta a una consulta y/o como comunicación y/o propia consulta), que comunican al punto terminal, que éste durante una ventana de tiempo determinada no debe realizar consultas adicionales (por ejemplo una cabecera de reintento posterior). La determinación de la ventana de tiempo puede producirse como se describió anteriormente.

Puede ser ventajoso que el optimizador genere y complemente elementos de protocolo y/o contenidos y/o modifique y/o complemente de manera correspondiente informaciones retransmitidas, que comunican a la aplicación y/o al usuario, que están en marcha una determinada operación.

Puede ser ventajoso que en estos contenidos se trate de secuencias de comandos y/o partes de programa y/o indicaciones, etc. que pueden interpretarse en el sistema terminal y/o realizarse de otro modo.

Los mecanismos descritos anteriormente también pueden utilizarse en caso de que en el momento en el que una aplicación quiere establecer una relación de comunicación, exista una interrupción. Así, el optimizador mediante la interpretación local de al menos uno (una parte) de los protocolos utilizados (por ejemplo del protocolo de transporte y opcionalmente también de los protocolos de aplicación/seleccionados) puede simular la iniciación de una relación de comunicación y de este modo proteger la aplicación frente a una interrupción existente. Así los optimizadores que implementan división de conexión pueden realizar por ejemplo una conexión entrante (por ejemplo conexión TCP) según la división de conexión, la retransmisión de la conexión y en última instancia una relación de comunicación completa entre A y B, pero por ejemplo realizar un retardo o dado el caso intento repetido, hasta que la interrupción ya no está presente. Según los protocolos utilizados, de manera similar los optimizadores que no operan según el procedimiento de división de conexión por ejemplo mediante la captura de paquetes y dado el caso el envío de paquetes de respuesta propios y repeticiones de paquetes, pueden simular por ejemplo la iniciación de una conexión o alargar el intervalo de tiempo, antes de que los protocolos implicados partan de una no iniciación de la conexión.

Puede ser ventajoso, a) predecir la duración que va a esperarse de una interrupción de la transmisión y/o b) la inminencia de una interrupción de la transmisión o al menos intentarlo. Anteriormente ya se describieron ejemplos para la utilización del caso a). El caso b) puede ser ventajoso para por ejemplo no siempre retransmitir informaciones de manera retardada, sino para recopilar sólo informaciones para la retransmisión retardada en al menos un optimizador aunque exista demanda de tales informaciones almacenadas en memoria intermedia, porque si no dado el caso puede disminuir el rendimiento de la relación de comunicación.

Por tanto puede ser útil incluir posibles informaciones sobre la probabilidad de una interrupción de transmisión o su final esperado. Por ejemplo en el caso de redes de radio una tasa de transmisión de datos en disminución o, en caso de estar disponible, también otros indicios como el nivel de señal en disminución (por ejemplo la intensidad de señal y/o la relación señal a ruido, SNR) puede indicar una interrupción inminente y/o un nivel en aumento, su final. También podrían utilizarse como ayuda GPS y/o indicadores de movimiento. También podrían utilizarse como ayuda heurísticas como valores de movimiento y/o valores de tiempo y/o cambios de red del pasado. También sistemas externos podrían indicar una interrupción de la transmisión inminente o potencialmente inminente o dar indicaciones sobre su probabilidad. Además valores de experiencia del pasado (que por ejemplo se almacenan en uno de los optimizadores) pueden dar indicaciones importantes. Las propias redes de transmisión implicadas o los mapas (digitales) con informaciones sobre la cobertura de red) también podrían dar indicaciones. Lo mismo también podría realizarlo un usuario en al menos algunos casos. Informaciones individuales, algunas informaciones y/o todas estas informaciones y/u otras pueden combinarse para realizar tales predicciones.

Como ya se ha descrito anteriormente en partes, la invención puede utilizarse de manera unidireccional y/o bidireccional. En caso de una utilización bidireccional las dos direcciones de transmisión pueden operarse independientemente o dependientemente una de otra. La operación independiente y/o dependiente puede referirse a paquetes de datos individuales, relaciones de comunicación individuales y/o a grupos de relaciones de comunicación y esta referencia o la operación independiente y/o dependiente puede modificarse a lo largo del tiempo una vez y/o repetidamente.

En caso de que para la comunicación entre los optimizadores sólo esté disponible un recorrido de transmisión unidireccional, entonces los optimizadores mediante la selección adecuada de algoritmos y/o informaciones de control transmitidas adicionalmente pueden encargarse de que los optimizadores recibidos puedan interpretar el flujo de datos optimizado y/o los paquetes de datos entrantes de manera optimizada y/o retransmitirlos de manera correspondiente. Para ello, podría emplearse por ejemplo la utilización de procedimientos FEC meramente (a menudo en cualquier caso) unidireccionales, la determinación de anchos de banda disponibles sin presuponer protocolos bidireccionales por ejemplo PING y/o también la utilización de recorridos de transmisión alternativos en dirección de retorno, que se utilizan sólo para unos pocos datos y/o sólo para informaciones de control.

Los optimizadores pueden integrarse en muchos escenarios de aplicación de manera ampliamente transparente en el trayecto de datos, es decir las aplicaciones no necesitan conocerlos ni direccionar obligatoriamente por tanto los paquetes de datos directamente a los optimizadores. Sin embargo, alternativa y/o adicionalmente, los optimizadores también podrían funcionar como proxy. Un ajuste de proxy lo soportan muchas aplicaciones como por ejemplo navegadores a menudo sin modificación de la aplicación en sí y sin trabajos de configuración muy complejos. También está previsto para algunas aplicaciones un reconocimiento de proxy automático, de modo que el propio proxy (o sus direcciones) no siempre debe configurarse directamente en las aplicaciones. Los protocolos utilizados para el reconocimiento de proxy automático permiten también en parte que optimizadores y/o componentes externos indiquen a las aplicaciones automáticamente, por ejemplo directamente, los optimizadores como proxy, de modo que dado el caso no es necesaria por ejemplo al menos por aplicación ninguna configuración de proxy manual. Estos procedimientos también permiten a menudo una reconfiguración de los proxys por ejemplo en caso de avería, como compartición de carga y/o para introducir los flujos de datos de manera controlada en otros proxys y/o por otras redes.

Según el escenario de aplicación puede ser ventajoso tunelizar el intercambio de datos entre los componentes (en particular también entre optimizadores implicados como por ejemplo X-1 y X-2 en la figura 1) mediante protocolos adicionales. Para ello son adecuados un gran número de protocolos conocidos y opcionalmente también diseñados especialmente para ello o combinaciones de ambos. Por ejemplo, la comunicación podría conducirse a través de un túnel TCP de una o varias conexiones TCP paralelas, también la utilización por ejemplo del protocolo IPsec y/o IPsec Nat Traversal puede ser ventajosa, especialmente pueden realizarse al mismo tiempo procedimientos adicionales como el cifrado. También puede ser ventajosa una tunelización de paquetes en diferentes protocolos del plano de red (por ejemplo tunelizar paquetes IPv6 a través de paquetes/redes IPv4) (por ejemplo cuando los optimizadores también soportan IPv6, sin embargo potencialmente (partes de) la red entre optimizadores sólo soporta(n) IPv4; lo mismo se aplica en escenarios similares o también inversos). También para la tunelización de paquetes de diferentes protocolos del plano de red son posibles protocolos conocidos así como también diseñados especialmente. A este respecto puede

producirse una correspondiente “tunelización” también muy indirectamente, por ejemplo intercambiando sólo al inicio de

las relaciones de comunicación reconocidas informaciones de dirección. Cuando comienza por ejemplo una nueva relación de comunicación IPv6, los optimizadores proporcionan para ello por ejemplo un número de identificación y por ejemplo sólo comunican inicialmente a otro optimizador este número de identificación junto con las correspondientes direcciones de origen y/o de destino. En este ejemplo, en una de muchas configuraciones el protocolo de túnel entre los optimizadores podría basarse en IPv4, mientras que para las relaciones de comunicación reconocidas internamente en el protocolo de túnel también se intercambian informaciones de dirección IPv6 (y/o similares o también en escenarios inversos).

También puede ser ventajoso según el escenario de aplicación, basar los protocolos utilizados entre optimizadores por ejemplo adicionalmente en UDP. La utilización de UDP podría servir en este caso por ejemplo para que un optimizador pueda instalarse y ejecutarse en ordenadores (por ejemplo ordenadores portátiles) más fácilmente también como proceso de usuario típico incluso cuando el usuario/instalador y/o el optimizador durante su ejecución posterior no tiene ningún derecho de administrador sobre este PC (al mismo tiempo esto puede servir para aumentar la seguridad de los ordenadores implicados, por ejemplo en caso de eventuales agujeros de seguridad en el optimizador en sí mismo,

puesto que, por ejemplo, códigos maliciosos/virus… ejecutados a través de los optimizadores tampoco pueden en este

caso acceder directamente con derechos de administrador al/a los ordenador(es) en cuestión). Además la utilización de protocolos correspondientes, en particular protocolos de túnel, puede posibilitar y/o simplificar que los datos intercambiados también puedan intercambiarse más allá de cortafuegos y/o traductores de dirección de red (NAT).

Según el escenario de aplicación hay para los optimizadores muchas estrategias potenciales que incluirán paquetes y/o flujos de datos en la optimización. Para ello los optimizadores pueden reconocer por ejemplo de manera autónoma paquetes y/o flujos de datos de diferentes protocolos y/o a este respecto recibir instrucciones de y/o ser ayudados por componentes externos a través de informaciones de control/señales de control y/o marcado de los propios paquetes. Son posibles para ello muchos procedimientos. Se consideran por ejemplo los ya mencionados anteriormente:

configuración de direcciones de origen/destino, marcado de los paquetes (por ejemplo campo “TOS” en cabeceras IP), reconocimiento de determinados protocolos (por ejemplo reconocido mediante el campo “Protocolo” en cabeceras IP), la evaluación de protocolos de señalización para determinar las direcciones de origen/destino y/o también procedimientos para reconocer (de manera heurística) determinadas clases de datos/aplicaciones (por ejemplo por medio de intervalos/tamaños de paquetes, determinados campos como números de versión y/o sellos de tiempo, números de secuencia en cabeceras de paquetes, etc.). También son posibles y ventajosos, según el escenario de aplicación, muchos otros criterios de selección por ejemplo para el soporte o especificación directa de qué paquetes/flujos de datos deben incluirse en la optimización. Pueden considerarse por ejemplo también: el suministro de datos sobre diferentes interfaces de red (físicas/virtuales/...) a los optimizadores o la utilización de (diferentes) protocolos de túnel y/o redes de superposición.

También son posibles al menos a menudo mediciones como por ejemplo de la tasa de pérdida de paquetes y/o RTT y/o de interrupciones de transmisión, cuando no se utiliza al igual que en las disposiciones de la figura 2 ningún optimizador X-2. En este caso, el optimizador X-1, por ejemplo adaptado al escenario de aplicación, puede aprovechar otras funcionalidades implementadas en el punto terminal B y/o en su entorno o en el trayecto de transmisión al punto terminal B, para llegar a las informaciones necesarias. Por ejemplo, en muchos escenarios de aplicación podría utilizarse el comando PING (protocolo ICMP; con tamaños de paquete PING normalizados o también con tamaños de paquete típicos tal como los que también se utilizan en el flujo de datos que va a optimizarse), para estimar pérdidas de paquetes y/o RTT para una estación remota correspondiente sin componentes de optimizador X-2 específicos y sin funciones de optimización especiales y/o establecer interrupciones de transmisión. En el ejemplo VoIP utilizando el protocolo RTP, en algunos escenarios de aplicación también pueden obtenerse informaciones similares a través del protocolo RTCP, a través del que las implementaciones de VoIP proporcionan al lado contrario acuses de recibo a través de los datos recibidos.

Para escenarios de aplicación y en función de los requisitos puede producirse además una combinación con una compresión de los datos útiles transmitidos y/o transcodificación/cambio de la codificación de contenido. A este respecto son válidos según el escenario de aplicación procedimientos de compresión tanto sin pérdidas como sujetos a pérdidas (como por ejemplo la reducción de resoluciones de imagen, de la calidad de imagen o de la eliminación por filtrado de informaciones adicionales opcionales, etc.). Esto se aplica en general para la utilización de disposiciones según la figura 1. En función del escenario de aplicación concreto y de los procedimientos de compresión utilizados también es posible sin embargo utilizar estas técnicas en disposiciones según la figura 2. Por ejemplo, en el caso de la reducción de resoluciones de imagen, de la calidad de imagen, de la eliminación por filtrado de informaciones adicionales, del cambio de la codificación de contenido/transcodificación (aunque esto con frecuencia depende del alcance de funcionamiento/las codificaciones de contenido soportadas de las aplicaciones utilizadas). Incluso para escenarios de aplicación como la navegación por la web, por ejemplo el protocolo HTTP permite comprimir los objetos web transmitidos directamente por el servidor web o incluso también por componentes intercalados como por ejemplo un optimizador. Puesto que los navegadores web comunes a menudo soportan varios de estos procedimientos de compresión, un optimizador también puede opcionalmente comprimir objetos web con uno de estos procedimientos de compresión y la compresión podría incluso mantenerse hasta el sistema terminal/aplicación de recepción (en este caso el navegador web).

En general, en caso de utilizar disposiciones según la figura 1 y parcialmente (como se ha descrito precisamente en el ejemplo de navegación por la web y compresión) también para disposiciones según la figura 2, puede ser apropiado integrar también otros procedimientos tales como el cifrado.

Para algunos escenarios de aplicación y algunas redes es adecuada además una combinación y/o utilización conjunta con procedimientos de mejora de protocolo adicionales. Hay procedimientos de mejora de protocolo para un gran número de protocolos y propósitos y/o redes. Muy frecuentemente se utilizan por ejemplo procedimientos de mejora de protocolo para protocolos TCP y/o HTTP y/o de compartición de archivos (como por ejemplo SMB, CIFS, NFS, NetBios). A este respecto, estos protocolos o bien se sustituyen por ejemplo para determinados tramos de transmisión por otros protocolos y/o bien se modifican parámetros de protocolo en los terminales y/o los paquetes de datos intercambiados. A este respecto hay múltiples propósitos potenciales para tales procedimientos de mejora de protocolo. Por ejemplo, la función de una mejora de protocolo TCP puede ser, también en el caso de retardos de transmisión elevados (y/o retardos de transmisión que se mantienen a pesar de la optimización) y/o tasas de pérdida de paquetes altas (y/o tasas de pérdida de paquetes que se mantienen a pesar de la optimización) posibilitar un ancho de banda de transmisión alto y/o mantener reducida la sobrecarga del protocolo, por ejemplo provocada por paquetes de control. Las mejoras de protocolo HTTP suelen presentar propósitos similares. En éstas se reducirán por ejemplo también los tiempos de carga de páginas que aparecen en caso de utilizar un navegador de Internet habitual también para redes con retardos de transmisión elevados y/o altas tasas de pérdida de paquetes. Posibilidades para hacer esto comprenden, por ejemplo, proxys intercalados y/o el envío proactivo de objetos contenidos en páginas web o incluso que siguen a enlaces.

El protocolo HTTP es también un ejemplo de que puede ser ventajoso combinar los diferentes procedimientos mencionados aquí (a este respecto HTTP es sólo un representante de muchos protocolos a los que se aplica esto, como por ejemplo, aunque no sólo, muchos protocolos basados en texto tales como SIP, RTSP, SOAP, SDP, etc.). Así, HTTP se sitúa por ejemplo sobre TCP e IP, por lo que se utiliza una jerarquía de protocolos relativamente grande, en la que las capas de protocolo situadas más arriba a menudo pueden aprovecharse directamente de optimizaciones para capas de protocolo situadas más abajo. En este ejemplo, podría acortarse una optimización de por ejemplo tasas de pérdida de paquetes y/o RTT. HTTP en sí se beneficia a menudo directamente de esta optimización. Sin embargo, HTTP se beneficia de las optimizaciones a menudo también ya porque se sitúa encima de TCP y TCP a su vez se beneficia a menudo considerablemente de tasas de pérdida de paquetes que se han reducido y/o RTT acortados.

HTTP también es un buen ejemplo de que en un escenario de aplicación correspondiente con frecuencia también pueden ser ventajosos procedimientos adicionales tales como mejoras de protocolo, compresión, cifrado y/o procedimientos de compresión de cabeceras específicos de HTTP además de las optimizaciones.

A este respecto, los tipos de procedimiento/procedimientos individuales que van a combinarse potencialmente con la optimización (como por ejemplo las mejoras de protocolo, compresión, cifrado, compresión de cabeceras, etc. anteriormente mencionados) podrían realizarse independientemente unos de otros y/o independientemente de la optimización, lo que entre otras cosas aumenta la flexibilidad y/o la intercambiabilidad. Una realización en componentes de sistema y/o aparatos combinados reduce sin embargo potencialmente la complejidad global y/o los esfuerzos de configuración. No por último, podrían realizarse y utilizarse de manera simplificada los tipos de procedimiento individuales en una realización total/parcialmente integrada y/o en una realización en la que se intercambian al menos informaciones de control individuales entre los componentes de los tipos de procedimiento.

Tal como ya se ha descrito, en muchos escenarios de aplicación es ventajoso realizar los optimizadores/la optimización que debe realizarse en combinación con otros procedimientos (tales como compresión de datos útiles, compresión de cabeceras, cifrado, mejora de protocolo, etc.). A este respecto, estos otros procedimientos, tal como ya se ha descrito, pueden realizarse por ejemplo directamente dentro del optimizador o también por ejemplo como componentes autónomos externos. También pueden estos otros procedimientos aplicarse a los paquetes según el escenario de aplicación y la disposición seleccionada antes o después de la optimización de los paquetes/flujos de datos. Sin embargo, según la disposición seleccionada, mediante la optimización en sí misma o mediante los otros procedimientos, las informaciones para “componentes posteriores” pueden no ser ya reconocibles y/o utilizables. Por ejemplo, las cabeceras de paquete (o partes de las mismas) y/o los datos útiles (o cabeceras de capas de protocolo más altas) podrían ser irreconocibles para componentes posteriores (o expresado de manera más general para otros componentes) debido a cifrado y/o compresión de contenido/datos útiles y/o compresión de cabeceras, mientras no vuelvan por ejemplo a descifrarse y/o descomprimirse. Estos componentes posteriores pueden ser de múltiples tipos. Esto podría afectar por ejemplo a componentes que aplican los otros procedimientos mencionados, puede afectar a los optimizadores, pero también por ejemplo pueden verse afectados encaminadores y/o catalogadores de tráfico y/u otros dispositivos de QoS en general, por el hecho de que las informaciones ya no son reconocibles y pueden por tanto por ejemplo sólo aprovechar sus funciones ya sólo de manera limitada o no aprovecharlas ya en absoluto. Por tanto puede ser ventajoso utilizar negociaciones y/o señalizaciones implícitas, por ejemplo adicionales, y/o un intercambio de información adicional entre los componentes implicados.

Ejemplos pueden ser también en este caso el marcado de paquetes (por ejemplo a través del campo TOS de la cabecera IP), la señalización/clasificación de paquetes/flujos de datos por medio de informaciones de dirección (que por ejemplo se dan a conocer a través de configuraciones y/o protocolos de señalización a otros componentes), la utilización de protocolos de túnel y/o también protocolos especiales, que por ejemplo en cabeceras de información y/o informaciones de control adicionales contienen las informaciones que de lo contrario ya no son reconocibles de los paquetes/flujos de datos. A este respecto puede ser ventajoso, en función de una disposición concreta, que estas cabeceras de información adicionales no se transmitan obligatoriamente a través de trayectos largos de las redes implicadas, sino que se eliminen por ejemplo por el último componente que necesita estas informaciones; también, según una disposición concreta, un componente podría pasar estas cabeceras de información adicionales completamente a componentes posteriores, podría ampliarlas con otras informaciones, podría por ejemplo eliminar informaciones ya no necesarias por los componentes posteriores de las cabeceras de información adicionales, eliminar completamente las cabeceras de información o una combinación de estas etapas.

Según el escenario de aplicación puede ser ventajoso transmitir los paquetes de datos que deben transmitirse, no sólo en un trayecto a través de la red/subredes y/o en paralelo a través de varios tramos de transmisión. Las ventajas que resultan pueden comprender, según el escenario de aplicación, por ejemplo una distribución de carga y retardos de transmisión y/o tasas de pérdida de paquetes asociados con ello potencialmente más bajos, un aumento de la capacidad de transmisión disponible en total y/o en particular en el caso de una transmisión redundante de todas y/o algunas de las informaciones también una seguridad frente averías y/o robustez aumentadas con respecto a por ejemplo la salida de zonas de recepción y/o el cambio entre redes. Para la distribución de los paquetes de datos que deben transmitirse en varios trayectos a través de la red/subredes y/o en paralelo a través de varios tramos de transmisión, según el escenario de aplicación pueden ser ventajosos procedimientos diferentes. En particular, en el caso de redes/subredes generalmente desconocidas y/o tramos de transmisión utilizados en paralelo puede ser ventajosa una distribución teniendo en cuenta el retardo de transmisión/RTT de los trayectos individuales. Un procedimiento correspondiente podría ser por ejemplo regular las cantidades de datos conducidas a través de los trayectos individuales, en el sentido de que los trayectos individuales presentan por ejemplo un RTT similar y/o un RTT que por ejemplo no supera, y/o al menos lo supera por poco, un máximo configurado y/o determinado.

En general, señales de control del usuario o de sistemas externos como por ejemplo de un sistema de gestión de red también pueden influir y/o directamente controlar por ejemplo el tipo, alcance, cantidad, procedimiento de optimización/sus parámetros y/o la selección de los flujos de datos incluidos en la optimización. También puede haber una funcionalidad opcional o siempre presente/utilizada del optimizador, que por ejemplo controla diferentes optimizaciones, alcances de optimización, parámetros y/o la inclusión de flujos de datos en la optimización también de manera dinámica y/o controlada mediante entradas del usuario y/o sistemas externos como por ejemplo un sistema de gestión de red. También puede ser ventajoso, según el escenario de aplicación, de manera complementaria a y/o en lugar de una optimización principalmente utilizada siempre (de manera estática), prever un reconocimiento y una adaptación automáticos a las posibles optimizaciones. Un mecanismo de este tipo puede realizarse de manera dividida entre dos o más optimizadores y/o unilateralmente en un compresor y/o incluso externamente a los optimizadores. El mecanismo de reconocimiento puede ser pasivo (por ejemplo sólo observar flujos de paquetes) o activo (por ejemplo incluso enviar paquetes para la determinación de las posibilidades de optimización). El mecanismo (independientemente de que se realice en uno o en varios optimizadores o de manera externa) puede obtener las informaciones necesarias de la red (por ejemplo mediante protocolos de encaminamiento, de señalización intermedia (middlebox) como por ejemplo RSVP, NSIS, SOCKS, MIDCOM, etc. y/u otros protocolos de control) y/o de una gestión de red y/o determinarlas por interacción de dos o más optimizadores. Pueden darse indicaciones mediante configuración inicial y/o continua.

Un mecanismo de este tipo reconoce de manera dinámica, parcial o totalmente de manera autónoma, qué procedimientos pueden integrarse en la optimización y/o qué procedimientos adicionales (dado el caso combinados con la optimización realizada) deben utilizarse. Esta determinación de las posibilidades de compresión puede realizarse con anterioridad a la puesta en marcha de la optimización, antes/durante el establecimiento de una o varias relaciones de comunicación y/o de manera continua durante la optimización activa.

A este respecto puede ser ventajoso que el mecanismo también reconozca automáticamente errores durante el funcionamiento (por ejemplo a partir de la transmisión o la no transmisión de los propios paquetes de datos optimizados, sus tasas de pérdida y/o sus otras características de transmisión) y que saque a partir de ello conclusiones sobre modificaciones en el recorrido de transmisión (nueva selección de recorrido, adiciones de uno o varios nodos adicionales, distribución de carga en varios encaminadores, etc.). Basándose en estas informaciones, el mecanismo puede adaptar entonces la optimización de cabeceras de manera correspondiente.

Un mecanismo de este tipo puede estar activo en diferentes desarrollos al mismo tiempo y también operar en paralelo de manera complementaria y/o de manera desplazada en el tiempo con respecto a una configuración estática. Pueden utilizarse diferentes desarrollos (diferentes determinaciones dinámicas y/o configuraciones estáticas y/o negociaciones) al mismo tiempo y/o de manera secuencial para diferentes paquetes de datos de relaciones de comunicación individuales y/o de varias de las mismas. La identificación de qué mecanismos deben emplearse en qué (partes de una) relación/relaciones de comunicación y/o grupos de relaciones de comunicación y/o los flujos de datos completos, puede producirse a su vez de manera estática o dinámica y/o depender de las propiedades de los paquetes de datos y/o los protocolos empleados y/o de la carga de red (actual, pasada, futura esperada) y/o de las propiedades de transmisión observadas (tasa de errores, tiempo de circulación, etc.).

En particular puede preverse, de manera complementaria y/o en lugar de la configuración, qué optimizaciones o procedimientos combinados se realizan, intercambiar activamente por ejemplo paquetes de prueba según un esquema acordado previamente (de manera estática o dinámica) y/o proporcionar realimentación por ejemplo en cuanto a la calidad de servicio actual de un optimizador de recepción al optimizador de emisión (por ejemplo para pedirle directa y/o indirectamente que inicie otras/más redundancias, por ejemplo de FEC, en la optimización y/o que reduzca adicionalmente las tasas de transmisión de datos para disminuir el RTT y/o que priorice determinados paquetes de otro modo).

Puede ser ventajoso determinar de manera dinámica qué tipo de flujos de datos y/o relaciones de comunicación están presentes, para adaptar la optimización de manera correspondiente. Así, puede decidirse automáticamente por ejemplo mediante reconocimiento dinámico del tipo de un flujo de datos (por ejemplo de un flujo de datos multimedia basado en RTP), si y/o qué paquetes de datos deben optimizarse de qué manera. Como motivos de decisión pueden servir por ejemplo la viabilidad técnica (así pueden comprimirse por ejemplo paquetes cifrados peor que los descifrados) y/o la eficacia de la optimización y/o el esfuerzo (por ejemplo potencia de cálculo, memoria, etc.).

Alternativamente o en combinación, la optimización puede realizarse en función de determinados puntos terminales y/o aplicaciones implicados y/o de la carga en las redes de transmisión y/o en tramos de transmisión individuales/grupos de los mismos y/o de la memoria disponible y/o de la carga de CPU/procesador de los componentes implicados. En función de criterios individuales o combinaciones de los mismos, la optimización puede activarse total/parcialmente, limitarse y/o desactivarse total/parcialmente o pueden tomarse decisiones correspondientes para procedimientos combinados con la optimización. Tanto en el caso de una decisión de optimización estática como de una dinámica, esta decisión puede tomarse unilateralmente mediante componentes individuales o componentes de un lado de transmisión

: o en conjunto por varios componentes implicados o también componentes de sistema “adyacentes” como un sistema de gestión de red. A este respecto también es posible en muchos escenarios de aplicación optimizar en primer lugar conexiones y durante la continuidad de las conexiones/de partes de las conexiones finalizar la optimización (y viceversa

: o alternando múltiples veces).

La invención también es adecuada en muchos escenarios de aplicación para la utilización en la comunicación de punto a multipunto (como la que suele estar presente por ejemplo en una red de difusión por satélite o terrestre). Pueden aplicarse los mismos procedimientos de optimización. No obstante, a menudo debe tenerse en cuenta que los (diversos) optimizadores que reciben paquetes optimizados y/o también los (diversos) sistemas terminales/aplicaciones (denominados aquí conjuntamente en este contexto receptores) pueden presentar diferentes capacidades y que los recorridos de transmisión hasta los mismos pueden presentar diferentes propiedades. Un optimizador debe entonces permitir a los optimizadores importantes, a una pluralidad de los mismos y/o a todos, una interpretación de los paquetes de datos optimizados. Esto puede producirse porque se seleccionan procedimientos de optimización que son adecuados para todos los receptores pretendidos. Y/o un optimizador puede enviar de manera diferente paquetes de datos/flujos de datos optimizados a receptores individuales y/o grupos de receptores, que son adecuados específicamente para el respectivo recorrido de transmisión y/u optimización. Y/o un optimizador puede enviar información adicional (paquetes de datos y/o de control existentes y/o adicionales) a receptores individuales y/o grupos de receptores (y/o nodos de las redes de transmisión), para posibilitar una retransmisión y/o recepción y/o evaluación satisfactoria del flujo de datos optimizado recibido. Lo mismo se aplica en muchos casos para la comunicaciónmultipunto a multipunto. Ésta puede a menudo además representarse en varias relaciones de comunicación de punto a multipunto.

Para disposiciones en particular según la figura 1 es adecuada también una combinación opcional con técnicas de compresión de cabeceras, para reducir el volumen de transmisión. Además de la ventaja evidente del ahorro de capacidad de red, esto reduce a menudo implícitamente por ejemplo, en redes/tramos de transmisión sobrecargados también las tasas de pérdida de paquetes y en particular en redes/tramos de transmisión de banda estrecha, el RTT. En el caso de la optimización mediante la introducción de informaciones FEC de redundancia, la utilización de compresión de cabeceras puede a menudo (como por ejemplo en el caso de VoIP y RTP) proporcionar una proporción considerable, para volver a disminuir la necesidad de ancho de banda, que aumenta debido a las informaciones de redundancia, total o parcialmente o incluso por debajo de la necesidad de ancho de banda original.

La invención también permite, opcionalmente, utilizar la optimización (por ejemplo O1) a través de casi cualquier red/trayecto de red/tramo de transmisión y/o incluso a través de redes/trayectos de red/tramos de transmisión cambiantes. Por tanto, y entre otras cosas para establecer, a pesar de técnicas de compresión de cabeceras al menos relativamente eficaces, requisitos relativamente reducidos o que sólo pueden determinarse ampliamente en cuanto al tipo de redes/trayectos de red/tramos de transmisión utilizados, también es ventajoso utilizar la invención opcionalmente en combinaciones con procedimientos de compresión de cabeceras parciales, tal como se describe a continuación en el apartado II.

II. Otras optimizaciones mediante compresión de cabeceras de protocolo

Este apartado describe un desarrollo específico de una optimización. Este aspecto se basa en el campo de la transmisión de datos orientada a paquetes y de la reducción de la sobrecarga creada debido a las cabeceras de paquete. A este respecto la invención permite ahorrar cabeceras de paquete tanto total como parcialmente en la transmisión. El estado de la técnica ya se describió al inicio.

Una compresión de cabeceras tal como se describe a continuación es un desarrollo específico de una función de optimización, un compresor una posible configuración de un optimizador. Para ilustrar esta relación, las figuras 3 a) a e) y 4 a) y b) muestran las mismas disposiciones de sistema que las figuras 1 y 2, no obstante en las figuras 3 y 4 se ilustran los optimizadores y las optimizaciones de las figuras 1 y 2 mediante los desarrollos específicos de las compresiones, de los compresores y descompresores. Para explicar las disposiciones de sistema para el desarrollo específico de la compresión se remite a las descripciones de las figuras 1 y 2 en el apartado I. Las realizaciones se aplican de manera análoga para optimización y compresión, para optimizador y (des)compresor. Ha de indicarse que la representación general en el apartado I para la optimización siempre habla de optimizadores: un optimizador introduce optimizaciones, otro optimizador las interpreta en el sentido de la optimización, para restablecer por ejemplo los paquetes de datos (tal como estaban presentes antes de la optimización) total o parcialmente. En el contexto de compresiones se introduce aquí para simplificar un segundo concepto: además del compresor (que comprime paquetes de datos) se habla para el lado contrario de descompresor (que restablece los paquetes de datos originales totalmente

o en partes esenciales).

A continuación se representan en detalle aspectos adicionales de la invención, pudiendo ser importantes las características de los diferentes aspectos tanto de manera individual como en cualquier combinación en la realización de la invención en sus diferentes formas de realización. En particular los diferentes aspectos dan lugar en cada caso en sí mismos a una mejora esencial del estado de la técnica.

La división realizada en este apartado en a), b), c) y d) sirve para estructurar mejor el apartado. Sin embargo, no tiene que respetarse obligatoriamente y algunos aspectos se tratan abarcando varios apartados o en contra de esta división ya en otros apartados.

Para facilitar la comprensión de los diferentes aspectos de la invención, a este respecto a continuación a menudo se comentan en primer lugar en cada caso de manera breve los antecedentes (apartado (i)) con respecto al aspecto, para a continuación describir la problemática especial y los aspectos de la invención (apartado (ii)) y una o varias formas de realización preferidas del aspecto de la invención (apartado (iii)). En cuanto a algunos de los aspectos de la invención, en un apartado (iv) se describen después configuraciones que son parcialmente alternativas. Sin embargo, esta división no tiene que respetarse obligatoriamente y algunos aspectos se tratan abarcando varios apartados o en contra de esta división ya en otros apartados. Algunas posibles disposiciones para la aplicación de las tecnologías según la invención están representadas en las figuras 1 y 2 en general para optimizaciones así como en las figuras 3 y 4 específicamente para compresión. Las realizaciones del apartado 1 con respecto a optimizaciones se aplican de manera correspondiente a compresiones, en particular las diferentes disposiciones de sistema y cualquier combinación de las mismas. Las explicaciones con respecto a las figuras 3 y 4 se desprenden por tanto directamente de las anteriores con respecto a las figuras 1 y 2 y por tanto no se repiten aquí. También pueden integrarse y/o enlazarse entre sí compresiones de cabeceras y otras optimizaciones de manera aleatoria en los mismos y/u otros componentes. Las realizaciones del apartado I con respecto a redes y tecnologías de red específicas se aplican igualmente de manera análoga.

De manera complementaria se indica que, en el caso de optimizaciones o compresiones anidadas y/o paralelas (por ejemplo como se representa en las figuras 1e)/3e)), algunos datos de las optimizaciones o compresiones paralelas o anidadas pueden utilizarse total o parcialmente en conjunto por ambas optimizaciones o compresiones. Ejemplos de esto pueden ser entre otros ID de conexión, campos de longitud o (sub)informaciones de longitud, aunque también muchos otros tipos de campo.

Las funciones de compresión no están limitadas a informaciones en cabeceras de paquete de una determinada capa. Sin embargo, compresiones individuales pueden especializarse en determinadas cabeceras de paquete, determinadas capas, determinados protocolos y/o determinadas aplicaciones. Compresiones individuales pueden funcionar en capas individuales o también abarcando varias capas. La compresión puede depender de las particularidades de las redes circundantes o los trayectos a través de la red y/o de la función y/o de la presencia de determinados elementos de red: así por ejemplo una función de compresión puede funcionar de otro modo, cuando los paquetes en el recorrido deben pasar por otros determinados elementos de red tales como encaminadores, NAT y/o cortafuegos. Diferentes compresiones (y sus compresores) pueden adaptarse entre sí y/o funcionar independientemente unos de otros.

Además de una mera reducción de las cabeceras de paquete, los compresores también pueden modificar el contenido, para hacer la comunicación más eficaz y/o con un mejor rendimiento y/o más robusta o simplemente posibilitar en realidad la comunicación. Una función de compresión (o compresión) tampoco tiene que llevar en todos los casos a una reducción del volumen de datos. Por ejemplo, si una red de transmisión no puede transmitir paquetes de datos de un determinado tipo (por ejemplo de una determinada aplicación, de un determinado protocolo de transporte), entonces una función de compresión puede reescribir los paquetes de datos de modo que a pesar de ello se realice una transmisión a través de la red en cuestión.

A continuación se explican algunos aspectos de la invención más en detalle. Sin embargo ha de tenerse en cuenta que también se han descrito ya anteriormente configuraciones y aspectos de la invención que pueden utilizarse, tomados por sí solos y/o en combinación con uno/varios de los siguientes (sub)aspectos.

II.a) Compresión de cabeceras parcial

(i) Antecedentes

La compresión de cabeceras reduce y/o elimina informaciones de cabecera en un subtrayecto entre dos sistemas en la red. Estos dos sistemas pueden (como se describió anteriormente) ser tanto los puntos terminales como otros nodos en

la red (“en medio, es decir entre los puntos terminales”). Pueden ser vecinos, es decir, estar unidos entre sí

directamente a través de un tramo de transmisión de una red física (por ejemplo una conexión conmutada, una sección de transmisión por satélite o una Ethernet). O pueden encontrarse uno o varios otros nodos (por ejemplo encaminadores) según la topología de red entre estos dos sistemas, de modo que la comunicación entre ambos requiere una transmisión de los paquetes de datos intercambiados por terceros (los otros nodos recién mencionados). En este último caso puede modificarse la ruta entre ambos sistemas a lo largo del tiempo. Este último caso se presenta a menudo (aunque no tiene que presentarse o puede también presentarse en otras situaciones y/o constelaciones), cuando los sistemas que realizan la compresión son dos puntos terminales.

Ha de indicarse que la cuestión de si dos sistemas son vecinos, en función de la capa de protocolo más baja, desde la que tiene lugar la compresión, se responde de manera diferente. Por ejemplo dos encaminadores IP son vecinos cuando no hay ningún otro encaminador entre los mismos y realizan compresión en la capa IP. En cambio en la capa de aplicación dos puntos terminales con cualquier número de encaminadores IP en medio también son vecinos, siempre que no se utilice ningún proxy de aplicación y la compresión sólo se produzca en la capa de aplicación. Además, dos proxys de aplicación son vecinos, cuando no hay ningún otro proxy entre los mismos y la compresión tiene lugar en la capa de aplicación.

En la compresión de cabeceras, parte de o todas las informaciones de la o de las cabeceras que deben comprimirse se extraen y/o se sustituyen en un sistema (el emisor) y se reconstruyen en el otro sistema (el receptor). A este respecto, los dos sistemas implicados en la compresión disponen de un conocimiento en conjunto (contexto) y/o conocimiento local (informaciones de estado) y/o de una comprensión en conjunto de los algoritmos de compresión que van a emplearse. Este conocimiento y los algoritmos pueden por ejemplo predefinirse y/o intercambiarse de manera dinámica y/o en el transcurso de uno o varios paquetes de datos intercambiados (de una o varias relaciones de comunicación) construirse dependiente y/o independientemente uno de otro de manera dinámica (“aprenderse”) y/o adaptarse.

Para que la compresión de cabeceras pueda funcionar, los paquetes de datos creados por el sistema de compresión deben llegar al sistema de descompresión sin modificar en las partes esenciales (y, según el procedimiento empleado, en algunos casos aunque a menudo no en todos los casos también en el orden correcto). Para ello es necesario que los nodos presentes eventualmente entre los dos sistemas puedan retransmitir los paquetes de datos comprimidos y a este respecto no puedan falsear ninguna información requerida para la descompresión. Esto es el caso más sencillo

cuando los dos sistemas son directamente vecinos (es decir, sólo están alejados un “salto” uno de otro), puesto que en este caso no hay ningún nodo de red “que moleste” en medio. En este caso se habla de compresión de cabeceras por

saltos. De manera correspondiente, compresión de extremo a extremo designa a la compresión de cabeceras entre dos puntos terminales. Se habla de compresión de centro a centro en todos los casos en los que los dos sistemas implicados en la compresión no son ni vecinos ni son ambos puntos terminales.

Si los dos sistemas son vecinos, no tienen que tener en cuenta las funciones de retransmisión de los sistemas que se encuentran entre los mismos. Para compresión de centro a centro y de extremo a extremo, las informaciones requeridas por los otros nodos para el procesamiento y/o retransmisión de los paquetes deben mantenerse sin modificar. Para la compresión en sí pueden considerar una o varias cabeceras de paquete de la jerarquía de cabeceras, siempre que siga cumpliéndose la condición anterior.

(ii) El procedimiento de compresión es en general tanto más eficaz, cuantas más cabeceras de la jerarquía de cabeceras puedan incluirse en la compresión. Esto posibilita que los procedimientos por saltos (que realizan precisamente la compresión para un tramo de transmisión) con frecuencia consigan esencialmente tasas de compresión más altas que los procedimientos de extremo a extremo (estos últimos en última instancia no pueden comprimir las cabeceras que se requieren para la retransmisión a través de los otros nodos). No obstante, un paquete con frecuencia adopta recorridos en los que no puede realizarse en cada tramo una compresión por saltos, por ejemplo por motivos de la capacidad de los componentes utilizados o porque los componentes para la respectiva función no están disponibles con la compresión de cabeceras instalada, dado el caso también, porque tal vez por motivos de ganancias/costes no se desea en absoluto una compresión.

Es ventajosa una compresión de cabeceras de centro a centro que combina entre sí algunas de las ventajas relacionadas con la eficacia de la compresión de cabeceras por saltos con el menor esfuerzo de integración de la compresión de cabeceras de extremo a extremo al menos en una parte especialmente relevante del trayecto. Una compresión de cabeceras de centro a centro de este tipo podrá ser a este respecto la más eficaz, cuando maximiza el área cubierta en la jerarquía de cabeceras. Un límite en esta maximización se obtiene porque los sistemas que se encuentran entre el compresor y el descompresor en el trayecto necesitan una parte de la jerarquía de cabeceras para

sus funciones respectivas y esta “parte baja” no puede, como se mencionó anteriormente, eliminarse mediante

compresión de manera sencilla.

En general, un compresor X-1 de una compresión C recibe un paquete de datos y comprime de manera selectiva las cabeceras que no se necesitan para la retransmisión de los paquetes de datos a través de otros sistemas. A este respecto se incluyen lógicamente tantas cabeceras “visibles” para el compresor (es decir, presentes de manera accesible sin cifrar) como sea posible.

La maximización descrita de las cabeceras detectadas por la compresión de cabeceras no tiene que limitarse a la inclusión o exclusión de cabeceras completas. Si un sistema sólo necesita en el trayecto entre el compresor y el descompresor determinados campos de una cabecera, los otros campos de esta cabecera quedan disponibles para la integración en el procedimiento de compresión, cuando al menos la estructura de la cabecera en esta compresión se conserva y/o puede reconstruirse.

Independientemente de que puedan incluirse cabeceras completas o sólo partes de las mismas en la compresión, puede ser necesario conservar todas o una parte de cabeceras individuales o de la jerarquía de cabeceras. Mediante la compresión realizada, se necesita sin embargo menos espacio que el que hay presente en total en la respectiva cabecera, para transmitir las informaciones requeridas. En tales casos, el espacio que queda libre debido a la compresión en una cabecera puede llenarse con informaciones de control, comprimidas o no comprimidas, de otras cabeceras y/o informaciones de control adicionales y/o informaciones de corrección de errores hacia delante (FEC) y/o datos útiles del paquete de datos.

La compresión de campos de cabecera puede realizarse individualmente para cada paquete de datos individual o para algunos de los paquetes de datos de manera relacionada. En la compresión, paquetes de datos pueden referirse a otros paquetes de datos (enviados previa o posteriormente) y de este modo puede aumentar por ejemplo la eficacia de compresión. La selección de los paquetes de datos que van a comprimirse y/o de los paquetes de datos para una compresión relacionada puede realizarse debido a reglas predefinidas de manera fija y/o creadas de manera dinámica y/o debido a las propiedades de paquete y/o a la sucesión temporal de los paquetes, etc.

En la compresión de paquetes de datos, pueden considerarse los (las secuencias de) paquetes de datos de diferentes relaciones de comunicación de extremo a extremo independientemente unos de otros y/o algunas (o todas) las relaciones de comunicación pueden considerarse en conjunto. La consideración independiente y/o conjunta para la compresión puede referirse a paquetes de datos individuales (cualquiera o determinados por sus propiedades) y/o a todos los paquetes de datos. Finalmente puede cambiarse entre una consideración individual y una conjunta de los paquetes de datos de diferentes relaciones de comunicación a lo largo del tiempo.

La compresión puede aumentar el volumen de datos transmitido entre compresor y (des)compresor (por paquete) también (dado el caso sólo a corto plazo), por ejemplo mediante cabeceras adicionales, cabeceras más grandes, paquetes adicionales y/u otra transmisión complementaria y/o redundante de informaciones. También puede preverse no aplicar la compresión para paquetes de datos individuales y/o, a pesar de la compresión, no disminuir el volumen de datos de paquetes de datos individuales. Lo mismo se aplica en general/de manera limitada en el tiempo para relaciones de comunicación completas y/o grupos de paquetes de datos y/o todos los paquetes de datos.

Puede ser ventajoso transmitir, además de los paquetes de datos retransmitidos (comprimidos o no comprimidos), paquetes de control adicionales en uno o ambos sentidos entre compresor y descompresor.

También puede preverse intercambiar informaciones de control, entre las que se encuentran confirmaciones implícitas

o explícitas acerca de paquetes de datos y/o de control adicionales recibidos y/o no recibidos, entre compresor y descompresor. Puede ser ventajoso transmitir de nuevo algunos paquetes de datos o paquetes de control adicionales y/o transmitir otras informaciones como paquetes y/o informaciones adicionales independientes en otros paquetes, a partir de las que pueden restablecerse partes de las informaciones y/o paquetes completos.

Un paquete de datos así comprimido (y/o una secuencia de paquetes de datos) se retransmite desde el compresor X-1 al (des)compresor X-2 y la compresión C se revierte de nuevo en el mismo por completo o ampliamente, de modo que el paquete de datos original se reconstruye por completo o esencialmente.

(iii) Ha de indicarse que el término seleccionado al inicio de “compresión de cabeceras de centro a centro” se seleccionó porque contribuye en muchas formas de realización a una compresión sencilla. Independientemente de los

componentes denominativos del término “compresión de cabeceras de centro a centro”, el procedimiento puede

utilizarse sin embargo en variadas formas de realización, incluyendo las descritas en las figuras 1, 2, 3 y 4. Por consiguiente, la compresión de cabeceras también puede comenzar por ejemplo ya en los/uno de los puntos terminales implicados. A continuación se describen algunas formas de realización a modo de ejemplo. A este respecto ha de tenerse en cuenta que los ejemplos descritos explican los aspectos de la invención en un contexto determinado como ejemplo. Sin embargo, los propios aspectos de la invención también pueden utilizarse de otro modo o de manera esencialmente más general.

En el ejemplo de una realización con IPv4, cuando los sistemas en el trayecto entre compresor y descompresor evalúan la dirección de destino IPv4, no obstante en muchos casos la dirección de origen IPv4 podría participar en la compresión. En una de las posibles realizaciones esto podría significar que podrían sustituirse direcciones de origen que se repiten por un identificador de contexto más corto y, para mantener la estructura de la cabecera al menos en las partes esenciales, los bits restantes del campo de dirección de origen se rellenan con datos comprimidos procedentes de la compresión de las capas superiores, por ejemplo UDP y RTP. Un correspondiente identificador de contexto también podría utilizarse en general, servir para varios campos de una/varias cabeceras de protocolo en conjunto, no servir en especial para una compresión de la dirección de origen IPv4, etc.

En muchos de estos casos, el identificador de contexto (o un equivalente) tampoco debería tener que transmitirse dentro de los bits del campo de dirección de origen, sino que con frecuencia debería poder sustituirse (implícitamente) en cualquier lugar dentro de los paquetes resultantes y/o incluso total o parcialmente por informaciones de cabecera por ejemplo de capas de protocolo situadas por debajo. En otras realizaciones posibles, por ejemplo en escenarios de aplicación en los que la dirección de origen IPv4 es irrelevante dado el caso tanto para los nodos de red intermedios como para el punto terminal y/o aplicación de recepción, la información de dirección de origen IPv4 también puede eliminarse sin sustitución. Esto también posibilita rellenar los bits del campo de dirección de origen con otros datos y aun así mantener la estructura propia de la cabecera al menos en las partes esenciales.

De manera generalizada, a partir de una serie de campos comprimidos de una o varias cabeceras se obtiene por un lado por agrupación un espacio libre disponible de n bits y por otro lado potencialmente la necesidad de transmitir al descompresor informaciones de contexto por ejemplo de k bits para la reconstrucción del paquetes de datos, siendo en general k < n. Los n-k bits que quedan disponibles para alojar informaciones de control (dado el caso igualmente comprimidas) de otras cabeceras o para alojar datos útiles.

Se presenta un caso especial cuando mediante la compresión pueden ahorrarse completamente una o varias cabeceras y/o partes de una o varias cabeceras.

En determinadas circunstancias, la información comprimida que queda por encima de una determinada cabecera (por ejemplo de la cabecera IP) se reduce al conjunto vacío, ya que todas las informaciones relevantes tras la compresión pueden alojarse en estos n-k bits.

Tal como ya se ha comentado anteriormente, en función de los requisitos y/o escenarios de aplicación y/o las cabeceras utilizadas/comprimidas y/o los campos de cabecera comprimidos, puede prescindirse de la transmisión explícita de identificadores de contexto dado el caso también en (algunos y/o todos los) paquetes, por ejemplo cuando éstos se obtienen implícitamente a partir de informaciones y/o informaciones de dirección de capas de protocolo situadas por debajo y/o se intercambian informaciones de control, que representan estas informaciones/informaciones de dirección en un identificador de contexto o contexto. En este caso k sería para todos/algunos de los paquetes menor

o incluso k=cero.

En función de los requisitos y/o escenarios de aplicación y/o cabeceras o campos de cabecera utilizados/comprimidos también puede suceder que partes de la cabecera no puedan o no deban sustituirse sencillamente por un identificador de contexto más o menos estático. Por ejemplo, esto podría deberse al tipo de campo de cabecera que debe comprimirse, pero también propósitos como la reducción de la complejidad y/o el aumento de la robustez y/o el acortamiento de retardos de transmisión, etc. pueden hacer que sea útil representar campos de cabecera individuales/algunos campos de cabecera no (sólo) mediante un identificador de contexto, sino mediante bits de información adicionales (de manera más general: mediante informaciones adicionales) en la cabecera comprimida.

Un ejemplo de tales campos de cabecera podrían ser por ejemplo números de secuencia contenidos en cabeceras, que por ejemplo se alojan como valor de diferencia o por ejemplo acortados en los últimos bits/bytes en las cabeceras comprimidas en todos o algunos de los paquetes. Sin embargo, para simplificar, también se habla a continuación siempre de k bits. Pudiendo contener k precisamente un identificador de contexto y/u otras informaciones y pudiendo ser k absolutamente por ejemplo según el paquete transmitido de tamaño diferente.

En el ejemplo descrito anteriormente de la dirección de origen IPv4 n=32, y al emplear un identificador de contexto corto de k=8, quedan n-k=24 bits. En caso de que esto no sea suficiente, queda, además de las informaciones alojadas en la dirección de origen, algo de información por encima de la cabecera IPv4. Con esta modificación ha de tenerse cuidado de que las cabeceras de paquete que participan sólo parcialmente en la compresión desde el punto de vista de las funciones de los sistemas en el trayecto entre compresor y descompresor parezcan consistentes: en el ejemplo descrito esto significa entre otras cosas: si uno de los sistemas en el trayecto entre compresor y descompresor comprueba los típicos requisitos en cuanto a direcciones de origen IPv4, el compresor debe tener cuidado de que los datos utilizados cumplan los requisitos comprobados (por ejemplo puede ser por tanto, que los datos utilizados no deban dar una dirección de multidifusión IP); si uno de los sistemas en el trayecto entre compresor y descompresor evalúa la suma de comprobación de cabecera IPv4, entonces el compresor debe modificarla de modo que el sistema evaluador considere que el paquete es consistente, y el descompresor debe restablecer el campo.

En el caso de la suma de comprobación de cabecera IPv4 esto se produce en cada caso mediante simple recálculo; en el caso de otros campos de cabecera, que deben cumplir con tales requisitos de consistencia, también puede ser necesario integrarlos en el compresor en la compresión y restablecerlos en la descompresión a partir del contexto y los campos comprimidos. (Si ninguno de los sistemas en el trayecto entre compresor y descompresor evalúa la suma de comprobación de cabecera IPv4, ésta es al igual que los otros campos de todas las cabeceras de paquete un candidato para participar en la compresión de cabeceras.) Esta descripción utilizó IPv4 y la dirección de origen IPv4 como ejemplo; sin embargo el aspecto descrito puede aplicarse a cualquier cabecera (o parte de la misma) tal como cabecera de Ethernet y otras cabeceras de las capas 1 y 2, cabecera IPv6 y otras cabeceras de la capa 3, así como las cabeceras de las capas que se sitúan por encima.

Como se describió anteriormente, la compresión no tiene que limitarse a una cabecera individual, sino que puede realizarse abarcando varios protocolos. Además de varios campos de la cabecera IP, también pueden considerarse aún uno o varios campos de UDP (como por ejemplo la suma de comprobación) o TCP (como por ejemplo el puntero urgente).

Los números de puerto UDP y TCP sirven a menudo para la identificación de relaciones de comunicación también para otros nodos en la red, y así puede ser necesario mantenerlos sin modificar. Lo mismo puede ser válido para la dirección de origen IP. Si no es necesaria, puede comprimirse toda la tupla que consiste en número de puerto origen IP y/o de origen de transporte y/o de destino y/o identificador de protocolo de transporte.

En el ejemplo de cabeceras IPv4 y encaminadores IP más o menos sencillos como nodos de red, por los que pasan los paquetes comprimidos, hay un gran número de campos de cabecera adicionales, que serían candidatos potenciales para su inclusión en la compresión de cabeceras parcial. En este caso, además de la dirección de origen IPv4 (source address) y la suma de comprobación se mencionan a modo de ejemplo los campos: protocolo, identificación, desplazamiento de fragmentos y/o el bit MF (por ejemplo, cuando entre X-1 y X-2 no se produce/debe producirse ninguna (otra) fragmentación), TOS, TTL (o una parte del mismo, en caso de que encaminadores intercalados comprueben por ejemplo sólo si >0 y se reducen de manera limitada, en este caso por ejemplo los 4 bits inferiores podrían ponerse a 1 y por ejemplo los 4 bits superiores podrían incluirse en la compresión), longitud total (por ejemplo, cuando ésta se obtiene a partir de las cabeceras de protocolo situadas por debajo y los componentes intercalados sólo evalúan la misma) y longitud de cabecera IP (por ejemplo cuando ésta se ignora o los componentes intercalados simplemente la asumen implícitamente por ejemplo en función del número de versión de IP). Cuáles de los campos pueden incluirse realmente en la compresión, se deduce, como se describió anteriormente, entre otras cosas mediante los escenarios de aplicación y los componentes intercalados.

En algunos escenarios de aplicación y realizaciones podrían incluirse dado el caso incluso las direcciones de destino IPv4 (destination address) total o parcialmente en la compresión. Esto podría ser ventajoso, por ejemplo, cuando los datos se transmiten a través de una red de difusión (o similar a de difusión), en las que los datos llegan en cualquier caso (siempre o por regla general o para determinados paquetes) a todos los receptores o descompresores independientemente de la dirección de destino. Es ventajoso en tales casos la utilización de compresión de cabeceras parcial entre otras cosas cuando, en el lado de emisión o en el lado de recepción (o en la propia red), se utilizan componentes que presuponen una cabecera IP (o por ejemplo total/parcialmente en la estructura y/o tamaño de una cabecera IP). En un caso de ejemplo sencillo, podría tener que utilizarse por ejemplo una tarjeta de red no modificada y/o un controlador de tarjeta de red no modificado para el envío de los paquetes, que presupone que obtiene paquetes de datos con una cabecera IP.

Un ejemplo similar podrían ser paquetes enviados a una dirección de multidifusión IP. Cuando por ejemplo se conoce qué direcciones se utilizan solamente, o tal vez incluso se conoce que sólo se utiliza una dirección de multidifusión IP en una red, y/o los receptores o descompresores restablecen las direcciones de multidifusión IP con ayuda de identificadores de contexto, para paquetes de multidifusión IP gran parte de la dirección de destino IP(v4) podría incluirse en la compresión.

Según qué protocolos se utilicen en las capas individuales y qué informaciones de cabecera se incluyan en la compresión, pueden utilizarse procedimientos complementarios o en casos más difíciles también tener que utilizarse. Si por ejemplo, independientemente de la multidifusión IP, debe incluirse la dirección de destino IP en una compresión, puede ser útil y/o necesario soportar componentes utilizados, para que puedan manejar estas direcciones de destino IP rellenas con otros contenidos. Si los paquetes IP deben transmitirse con una dirección de destino IP incluida en la compresión por ejemplo a través de una “Ethernet” (por ejemplo según IEEE 802.3), el protocolo de resolución de direcciones (ARP) utilizado puede soportarse, respondiendo por ejemplo una caché ARP local o un proxy ARP/una instancia para responder a consultas ARP, a consultas ARP con una pseudodirección de destino IP que aparece debido a la compresión, con respuestas/valores ARP adecuados.

(iv) Las realizaciones anteriores se refieren en parte a IPv4. De manera correspondiente también puede procederse con IPv6, lo que puede ser ventajoso, porque en ese caso los campos de dirección son más grandes y por tanto debido a la compresión aparece potencialmente más espacio para alojar informaciones de control y/o datos adicionales. Esto se aplica también cuando en lugar de direcciones IPv6 se emplean formatos de dirección relacionados tales como direcciones HIP.

También pueden comprimirse otros protocolos de manera correspondiente. Así, en la capa 2 del modelo de referencia OSI por ejemplo las direcciones de origen de las cabeceras de los protocolos LAN de IEEE-802 ofrecen espacio correspondiente. Por encima de la capa de red pueden comprimirse cabeceras de protocolo de transporte y/o cabeceras de protocolo de aplicación de manera correspondiente.

Los bits “ganados” en capas individuales debido a la compresión de los correspondientes campos de cabecera pueden agruparse abarcando varias capas y utilizarse en conjunto. Esto puede ahorrar por ejemplo espacio para identificadores de contexto, por ejemplo porque éstos ya no tienen que proporcionarse, administrarse y/o transmitirse en cada capa y/o pueden incluso derivarse total/parcialmente a partir de campos de cabeceras de protocolo situadas por debajo.

Tal como se indicó anteriormente, este procedimiento puede utilizarse de manera unidireccional y/o bidireccional. En el caso de la compresión bidireccional, las dos direcciones de transmisión pueden funcionar de manera independiente o dependiente entre sí. El funcionamiento independiente y/o dependiente puede referirse a paquetes de datos individuales, relaciones de comunicación individuales y/o a grupos de relaciones de comunicación y esta referencia o el funcionamiento independiente y/o dependiente puede modificarse a lo largo del tiempo una vez y/o de manera repetida.

Si para la comunicación entre compresor y descompresor sólo está disponible un recorrido de transmisión unidireccional, entonces el compresor mediante una selección adecuada de algoritmos (por ejemplo la utilización de DEFLATE) y/o informaciones de control transmitidas adicionalmente puede encargarse de que el descompresor pueda reconstruir uno o varios paquetes de datos comprimidos y retransmitidos por el compresor totalmente o en una parte esencial.

Una utilización alternativa se consigue cuando, en lugar de la compresión de cabeceras parcial con la conservación de subcabeceras o (sub)estructuras de cabecera (por ejemplo para soportar componentes de red intercalados, que evalúan estas cabeceras), se introducen cabeceras de otro protocolo (por ejemplo soportados por estos componentes de red). Por ejemplo, para el caso de que los encaminadores intercalados soporten el protocolo IPv4, las cabeceras IPv6 claramente más grandes pueden comprimirse y transmitirse la información comprimida, dotada de cabeceras IPv4 introducidas. Entonces en este caso opcionalmente, tal como se describió anteriormente para las cabeceras IPv4, a su vez pueden comprimirse partes del contenido de la cabecera IPv4 y/o sustituirse para la transmisión de otras informaciones y/o datos útiles.

Para escenarios de aplicación y en función de los requisitos puede producirse además una combinación con una compresión de los datos útiles transmitidos. A este respecto son adecuados según el escenario de aplicación tanto procedimientos de compresión sin pérdidas como sujetos a pérdidas (como por ejemplo la reducción de resoluciones de imagen, la calidad de imagen o el filtrado de informaciones adicionales opcionales, etc.).

Para algunos escenarios de aplicación y algunas redes es adecuada además en general una combinación y/o utilización en conjunto de procedimientos de compresión y procedimientos de mejora de protocolo adicionales. Hay procedimientos de mejora de protocolo para un gran número de protocolos y objetivos y/o redes. Muy frecuentemente se utilizan por ejemplo procedimientos de mejora de protocolo para TCP y/o HTTP. A este respecto, estos protocolos o bien se sustituyen por ejemplo para determinados tramos de transmisión por otros protocolos y/o bien se modifican parámetros de protocolo en los terminales y/o los paquetes de datos intercambiados. A este respecto hay múltiples objetivos potenciales para tales procedimientos de mejora de protocolo. Por ejemplo la función de una mejora de protocolo TCP puede ser, también en el caso de retardos de transmisión elevados y/o tasas de pérdida de paquetes altas posibilitar un ancho de banda de transmisión alto y/o mantener reducida la sobrecarga del protocolo, por ejemplo provocada por paquetes de control. Las mejoras de protocolo HTTP suelen presentar objetivos similares. En éstas se reducirán por ejemplo también los tiempos de carga de páginas que aparecen en caso de utilizar un navegador de Internet habitual también para redes con retardos de transmisión elevados y/o altas tasas de pérdida de paquetes. Posibilidades para hacer esto comprenden, por ejemplo, proxys intercalados y/o el envío proactivo de objetos contenidos en páginas web o incluso que siguen a enlaces.

El protocolo HTTP es también un ejemplo de que puede ser muy útil combinar los diferentes procedimientos mencionados aquí (a este respecto HTTP es sólo representante de muchos protocolos a los que se aplica esto). Así, HTTP se sitúa por ejemplo sobre TCP e IP, por lo que se utiliza una jerarquía de protocolos relativamente grande, para la que son adecuados procedimientos de compresión de cabeceras y de compresión de cabeceras parcial típicos; las propias cabeceras HTTP están a menudo ampliamente basadas/codificadas en texto. Entre otras cosas, por tanto, para cabeceras HTTP podrían utilizarse también procedimientos de compresión de cabeceras típicos (también parciales). Sin embargo, aunque las cabeceras HTTP se compriman con y/o sin los datos útiles dado el caso siguientes con un procedimiento de compresión convencional (como por ejemplo DEFLATE) (por ejemplo también opcionalmente o en función del tipo de datos útiles y/o de si los datos útiles ya están comprimidos), pueden obtenerse ahorros de volumen significativos. No por último, HTTP es un protocolo, para el que se recomiendan en muchas redes procedimientos de mejora y para el que a menudo es útil un cifrado.

Cada uno de estos tipos de procedimiento mencionados (tales como compresión de cabeceras, FEC, compresión de datos útiles, mejora de protocolo, cifrado) puede introducirse por ejemplo para HTTP en todas las disposiciones mencionadas en las figuras 1, 2, 3 y 4. A este respecto podrían realizarse los tipos de procedimiento individuales de manera independiente unos de otros, lo que aumenta entre otras cosas la flexibilidad y/o la intercambiabilidad. Sin embargo una realización en componentes de sistema y/o aparatos combinados reduce potencialmente la complejidad global y/o los esfuerzos de configuración. No por último, los tipos de procedimiento individuales, en una realización total/parcialmente integrada y/o en una realización en la que se intercambian al menos informaciones de control individuales entre los componentes de los tipos de procedimiento, podrían realizarse y utilizarse de manera simplificada. Por ejemplo, mediante la utilización en conjunto, que abarca varios tipos de procedimiento, de informaciones de estado y/o identificadores de contexto, puede reducirse en algunos casos además la cantidad de informaciones de control que van a intercambiarse a través de la red y/o utilizarse de manera más eficaz. En algunos casos puede reducirse así también por ejemplo el intervalo de tiempo para el establecimiento de nuevas conexiones y/o del intercambio de datos.

II.b) Reconocimiento de posibilidades de compresión/control de la compresión

(i): Anteriormente se describió que pueden configurarse reglas (estáticas), de cómo y en qué cabeceras/campos de cabecera puede aplicarse una compresión de cabeceras. Sin embargo, esto requiere trabajos preparatorios y es además poco flexible por ejemplo con respecto a estructuras de red que varían o nodos/componentes de red adicionales que se suprimen o intercalados adicionalmente como por ejemplo encaminadores.

(ii): Puede ser ventajoso, como complemento a y/o en lugar de una configuración (estática) de este tipo, prever un reconocimiento y adaptación automático de la posible compresión de cabeceras. Un mecanismo de este tipo puede realizarse de manera distribuida entre dos o más compresores y/o unilateralmente en un compresor. El mecanismo de reconocimiento puede ser pasivo (sólo observar flujos de paquetes) o activo (por ejemplo enviar incluso paquetes para la determinación de las posibilidades de compresión). El mecanismo (independientemente de que se realice en uno o en varios compresores) puede obtener las informaciones necesarias de la red (por ejemplo mediante protocolos de encaminamiento, de señalización intermedia como por ejemplo RSVP, NSIS, SOCKS, MIDCOM, etc. y/u otros protocolos de control) y/o de una gestión de red y/o determinarlas por interacción de dos o más compresores. Pueden darse indicaciones mediante configuración inicial y/o continua.

Un mecanismo de este tipo reconoce de manera dinámica, parcial o totalmente de manera autónoma, qué cabeceras o campos de cabecera pueden incluirse en una compresión determinada. Esta determinación de las posibilidades de compresión puede realizarse con anterioridad a la puesta en marcha de la compresión, antes/durante el establecimiento de una o varias relaciones de comunicación y/o de manera continua durante la compresión activa.

A este respecto puede ser ventajoso que el mecanismo también reconozca automáticamente errores durante el funcionamiento (por ejemplo a partir de la transmisión o la no transmisión de los propios paquetes de datos comprimidos, sus tasas de pérdida y/o sus otras características de transmisión) y que saque a partir de ello conclusiones sobre modificaciones en el recorrido de transmisión (nueva selección de recorrido, adición de uno o más nodos adicionales, distribución de carga en varios encaminadores, etc.). Basándose en estas informaciones, el mecanismo puede adaptar entonces la compresión de cabeceras de manera correspondiente.

Un mecanismo de este tipo puede estar activo en diferentes desarrollos al mismo tiempo y también operar en paralelo como complemento y/o de manera desplazada en el tiempo con respecto a una configuración estática. Pueden utilizarse diferentes desarrollos (diferentes determinaciones dinámicas y/o configuraciones estáticas y/o negociaciones) al mismo tiempo y/o de manera secuencial para diferentes paquetes de datos de relaciones de comunicación individuales y/o de varias de las mismas. La identificación de qué mecanismos deben emplearse en qué (partes de una) relación/relaciones de comunicación puede producirse a su vez de manera estática o dinámica y/o depender de las propiedades de los paquetes de datos y/o los protocolos empleados y/o de la carga de red (actual, pasada, futura esperada) y/o de las propiedades de transmisión observadas (tasa de errores, tiempo de circulación, etc.).

(iii) En particular puede preverse, como complemento y/o en lugar de la configuración de qué campos/subcampos pueden incluirse en la compresión, intercambiar activamente por ejemplo paquetes de prueba según un esquema acordado previamente (de manera estática o dinámica). Así puede determinarse mediante pruebas sistemáticas sucesivas, qué campos de cabecera pueden comprimirse y cuáles deben estar presentas sin modificar y/o si la y/o qué partes de esa una o varias cabeceras de paquete deben conservarse en su estructura.

(iv) Puede ser ventajoso determinar de manera dinámica qué tipos de paquetes de datos están presentes, para adaptar la compresión de manera correspondiente. Así puede decidirse automáticamente por ejemplo mediante reconocimiento dinámico del tipo de un flujo de datos (por ejemplo de un flujo de datos multimedia basado en RTP), si y/o qué paquetes de datos deben optimizarse de qué manera. Como motivos de decisión pueden servir por ejemplo la viabilidad técnica (así pueden comprimirse por ejemplo paquetes cifrados peor que los descifrados) y/o la eficacia de la compresión y/o el esfuerzo (por ejemplo potencia de cálculo, memoria, etc.).

Puede ser ventajoso combinar entre sí estas dos (y dado el caso otras) etapas de reconocimiento y/o decisión (dinámicas y/o estáticas) y/o la compresión en sí mismas.

(v) Naturalmente también valen combinaciones de la configuración precedente y un reconocimiento automático. A este respecto podría realizarse por ejemplo previamente una distinción por cabecera de protocolo o campo de cabecera, de si esta parte siempre debe comprimirse, nunca debe comprimirse, o debe comprimirse dependiendo del resultado de un reconocimiento automático.

Alternativamente o en combinación, la compresión puede hacerse dependiente de determinados puntos terminales y/o aplicaciones implicados y/o de la carga en las redes de transmisión y/o en tramos de transmisión individuales/grupos de los mismos y/o de la memoria disponible y/o de la carga de CPU/ procesador de los componentes implicados. En función de criterios individuales o combinaciones de los mismos, la compresión puede activarse total/parcialmente, limitarse y/o desactivarse total/parcialmente. Tanto en el caso de una decisión de compresión estática como de una dinámica, esta decisión puede tomarse unilateralmente mediante componentes individuales o componentes de un lado de transmisión o en conjunto por varios componentes implicados o también componentes de sistema “adyacentes” como un sistema de gestión de red. A este respecto también es posible comprimir en primer lugar conexiones y durante la continuidad de las conexiones/de partes de las conexiones finalizar la compresión (y viceversa o alternando múltiples veces).

II.c) Compresión anidada o incremental

(i) Las descripciones anteriores para la compresión de centro a centro parten inicialmente de que los paquetes de datos que deben comprimirse por el compresor (por ejemplo X-1) están presentes como paquetes de datos no

comprimidos (“originales”) (o las descripciones anteriores no han distinguido adicionalmente, si los paquetes de

datos entrantes ya están comprimidos de alguna forma). De manera correspondiente, el descompresor (por ejemplo X-2) también reconstruye los paquetes de datos no comprimidos por completo o en partes esenciales. Sin embargo, la aplicación de los procedimientos anteriormente descritos no se limita a paquetes no comprimidos.

(ii) Si está presente una topología de red según una estructura tal como se representa en la figura 1e) o 3e), entonces los paquetes, que ya van a procesarse por la compresión C2 en la misma, ya se han comprimido previamente ya (parcial o totalmente) mediante la compresión C1.

Del mismo modo, una aplicación o un punto terminal podría generar por ejemplo ya paquetes de datos con compresión (de cabecera). (En el caso de una aplicación VoIP esto podría ser por ejemplo, tal como se describe en [9], cabeceras RTP comprimidas, pudiendo mantenerse sin comprimir las cabeceras UDP e IP situadas por debajo según [9].

En estos casos puede realizarse una compresión interna como compresión complementaria y/o de sustitución.

La compresión interna puede ser complementaria porque se comprimen cabeceras y/o campos de cabecera adicionales, que tal vez pueden ahorrarse en la transmisión en la red de transmisión en cuestión (N-X2 en el caso de la figura 1e) o 3e), en una etapa de compresión anidada.

La compresión puede ser de sustitución cuando, antes de la nueva compresión, se produce en primer lugar una descompresión, por ejemplo porque varias cabeceras o campos de cabecera pueden comprimirse entonces de manera más eficaz en conjunto.

Pueden estar activas una compresión complementaria y una de sustitución al mismo tiempo y/o de manera alternante en el tiempo.

Paquetes de datos no reconocidos y/o no comprimidos por la compresión externa pueden detectarse por la compresión interna y viceversa.

En todos los casos puede configurarse el reconocimiento de paquetes de datos comprimidos y el reconocimiento de las informaciones de cabecera que todavía deben comprimirse de nuevo de manera estática y/o determinarse de manera dinámica y/u obtenerse mediante interacciones con los componentes que participan en la compresión o externos.

Las compresiones individuales pueden referirse, tal como ya se describió anteriormente, a paquetes individuales y/o a secuencias de paquetes y/o a todos los paquetes de una relación de comunicación y/o un grupo de relaciones de comunicación. También pueden aplicarse en sucesión temporal de manera diferente.

Una compresión “interna” puede recurrir en algunas configuraciones por ejemplo a los identificadores de contexto de la compresión “externa”, para así reducir adicionalmente por ejemplo el volumen de datos y/o reducir la complejidad y/o

las informaciones de control de la compresión interna.

Por ejemplo, para paquetes de datos multimedia, que utilizan RTP, una compresión interna puede reconocer cabeceras CRTP en los paquetes de datos entrantes y entonces comprimir total o parcialmente de manera especialmente eficaz las cabeceras UDP e IP aún conservadas en la compresión externa (por ejemplo utilizando la compresión interna los identificadores de contexto/ID de flujo de la compresión externa e incluyendo las informaciones que deben comprimirse en las cabeceras UDP, IP total o parcialmente en el contexto al que hacen referencia los identificadores de contexto). Un anidamiento de este tipo puede continuar de manera recursiva o también continuar de manera secuencial y similar a la figura 1d) o 3d).

(iv) Alternativamente, sin embargo una compresión interna también puede comprimir menos cabeceras y/o campos de cabecera (por ejemplo, cuando en una red de transmisión interna se utilizan componentes intercalados, que permiten una compresión de determinadas cabeceras y/o campos de cabecera).

Sin embargo también es concebible una reducción del alcance de una compresión interna o incluso la supresión completa de una compresión para por ejemplo fines de cálculo de volumen y/o de monitorización y/o de intercepción simplificados y/o fines de registro. Alternativamente, para todos estos fines o algunos de ellos también pueden mantenerse sin modificar los propios sistemas terminales de transmisión y adicionalmente crearse un flujo de datos a partir de datos no comprimidos. También puede ser ventajoso en algunos casos (entre otras cosas en función de los procedimientos de compresión empleados), que los procedimientos de compresión utilizados en una compresión externa envíen informaciones de control adicionales a los componentes de (des)compresión internos o las intercambian con los mismos.

También es posible la introducción de cifrado de datos de manera alternativa o adicional o en combinación con procedimientos de compresión, con frecuencia también independientemente de su utilización anidada o incremental. Y también en la utilización de procedimientos de cifrado de datos puede ser ventajoso, entre otras cosas en función del fin de uso, los procedimientos empleados y los propósitos, intercambiar informaciones de control con componentes internos por ejemplo para posibilitar un descifrado.

II.d) Compresión de cabeceras en comunicación de punto a multipunto

(i): Como se describió anteriormente, la compresión de cabeceras de protocolo no tiene que limitarse a un trayecto entre dos compresores, sino que también puede comprender más de dos compresores. A este respecto son posibles en principio dos tipos de comunicación, que pueden estar (aunque no tienen que estar) preestablecidos

por la red subyacente: a) unidireccional desde exactamente un nodo S a muchos nodos R1, ..., Rn (n ; 1) sin que los nodos R1, ..., Rn tengan la posibilidad de enviar también paquetes al nodo S; b) bidireccional, de modo que es posible la transmisión de paquetes desde los nodos R1, ..., Rn al nodo S. En el caso b) los paquetes desde los nodos R1, ..., Rn al nodo S sólo pueden ser paquetes de control y/o también paquetes de datos comprimidos. En este último caso puede distinguirse todavía, si uno, varios o todos los nodos R1, ..., Rn pueden enviar paquetes de control y/o datos. Cada nodo Ri, que también envía paquetes de datos (comprimidos), funciona entonces del mismo modo que el nodo S de emisión.

(ii): También en una red de este tipo debe poder comprimirse según la presente invención (tal como se explicó anteriormente en A, B y/o C). Sin embargo, según el estado de la técnica para compresión de cabeceras tradicional, se requiere una comprensión común entre compresor y descompresor, que se ajusta de manera continua, lo que asume naturalmente una relación 1:1 entre compresor y descompresor. Sin embargo en cuanto varios descompresores obtienen paquetes de datos comprimidos de un compresor, lo que es el caso en el presente escenario, esta relación 1:1 se pierde.

La presente invención también es adecuada para la utilización de compresión de cabeceras en la comunicación de punto a multipunto (tal como está presente por ejemplo en una red de difusión por satélite o terrestre). Pueden aplicarse las mismas técnicas de compresión.

No obstante ha de tenerse en cuenta demasiado a menudo que los descompresores por ejemplo en (o “tras”) los nodos R1, ..., Rn pueden presentar diferentes capacidades y que los recorridos de transmisión a los diferentes descompresores pueden presentar propiedades diferentes. Un compresor debería posibilitar entonces a los descompresores importantes, a una pluralidad de los mismos y/o a todos, una descompresión de los paquetes de datos comprimidos. Esto puede suceder porque el compresor selecciona procedimientos y cabeceras/campos de cabecera para la compresión, que son aptos para todos los descompresores previstos. Y/o el compresor puede enviar paquetes de datos comprimidos de manera diferente a descompresores individuales y/o grupos de descompresores, que son adecuados específicamente para el recorrido de transmisión y/o descompresor respectivo. Y/o el compresor puede enviar información adicional (en paquetes de datos y/o de control existentes y/o adicionales) a descompresores individuales y/o grupos de descompresores (y/o nodos en las redes de transmisión), para posibilitar una retransmisión y descompresión satisfactoria de los paquetes de datos.

Puesto que en redes IP pueden perderse paquetes de datos (por ejemplo debido a errores de bit o sobrecarga), es posible que a uno, a varios o a todos los descompresores les falten informaciones para la correcta descompresión de un paquete de datos. En tal caso está previsto que un descompresor comunique al compresor (por tanto es posible la comunicación bidireccional directamente a través de redes de transmisión iguales o indirectamente a través de redes de transmisión parcial o totalmente diferentes), que faltan informaciones. El compresor puede decidir si y cuándo transmite, para la reconstrucción de las informaciones que faltan (del contexto), informaciones adicionales en paquetes de datos y/o de control existentes y/o adicionales. Esta decisión puede suceder en función de la relación de comunicación (tipo de datos, duración, etc.) y/o del/de los descompresor(es) en cuestión y/o del número de descompresores, que necesitan estas informaciones y/u otras informaciones de configuración y/o especificaciones y/o las propiedades de transmisión generales y/o actuales de la red. Alternativamente o de manera complementaria, un compresor también puede transmitir a intervalos regulares o no regulares informaciones redundantes para la eventual reconstrucción del contexto, por ejemplo mediante la utilización de FEC, pudiendo variar a lo largo del tiempo la tasa de transmisión de bits para las informaciones redundantes según la red, la carga de red supuesta o real, la tasa de errores de bits y/o paquetes esperada u observada o debido a la configuración o debido a la señalización de un sistema de gestión de red.

Es posible que uno o varios o todos los descompresores puedan enviar una realimentación acerca de informaciones que faltan y/o el contexto y/o el conocimiento local (estado) al compresor. En tal caso puede ser ventajoso que no todos los descompresores posibles también hagan esto, por ejemplo para evitar que el compresor o el trayecto de transmisión inverso se sobrecargue con demasiada información. En lugar de ello puede por ejemplo seleccionarse uno o varios descompresores como descompresores designados de un grupo o todos los descompresores; sólo estos descompresores designados proporcionan entonces realimentación como representación del grupo respectivo o de todos los receptores. No todos los descompresores tienen que estar representados por descompresores designados.

La selección de los descompresores designados puede establecerse de manera estática y/o negociarse de manera dinámica (por ejemplo el compresor puede determinar los descompresores) y/o establecerse debido a las características de transmisión con respecto a los descompresores y/o por las propiedades funcionales (características de rendimiento) de los descompresores y/o las propiedades con respecto a las cabeceras y/o campos de cabecera que pueden comprimirse en el respectivo recorrido de transmisión; en todos estos casos puede utilizarse también un componente aleatorio (números aleatorios reales, números pseudoaleatorios, funciones calculadas criptográficamente), para limitar adicionalmente la verdadera selección. Diferentes descompresores pueden enviar a este respecto con ayuda de uno o varios de estos criterios también en cada caso partes específicas de la información útil para el compresor información de realimentación útil. Tanto con respecto a uno o varios de los criterios como con respecto a las cantidades parciales transmitidas en cada caso, la selección puede producirse permanentemente y/o hasta una reconfiguración explícita y/o variar en el tiempo. La selección puede ser válida para todos los paquetes transmitidos por el compresor y/o para los paquetes de relaciones de comunicación individuales y/o grupos de relaciones de comunicación y/o para paquetes determinados por su tipo y/o por otras propiedades.

(iii) Un procedimiento de este tipo puede utilizarse por ejemplo a través de una red de radio terrestre (por ejemplo DVB

5 T, DVBH, WLAN, WiMAX, radiotelefonía móvil tal como GSM, UMTS, HS (D)PA, LTE, UWB, OFDM, etc.). También puede utilizarse a través de cualquier red por satélite, red de radio en el espacio, etc. Igualmente puede utilizarse en redes de difusión por cable (tales como redes por cable, DSL, fibra hasta tu casa, Ethernet, etc.). Estas redes pueden utilizarse individualmente o en cualquier combinación para la difusión.

10 Tal como ya se ha descrito, con todas las compresiones puede ir acompañado un cifrado completo y/o parcial de las informaciones. A este respecto pueden por ejemplo también crearse criptográficamente los identificadores de contexto e informaciones de contexto utilizados para la identificación de relaciones de comunicación (individuales), de modo que por ejemplo a un receptor intercalado no autorizado ni siquiera le quede claro qué paquetes por ejemplo deben asociarse a una relación de comunicación. Igualmente pueden servir informaciones criptográficas para la

15 autenticación/autorización o también priorización de informaciones de realimentación.

Las características de la invención dadas a conocer en la descripción anterior, en las reivindicaciones y en el dibujo pueden ser importantes tanto individualmente como en cualquier combinación para la implementación de la invención en sus diferentes formas de realización.

Claims

REIVINDICACIONES

1. Procedimiento para la optimización de una transmisión de datos entre puntos terminales de comunicación en una red con puntos terminales de comunicación, comprendiendo el procedimiento las etapas siguientes:

-

establecer una relación de comunicación o intentar establecer una relación de comunicación entre un punto terminal de comunicación y un punto terminal de comunicación adicional, estando prevista para la relación de comunicación una transmisión de datos orientada a paquetes, en la que se forma o debe formarse un flujo de datos que comprende paquetes de datos intercambiados,

-

proporcionar una disposición de optimizador asociada a la relación de comunicación, que se forma con al menos un optimizador, y

-

optimizar la transmisión de datos orientada a paquetes entre el punto terminal de comunicación y el punto terminal de comunicación adicional simulando, para la relación de comunicación, por medio de la disposición de optimizador, para el punto terminal de comunicación y/o el punto terminal de comunicación adicional, una continuación o una iniciación de la relación de comunicación durante una interrupción de la transmisión, concretamente un periodo, en el que entre el punto terminal de comunicación y el punto terminal de comunicación adicional no pueden intercambiarse paquetes de datos, en el que durante la simulación se continúa o se comienza una transmisión de paquetes de datos desde la disposición de optimizador al punto terminal de comunicación y/o al punto terminal de comunicación adicional.
2.

Procedimiento según la reivindicación 1, caracterizado porque la optimización de la transmisión de datos orientada a paquetes comprende una etapa destinada a retener datos del flujo de datos de la transmisión de datos orientada a paquetes.
3.

Procedimiento según la reivindicación 1 o 2, caracterizado porque la optimización de la transmisión de datos orientada a paquetes comprende unas etapas para generar localmente datos en la disposición de optimizador y para enviar los datos generados localmente al punto terminal de comunicación y/o al punto terminal de comunicación adicional.
4.

Procedimiento según al menos una de las reivindicaciones 1 a 3, caracterizado porque la optimización de la transmisión de datos orientada a paquetes comprende una etapa destinada a predecir propiedades de interrupción de la interrupción de la transmisión de la relación de comunicación.
5.

Procedimiento según al menos una de las reivindicaciones 1 a 4, caracterizado porque la optimización comprende una etapa destinada a solicitar de manera adicional y/o anticipada datos del flujo de datos de la transmisión de datos orientada a paquetes.
6.

Procedimiento según al menos una de las reivindicaciones anteriores, caracterizado porque la optimización de la transmisión de datos orientada a paquetes comprende una etapa destinada a aplicar el mecanismo de optimización a paquetes de datos seleccionados del flujo de datos, seleccionándose los paquetes de datos seleccionados, incluyendo al menos un criterio de selección de entre el siguiente grupo de criterios de selección:

- configuración de los puntos terminales de comunicación,

-

regla de selección estática,

-

regla de selección dinámica,

- propiedad de paquete de datos,

- secuencia de paquete de datos e

- información de tiempo relativa al flujo de datos.
7.

Procedimiento según al menos una de las reivindicaciones anteriores, caracterizado porque la optimización de la transmisión de datos orientada a paquetes comprende además las etapas siguientes:

- determinar, si cabe esperar un fallo o una interrupción de la transmisión de la transmisión de datos orientada a paquetes con respecto a la disposición de optimización en un trayecto de comunicación asociado al punto terminal de comunicación o en un trayecto de comunicación asociado al punto terminal de comunicación adicional, y

- adaptar el mecanismo de optimización al trayecto de comunicación determinado.
8.

Procedimiento según al menos una de las reivindicaciones anteriores, caracterizado porque la optimización de la transmisión de datos orientada a paquetes comprende además al menos una etapa seleccionada de entre el siguiente grupo de etapas:

- transmitir informaciones redundantes para al menos un paquete de datos del flujo de datos,

- introducir una información de corrección de errores hacia delante por medio de un paquete de datos adicional en el flujo de datos de la transmisión de datos orientada a paquetes,

- añadir una información de corrección de errores hacia delante a un paquete de datos del flujo de datos de la transmisión de datos orientada a paquetes,

- entrelazar para al menos una parte de los paquetes de datos del flujo de datos de la transmisión de datos orientada a paquetes y

- restablecer al menos parcialmente un orden de paquetes de datos para los paquetes de datos del flujo de datos de la transmisión de datos orientada a paquetes.
9.

Procedimiento según al menos una de las reivindicaciones anteriores, caracterizado porque la optimización de la transmisión de datos orientada a paquetes se realiza combinada con al menos una etapa de entre el siguiente grupo de etapas:

- procedimiento de mejora de rendimiento,

- compresión de datos,

- cifrado de datos y

- transcodificación de datos.
10.

Procedimiento según al menos una de las reivindicaciones anteriores, caracterizado porque la optimización de la transmisión de datos orientada a paquetes comprende una etapa destinada a controlar una funcionalidad de optimización del mecanismo de optimización en función de señales de red.
11.

Producto de programa informático con un código de programa, que opcionalmente está almacenado en un medio de almacenamiento legible por ordenador y que, cuando se ejecuta en un dispositivo informático, es apto para realizar un procedimiento según al menos una de las reivindicaciones anteriores.