ES2887650T3 - Conformación a nivel de dispositivo en una red de comunicaciones - Google Patents

Conformación a nivel de dispositivo en una red de comunicaciones Download PDF

Info

Publication number
ES2887650T3
ES2887650T3 ES17758330T ES17758330T ES2887650T3 ES 2887650 T3 ES2887650 T3 ES 2887650T3 ES 17758330 T ES17758330 T ES 17758330T ES 17758330 T ES17758330 T ES 17758330T ES 2887650 T3 ES2887650 T3 ES 2887650T3
Authority
ES
Spain
Prior art keywords
provider
network node
cpe
user
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES17758330T
Other languages
English (en)
Inventor
Sheridan Wright
Bakul Khanna
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Viasat Inc
Original Assignee
Viasat Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Viasat Inc filed Critical Viasat Inc
Application granted granted Critical
Publication of ES2887650T3 publication Critical patent/ES2887650T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/20—Traffic policing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0215—Traffic management, e.g. flow control or congestion control based on user or device properties, e.g. MTC-capable devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/38—Flow based routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/22—Traffic shaping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H04L47/263—Rate modification at the source after receiving feedback
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/14—Relay systems
    • H04B7/15—Active relay systems
    • H04B7/185—Space-based or airborne stations; Stations for satellite systems
    • H04B7/18578—Satellite systems for providing broadband data service to individual earth stations
    • H04B7/18595—Arrangements for adapting broadband applications to satellite systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Un método para la conformación de dispositivo de tráfico en una red de comunicaciones, comprendiendo el método: recibir (1004) un flujo (720) de enlace directo en un nodo (110) de red de lado de usuario desde una red (150) de proveedor, siendo el nodo de red de lado de usuario un nodo de red de intermediarios entre la red de proveedor y una red (115) de usuario local que tiene un conjunto de dispositivos (117) de tipo equipos en instalaciones del cliente, CPE; determinar (1008), por el nodo de red de lado de usuario a partir del flujo de enlace directo, un dispositivo (117) de tipo CPE de destino del conjunto de dispositivos de tipo CPE, clasificándose el dispositivo de tipo CPE de destino en una de una pluralidad de clases de dispositivo de acuerdo con una característica relevante para la velocidad predeterminada del dispositivo de tipo CPE de destino; identificar (1012), por un conformador de dispositivo del nodo de red de lado de usuario, una de una pluralidad de políticas de conformación de dispositivo almacenadas como correspondientes a la clase de dispositivo del dispositivo de tipo CPE de destino; y realimentar (1016) una indicación de la política de conformación de dispositivo identificada desde el nodo de red de lado de usuario a través de la red de proveedor, conformando de ese modo la comunicación posterior del flujo de enlace directo de acuerdo con la política de conformación de dispositivo identificada.

Description

DESCRIPCIÓN
Conformación a nivel de dispositivo en una red de comunicaciones
Campo
Las realizaciones se refieren, generalmente, a sistemas de comunicación y, más particularmente, a la conformación a nivel de dispositivo de tráfico en una red de comunicaciones.
Antecedentes
Muchas redes de comunicación proporcionan conectividad a través de al menos un enlace compartido entre grandes números de nodos de red de lado de usuario y una o más redes remotas, tales como una red de proveedor y/o Internet. Frecuentemente, múltiples dispositivos de tipo customer premises equipment (equipos en instalaciones del cliente - CPE) (p. ej., ordenadores portátiles, tabletas, teléfonos móviles, televisores inteligentes, etc.) pueden comunicarse con la red a través de un único nodo de red de lado de usuario. Por ejemplo, cada nodo de red de lado de usuario tiene una dirección de red pública (p. ej., dirección de protocolo de Internet), mientras a cada dispositivo de tipo CPE detrás del nodo de red de lado de usuario se le asigna una dirección de red privada que solo se garantiza que es única en el contexto de la red privada detrás del nodo de red de lado de usuario.
Los enlaces en una red de comunicaciones tienen un ancho de banda limitado y proporcionan conectividad a múltiples nodos de red de lado de usuario. Compartir un enlace implica atribuir el ancho de banda limitado entre esos nodos de red de lado de usuario. Normalmente, un conformador de tráfico en un nodo de red de lado de proveedor conforma tráfico de enlace directo destinado para cada nodo de red de lado de usuario en un enlace compartido antes de enviar el tráfico a través del enlace compartido. La conformación de tráfico puede atribuir el ancho de banda limitado entre los nodos de red de lado de usuario de una manera que es dinámica e inteligente, p. ej., que trata de cumplir con un objetivo de quality of service (calidad de servicio - QoS), o similar. Sin embargo, en redes que tienen dispositivos de tipo CPE dispuestos en redes privadas detrás de los nodos de red de lado de usuario, normalmente solo es el nodo de red de lado de usuario el que conoce los dispositivos de tipo CPE detrás de este en la red, de tal manera que los paquetes enviados a través de la red pública a esos dispositivos se marcan con la dirección pública del nodo de red de lado de usuario como destino. Como tal, los conformadores de tráfico tradicionales tienen dificultades para conformar tráfico considerando las características de los dispositivos de tipo CPE individuales detrás de los nodos de red de lado de usuario. En muchos casos, sin embargo, la conformación de tráfico que considera características de dispositivos de tipo CPE de destino particulares para el tráfico de enlace directo puede dar como resultado atribuciones de ancho de banda más eficientes, p. ej., satisfacer de manera más óptima los objetivos de QoS, en comparación con la conformación de tráfico que considera solo el nivel de nodo de red de lado de usuario.
US-9.276.665 B1 describe métodos, sistemas y dispositivos para proporcionar servicios de acceso a red a usuarios móviles a través de terminales móviles a través de un sistema por satélite.
Breve resumen
En las reivindicaciones independientes se establecen aspectos de la invención.
Entre otras cosas, se describen sistemas y métodos para proporcionar conformación a nivel de dispositivo de tráfico en una red de comunicaciones. Algunas realizaciones operan en una red de comunicaciones por satélite, u otras redes de comunicaciones, que proporcionan conectividad a grandes números de nodos de red de lado de usuario a través de uno o más enlaces de comunicaciones compartidos. Las realizaciones proporcionan técnicas para la conformación a nivel de dispositivo de tráfico en una red de comunicaciones. Las realizaciones operan en redes de comunicación que proporcionan conectividad a grandes números de nodos de red de lado de usuario a través de enlaces de comunicaciones compartidos. Por ejemplo, los dispositivos de tipo customer premises equipment (equipos en instalaciones del cliente - CPE) detrás de uno de los nodos de red de lado de usuario se clasifican en tipos de dispositivo según una característica relevante para la velocidad predeterminada del dispositivo de tipo CPE. Después de recibir un flujo de tráfico de forward-link (enlace directo - FL) destinado para uno de los dispositivos de tipo CPE, se identifica el tipo de dispositivo del dispositivo de tipo CPE, y se conforma el flujo de tráfico FL de acuerdo con una política de conformación de tráfico que corresponde al tipo de dispositivo de tipo CPE. Se personalizan diversas realizaciones para soportar arquitecturas que tienen conformadores a nivel de dispositivo y/o network address translators (traductores de direcciones de red - NAT) en nodos de red de lado de usuario y/o en un nodo de red de lado de proveedor.
Breve descripción de los dibujos
La presente descripción se describe conjuntamente con las figuras adjuntas:
la Fig. 1 muestra un entorno de comunicaciones ilustrativo, como contexto para diversas realizaciones;
la Fig. 2 muestra un entorno de comunicaciones ilustrativo que tiene una arquitectura en la que se implementan tanto funciones de conformación de dispositivo como funciones de traducción de direcciones de red en el nodo de red de lado de usuario, según diversas realizaciones;
las Figs. 3A y 3B muestran la conformación de dispositivo ilustrativa en una arquitectura, como el entorno de comunicaciones de la Fig. 2 ;
la Fig. 4 muestra un entorno de comunicaciones ilustrativo que tiene una arquitectura en la que se implementan tanto funciones de conformación de dispositivo como funciones de traducción de direcciones de red en el nodo de red de lado de proveedor, según diversas realizaciones;
las Figs. 5A y 5B muestran la conformación de dispositivo ilustrativa en una arquitectura, como el entorno de comunicaciones de la Fig. 4 ;
la Fig. 6 muestra un entorno de comunicaciones ilustrativo que tiene una arquitectura en la que se implementan funciones de conformación de dispositivo en el nodo de red de lado de proveedor, y se implementan funciones de traducción de direcciones de red en los nodos de red de lado de usuario, según diversas realizaciones;
las Figs. 7A y 7B muestran una conformación de dispositivo ilustrativa en una arquitectura, como el entorno de comunicaciones de la Fig.6 ;
la Fig. 8 muestra un sistema de comunicaciones por satélite ilustrativo para implementar diversas realizaciones descritas en la presente memoria;
la Fig. 9 muestra un sistema de comunicaciones híbrido ilustrativo para implementar diversas realizaciones descritas en la presente memoria; y
las Figs. 10 y 11 muestran diagramas de flujo ilustrativos de métodos para la conformación de dispositivo, según diversas realizaciones.
La Fig. 12 ilustra un ejemplo de un método para clasificar dispositivos de tipo CPE según diversas realizaciones.
En las figuras adjuntas, los componentes y/o las características similares pueden tener la misma etiqueta de referencia. Además, pueden distinguirse diversos componentes del mismo tipo siguiendo la etiqueta de referencia por una segunda etiqueta que distingue entre los componentes similares. Si solo se usa la primera etiqueta de referencia en la memoria descriptiva, la descripción es aplicable a uno cualquiera de los componentes similares que tienen la misma primera etiqueta de referencia independientemente de la segunda etiqueta de referencia.
Descripción detallada
En la siguiente descripción, se exponen numerosos detalles específicos para proporcionar una comprensión completa de la presente invención. Sin embargo, un experto en la técnica reconocerá que la invención puede ponerse en práctica sin estos detalles específicos. En algunos casos, no se han mostrado detalladamente circuitos, estructuras y técnicas para evitar el oscurecimiento de la presente invención.
La Fig. 1 muestra un entorno 100 de comunicaciones ilustrativo, como contexto para diversas realizaciones. Tal como se ilustra, el entorno 100 de comunicaciones incluye un número de nodos 110 de red de lado de usuario (p. ej., terminales de usuario) en comunicaciones con al menos un nodo 130 de red de lado de proveedor (p. ej., un nodo de núcleo) a través de una red 150 de proveedor. Los nodos 110 de red de lado de usuario pueden ser terminales de usuario fijos ubicados en la ubicación residencial o comercial de los usuarios. Alternativamente, los nodos 110 de red de lado de usuario pueden estar en una nave móvil, tal como aviones, trenes, automóviles, barcos, etc. El nodo 130 de red de lado de proveedor puede estar en comunicación con diversos proveedores, tales como proveedores 172 de servicios de comunicaciones, proveedores 174 de servicios de contenido, proveedores 176 de servicios empresariales y/u otros proveedores a través de una o más red(es) 170 de contenido. Por ejemplo, la(s) red(es) 170 de contenido puede(n) incluir Internet y/u otras redes públicas o privadas. La red 150 de proveedor puede incluir cualquier tipo adecuado de red de comunicaciones que se comunica con los nodos de red de lado de usuario a través de uno o más enlaces de comunicaciones compartidos. Por ejemplo, la red 150 de proveedor puede incluir enlaces de red por cable, inalámbricos, públicos, privados, seguros, inseguros y/u otros. En algunas realizaciones, la red 150 de proveedor es una red de comunicaciones por satélite implementada con uno o más satélites de geosynchronous earth orbit (órbita terrestre geosíncrona - GEO), satélites de medium earth orbit (órbita terrestre media - MEO), satélites de low earth orbit (órbita terrestre baja - LEO), etc. Otras realizaciones pueden incluir una red de digital subscriber line (línea de abonado digital - DSL), una red basada en cable, una red inalámbrica de long-term evolution (evolución a largo plazo - LTE), una red celular o similar.
Al menos algunos de los nodos 110 de red de lado de usuario proporcionan, o se acoplan con, una red 115 de usuario local respectiva, tal como una red Wi-Fi doméstica u otra red de área local privada. Cada red 115 de usuario local puede incluir uno o más dispositivos 117 de tipo consumer premises equipment (equipos en instalaciones del cliente -CPE) que se acoplan con su nodo 110 de red de lado de usuario respectivo a través de conexiones por cable o inalámbricas. Por ejemplo, los nodos 110 de red de lado de usuario pueden incluir cualquier interfaz de red local adecuada, tal como un encaminador por cable y/o inalámbrico que implementa una local area network (red de área local - LAN); y los dispositivos 117 de tipo CPE pueden ser dispositivos informáticos domésticos o de oficina, tales como ordenadores de escritorio, ordenadores portátiles, teléfonos inteligentes, dispositivos de tipo tableta, televisores habilitados para Internet u otros dispositivos, o similar. En algunos casos, un dispositivo 117 de tipo CPE también puede ser otra red 115 de usuario local (p. ej., otra LAN), que puede tener dispositivos 117 de tipo CPE adicionales conectados a este.
En arquitecturas que tienen redes 115 de usuario locales implementadas detrás de los nodos 110 de red de lado de usuario, el nodo 110 de red de lado de usuario puede incluir normalmente un network address translator (traductor de direcciones de red - NAT) que traduce entre una dirección del nodo 110 de red de lado de usuario y las direcciones de los dispositivos 117 de tipo CPE detrás del nodo de red de lado de usuario. Generalmente, la dirección del nodo 110 de red de lado de usuario la usa la red 150 de proveedor y/o la(s) red(es) 170 de contenido para identificar de manera única el nodo 110 de red de lado de usuario en el lado orientado hacia el público de la red del usuario, y se denomina en la presente invención “dirección pública” o “dirección de red pública” (p. ej., una dirección de Internet Protocol (protocolo de Internet -IP) pública y una combinación de puertos TCP/UDP). La dirección de cada dispositivo 117 de tipo CPE se usa para identificar de manera única el dispositivo 117 de tipo CPE en la red 115 de usuario local (p. ej., privada), y se denomina en la presente memoria “dirección privada” o “direcciones de red privadas” (p. ej., una dirección IP privada). Los términos “público” y “privado” solo pretenden aclarar la naturaleza de los dispositivos 117 de tipo CPE como efectivamente ocultos de los orígenes de contenido que envían contenido a esos dispositivos y reciben peticiones de contenido desde esos dispositivos. Por ejemplo, la dirección pública del nodo 110 de red de lado de usuario puede implementarse, en algunos casos, como una dirección IP pública para la(s) red(es) 170 de contenido y/u otros nodos de Internet pública, mientras algunos nodos 130 de red de lado de proveedor pueden implementar la dirección pública del nodo 110 de red de lado de usuario como una dirección IP privada según un nodo de red de lado de usuario de protocolo de comunicaciones particular (p. ej., punto de presencia o PoP). En la presente memoria se describen realizaciones para arquitecturas que implementan un NAT en el nodo 130 de red de lado de proveedor y para implementar NAT en cada nodo 110 de red de lado de usuario.
En la presente memoria se supone que múltiples nodos 110 de red de lado de usuario están en comunicación con el nodo 130 de red de lado de proveedor a través de uno o más enlaces de comunicaciones compartidos de la red 150 de proveedor. Dado que cada enlace de comunicaciones tiene una cantidad limitada de ancho de banda, el servicio de los nodos 110 de red de lado de usuario en un enlace puede implicar atribuir ese ancho de banda limitado entre esos nodos 110 de red de lado de usuario. De manera convencional, en tal arquitectura, un conformador de tráfico puede implementarse en el nodo 130 de red de lado de proveedor para “conformar” tráfico de forward-link (enlace directo - FL) destinado para los nodos 110 de red de lado de usuario antes de que el tráfico FL atraviese un enlace de comunicaciones compartido, de modo que el ancho de banda del enlace compartido se atribuye de manera dinámica e inteligente entre los nodos 110 de red de lado de usuario. La conformación de tráfico se refiere de manera convencional a descartar, retrasar o acelerar selectivamente la transmisión de paquetes de datos de un flujo de datos a través de un enlace de comunicaciones para reducir o aumentar el ancho de banda del enlace consumido por ese flujo de datos. Por ejemplo, las redes convencionales pueden incluir sistemas de gestión de tráfico que atribuyen ancho de banda del dominio de media access control (control de acceso a medios - MAC) media access control domain (dominio de control de acceso a medios -MACD) para cada MACD a través de todos los consumidores configurados del ancho de banda (p. ej., a través de todos los nodos 110 de red de lado de usuario, dependiendo de las cargas de tráfico reales, las velocidades de tráfico especificadas, los objetivos de quality of service (calidad de servicio - QoS) y la capacidad de ancho de banda variable de manera dinámica en diversas condiciones de carga del sistema). Frecuentemente, la conformación de tráfico puede realizarse en múltiples niveles de jerarquía, tal como en un nivel de virtual network operator (operador de red virtual - VNO), un nivel de nodo 110 de red de lado de usuario y un nivel de clase de tráfico. Tales enfoques pueden ayudar a proporcionar equidad entre todos los abonados del mismo plan y pueden funcionar bien bajo la suposición de que el objetivo es proporcionar a cada abonado en el mismo plan el mismo ancho de banda.
Sin embargo, la conformación de tráfico realizada al nodo 110 de red de lado de usuario, tradicionalmente no tiene en cuenta características de los dispositivos 117 de tipo CPE detrás del nodo 110 de red de lado de usuario. Por ejemplo, supóngase que un primer flujo de tráfico FL es una película de transmisión por secuencias desde un origen de contenido destinada a un teléfono inteligente con una pantalla pequeña, y un segundo flujo de tráfico FL es la misma película de transmisión por secuencias desde el mismo origen de contenido destinada a un ordenador portátil con una pantalla más grande. Un conformador de tráfico convencional tratará probablemente ambos flujos de tráfico FL de la misma manera, ya que ambos son el mismo tipo de tráfico procedente del mismo origen de contenido destinado al mismo tipo de nodo 110 de red de lado de usuario.
De manera convencional, el conformador de tráfico no tiene acceso a las direcciones privadas de los dispositivos 117 de tipo CPE, de tal manera que sus atribuciones de recursos de red se basan en los nodos 110 de red de lado de usuario, que son identificables públicamente en la red. Por ejemplo, cuando el nodo 130 de red de lado de proveedor recibe (p. ej., intercepta) tráfico FL, las cabeceras de paquete identifican el destino para el tráfico FL como la dirección pública del nodo 110 de red de lado de usuario (aunque, en última instancia, el nodo 110 de red de lado de usuario reenviará el tráfico a un dispositivo 117 de tipo CPE en su red 115 de usuario local). Como tal, aunque los conformadores de tráfico convencionales son capaces de identificar diferentes flujos de tráfico FL por su combinación de direcciones públicas y puertos, tienden a no ser capaces de asociar cada flujo de este tipo con un único dispositivo 117 de tipo CPE y, por tanto, no consideran características a nivel de dispositivo en sus determinaciones de conformación de tráfico.
Las realizaciones descritas en la presente memoria incluyen enfoques novedosos para la conformación de tráfico, que se denomina en la presente memoria “conformación de dispositivo” . A diferencia de la conformación a nivel de nodo de red de lado de usuario de muchos conformadores de tráfico convencionales, que realiza determinaciones de la conformación de tráfico basándose solo en características de los nodos 110 de red de lado de usuario sin tener conocimiento de los dispositivos 117 de tipo CPE detrás de esos nodos 110 de red de lado de usuario, la conformación de dispositivo permite que la red realice determinaciones de conformación de tráfico de una manera que considera diferentes características a nivel de dispositivo de diferentes dispositivos 117 de tipo CPE detrás de los nodos 110 de red de lado de usuario. En tales contextos, los términos “conformación” , “conformación de tráfico” , “conformación de dispositivo” y similares pretenden incluir ampliamente nociones convencionales de conformación de tráfico, así como cualquier otra acción emprendida para reducir o aumentar los recursos atribuidos de un enlace de comunicaciones según lo consumido por un flujo de datos. Por ejemplo, algunas realizaciones implican flujos de tráfico que tienen tráfico adaptativo, tal como tráfico de adaptive bit rate (velocidad de bits adaptativa - ABR), tráfico codificado de manera adaptativa (p. ej., tráfico de H.264 AVC), etc. En tales realizaciones, conformar el tráfico puede implicar que el proveedor de contenido seleccione una versión adecuada del tráfico que tiene una velocidad de bits particular, un conjunto particular de capas de codificación base y mejorada, etc. La conformación de dispositivo puede personalizar el ancho de banda de vídeo adaptativo, o gestionar de otro modo atribuciones de ancho de banda, a cada una de las múltiples clases de dispositivo, evitando de ese modo afectar a la quality of experience (calidad de experiencia - QoE) de los consumidores finales. Tales enfoques también pueden tender a liberar ancho de banda o bien para alojar abonados adicionales y/o bien para proporcionar mejor QoE para algunas o todas las clases de dispositivo. Algunas realizaciones operan en el contexto de ofertas de plan de servicios en las que los abonados usuarios tienen acceso ilimitado o, de cualquier otro modo, no se preocupan efectivamente sobre sus hábitos de uso o sobre la cantidad de ancho de banda que consumen.
Se describen diversas realizaciones en la presente memoria en el contexto de diferentes arquitecturas de red. Como una categoría general de realizaciones, la conformación de tráfico de enlace directo se realiza en los nodos 110 de red de lado de usuario. Por ejemplo, un nodo 110 de red de lado de usuario puede determinar a partir de los paquetes iniciales del flujo de tráfico de enlace directo si puede controlar el ancho de banda del enlace compartido que se consumirá por los paquetes posteriores del flujo. En caso afirmativo, el nodo 110 de red de lado de usuario puede realizar por sí mismo conformación de tráfico o proporcionar realimentación implícita o explícita a un conformador de tráfico en un nodo 130 de red de lado de proveedor u otro dispositivo de lado de proveedor (p. ej., proveedor 174 de contenido), provocando de ese modo la regulación del ancho de banda del enlace compartido, según sea apropiado para paquetes posteriores del flujo. Se describen ejemplos de tales realizaciones con referencia a las Figs. 2, 3A y 3B a continuación.
Como otra categoría general de realizaciones, un conformador de dispositivo en un nodo 130 de red de lado de proveedor está configurado para conformar tráfico hacia dispositivos 117 de tipo CPE individuales detrás de cada nodo 110 de red de lado de usuario de acuerdo con las características de cada dispositivo. Por ejemplo, un flujo de enlace de retorno desde un dispositivo 117 de tipo CPE particular puede marcarse en el nodo 110 de red de lado de usuario con un identificador que indica una clasificación del dispositivo 117 de tipo CPE que originó el flujo. Los componentes de un nodo 130 de red de lado de proveedor pueden almacenar (p. ej., en una look up table (tabla de búsqueda - LUT)) el identificador que indica la clasificación del dispositivo 117 de tipo CPE con datos que pueden usarse para identificar un flujo de enlace directo posterior asociado con el flujo de enlace de retorno. Cuando se recibe un flujo de enlace directo posterior en el nodo 130 de red de lado de proveedor, los componentes pueden usar los identificadores almacenados (p. ej., en la LUT) para determinar si el flujo de tráfico de enlace directo corresponde a un flujo de enlace de retorno conocido. En caso afirmativo, el conformador de dispositivo en el nodo 130 de red de lado de proveedor puede conformar el flujo de enlace directo de acuerdo con la clasificación del dispositivo 117 de tipo CPE que originó el flujo de enlace de retorno correspondiente. En algunas de tales realizaciones, el nodo 130 de red de lado de proveedor mantiene la conectividad con cada nodo 110 de red de lado de usuario en un enlace compartido mediante el uso de túneles virtuales (p. ej., túneles de capa 2), y diversas funciones de red “ privada” pueden realizarse por componentes del nodo 130 de red de lado de proveedor. Un ejemplo de una función de red privada en este contexto es la network address translation (funcionalidad de traducción de direcciones de red - NAT), que puede usarse para traducir entre una dirección de Internet protocol (protocolo de Internet - IP) privada de un dispositivo 117 de tipo CPE en una red 115 de usuario local y una dirección IP pública del nodo 110 de red de lado de usuario que acopla la red 115 de usuario local a otras redes (p. ej., la(s) red(es) 170 de contenido a través de la red 150 de proveedor). En otras de tales realizaciones, las funciones de red privada se realizan en los nodos 110 de red de lado de usuario (p. ej., el nodo 110 de red de lado de usuario incluye un NAT). Se describen ejemplos de estas realizaciones con referencia a las Figs. 4 - 7B a continuación.
La Fig. 2 muestra un entorno 200 de comunicaciones ilustrativo que tiene una arquitectura en la que se implementan tanto funciones de conformación de dispositivo como funciones de traducción de direcciones de red en el nodo 110 de red de lado de usuario, según diversas realizaciones. De manera similar a la Fig. 1, el entorno 200 de comunicaciones incluye un número de nodos 110 de red de lado de usuario (solo se muestra una para evitar complicar en exceso la Figura) en comunicación con al menos un nodo 130 de red de lado de proveedor a través de una red 150 de proveedor, y el nodo 130 de red de lado de proveedor puede estar en comunicación con diversos servicios de contenido a través de una o más red(es) 170 de contenido. Para evitar la complicación excesiva de las figuras, los servicios de contenido y similares, no se muestran de manera explícita. Los servicios de contenido pueden incluir servidores web, servicios de voice over Internet protocol (voz sobre protocolo de Internet - VoIP), proveedores de contenido multimedia, redes de distribución de contenido y/o cualquier otro servicio de contenido adecuado. El nodo 110 de red de lado de usuario se ilustra implementando una red 115 de usuario local que tiene múltiples dispositivos 117 de tipo CPE.
Tal como se ilustra, cada nodo 110 de red de lado de usuario puede incluir una interfaz 252 de red de proveedor que incluye cualquier puerto de red, componente transceptor y/u otros componentes adecuados para proporcionar conectividad entre el nodo 110 de red de lado de usuario y la red 150 de proveedor (o múltiples red(es) 150 de proveedor en algunas realizaciones). Además, cada nodo 110 de red de lado de usuario puede incluir una interfaz 217 de red de usuario que incluye cualquier puerto de red, interfaz de dispositivo y/u otros componentes adecuados para proporcionar conectividad entre el nodo 110 de red de lado de usuario y la red 115 de usuario local. Aunque no se muestra de manera explícita a lo largo de las diversas figuras, cualquier realización de los nodos 110 de red de lado de usuario descritos en la presente memoria puede incluir una o más interfaces 252 de red de proveedor y/o una o más interfaces 217 de red de usuario.
En la arquitectura ilustrada, hay un conformador 235 de lado de proveedor implementado en el nodo 130 de red de lado de proveedor y un conformador 215 de lado de usuario (p. ej., un conformador de dispositivo) implementado en el nodo 110 de red de lado de usuario. El conformador 235 de lado de proveedor puede implementarse como un conformador de tráfico de nivel de nodo de red de lado de usuario, realizando el conformador 215 de lado de usuario o facilitando la conformación a nivel del dispositivo 117 de tipo CPE (conformación de dispositivo). Algunas realizaciones realizan la totalidad de la conformación de dispositivo en el conformador 215 de lado de usuario (es decir, ninguna parte de la conformación de dispositivo se realiza en el conformador 235 de lado de proveedor). Tal como se ilustra, algunas realizaciones del conformador 215 de lado de usuario pueden incluir, o estar en comunicación con, uno o más almacenamientos 212 de datos que tienen, almacenados en los mismos, políticas de conformación de dispositivo y/u otra información relevante. Por ejemplo, tal como se describe en la presente memoria, los dispositivos 117 de tipo CPE se clasifican en clases de dispositivo basándose en características relevantes para la velocidad, y se identifican políticas apropiadas de conformación de dispositivo, en consecuencia. Como tal, el/los almacenamiento(s) 212 de datos puede(n) incluir información relacionada con clases de dispositivo, características relevantes para la velocidad, políticas de conformación de dispositivo (p. ej., reglas de conformación de dispositivo), etc.
El nodo 110 de red de lado de usuario también puede incluir un clasificador 210 de dispositivos, un network address translator (traductor 220 de direcciones de red - NAT) y un identificador 225 de flujo de enlace directo. Aunque se describen realizaciones que tienen el NAT 220 en el nodo 110 de red de lado de usuario, se pretende generalmente que tales descripciones incluyan cualquier implementación de las funciones de traducción de direcciones de red aguas abajo del conformador 235 de lado de proveedor (p. ej., entre el conformador 235 de lado de proveedor y el nodo 110 de red de lado de usuario). Por ejemplo, el NAT 220 puede implementarse fuera del nodo 110 de red de lado de usuario (p. ej., como un aparato independiente en el lado de usuario o lado de proveedor de la red 150 de proveedor), o incluso en el nodo 130 de red de lado de proveedor aguas abajo del conformador 235 de lado de proveedor. En cualquiera de estas u otras implementaciones, la conformación de dispositivo puede realizarse según las técnicas descritas con respecto a la Fig.2.
Además, las realizaciones pueden asociar un dispositivo 117 de tipo CPE particular con una de múltiples clases de dispositivo de cualquier manera adecuada. Por ejemplo, la Fig. 12 muestra un diagrama de flujo de un método 1200 ilustrativo para clasificar los dispositivos 117 de tipo CPE, según diversas realizaciones. Algunas realizaciones comienzan en la etapa 1204 detectando la conectividad de un dispositivo 117 de tipo CPE con la red 115 de usuario local. Por ejemplo, las realizaciones del clasificador 210 de dispositivos detectan nuevos dispositivos 117 de tipo CPE cuando establecen conectividad con el nodo 110 de red de lado de usuario. El dispositivo 117 de tipo CPE detectado puede identificarse basándose en su dirección MAC o cualquier otro identificador adecuado. Otras realizaciones pueden clasificar dispositivos en cualquier momento adecuado, incluidos en momentos distintos a cuando un dispositivo 117 de tipo CPE establece conectividad con la red 115 de usuario local. Por ejemplo, algunas realizaciones pueden auditar periódicamente conexiones locales para determinar qué dispositivos 117 de tipo CPE están presentes en la red 115 de usuario local. Alternativa o adicionalmente, las realizaciones pueden incluir una tabla de asociaciones precargada entre los dispositivos 117 de tipo CPE y las clasificaciones de dispositivos respectivas (p. ej., clasificaciones por defecto, etc.).
En la etapa 1206, en respuesta a la detección de un nuevo dispositivo 117 de tipo CPE, algunas implementaciones del clasificador 210 de dispositivos determinan si el dispositivo 117 de tipo CPE detectado se clasificó previamente. Por ejemplo, las realizaciones pueden consultar una tabla de asociaciones entre los dispositivos 117 de tipo CPE clasificados anteriormente y sus clases de dispositivo respectivas. Si la determinación es que el dispositivo 117 de tipo CPE ya está clasificado, las realizaciones pueden emprender cualquier acción adecuada, tal como volver a clasificar el dispositivo 117 de tipo CPE (p. ej., las clasificaciones pueden prescribir, etc.), actualizar la tabla de asociaciones para indicar que el dispositivo está conectado actualmente en la etapa 1220, o finalizar el método 1200. En algunas implementaciones, el clasificador 210 de dispositivos puede añadir de manera dinámica un conjunto de reglas de conformación de dispositivo basándose en políticas de conformación de dispositivo almacenadas para el nuevo dispositivo 117 de tipo CPE basándose en su clase de dispositivo determinada previamente (p. ej., y basándose en factores adicionales, tales como la congestión en la red presente). En algunas de tales implementaciones, el clasificador 210 de dispositivos puede expirar los dispositivos 117 de tipo CPE de rancio que han prescrito retirando las reglas de conformación de dispositivo para esos dispositivos 117 de tipo CPE después de algún tiempo (p. ej., periódicamente, después de un periodo predefinido sin uso, etc.). Tal como se describe en la presente memoria, otras implementaciones pueden realizar todo el manejo de las reglas de conformación de dispositivo mediante el conformador 215 de lado de usuario.
Si la determinación en la etapa 1206 es que el dispositivo 117 de tipo CPE detectado ya no tiene una clasificación almacenada, la clasificación del dispositivo 117 de tipo CPE puede implicar además la identificación de una o más características relevantes para la velocidad de cada dispositivo clasificado en la etapa 1208. Una característica relevante para la velocidad puede ser cualquier característica del dispositivo 117 de tipo CPE que pueda tener un impacto en la QoE con respecto a la velocidad de datos. Por ejemplo, una velocidad de datos particular puede proporcionar una QoE suficientemente alta para la visualización en una pantalla pequeña de teléfono inteligente, mientras que la misma velocidad de datos puede proporcionar una escasa QoE para la visualización en una pantalla de ordenador portátil grande. En algunas implementaciones, el sistema operativo y el tipo de dispositivo pueden usarse para categorizar dispositivos por área funcional (p. ej., reproductor multimedia, ordenador personal, ordenador portátil, tableta, teléfono inteligente, televisor habilitado para Internet, etc.), fidelidad de pantalla (p. ej., tamaño de pantalla, resolución, profundidad de color, códecs de vídeo soportados, etc.) y/u otras características relevantes para la velocidad de cada dispositivo 117 de tipo CPE. Aunque se comentó anteriormente la clasificación de los dispositivos 117 de tipo CPE basándose en características relevantes para la velocidad y se comenta en los párrafos siguientes, los dispositivos 117 de tipo CPE pueden clasificarse basándose en otras características.
Otros datos pueden usarse en otras realizaciones para determinar las características relevantes para la velocidad de un dispositivo 117 de tipo CPE. Como una implementación, el nombre del dispositivo 117 de tipo CPE en la red 115 de usuario local (denominado algunas veces “ nombre de equipo” ) se usa para derivar pistas sobre la clasificación del dispositivo. Por ejemplo, un dispositivo 117 de tipo CPE denominado “ iPhone de Juan Pérez” es probablemente un teléfono móvil con una pantalla de tamaño de teléfono móvil. En otra implementación, el fabricante del dispositivo, que puede estar indicado por un código OUI en la dirección MAC del dispositivo, puede usarse para derivar pistas sobre la clasificación del dispositivo. Por ejemplo, un código OUI que indica “Zenith” identifica, probablemente, un dispositivo 117 de tipo CPE que es un televisor y tiene una pantalla relativamente grande. En otra implementación, el tipo de conexión (p. ej., por cable o inalámbrica) entre el dispositivo 117 de tipo CPE y el nodo 110 de red de lado de usuario puede usarse para derivar pistas sobre la clasificación del dispositivo. Por ejemplo, es probable que las conexiones por cables correspondan a dispositivos 117 de tipo CPE que tienen pantallas más grandes (p. ej., televisores y ordenadores de escritorio), mientras que las conexiones inalámbricas correspondan a los dispositivos 117 de tipo CPE que tienen pantallas más pequeñas (p. ej., teléfonos móviles, tabletas y ordenadores portátiles). De manera similar, algunas implementaciones pueden determinar un modo Wi-Fi de soporte de operaciones en el lado LAN (p. ej., 802.11b, 802.11 g, 802.11n, 802.11ac) y/u otras propiedades diversas de conexión específicas para Wi-Fi; y tales propiedades pueden indicar otras características relevantes para la velocidad de los dispositivos 117 de tipo CPE conectados. En algunas implementaciones, se usan técnicas de deep packet inspection (inspección profunda de paquetes - DP) para derivar las características relevantes para la velocidad. Por ejemplo, pueden inspeccionarse cadenas de agente de usuario HTTP para derivar un sistema operativo y un tipo de dispositivo de una plataforma. En otras realizaciones, los dispositivos se clasifican de manera única (p. ej., se identifican características relevantes para la velocidad y se asocian con el dispositivo 117 de tipo CPE) basándose en combinaciones de nombre de equipo, organizationally unique identifier (identificadores únicos de organización - OUI) y propiedades de conexión (p. ej., conexión inalámbrica frente a por cable, velocidad de conexión inalámbrica, etc.). Algunas implementaciones permiten tal clasificación a través de la gestión integrada de módem, encaminador y equipos en la nube como parte de una red 150 de proveedor extendida.
En la etapa 1212, las realizaciones pueden determinar una clase de dispositivo adecuada, p. ej., basándose en las características relevantes para la velocidad identificadas del dispositivo 117 de tipo CPE. Por ejemplo, las implementaciones pueden incluir una tabla de búsqueda, o similar, que mapea ciertas características relevantes para la velocidad en ciertas clases de dispositivo. Como ejemplo, la tabla de búsqueda puede identificar clases de dispositivo de cualquier manera adecuada (p. ej., “clase_01” ; “clase_02” ; etc.), y cada una puede asociarse en la tabla de búsqueda con características relevantes para la velocidad particulares (p. ej., “clase_01” = dispositivo portátil de pantalla pequeña). La clase de dispositivo identificada puede asociarse con un identificador del dispositivo 117 de tipo CPE en la etapa 1216. Por ejemplo, una tabla de asociación de dispositivo puede actualizarse en la etapa 1220 para incluir una entrada que asocia la dirección MAC de un dispositivo 117 de tipo CPE detectado con la “clase_01” .
Tal como se describió anteriormente, puede ser deseable realizar la conformación de tráfico de una manera que considere características relevantes para la velocidad de los dispositivos 117 de tipo CPE que se asientan detrás de los nodos 110 de red de lado de usuario en la red. Sin embargo, debido al NAT 220 en cada nodo 110 de red de lado de usuario, el tráfico FL que atraviesa la red 150 de proveedor indica una dirección de destino correspondiente a un nodo 110 de red de lado de usuario (es decir, la dirección pública), no al dispositivo 117 de tipo CPE de destino real (que se identifica de manera privada en el NAT 220, pero no en el nodo 130 de red de lado de proveedor). Por consiguiente, las realizaciones descritas en el contexto de la arquitectura ilustrada tratan de determinar qué dispositivo 117 de tipo CPE se asocia con un flujo de tráfico FL después de que se realiza la traducción de direcciones por el NAT 220. El dispositivo 117 de tipo CPE identificado se habría clasificado en una clase de dispositivo por el clasificador 210 de dispositivos (p. ej., cuando el dispositivo 117 de tipo CPE se conectó por primera vez al nodo 110 de red de lado de usuario tal como se comentó anteriormente) y la clasificación se almacenó, y puede identificarse una política de conformación de dispositivo correspondiente para aplicarse al flujo de tráfico Fl por el clasificador 210 de dispositivos y/o por el conformador 215 de lado de usuario. En algunas realizaciones, el conformador 215 de lado de usuario puede implementar reglas de conformación de dispositivo de la política de conformación de dispositivo al menos parcialmente al comunicar las reglas, de manera implícita y/o explícita, de vuelta al conformador 235 de lado de proveedor.
Para mayor claridad, las Figs. 3A y 3B muestran la conformación de dispositivo ilustrativa en una arquitectura 300, como el entorno 200 de comunicaciones de la Fig. 2. En algunas implementaciones, el conformador 235 de lado de proveedor puede implementarse de manera similar a un conformador de tráfico convencional, y la funcionalidad de conformación de dispositivo se impone sobre el conformador 235 de lado de proveedor mediante el conformador 215 de lado de usuario. En otras realizaciones, no hay un conformador 235 de lado de proveedor.
Se ilustra un flujo 310 de tráfico FL en la Fig. 3A mediante una flecha de trazo grueso. El flujo 310 de tráfico FL comienza en un proveedor de contenido en una red 170 de contenido y fluye a través del nodo 130 de red de lado de proveedor (p. ej., el flujo 310 de tráfico FL puede fluir o no a través del conformador 235 de lado de proveedor en el nodo 130 de red de lado de proveedor). Los paquetes del flujo 310 de tráfico FL incluyen al menos un identificador del nodo 110 de red de lado de usuario de destino para el flujo 310 de tráfico FL. Por ejemplo, cada paquete incluye una cabecera que tiene una 5-tupla que indica una dirección IP de origen y un número de puerto de origen (del origen de contenido en la red 170 de contenido), un número de puerto de destino y una dirección IP de destino (del nodo 110 de red de lado de usuario de destino), y un identificador de protocolo. Inicialmente, el conformador 235 de lado de proveedor puede realizar la conformación de tráfico basándose, por ejemplo, en la congestión en el enlace presente, el tipo de tráfico, el nodo 110 de red de lado de usuario de destino y/u otras consideraciones. Sin embargo, se supone que la identificación de destino corresponde a la dirección pública del nodo 110 de red de lado de usuario, en lugar de la dirección privada del dispositivo 117 de tipo CPE de destino final, cuando el dispositivo 117 de tipo CPE de destino está detrás de un NAT 220 de lado de usuario. Como tal, el conformador 235 de lado de proveedor no realizará inicialmente la conformación de dispositivo, ya que desconoce las características del dispositivo 117 de tipo CPE de destino final para el flujo.
El flujo 310 de tráfico FL se comunica (según la identificación de destino en los paquetes) desde el nodo 130 de red de lado de proveedor al nodo 110 de red de lado de usuario de destino a través de la red 150 de proveedor. El NAT 220 en el nodo 110 de red de lado de usuario puede identificar el dispositivo 117 de tipo CPE de destino apropiado para el flujo 310 de tráfico FL. En algunas implementaciones, un identificador 225 de flujo de enlace directo puede identificar el flujo 310 de tráfico FL como portador de tráfico de velocidad adaptativa, asociar el flujo 310 de tráfico FL con un dispositivo 117 de tipo CPE de destino particular y /o asociar el flujo 310 de tráfico FL con un identificador de flujo FL. Por ejemplo, conociendo el dispositivo 117 de tipo CPE de destino final (p. ej., después de la traducción de direcciones mediante el NAT 220), el identificador 225 de flujo de enlace directo puede identificar una clasificación de dispositivo del dispositivo 117 de tipo CPE de destino (p. ej., un dispositivo de pantalla pequeña que soporta un códec de vídeo particular), y puede rotular el flujo 310 de tráfico FL con la clasificación de dispositivo identificada, o proporcionar de otro modo una indicación de la clasificación de dispositivo, de una manera que pueda usarse por el conformador 215 de lado de usuario. Se supone que el dispositivo 117 de tipo CPE de destino se clasificó previamente por el clasificador 210 de dispositivos en el nodo 110 de red de lado de usuario. Basándose en la clasificación de dispositivo asociada con el dispositivo 117 de tipo CPE de destino, el conformador 215 de lado de usuario puede determinar un perfil de conformación de dispositivo apropiado para aplicar al flujo 310 de tráfico FL (p. ej., si y cómo conformar el tráfico y/o ajustar la conformación del tráfico basándose en características relevantes para la velocidad del dispositivo 117 de tipo CPE de destino). En algunas implementaciones, el conformador 215 de lado de usuario puede incluir el identificador 225 de flujo de enlace directo (p. ej., estos pueden integrarse en un único componente).
Volviendo a la Fig. 3B, habiéndose determinado un perfil de conformación de dispositivo apropiado (p. ej., un conjunto de reglas de conformación de dispositivo) por el conformador 215 de lado de usuario, las realizaciones pueden usar diversas técnicas para efectuar las reglas de conformación de dispositivo en el conformador 235 de lado de proveedor. En algunas realizaciones, el conformador 215 de lado de usuario comunica de manera explícita la información de control de vuelta al conformador 235 de lado de proveedor (p. ej., a través del enlace compartido, a través de un canal de datos de control especial o de cualquier otra manera adecuada), que dirige el conformador 235 de lado de proveedor para implementar las reglas de conformación de dispositivo identificadas. En una de tales realizaciones, la información de control incluye directivas explícitas para el conformador 235 de lado de proveedor que corresponden a las reglas de conformación de dispositivo identificadas. En otra de tales realizaciones, la información de control identifica o bien un subconjunto de reglas o bien uno de un número de perfiles de conformación almacenados en el conformador 235 de lado de proveedor. Por ejemplo, el conformador 235 de lado de proveedor incluye, o está en comunicación con, una tabla de búsqueda u otro almacenamiento de datos que tiene, almacenado en el mismo, un conjunto de reglas y/o perfiles de conformación, y la información de control identifica cuáles de las reglas o los perfiles almacenados se activarán. En otras realizaciones, el conformador 215 de lado de usuario comunica de manera implícita la determinación de conformación de dispositivo de vuelta al conformador 235 de lado de proveedor. Por ejemplo, el conformador 215 de lado de usuario puede generar errores de paquete reales y/o aparentes (p. ej., enviando mensajes de negative acknowledgement (acuse de recibo negativo - NACK), descartando paquetes, etc.), indicando de manera implícita una condición de congestión al conformador 235 de lado de proveedor. El conformador 235 de lado de proveedor puede responder entonces a la condición de congestión aparente conformando el tráfico FL posterior, en consecuencia. En algunas implementaciones, para algunos tipos de tráfico, la información de congestión aparente puede realimentarse al proveedor de contenido; y el proveedor de contenido puede reaccionar en consecuencia, conformando de ese modo efectivamente el tráfico. Por ejemplo, algunos servicios multimedia de transmisión por secuencias pueden seleccionar automáticamente una versión apropiada de múltiples versiones de contenido, cada una codificada según una velocidad de bits diferente, en respuesta a la detección de condiciones de congestión.
Algunas realizaciones descritas en la presente memoria pretenden aplicarse a flujos 310 de tráfico FL que transportan tráfico de velocidad adaptativa. Tal como se describió anteriormente, el tráfico de velocidad adaptativa puede incluir tráfico codificado por adaptive bit rate (velocidad de bits adaptativa - ABR) y/u otro tráfico codificado de manera adaptativa. Generalmente, el tráfico de velocidad adaptativa también puede incluir generalmente tipos de tráfico que están codificados de manera múltiple (p. ej., por un distribuidor de contenido, en un origen de contenido, en el nodo 130 de red de lado de proveedor, etc.) en diferentes versiones que pueden comunicarse con diferentes impactos de recursos de enlace (p. ej., a diferentes velocidades de bits, a diferentes fidelidades, en diferentes formatos de codificación, etc.), de tal manera que la adaptación de velocidad puede incluir seleccionar y/o generar una versión apropiada del contenido en respuesta a una condición de conformación. Algunas realizaciones comienzan a transmitir el flujo 310 de tráfico FL en alguna calidad por defecto, o alguna calidad establecida previamente (p. ej., velocidad de bits); y, posteriormente, adaptarse en función de las determinaciones de conformación de dispositivo.
En aras de la ilustración, algunos orígenes de contenido envían paquetes de contenido a una velocidad por defecto (p. ej., o cualquier velocidad determinada previamente). Si no se recibe acuse de recibo (p. ej., mensaje “ACK” ) por el origen de contenido desde el nodo de destino (p. ej., el nodo 110 de red de lado de usuario) dentro de un periodo de tiempo de espera, el proveedor de contenido ajusta automáticamente su tráfico a una menor velocidad de bits. Por ejemplo, se supone que los paquetes se han descartado y se vuelven a enviar a la menor velocidad. Si no se recibe acuse de recibo a la menor velocidad, el proveedor de contenido puede continuar iterativamente disminuyendo la velocidad hasta que los acuses de recibo comiencen a recibirse, o se alcance la menor velocidad. En el contexto de tales orígenes de contenido, las realizaciones del conformador 215 de lado de usuario pueden afectar a la velocidad de datos de tráfico enviado desde tales orígenes de contenido descartando selectivamente paquetes, o pareciendo que se descartan paquetes (p. ej., al no enviar mensajes ACK), hasta que los paquetes comiencen a recibirse a una velocidad deseada. En tal implementación, por tanto, la realimentación 320 mostrada en la Fig. 3B puede estar implícita como una falta de mensajes ACK o como una presencia de mensajes NACK (negative acknowledgement - acuse de recibo negativo), al origen de contenido. Obsérvese que, por tanto, la realimentación 320 pretende cubrir ampliamente no solo la realimentación explícita sino también tal realimentación implícita. Además, la realimentación 320 puede ser al conformador 235 a nivel de UT y/u otro dispositivo tal como el proveedor de contenido que es el origen del flujo 310 FL.
La Fig. 4 muestra un entorno 400 de comunicaciones ilustrativo que tiene una arquitectura en la que se implementan tanto funciones de conformación de dispositivo como funciones de traducción de direcciones de red en el nodo 130 de red de lado de proveedor, según diversas realizaciones. De manera similar a las Figs. 1 y 2 , el entorno 400 de comunicaciones incluye un número de nodos 110 de red de lado de usuario (solo se muestran dos para evitar complicar en exceso la Figura) en comunicación con al menos un nodo 130 de red de lado de proveedor a través de una red 150 de proveedor, y el nodo 130 de red de lado de proveedor puede estar en comunicación con diversos servicios de contenido a través de una o más red(es) 170 de contenido. Tal como se ilustra, cada nodo 130 de red de lado de proveedor puede incluir una interfaz 452 de red de proveedor que incluye cualesquiera componentes adecuados para proporcionar conectividad entre el nodo 130 de red de lado de proveedor y la red 150 de proveedor (o múltiples red(es) 150 de proveedor en algunas realizaciones); y cada nodo 130 de red de lado de proveedor puede incluir una interfaz 472 de red de contenido que incluye cualesquiera componentes adecuados para proporcionar conectividad entre el nodo 130 de red de lado de proveedor y una o más red(es) 170 de contenido. Aunque no se muestra de manera explícita en las diversas figuras, cualquiera de las realizaciones de nodos 130 de red de lado de proveedor descritas en la presente memoria puede incluir una o más interfaces 452 de red de proveedor y/o una o más interfaces 472 de red de contenido.
Cada nodo 110 de red de lado de usuario se ilustra implementando una red 115 de usuario local respectiva, y cada red 115 de usuario local se muestra con múltiples dispositivos 117 de tipo CPE. Como en la arquitectura de la Fig. 2 , cada nodo 110 de red de lado de usuario incluye un clasificador 210 de dispositivos. A diferencia de la Fig. 2 , cada nodo 110 de red de lado de usuario incluye un marcador 425 de flujo de return-link (enlace de retorno - RL); y el nodo 130 de red de lado de proveedor incluye un conformador 435 de lado de proveedor, un NAT 420, un identificador 445 de flujo FL, un módulo 440 de flujo RL y un almacenamiento 450 de datos de flujo. Como también se muestra, cada nodo 110 de red de lado de usuario incluye un módulo 421 de tunelización mediante el cual se establece un túnel de red entre el nodo 110 de red de lado de usuario y un módulo 422 de tunelización similar en el nodo 130 de red de lado de proveedor. En la arquitectura ilustrada, debido a que el NAT 420 se implementa en el nodo 130 de red de lado de proveedor, el conformador 435 de lado de proveedor puede tener conocimiento de, y puede considerar características de, los dispositivos 117 de tipo CPE de destino finales de flujos de tráfico FL, permitiendo de ese modo la conformación de dispositivo en el conformador 435 de lado de proveedor. El NAT 420 puede implementar la funcionalidad NAT de cualquier manera adecuada. Por ejemplo, el NAT 420 puede implementar la funcionalidad NAT tradicional. Como otro ejemplo, el NAT 420 puede implementar la funcionalidad de carrier grade network address translation (traducción de direcciones de red de grado de portadora - CGNAT).
Aunque no se muestra de manera explícita, algunas realizaciones del conformador 435 de lado de proveedor pueden incluir, o estar en comunicación con, uno o más almacenamientos 212 de datos (p. ej., de manera similar al/a los almacenamiento(s) 212 de datos descrito(s) con referencia a la Fig. 2). Los almacenamientos de datos pueden tener, almacenada en los mismos, cualquier información adecuada relacionada con clases de dispositivo, características relevantes para la velocidad, políticas de conformación de dispositivo (p. ej., reglas de conformación de dispositivo), etc. Los módulos 421 y 422 de tunelización pueden proporcionar un único túnel de red entre el nodo 130 de red de lado de proveedor y cada nodo 110 de red de lado de usuario. Tal como se observará, el identificador único asociado con cada uno de tales túneles puede usarse para registrar cuáles nodos 110 de red de lado de usuario se asocian con qué flujos en el nodo 130 de red de lado de proveedor (tal como se describe a continuación). Por ejemplo, un flujo de tráfico RL recibido en el nodo 130 de red de lado de proveedor puede incluir la dirección de red del dispositivo 117 de tipo CPE originador (p. ej., el dispositivo 117aa de tipo CPE), sin una indicación del nodo 110 de red de lado de usuario asociado con ese dispositivo 117 de tipo CPE originador. Sin embargo, el identificador de túnel puede usarse como una indicación del nodo 110 de red de lado de usuario asociado.
Las realizaciones que operan en la arquitectura ilustrada pueden usar el marcador 425 de flujo RL para marcar flujos de tráfico RL en asociación con un dispositivo 117 de tipo CPE particular. En algunas realizaciones, el marcador 425 de flujo RL recibe un flujo RL desde un dispositivo 117 de tipo CPE. El marcador 425 de flujo RL puede asociar el flujo RL con una indicación de la clasificación de dispositivo del dispositivo 117 de tipo CPE originador, que se clasificó previamente por el clasificador 210 de dispositivos. Por ejemplo, el marcador 425 de flujo RL puede marcar los paquetes del flujo RL con una indicación de la clasificación de dispositivo del dispositivo 117 de tipo CPE originador. Cuando el flujo Rl se recibe por el nodo 130 de red de lado de proveedor, los datos que caracterizan el flujo RL (p. ej., los datos asociados con el flujo RL mediante el marcador 425 de flujo RL) pueden almacenarse mediante el módulo 440 de flujo RL en el almacenamiento 450 de datos de flujo. Por ejemplo, los datos que identifican el flujo RL pueden almacenarse en el almacenamiento 450 de datos de flujo con datos que identifican el tipo del dispositivo 117 de tipo CPE que originó el flujo RL. Cuando se recibe un flujo de tráfico FL correspondiente en el nodo 130 de red de lado de proveedor, el identificador 445 de flujo FL puede buscar en el almacenamiento 450 de datos de flujo un flujo RL correspondiente, y si se encuentra, puede identificar el tipo del dispositivo 117 de tipo CPE al que está destinado el flujo FL. Después, el conformador 435 P-S puede conformar el flujo FL al tipo del dispositivo 117 de tipo CPE de destino.
Para mayor claridad, las Figs. 5A y 5B muestran la conformación de dispositivo ilustrativa en una arquitectura 500, como el entorno 400 de comunicaciones de la Fig. 4. Tal como se describió anteriormente, el entorno 400 de comunicaciones está diseñado con una arquitectura para usar componentes del nodo 130 de red de lado de proveedor para implementar cierta funcionalidad que estaría normalmente en el nodo 110 de red de lado de usuario. Particularmente, la funcionalidad NAT puede implementarse en un NAT 420 de lado de proveedor. Tal como se mencionó anteriormente, pueden usarse túneles virtuales para proporcionar conectividad entre el módulo 422 de tunelización en el nodo 130 de red de lado de proveedor y un módulo 421 de tunelización correspondiente en cada nodo 110 de red de lado de usuario a través de los enlaces compartidos de la red 150 de proveedor. Tal arquitectura puede usarse como parte de una implementación de computación virtual, por ejemplo, como en una oferta de servicios en la nube construida con técnicas de redes o virtualización de funciones de red definidas por software.
Volviendo en primer lugar a la Fig. 5A, se muestra un flujo 510 de tráfico de return-link (enlace de retorno - RL) como una flecha de trazo grueso. El flujo 510 de tráfico RL comienza en un dispositivo 117a de tipo CPE de origen y está destinado a un nodo de contenido u otro destino en la red 170 de contenido (p. ej., el flujo 510 de tráfico RL corresponde a una petición de contenido desde el dispositivo 117a de tipo CPE a un servidor de contenido en la red 170 de contenido). En una ubicación etiquetada como ‘A’, los paquetes del flujo 510 de tráfico RL incluyen información de cabecera que identifica una dirección de origen como la dirección privada (p. ej., dirección IP privada) del dispositivo 117a de tipo CPE, y una dirección de destino como la dirección pública del nodo de contenido de destino. Puede suponerse que el dispositivo 117a de tipo CPE se ha clasificado por un clasificador 210a de dispositivos, tal como se describió anteriormente.
El flujo 510 de tráfico RL se recibe por el nodo 110a de red de lado de usuario. Un marcador 425 de flujo RL en el nodo 110 de red de lado de usuario marca paquetes del flujo 510 de tráfico RL con un identificador que indica la clasificación de dispositivo del dispositivo 117a de tipo CPE de origen. Luego, el módulo 421a de tunelización encapsula los paquetes con una cabecera de túnel que identifica el módulo 422 de tunelización en el nodo 130 de red de lado de proveedor como el punto final del túnel. La cabecera de túnel también puede incluir un identificador único de túnel que distingue al túnel de todos los demás túneles entre el nodo 130 de red de lado de proveedor y otros nodos 110 de red de lado de usuario. Por consiguiente, en la ubicación etiquetada como ‘B’ (es decir, donde los paquetes del flujo 510 de tráfico RL salen del nodo 110a de red de lado de usuario destinados al nodo 130 de red de lado de proveedor), cada paquete se asocia con uno o más identificadores que indican una dirección de origen como la dirección privada del dispositivo 117a de tipo CPE, una dirección de destino como la dirección pública del nodo de contenido, un tipo de clasificación del dispositivo 117a de tipo CPE (p. ej., una etiqueta de tipo de dispositivo real, un índice a una lista de tipos de dispositivo almacenados, etc.), y un identificador de túnel (que identifica de manera única el nodo 110a de red de lado de usuario de todos los demás nodos 110 de red de lado de usuario conectados a través de la red 150 de proveedor al nodo 130 de red de lado de proveedor). Aunque se describen realizaciones que usan un identificador de túnel para identificar efectivamente el nodo 110a de red de lado de usuario al nodo 130 de red de lado de proveedor, puede usarse cualquier identificador adecuado en realizaciones alternativas. Por ejemplo, el paquete puede etiquetarse con una identificación del propio nodo 110a de red de lado de usuario.
El flujo 510 de tráfico RL atraviesa la red 150 de proveedor y llega al nodo 130 de red de lado de proveedor. En el nodo 130 de red de lado de proveedor, un módulo 440 de flujo RL almacena información de identificación para el flujo 510 de tráfico RL en un almacenamiento 450 de datos de flujo. Por ejemplo, el módulo 440 de flujo RL puede asociar un identificador de flujo RL con el flujo 510 de tráfico RL, y el identificador de flujo RL puede almacenarse en el almacenamiento 450 de datos de flujo en asociación con una indicación de la clasificación de dispositivo del dispositivo 117a de tipo CPE. En algunas implementaciones, para cada flujo RL recibido en el nodo 130 de red de lado de proveedor, el almacenamiento 450 de datos de flujo tiene una entrada que incluye direcciones de origen y destino invertidas del flujo RL (que, por tanto, identificarán un flujo de enlace directo posterior que corresponde al flujo 510 de tráfico RL almacenado), un identificador de túnel, y una indicación de la clasificación de dispositivo del dispositivo 117a de tipo CPE de origen. En la implementación descrita, el destino FL almacenado corresponderá a la dirección privada del dispositivo 117a de tipo CPE, y no a la dirección pública del nodo 110a de red de lado de usuario; pero el identificador de túnel será único para el nodo 110a de red de lado de usuario. Después del procesamiento por el módulo 440 de flujo RL, los paquetes del flujo 510 de tráfico RL se preparan para la comunicación al nodo de contenido de destino. En algunas realizaciones, el módulo 440 de flujo RL extrae efectivamente la clasificación de dispositivo de los paquetes del flujo 510 RL, y el módulo 422 de tunelización desencapsula los paquetes. El NAT 420 traduce la dirección de origen de red de los paquetes desde la dirección de red privada del dispositivo 117a de tipo CPE de origen a la dirección de red pública del nodo 110a de red de lado de usuario. Por consiguiente, en la ubicación etiquetada como ‘C’ (es decir, cuando los paquetes del flujo 510 de tráfico RL salen del nodo 130 de red de lado de proveedor destinados a la red 170 de contenido), cada paquete se etiqueta con una dirección de origen como la dirección pública del nodo 110a de red de lado de usuario de origen y una dirección de destino como la dirección pública del nodo de contenido.
Volviendo a la Fig. 5B, se indica un flujo 520 de tráfico de forward-link (enlace directo - FL) mediante una flecha de trazo grueso, y se supone que el flujo 520 de tráfico FL corresponde al flujo 510 de tráfico RL de la Fig. 5A. Tal como se usa en la presente memoria, las referencias a un flujo de FL y flujo de RL “correspondientes” entre sí pretenden indicar, generalmente, que el tráfico en los dos flujos forma parte de una misma transacción de comunicaciones. Por ejemplo, el flujo 510 RL puede ser una petición de contenido desde un dispositivo 117 de tipo CPE a un origen de contenido en la red 170 de contenido, y el flujo 520 FL puede ser parte o la totalidad del contenido solicitado que se envía por el origen de contenido al dispositivo 117 de tipo CPE solicitante. En una ubicación etiquetada como ‘D’ (es decir, cuando los paquetes del flujo 520 de tráfico FL se reciben en el nodo 130 de red de lado de proveedor desde la red 170 de contenido), cada paquete se etiqueta con una dirección de destino como la dirección pública del nodo 110a de red de lado de usuario de destino y una dirección de origen como la dirección pública del nodo de contenido de origen (es decir, la inversa del etiquetado de los paquetes en la ubicación ‘C’ de la Fig. 5A). En el nodo 130 de red de lado de proveedor, el NAT 420 traduce la dirección de red de destino desde la dirección pública del nodo 110a de red de lado de usuario a la dirección de red privada del dispositivo 117a de tipo CPE de destino. El módulo 422 de tunelización encapsula paquetes del flujo 520 FL, que identifica el módulo 421 a de tunelización en el nodo 110a de red de lado de usuario del dispositivo 117a de tipo CPE de destino como el punto final de un túnel de red que seguirán los paquetes.
Por consiguiente, en una ubicación etiquetada como ‘E’ (es decir, un punto en el que los paquetes del flujo de tráfico FL han pasado a través del NAT 420 y el módulo 422 de tunelización, el contenido de cada paquete incluye lo siguiente: la dirección de red de destino del paquete es la dirección de red privada del dispositivo 117a de tipo CPE de destino, la dirección de red de origen del paquete es la dirección de red del origen de contenido en la red 170 de contenido, y el paquete se encapsula en una cabecera de túnel que identifica el módulo 421a de tunelización como el punto final del túnel. Los paquetes pueden recibirse por el identificador 445 de flujo FL en el nodo 130 de red de lado de proveedor, que puede intentar hacer coincidir el flujo 520 de tráfico FL con un flujo almacenado en el almacenamiento 450 de datos de flujo (correspondiente a algún flujo 510 de tráfico RL monitorizado anteriormente). En el ejemplo ilustrado, el etiquetado de paquetes en la ubicación ‘E’ puede ser efectivamente la inversa del etiquetado de los paquetes en la ubicación ‘B’ de la Fig. 5A , de tal manera que el etiquetado de los paquetes del flujo 520 de tráfico FL corresponda sustancialmente a la entrada en el almacenamiento 450 de datos de flujo generado a partir del etiquetado del flujo 510 de tráfico RL correspondiente.
Tal como se describió anteriormente, la entrada en el almacenamiento 450 de datos de flujo puede incluir una indicación de la clasificación de dispositivo del dispositivo 117 de tipo CPE de destino (el dispositivo 117a de tipo CPE en el caso ilustrado). Como tal, el conformador 435 de lado de proveedor puede usar la clasificación de dispositivo indicada para determinar un perfil de conformación de dispositivo apropiado para aplicarse al flujo 520 de tráfico FL. Por ejemplo, si el dispositivo 117a de tipo CPE es un dispositivo de pantalla pequeña, el conformador 435 de lado de proveedor puede conformar la comunicación del flujo 520 de tráfico FL según un perfil de conformación de pantalla pequeña (p. ej., y según la congestión en el enlace presente y/u otros factores). En algunas implementaciones, el conformador 435 de lado de proveedor recibe información de clasificación de dispositivo como un mensaje del identificador 445 de flujo FL. En otras implementaciones, el identificador 445 de flujo FL puede adjuntar la indicación de clasificación de dispositivo a los paquetes del flujo 520 de tráfico FL antes de reenviar los paquetes al conformador 435 de lado de proveedor, y el conformador 435 de lado de proveedor puede extraer la indicación de clasificación de dispositivo de los paquetes antes de reenviar el flujo 520 de tráfico FL a través de la red 150 de proveedor. El flujo 520 de tráfico FL conformado de dispositivo puede comunicarse a través del túnel virtual al nodo 110a de red de lado de usuario de destino, y encaminarse por el nodo 110a de red de lado de usuario al dispositivo 117a de tipo CPE de destino. En algunas implementaciones, el conformador 435 de lado de proveedor puede incluir el identificador 445 de flujo FL (p. ej., pueden integrarse en un único componente).
La Fig. 6 muestra un entorno de comunicaciones ilustrativo que tiene una arquitectura en la que se implementan funciones de conformación de dispositivo en el nodo 130 de red de lado de proveedor, y se implementan funciones de traducción de direcciones de red en los nodos 110 de red de lado de usuario, según diversas realizaciones. De manera similar a las Figs. 1, 2 y 4 , el entorno 600 de comunicaciones incluye un número de nodos 110 de red de lado de usuario (solo se muestra uno para evitar complicar en exceso la Figura) en comunicación con al menos un nodo 130 de red de lado de proveedor a través de una red 150 de proveedor, y el nodo 130 de red de lado de proveedor puede estar en comunicación con diversos servicios de contenido a través de una o más red(es) 170 de contenido. El nodo 110 de red de lado de usuario se ilustra implementando una red 115 de usuario local que tiene múltiples dispositivos 117 de tipo CPE.
Como en la arquitectura de la Fig. 2 , cada nodo 110 de red de lado de usuario incluye un clasificador 210 de dispositivos y un NAT 220; y como en la arquitectura de la Fig. 4 , cada nodo 110 de red de lado de usuario incluye un marcador 425 de flujo RL. Además, como en la arquitectura de la Fig. 4 , el nodo 130 de red de lado de proveedor incluye un conformador 435 de lado de proveedor, un identificador 445 de flujo FL, un módulo 440 de flujo RL y un almacenamiento 450 de datos de flujo. En tal arquitectura, puede usarse marcado de flujo de tráfico RL para ayudar a habilitar la conformación de dispositivo de lado de proveedor (p. ej., como en la Fig. 4), pero se implementan técnicas adicionales para superar la falta de conocimiento del nodo 130 de red de lado de proveedor de la identidad de los dispositivos 117 de tipo CPE de destino para los flujos de tráfico FL.
En una realización alternativa, el NAT 420 también puede incluir (o estar en comunicación con otro componente que implementa) funcionalidad del dynamic host configuration protocol (protocolo de configuración dinámica de anfitrión -DHCP). Por ejemplo, en algunas realizaciones (incluidas algunas implementaciones que operan en el contexto de la arquitectura de la Fig. 6), cuando un nuevo dispositivo 117 de tipo CPE es detectado por el nodo 110 de red de lado de usuario, un servidor DHCP en el nodo 110 de red de lado de usuario asigna una dirección IP privada al dispositivo 117 de tipo CPE detectado. En la realización alternativa, las funciones del servidor DHCP pueden moverse al nodo 130 de red de lado de proveedor. Por ejemplo, las funciones DHCP pueden estar en una configuración denominada algunas veces carrier grade NAT (NAT de grado de portadora -CGNAT). Cuando se detecta un nuevo dispositivo 117 de tipo CPE en un nodo 110 de red de lado de usuario, puede enviarse un mensaje de petición DHCP por el nodo 110 de red de lado de usuario a través de la red 150 de proveedor a la función DHCP de lado de proveedor en el nodo 130 de lado de proveedor, y la función DHCP de lado de proveedor puede asignar una dirección IP privada al dispositivo 117 de tipo CPE recientemente detectado. En algunas realizaciones, la petición DHCP puede comprender un rango de puertos NAT para el nuevo dispositivo 117 de tipo CPE. Independientemente, el nodo 130 de red de lado de proveedor puede enviar de vuelta un mensaje de respuesta al nodo 110 de red de lado de usuario con la dirección IP privada asignada del dispositivo 117 de tipo CPE recientemente detectado. Los mensajes de petición y respuesta de DHCP pueden dar como resultado que se comunique tráfico adicional a través de la red 150 de proveedor, en comparación con otros enfoques descritos en la presente memoria. Tal como se comentó anteriormente, el clasificador 210 de dispositivos en el nodo 110a de red de lado de usuario clasifica el dispositivo recientemente detectado, y en algunas realizaciones, el nodo 130 de red de lado de proveedor puede enviar una petición al nodo 110a de red de lado de usuario para la clasificación del dispositivo 117a de tipo CPE recientemente detectado. Por ejemplo, una función de contexto de dispositivo en el nodo 130 de red de lado de proveedor puede analizar los mensajes de petición y respuesta de DHCP (p. ej., que pueden incluir información relacionada con la dirección MAC del dispositivo, OUI, nombre de equipo y otras características del dispositivo, así como las direcciones IP privadas asignadas y el rango de puertos NAT) y pueden consultar al clasificador 210 de dispositivos (u otro componente en comunicación con los listados de clasificación de dispositivos) para obtener una clasificación para el dispositivo 117 de tipo CPE detectado. De esta manera, el nodo 130 de red de lado de proveedor puede desarrollar una asignación de clasificación de dispositivos para cada dispositivo 117 de tipo CPE indexado por la dirección pública del dispositivo (p. ej., la dirección IP pública y un rango de puertos TCP/UDP NAT). Otro manejo del flujo de tráfico, incluidos otros aspectos de la conformación de dispositivo, puede manipularse de una manera que sea similar, o idéntica, a otras implementaciones descritas con referencia a la Fig.5.
Para mayor claridad, las Figs. 7A y 7B muestran la conformación de dispositivo ilustrativa en una arquitectura 700, como el entorno 600 de comunicaciones de la Fig. 6. Como en las Figs. 5A y B, el tráfico de return-link (enlace de retorno - RL) está marcado por el nodo 110 de red de lado de usuario para habilitar la conformación de dispositivo de tráfico de enlace directo correspondiente por un conformador 435 de lado de proveedor en el nodo 130 de red de lado de proveedor. Sin embargo, debido a que el NAT 220 está en el nodo 110 de red de lado de usuario, el nodo 130 de red de lado de proveedor no conoce la identidad del dispositivo 117 de tipo CPE de destino cuando se recibe tráfico de enlace directo, de tal manera que otras técnicas (p. ej., se usa una combinación de la dirección pública del nodo 110a de red de lado de usuario y el puerto TCP/UDP para identificar de manera única el dispositivo 117 de tipo CPE) estén involucradas en realizar las determinaciones de conformación de dispositivo.
Volviendo en primer lugar a la Fig. 7A , se muestra un flujo 710 de tráfico de return-link (enlace de retorno - RL) como una flecha de trazo grueso. El flujo 710 de tráfico RL comienza en un dispositivo 117a de tipo CPE de origen y está destinado a un nodo de contenido u otro destino en la red 170 de contenido. En una ubicación etiquetada como ‘A’, los paquetes del flujo 710 de tráfico RL pueden incluir información de cabecera que identifica una dirección de origen como la dirección privada (p. ej., dirección IP privada) del dispositivo 117a de tipo CPE, y una dirección de destino como la dirección pública del nodo de contenido de destino. Puede suponerse que el dispositivo 117a de tipo CPE se ha clasificado por un clasificador 210 de dispositivos, tal como se describió anteriormente.
El flujo 710 de tráfico RL se recibe por el nodo 110a de red de lado de usuario. Un marcador 425 de flujo RL en el nodo 110a de red de lado de usuario marca paquetes del flujo 710 de tráfico RL con un identificador que indica la clasificación de dispositivo para el dispositivo 117a de tipo CPE. Luego, los paquetes se reenvían al NAT 220a en el nodo 110a de red de lado de usuario, que puede traducir la dirección privada del dispositivo 117a de tipo CPE de origen en la dirección pública del nodo 110a de red de lado de usuario. Por consiguiente, en la ubicación etiquetada como ‘B’ (es decir, cuando los paquetes del flujo 710 de tráfico RL salen del nodo 110a de red de lado de usuario destinados al nodo 130 de red de lado de proveedor), cada paquete puede asociarse con uno o más identificadores que indican una dirección de origen como la dirección pública del nodo 110a de red de lado de usuario, una dirección de destino como la dirección pública del nodo de contenido, y un tipo de dispositivo (p. ej., una etiqueta de tipo de dispositivo real, un índice a una lista de tipos de dispositivos almacenados, etc.) del CPE 117a originador.
El flujo 710 de tráfico RL atraviesa el enlace compartido de la red 150 de proveedor y llega al nodo 130 de red de lado de proveedor. En el nodo 130 de red de lado de proveedor, un módulo 440 de flujo RL almacena información de identificación para el flujo 710 de tráfico RL en un almacenamiento 450 de datos de flujo. Por ejemplo, el módulo 440 de flujo RL asocia un identificador de flujo RL con el flujo 710 de tráfico RL, y el identificador de flujo RL se almacena en el almacenamiento 450 de datos de flujo en asociación con una indicación de la clasificación de dispositivo del dispositivo 117a de tipo CPE (a partir de las etiquetas de paquete). En algunas implementaciones del identificador de flujo RL, el almacenamiento 450 de datos de flujo tiene una entrada para cada flujo que incluye direcciones de origen y destino invertidas (es decir, para un flujo de enlace directo correspondiente al flujo 710 de tráfico RL almacenado, el origen RL (nodo 110a de red de lado de usuario) será el destino FL, y el destino RL (nodo de contenido) será el origen FL), y una indicación de la clasificación (p. ej., tipo del dispositivo) del dispositivo 117a de tipo CPE originador (para los flujos RL) y de destino (para los flujos FL). En algunas implementaciones del identificador de flujo RL en el almacenamiento 450 de datos de flujo, cada entrada también indica un puerto (p. ej., el puerto de origen RL correspondiente al dispositivo 117a de tipo CPE puede ser el puerto de destino FL). Los paquetes del flujo 710 de tráfico RL pueden prepararse entonces para la comunicación con el nodo de contenido de destino. En algunas realizaciones, el módulo 440 de flujo RL extrae la clasificación de dispositivo de los paquetes. Por consiguiente, en la ubicación etiquetada como ‘C’ (es decir, cuando los paquetes del flujo 710 de tráfico RL salen del nodo 130 de red de lado de proveedor destinados a la red 170 de contenido), cada paquete se etiqueta con una dirección de origen como la dirección pública del nodo 110a de red de lado de usuario de origen y una dirección de destino como la dirección pública del nodo de contenido (p. ej., y un puerto de origen como el puerto correspondiente al dispositivo 117a de tipo CPE). Por ejemplo, las direcciones de origen y destino pueden añadirse a cada paquete como parte de una 5-tupla o de cualquier otra manera adecuada.
Volviendo a la Fig. 7B, se indica un flujo 720 de tráfico de forward-link (enlace directo - FL) mediante una flecha de trazo grueso, y se supone que el flujo 720 de tráfico FL corresponde al flujo 710 de tráfico RL de la Fig. 7A. En una ubicación etiquetada como ‘D’ (es decir, cuando los paquetes del flujo 720 de tráfico FL se reciben en el nodo 130 de red de lado de proveedor desde la red 170 de contenido), cada paquete se etiqueta con una dirección de destino como la dirección pública del nodo 110 de red de lado de usuario de destino y una dirección de origen como la dirección pública del nodo de contenido de origen (es decir, la inversa del etiquetado de los paquetes en la ubicación ‘C’ de la Fig. 7A). Los paquetes también pueden indicar un puerto de destino (p. ej., puerto TCP/UDP) correspondiente al puerto asociado con el dispositivo 117a de tipo CPE de destino. Los paquetes pueden recibirse por el identificador 445 de flujo FL en el nodo 130 de red de lado de proveedor, que puede intentar hacer coincidir el flujo 720 de tráfico FL con un flujo almacenado en el almacenamiento 450 de datos de flujo (correspondiente a algunos flujos 710 de tráfico RL monitorizados anteriormente). En el ejemplo ilustrado, el etiquetado de paquetes en la ubicación ‘D’ corresponde suficientemente al inverso del etiquetado de los paquetes en la ubicación ‘B’ de la Fig. 7A, de tal manera que el flujo 720 de tráfico FL puede hacerse coincidir con la entrada en el almacenamiento 450 de datos de flujo generada a partir del etiquetado del flujo 710 de tráfico RL correspondiente.
Tal como se describió anteriormente, la entrada en el almacenamiento 450 de datos de flujo puede incluir una indicación de la clasificación de dispositivo del dispositivo 117 de tipo CPE de destino (el dispositivo 117a de tipo CPE en el caso ilustrado). Como tal, el conformador 435 de lado de proveedor puede usar la clasificación de dispositivo indicada para determinar un perfil de conformación de dispositivo apropiado para aplicar al flujo 720 de tráfico FL. Por ejemplo, si el dispositivo 117a de tipo CPE es un dispositivo de pantalla pequeña, el conformador 435 de lado de proveedor puede conformar la comunicación del flujo 720 de tráfico FL según un perfil de conformación de pantalla pequeña (p. ej., y según la congestión en el enlace presente y/u otros factores). En algunas implementaciones, el conformador 435 de lado de proveedor recibe información de clasificación de dispositivo como un mensaje del identificador 445 de flujo FL. En otras implementaciones, el identificador 445 de flujo FL puede adjuntar la indicación de clasificación de dispositivo a los paquetes del flujo 720 de tráfico FL antes de reenviar los paquetes al conformador 435 de lado de proveedor, y el conformador 435 de lado de proveedor puede extraer la indicación de clasificación de dispositivo de los paquetes antes de reenviar el flujo 720 de tráfico Fl a través de la red 150 de proveedor. El flujo 720 de tráfico FL conformado de dispositivo puede comunicarse a través de la red 150 de proveedor al nodo 110 de red de lado de usuario de destino. Los paquetes del flujo 520 de tráfico FL se reciben por el NAT 220a en el nodo 110a de red de lado de usuario, lo que traduce la dirección y el puerto de destino públicos a la dirección de destino privado del dispositivo 117a de tipo CPE. Los paquetes pueden encaminarse al dispositivo 117a de tipo CPE, en consecuencia.
Pueden implementarse componentes de las diversas realizaciones descritas anteriormente en las Figs. 1-7B de cualquier manera adecuada. En algunas implementaciones, se implementan componentes como máquinas de estados de hardware que realizan diversas funciones mediante el uso de circuitos, tales como circuitos programables, procesadores, etc. En otras implementaciones, algunas funciones se implementan en hardware, software, firmware o cualquier combinación de los mismos. Si se implementan en software, las funciones pueden almacenarse como una o más instrucciones en un medio legible por ordenador no transitorio. Un medio de almacenamiento puede ser cualquier medio legible disponible al que pueda acceder un ordenador. A modo de ejemplo y sin limitación, tales medios legibles por ordenador pueden incluir RAM, ROM, EEPROM, CD-ROM, u otro almacenamiento de disco óptico, almacenamiento de disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio tangible que pueda usarse para portar o almacenar el código de programa deseado en forma de instrucciones o estructuras de datos y al que pueda accederse mediante un ordenador.
Las diversas realizaciones descritas anteriormente pueden implementarse en el contexto de cualquier tipo adecuado de sistemas de comunicaciones. Como ejemplo, la Fig. 8 muestra un sistema 800 de comunicaciones por satélite ilustrativo para implementar diversas realizaciones descritas en la presente memoria. Tal como se ilustra, la red 150 de proveedor se implementa como un sistema de comunicaciones por satélite que tiene uno o más satélites 805 que iluminan una o más áreas de cobertura de nodos de red de lado de usuario con uno o más haces puntuales 810. A cada haz puntual 810 puede atribuirse una cierta cantidad de ancho de banda (p. ej., una cantidad fija o dinámica), de tal manera que múltiples nodos 110 de red de lado de usuario en el haz puntual puedan compartir los recursos de ancho de banda del haz puntual 810. Tal como se describe en la presente memoria, la conformación de dispositivo puede usarse para atribuir de manera dinámica los recursos compartidos del haz puntual 810 entre algunos o todos los nodos 110 de red de lado de usuario en su área de cobertura.
Como otro ejemplo, la Fig. 9 muestra un sistema 900 de comunicaciones híbrido ilustrativo para implementar diversas realizaciones descritas en la presente memoria. La red 150 de proveedor puede implementarse como un sistema híbrido que tiene múltiples sistemas de comunicaciones (solo se muestran dos para evitar la complicación excesiva de la ilustración), tal como una subred 150a de proveedor de mayor latencia y mayor caudal y una subred 150b de proveedor de menor latencia y menor caudal (p. ej., un sistema de comunicaciones terrestres). Otros ejemplos de redes de satélites de la subred 150b comprenden satélites en órbitas más bajas que los satélites de la red 150a de subred. Por ejemplo, si los satélites de la subred 150a son satélites GEO, la subred 150b puede comprender satélites de medium earth orbit (órbita terrestre media - MEO) o satélites de low earth orbit (órbita terrestre baja - LEO). Tal como se ilustra, una subred 150a de proveedor puede ser un sistema de comunicaciones por satélite que tiene uno o más satélites 805 que iluminan una o más áreas de cobertura de nodos de red de lado de usuario con uno o más haces puntuales 810 (p. ej., como en la Fig. 8), y otra subred 150b de proveedor puede ser un sistema de comunicaciones terrestres que tiene uno o más enlaces 910 terrestres compartidos (p. ej., enlaces celulares, etc.). En tales realizaciones, la conformación de dispositivo puede incluir (o puede ser además de) determinar a través de cuál de las múltiples subredes de proveedor enviar un tráfico particular. Por ejemplo, el tráfico de vídeo de transmisión por secuencias puede encaminarse a través de la red de satélites de manera predeterminada, pero el tráfico puede reencaminarse (p. ej., temporalmente) a la red terrestre en respuesta a una condición de congestión. En tal ejemplo, la conformación a nivel de dispositivo puede usarse para conformar solo el tráfico que se encamina a través de la red de satélites, solo el tráfico que se encamina a través de la red terrestre, a través de ambas, etc.
La Fig. 10 ilustra un ejemplo de funcionamiento de la realización ilustrada en las Figs. 2-3B. La siguiente descripción pretende estar de acuerdo con las descripciones de las Figs. 2-3B anteriores. Cualquier discrepancia debe considerarse como un comentario adicional y la elaboración de ejemplos o ejemplos alternativos de operaciones y capacidades posibles del entorno 200/300a/300b de comunicaciones.
En la etapa 1004, el nodo 110 de red de lado de usuario recibe un primer conjunto de uno o más paquetes de un flujo 310 de tráfico FL tal como se muestra en la Fig. 3A. Tal como se indicó, cada paquete puede tener como su dirección de destino de red (p. ej., IP) la dirección de red pública del nodo 110 de red de lado de usuario, que el NAT 220 puede traducir a la dirección de red privada del dispositivo 117a de tipo CPE de destino, que en el ejemplo ilustrado en la Fig. 3A, es el dispositivo 117a de tipo CPE. Tal como se indicó, antes de recibir el flujo 310 de tráfico FL, el clasificador 210 de dispositivos puede haber clasificado cada uno de los dispositivos 117a y 117b de tipo CPE de la red 115 local de usuario detrás del nodo 110 de red de lado de usuario, y almacenado (p. ej., en una tabla de búsqueda) una identificación de cada CPE 117 (p. ej., por su dirección de red privada) en asociación con la clasificación del CPE. Por ejemplo, tal como se comentó anteriormente, la clasificación de cada dispositivo 117a de tipo CPE puede haber sido de acuerdo con una característica relevante para la velocidad del dispositivo. En la etapa 1008, el identificador 225 de flujo FL determina a partir de la tabla de clasificación del CPE la clasificación del dispositivo 117a de tipo CPE de destino. En la etapa 1012, el conformador 215 U-S (a nivel de CPE) identifica una política de conformación predeterminada que corresponde a la clasificación del dispositivo 117a de tipo CPE de destino. Por ejemplo, si el dispositivo 117a de tipo CPE de destino se clasifica como un dispositivo de pantalla pequeña, la política de conformación puede indicar una velocidad de bits relativamente baja a la que pueden visualizarse datos de vídeo en el dispositivo 117a de tipo CPE sin afectar negativamente a la QoE del usuario. En la etapa 1016, suponiendo que el tráfico 310 FL comprende tráfico de velocidad de bits adaptativa, el conformador 215 U-S (a nivel de CPE) emprende una acción para proporcionar realimentación (p. ej., la realimentación 320 ilustrada en la Fig.3B) al nodo 130 de red de lado de proveedor o al origen del flujo 310 de tráfico FL que implementa la política de conformación identificada en la etapa 1012. En algunas realizaciones, la realimentación 320 es explícita: por ejemplo, una o más instrucciones de conformación a nivel de dispositivo a un conformador 235 de tráfico (p. ej., P-S (a nivel de UT) en el nodo 130 de red de lado de proveedor. En otras realizaciones, la realimentación 320 es implícita. Por ejemplo, la realimentación 320 comprende una restricción de tráfico proporcionada al origen del tráfico 310 FL. Tal como se comentó anteriormente, un ejemplo de tal restricción implícita puede ser descartar paquetes del flujo 310 de tráfico FL en el nodo 110 de red de lado de usuario hasta que el origen del flujo de tráfico FL envía paquetes a una velocidad de bits que corresponde a la política de conformación identificada en la etapa 1012. Alternativamente, la restricción puede comprender enviar desde el nodo 110 de red de lado de usuario respuestas de tipo NACK a los paquetes del flujo 310 de tráfico FL hasta que el origen del flujo de tráfico FL envía paquetes a una velocidad de bits que corresponde a la política de conformación identificada en la etapa 1012.
La Fig. 11 ilustra un ejemplo de operación de las realizaciones ilustradas en las Figs. 4-7B . La siguiente descripción pretende ser de acuerdo con las descripciones de las Figs. 4-7B anteriores. Cualquier discrepancia debe considerarse como un comentario adicional y la elaboración de ejemplos o ejemplos alternativos de posibles operaciones y capacidades del entorno 400/500a/500b/600/700a/700b de comunicaciones.
En la etapa 1150, los paquetes de un flujo de tráfico RL tal como 510 en la Fig. 5A o 710 en la Fig. 7A desde un dispositivo 117a de tipo CPE se reciben en un nodo 110a de red de lado de usuario. (A continuación en la presente memoria, tal flujo de tráfico RL se denomina 510/710). La dirección de origen de red (p. ej., IP) es la dirección de red privada del CPE 117a originador. El clasificador 210a de dispositivos habría clasificado cada uno del dispositivo 117a y 117b de tipo CPE detrás del nodo 110a de red de lado de usuario y almacenado (p. ej., en una tabla de búsqueda) una identificación (p. ej., la dirección de red privada) de cada dispositivo de tipo CPE con la clasificación (p. ej., tipo de dispositivo) del dispositivo de tipo CPE. La clasificación de los dispositivos 117 de tipo CPE se comentó anteriormente y los ejemplos de técnicas para clasificar los dispositivos 117 de tipo CPE se ilustran en la Fig. 12. Mediante el uso de las clasificaciones anteriores de los dispositivos 117 de tipo CPE, el marcador 425a de flujo RL identifica el tipo del dispositivo 117a de tipo CPE originador y, en la etapa 1154, marca (p. ej., rotula) paquetes del flujo 510/710 RL con el tipo del dispositivo 117a de tipo CPE originador. Por ejemplo, si el tipo del dispositivo 117a de tipo CPE es de “ pantalla pequeña” , el marcador 425a de flujo RL establecerá un campo, una bandera o similar en los paquetes que indican que el dispositivo 117a de tipo CPE originador es un dispositivo del tipo de pantalla pequeña.
En la etapa 1158, el nodo 110 de red de lado de usuario envía los paquetes del flujo 510/710 RL a través de la(s) red(es) 1150 de proveedor al nodo 130 de red de lado de proveedor.
Tal como se comentó anteriormente, en la realización ilustrada en las Figs. 4-5B, se proporciona un túnel de red único desde cada nodo 110a de red de lado de usuario al nodo 130 de red de lado de proveedor, y los paquetes del flujo 510 RL se comunican desde el nodo 110a de red de lado de usuario al nodo 130 de red de lado de proveedor en la etapa 1150 a través del túnel único del nodo 110a de red de lado de usuario. Debido a que el NAT 420 y el módulo 422 de tunelización están aguas arriba de la conexión del nodo 130 de red de lado de proveedor a la(s) red(es) 150 de proveedor, los paquetes del flujo 510 RL llegan al nodo 130 de red de lado de proveedor con una identificación del túnel único desde el nodo 110a de red de lado de usuario, y la dirección de red de origen es la dirección de red privada del dispositivo 117a de tipo CPE originador.
En la realización ilustrada en las Figs. 6-7B, el NAT 220a en el nodo 110a de red de lado de usuario traduce la dirección de red privada del CPE 117a originador a la dirección de red pública del nodo 110a de red de lado de usuario. Por consiguiente, los paquetes del flujo 710 RL llegan al nodo 130 de red de lado de proveedor con una dirección de red de origen de la dirección de red pública del nodo 110a de red de lado de usuario y un número de puerto de origen que corresponde al CPE 117a originador.
En ambas realizaciones ilustradas en las Figs. 4-7B, el nodo 130 de red de lado de proveedor recibe los paquetes del flujo 510/710 comunicados en la etapa 1158, y en la etapa 1162, el módulo 440 de flujo RL en el nodo 130 de red de lado de proveedor almacena en el almacenamiento 450 de datos de flujo el tipo (p. ej., tal como se rotula en la etapa 1154) del dispositivo 117a de tipo CPE originador con un identificador que identifica el flujo 510/710 RL. Tal como se conoce, un paquete incluye normalmente una 5-tupla, que puede comprender la dirección de red de origen y el puerto del paquete, la dirección de red de destino y el puerto del paquete, y el protocolo de direccionamiento de red del paquete.
En la realización de las Figs. 4-5B, el identificador del flujo 510 RL almacenado en la etapa 1162 puede comprender la dirección de red privada del CPE 117 originador a partir de la 5-tupla y un identificador del túnel único (que corresponde al nodo 110a de red de lado de usuario) a través del cual se recibió el flujo 510 RL. El identificador puede comprender, alternativa o adicionalmente, la dirección de red y el número de puerto del nodo de destino de los paquetes del flujo 510 RL. En algunas realizaciones, la dirección y puertos de red de origen y destino de identificador pueden invertirse en el almacenamiento 450 de datos de flujo.
En la realización de las Figs. 6-7B, el identificador del flujo 710 RL almacenado en la etapa 1162 puede comprender la dirección de red pública del nodo 110a de red de lado de usuario y el número de puerto que corresponde al CPE 117a originador a partir de la 5-tupla de los paquetes. El identificador puede comprender, alternativa o adicionalmente, la dirección de red y el número de puerto del nodo de destino de los paquetes del flujo 710 RL. En algunas realizaciones, la dirección y puertos de red de origen y destino de identificador pueden invertirse en el almacenamiento 450 de datos de flujo.
Las etapas 1150-1162 pueden repetirse para múltiples flujos de tráfico RL (p. ej., de manera similar a los flujos 510 y 710), originándose cada uno desde un dispositivo 117 de tipo CPE detrás de uno de los nodos 110 de red de lado de usuario conectados al nodo 130 de red de lado de proveedor. Esto puede dar como resultado múltiples entradas en el almacenamiento 450 de datos de flujo, que comprenden cada una un identificador que identifica un flujo RL y una indicación del tipo del dispositivo 117 de tipo CPE que originó el flujo RL.
En la etapa 1108, un flujo 520 de tráfico FL (como en la Fig. 5B) o 720 (como en la Fig. 7B) se recibe en el nodo 130 de red de lado de proveedor. Tales flujos 520/720 de tráfico FL pueden ser en respuesta a uno de los flujos 510/710 de tráfico RL almacenados en el almacenamiento 450 de datos de flujo. En la etapa 1112, el identificador 445 de flujo FL determina si el flujo 520/720 FL corresponde (p. ej., es una respuesta) a un flujo de tráfico RL cuyo identificador se almacena en el almacenamiento 450 de datos de flujo. Esto lo hace comparando un atributo del flujo 520/720 FL con atributos similares de identificadores de flujos RL almacenados en el almacenamiento 450 de datos de flujo. Por ejemplo, en realizaciones en las que los identificadores de flujo RL en el almacenamiento 450 de datos de flujo comprenden la totalidad o parte de la 5-tupla de un flujo RL, el identificador 445 de flujo FL intenta encontrar en el almacenamiento 450 de datos de flujo una 5-tupla (o parte de la misma) que corresponde a la 5-tupla (o parte de la misma) de paquetes del flujo 520/720 FL. La 5-tupla de un flujo 520/720 FL que corresponde a un flujo RF (p. ej., 510) presumiblemente es la misma que la del flujo RF correspondiente excepto que las direcciones de red de destino y de origen y los números de puerto se invierten. Al identificar un flujo RF en el almacenamiento 450 de datos de flujo que corresponde al flujo 520/720 FL, el identificador 445 de flujo FL identifica el tipo del dispositivo 117a de tipo CPE de destino almacenado en el almacenamiento 450 de datos de flujo. El identificador 445 de flujo FL proporciona entonces el tipo de dispositivo de tipo CPE de destino al conformador 435 a nivel de dispositivo. Por ejemplo, el identificador 445 de flujo FL puede marcar los paquetes del flujo 520/720 FL con el tipo del dispositivo de tipo CPE de destino. Como otro ejemplo, el identificador 445 de flujo FL puede señalizar al conformador 435 a nivel de dispositivo el tipo de dispositivo.
Tal como se indicó, en la realización ilustrada en las Figs. 5A y 5B, los identificadores de flujo RL almacenados en el almacenamiento 450 de datos de flujo pueden comprender, para cada flujo RL, una identificación del túnel a través del cual se recibió el flujo RL en el nodo 130 de red de lado de proveedor y la dirección de red privada del dispositivo 117a de tipo CPE que originó el flujo RL. El túnel identifica de manera única el nodo 110 de red de lado de usuario a partir de los otros nodos 110 de red de lado de proveedor conectados al nodo 130 de red de lado de proveedor, y la dirección de red privada del dispositivo 117a de tipo CPE identifica el dispositivo de tipo CPE originador. Obsérvese que, debido a que los flujos RL (p. ej., 510) se traducen por el NAT 420 y se someten a destunelización por 422 después del procesamiento por el módulo 440 de flujo RL, el identificador de túnel y la dirección de red privada del dispositivo 117a de tipo CPE originador están disponibles en los paquetes del flujo 510 RL que llega al módulo 440 de flujo RL.
En la realización ilustrada en las Figs. 7A y 7B , los identificadores de flujo RL almacenados en el almacenamiento 450 de datos de flujo pueden comprender, para cada flujo RL, la dirección de red pública del nodo 110a de red de lado de usuario y el número de puerto del dispositivo 117a de tipo CPE originador, formando parte ambos de la 5-tupla de los paquetes del flujo RL. Debido a que los flujos RL (p. ej., 710) se traducen por el NAT 220a antes del procesamiento por el módulo 440 de flujo RL, las 5-tuplas de los paquetes del flujo 710 RL que llegan al módulo 440 de flujo RL comprenden como la dirección de origen la dirección de red pública del nodo 110a de red de lado de usuario y un número de puerto que corresponde al dispositivo 117a de tipo CPE originador.
Tal como se señaló anteriormente, el almacenamiento 450 de datos de flujo incluye un tipo del dispositivo 117a de tipo CPE de destino almacenado en asociación con el identificador de flujo RL determinado en la etapa 1112. En la etapa 1116, el conformador 435 P-S (a nivel de CPE) identifica una política de conformación prealmacenada que corresponde a ese tipo de CPE y, en la etapa 1120, conforma el flujo 520/720 FL de acuerdo con la política de conformación identificada.
Los métodos descritos en la presente memoria incluyen una o más acciones para lograr el método descrito. El método y/o las acciones pueden intercambiarse entre sí sin apartarse del alcance de las reivindicaciones. Dicho de otro modo, a menos que se especifique un orden específico de las acciones, puede modificarse el orden y/o el uso de acciones específicas sin apartarse del alcance de las reivindicaciones.
Un producto de programa informático puede realizar ciertas operaciones presentadas en la presente memoria. Por ejemplo, un producto de programa informático de este tipo puede ser un medio tangible legible por ordenador que tiene instrucciones almacenadas (y/o codificadas) en el mismo, pudiendo ejecutarse las instrucciones por uno o más procesadores para realizar las operaciones descritas en la presente memoria. El producto de programa informático puede incluir material de embalaje. También pueden transmitirse software o instrucciones a través de un medio de transmisión. Por ejemplo, puede transmitirse software desde un sitio web, servidor, u otro origen remoto mediante el uso de un medio de transmisión tal como un cable coaxial, cable de fibra óptica, par trenzado, digital subscriber line (línea de abonado digital - DSL) o tecnología inalámbrica tal como infrarrojo, radio o microondas.
Además, los módulos y/u otros medios adecuados para realizar las técnicas y los métodos descritos en la presente memoria pueden descargarse y/u obtenerse de otro modo mediante terminales adecuados y/o acoplarse a servidores, o similares, para facilitar la transferencia de los medios para realizar los métodos descritos en la presente memoria. Además, puede utilizarse cualquier otra técnica adecuada para proporcionar los métodos y las técnicas descritos en la presente memoria a un dispositivo. Las funciones que implementan características también pueden estar ubicadas físicamente en diversas posiciones, incluido estar distribuidas de tal manera que se implementan porciones de las funciones en diferentes ubicaciones físicas.
Al describir la presente invención, se usará la siguiente terminología: Las formas en singular “un(o)” , “una” y “el/la” abarcan referentes en plural a menos que el contexto dicte claramente otra cosa. Así, por ejemplo, la referencia a un artículo incluye la referencia a uno o más artículos. El término “unos” hace referencia a uno, dos o más y, por lo general, se aplica a la selección de parte o la totalidad de una cantidad. El término “pluralidad” hace referencia a dos o más de un artículo. El término “aproximadamente” significa cantidades, dimensiones, tamaños, formulaciones, parámetros, formas y otras características que no es necesario que sean exactos, pero que pueden aproximarse y/o ser mayores o menores, según se desee, reflejando tolerancias aceptables, factores de conversión, redondeo, error de medición y similares y otros factores conocidos por los expertos en la técnica. El término “sustancialmente” significa que no es necesario que la característica, el parámetro o valor mencionado se consiga exactamente, sino que pueden tener lugar desviaciones o variaciones incluidas, por ejemplo, tolerancias, error de medición, limitaciones de exactitud de medición y otros factores conocidos por los expertos en la técnica, en cantidades que no excluyen el efecto que se pretendía que proporcionase la característica. Los datos numéricos pueden expresarse o presentarse en la presente memoria en un formato de intervalo. Debe entenderse que un formato de intervalo de este tipo se usa simplemente con fines de conveniencia y brevedad y, por tanto, deberá interpretarse de manera flexible que incluye no solo los valores numéricos mencionados de manera explícita como los límites del intervalo, sino también debe interpretarse que incluye todos los valores numéricos individuales o subintervalos comprendidos dentro de ese intervalo, como si cada valor numérico y subintervalo se mencionaran de manera explícita. Como ilustración, debe interpretarse que un intervalo numérico de “aproximadamente 1 a 5” incluye no solo los valores mencionados de manera explícita de aproximadamente 1 a aproximadamente 5, sino que también incluye valores individuales y subintervalos dentro del intervalo indicado. Por tanto, en este intervalo numérico se incluyen valores individuales, tales como 2, 3 y 4 y subintervalos, tales como 1-3, 2-4 y 3-5, etc. Este mismo principio se aplica a intervalos que enumeran solo un valor numérico (p. ej., “ mayor de aproximadamente 1 ” ) y debe aplicarse independientemente de la amplitud del intervalo o de las características que se describen. Una pluralidad de artículos puede presentarse en una lista común por comodidad de uso. Sin embargo, estas listas deben interpretarse como si cada miembro de la lista se identificara individualmente como un miembro independiente y único. Por tanto, ningún miembro individual de esta lista debe interpretarse como un equivalente de facto de cualquier otro miembro de la misma lista basándose únicamente en su presentación en un grupo común sin indicaciones de lo contrario. Además, cuando se usan los términos “y” y “o” junto con una lista de artículos, deben interpretarse ampliamente en cuanto a que uno cualquiera o más de los artículos mencionados pueden usarse solos o en combinación con otros artículos enumerados. La expresión “alternativamente” se refiere a la selección de una de dos o más alternativas, y no pretende limitar la selección a solo aquellas alternativas enumeradas o solo a una de las alternativas enumeradas a la vez, a menos que el contexto indique claramente otra cosa. El término “acoplado” tal como se usa en la presente memoria no requiere que los componentes estén conectados directamente entre sí. En lugar de ello, el término pretende incluir también configuraciones con conexiones indirectas en las que pueden incluirse uno o más de otros componentes entre componentes acoplados. Por ejemplo, tales otros componentes pueden incluir amplificadores, atenuadores, aisladores, acopladores direccionales, interruptores redundantes, y similares. Además, tal como se usa en la presente memoria, incluidos en las reivindicaciones, “o” tal como se usa en una lista de artículos precedidos por “al menos uno de” indica una lista disyuntiva de tal manera que, por ejemplo, una lista de “al menos uno de A, B o C” significa A o B o C o AB o AC o BC o ABC (es decir, A y B y C). Además, el término “a modo de ejemplo” no significa que el ejemplo descrito sea preferido o mejor que otros ejemplos. En la presente memoria, un “conjunto” de elementos se pretende que signifique “uno o más” de esos elementos, salvo donde el conjunto se requiera de manera explícita que tenga más de uno o esté permitido de manera explícita que sea un conjunto nulo.
Pueden realizarse diversos cambios, sustituciones y alteraciones en las técnicas descritas en la presente memoria sin apartarse de la tecnología de las enseñanzas tal como se define mediante las reivindicaciones adjuntas. Además, el alcance de la descripción y las reivindicaciones no se limita a los aspectos particulares del proceso, la máquina, fabricación, composición de materia, los medios, métodos y las acciones descritos anteriormente. Pueden utilizarse procesos, máquinas, fabricación, composiciones de materia, medios, métodos o acciones, que existen actualmente o que se desarrollarán posteriormente, que realizan sustancialmente la misma función o logran sustancialmente el mismo resultado que los aspectos correspondientes descritos en la presente memoria. Por consiguiente, las reivindicaciones adjuntas incluyen dentro de su alcance tales procesos, máquinas, fabricación, composiciones de materia, medios, métodos o acciones.

Claims (20)

  1. REIVINDICACIONES
    i. Un método para la conformación de dispositivo de tráfico en una red de comunicaciones, comprendiendo el método:
    recibir (1004) un flujo (720) de enlace directo en un nodo (110) de red de lado de usuario desde una red (150) de proveedor, siendo el nodo de red de lado de usuario un nodo de red de intermediarios entre la red de proveedor y una red (115) de usuario local que tiene un conjunto de dispositivos (117) de tipo equipos en instalaciones del cliente, CPE;
    determinar (1008), por el nodo de red de lado de usuario a partir del flujo de enlace directo, un dispositivo (117) de tipo CPE de destino del conjunto de dispositivos de tipo CPE, clasificándose el dispositivo de tipo CPE de destino en una de una pluralidad de clases de dispositivo de acuerdo con una característica relevante para la velocidad predeterminada del dispositivo de tipo CPE de destino;
    identificar (1012), por un conformador de dispositivo del nodo de red de lado de usuario, una de una pluralidad de políticas de conformación de dispositivo almacenadas como correspondientes a la clase de dispositivo del dispositivo de tipo CPE de destino; y
    realimentar (1016) una indicación de la política de conformación de dispositivo identificada desde el nodo de red de lado de usuario a través de la red de proveedor, conformando de ese modo la comunicación posterior del flujo de enlace directo de acuerdo con la política de conformación de dispositivo identificada.
  2. 2. El método de la reivindicación 1, que comprende además:
    clasificar el conjunto de dispositivos de tipo CPE en clases respectivas de la pluralidad de clases de dispositivo por un clasificador (210) de dispositivos en comunicación con el nodo de red de lado de usuario de acuerdo con las características relevantes para la velocidad predeterminadas respectivas del conjunto de dispositivos de tipo CPE.
  3. 3. El método de la reivindicación 1, en donde la realimentación comprende:
    comunicar una instrucción de conformación de dispositivo desde el conformador de dispositivo a un conformador (235) de lado de proveedor en un nodo (130) de red de lado de proveedor a través de la red de proveedor, generada la instrucción de conformación de dispositivo de acuerdo con la política de conformación de dispositivo identificada, adaptando de ese modo la comunicación del flujo de enlace directo mediante el conformador de lado de proveedor en respuesta a la instrucción de conformación de dispositivo.
  4. 4. El método de la reivindicación 1, en donde la realimentación comprende:
    generar una restricción de tráfico mediante el conformador de dispositivo en el nodo de red de lado de usuario, siendo la restricción de tráfico detectable por un proveedor de contenido, haciendo de ese modo que el proveedor de contenido adapte la comunicación del flujo de enlace directo en respuesta a la detección de la restricción de tráfico, generada la restricción de tráfico de tal manera que la adaptación sea de acuerdo con la política de conformación de dispositivo identificada.
  5. 5. El método de la reivindicación 4, en donde:
    la política de conformación de dispositivo identificada indica una velocidad de datos objetivo; y generar la restricción de tráfico comprende descartar iterativamente paquetes del flujo de enlace directo hasta que se haga que el proveedor de contenido adapte la comunicación del flujo de enlace directo a la velocidad de datos objetivo.
  6. 6. El método de la reivindicación 1, en donde:
    el flujo de enlace directo comprende paquetes que indican una dirección de destino que es una dirección de red pública del nodo de red de lado de usuario; y
    determinar el dispositivo de tipo CPE de destino comprende traducir la dirección de red pública en una dirección de red privada del dispositivo de tipo CPE mediante el uso de un traductor de direcciones de red, NAT, (220) del nodo de red de lado de usuario.
  7. 7. El método de la reivindicación 1, en donde la característica relevante para la velocidad corresponde a una fidelidad de pantalla del dispositivo de tipo CPE de destino.
  8. 8. El método de la reivindicación 1, que comprende además:
    detectar que el flujo de enlace directo comprende tráfico adaptativo,
    en donde la identificación y la realimentación son en respuesta a la detección.
  9. 9. Un método para la conformación de dispositivo de tráfico en una red de comunicaciones, comprendiendo el método:
    almacenar (1162), en un nodo (130) de red de lado de proveedor, un identificador de clase de dispositivo en asociación con un identificador (445) de flujo de un flujo (710) de enlace de retorno recibido por el nodo de red de lado de proveedor a través de una red (150) de proveedor, etiquetado el flujo de enlace de retorno con el identificador de clase de dispositivo por un nodo (110) de red de lado de usuario para indicar una de una pluralidad de clases de dispositivo en las cuales un dispositivo (117) de tipo equipo en instalaciones del cliente, CPE de origen, del flujo de enlace de retorno se clasificó previamente de acuerdo con una característica relevante para la velocidad predeterminada del dispositivo de tipo CPE de origen;
    recibir (1108) un flujo (720) de enlace directo en el nodo de red de lado de proveedor de manera posterior al almacenamiento;
    determinar (1112), en el nodo de red de lado de proveedor, que el flujo de enlace directo corresponde al flujo de enlace de retorno de acuerdo con el identificador de flujo almacenado; identificar (1116), mediante un conformador de dispositivo del nodo de red de lado de proveedor, una de una pluralidad de políticas de conformación de dispositivo almacenadas como correspondientes a la una de una pluralidad de clases de dispositivo del dispositivo de tipo CPE de origen de acuerdo con el identificador de clase de dispositivo almacenado en asociación con el identificador de flujo almacenado; y
    conformar (1120) la comunicación del flujo de enlace directo a través de la red de proveedor de acuerdo con la política de conformación de dispositivo identificada.
  10. 10. El método de la reivindicación 9, que comprende además, antes del almacenamiento:
    recibir (1150) el flujo de enlace de retorno en el nodo de red de lado de usuario, originándose el flujo de enlace de retorno en el dispositivo de tipo CPE de origen;
    rotular (1154) el flujo de enlace de retorno con el identificador de clase de dispositivo; y comunicar (1158) el flujo de enlace de retorno a través de la red de proveedor al nodo de red de lado de proveedor.
  11. 11. El método de la reivindicación 10, en donde:
    el rotulado comprende además rotular el flujo de enlace de retorno con un identificador de túnel que identifica uno de una pluralidad de túneles virtuales, proporcionando cada uno una conexión virtual entre el nodo de red de lado de proveedor y uno de una pluralidad de nodos de red de lado de usuario respectivo a través de la red de comunicaciones;
    el almacenamiento comprende además almacenar el identificador de túnel en el nodo de red de lado de proveedor en asociación con el identificador de flujo; y
    la determinación es además de acuerdo con el identificador de túnel.
  12. 12. El método de la reivindicación 11, en donde:
    el nodo de red de lado de proveedor comprende un traductor de direcciones de red, NAT, (220); el flujo de enlace directo, tal como se recibe por el nodo de red de lado de proveedor, indica una dirección de destino pública; y
    la determinación comprende:
    traducir la dirección de destino pública en un identificador de túnel de destino usando el NAT; y
    determinar que el flujo de enlace directo corresponde al flujo de enlace de retorno mediante la coincidencia del identificador de túnel de destino con el identificador de túnel almacenado asociado con el flujo de enlace de retorno.
  13. 13. El método de la reivindicación 10, que comprende además:
    detectar la presencia del dispositivo de tipo CPE de origen en la red de usuario local; y clasificar el dispositivo de tipo CPE de origen en la una de la pluralidad de clases de dispositivo en respuesta a la detección.
  14. 14. El método de la reivindicación 10, en donde:
    el dispositivo de tipo CPE de origen es uno de un conjunto de dispositivos de tipo CPE de una red de usuario local, siendo el nodo de red de lado de usuario un nodo de red de intermediarios entre la red de usuario local y la red de proveedor;
    el nodo de red de lado de usuario es direccionable de manera única por el nodo de red de lado de proveedor a través de la red pública de acuerdo con un identificador de red pública; cada uno del conjunto de dispositivos de tipo CPE es direccionable de manera única por el nodo de red de lado de usuario a través de la red de usuario local de acuerdo con un identificador de red privada respectivo, y no es direccionable de manera única por el nodo de red de lado de proveedor a través de la red pública; y
    el rotulado comprende, además:
    determinar el identificador de red privada respectivo del dispositivo de tipo CPE de origen, de tal manera que el identificador de clase de dispositivo se genera para indicar el identificador de red privada respectivo del dispositivo de tipo CPE de origen.
  15. 15. El método de la reivindicación 14, en donde:
    el nodo de red de lado de usuario comprende un traductor de direcciones de red, NAT; y la conformación comprende comunicar el flujo de enlace directo de acuerdo con el identificador de red pública del nodo de red de lado de usuario,
    de tal manera que el identificador de red pública se traduce en el identificador de red privada respectivo del CPE de origen por el NAT cuando se recibe por el nodo de red de lado de usuario a través de la red de proveedor.
  16. 16. El método de la reivindicación 9 que comprende además:
    recibir en el nodo de red de lado de proveedor una petición para una dirección de red privada para un dispositivo de tipo CPE recientemente conectado al nodo de red de lado de usuario; y enviar desde el nodo de red de lado de proveedor la dirección de red privada para el dispositivo de tipo CPE.
  17. 17. El método de la reivindicación 16, en donde la petición de una dirección de red privada comprende un rango de puertos para el dispositivo de tipo CPE recientemente conectado.
  18. 18. El método de la reivindicación 17 que comprende además:
    enviar desde el nodo de red de lado de proveedor una petición para una clasificación del dispositivo de tipo CPE recientemente conectado; y
    almacenar en el nodo de red de lado de proveedor una clasificación del dispositivo de tipo CPE recientemente conectado recibida desde un clasificador (210) de dispositivos en el nodo de red de lado de usuario.
  19. 19. Un sistema de comunicaciones que comprende:
    un nodo (110) de red de lado de usuario que comprende:
    una interfaz (217) de red de usuario que comprende una pluralidad de puertos de red de usuario configurados para proporcionar conectividad con una red de usuario local que comprende un conjunto de dispositivos (117) de tipo equipos en instalaciones del cliente, CPE; una interfaz (252) de red de proveedor que comprende un puerto de red de proveedor configurado para proporcionar conectividad a través de una red de proveedor;
    un identificador (225) de flujo de enlace directo acoplado con la interfaz de red de proveedor y operable para determinar un dispositivo de tipo CPE de destino a partir de un flujo (720) de enlace directo recibido a través de la red de proveedor;
    un almacenamiento (212) de datos que tiene, almacenadas en el mismo, una pluralidad de políticas de conformación de dispositivo; y
    un conformador de dispositivo acoplado con el identificador de flujo de enlace directo y el almacenamiento de datos, configurado el conformador de dispositivo para:
    identificar una de la pluralidad de políticas de conformación de dispositivo como correspondiente a una clase de dispositivo del dispositivo de tipo CPE de destino, siendo el dispositivo de tipo CPE de destino uno del conjunto de dispositivos de tipo CPE y clasificándose previamente en la clase de dispositivo de acuerdo con una característica relevante para la velocidad predeterminada del dispositivo de tipo CPE de destino; y realimentar una indicación de la política de conformación de dispositivo identificada a través de la red de proveedor, conformando de ese modo la comunicación posterior del flujo de enlace directo de acuerdo con la política de conformación de dispositivo identificada.
  20. 20. El sistema de la reivindicación 19, que comprende además:
    un clasificador (210) de dispositivos en comunicación con el nodo de red de lado de usuario y operable para clasificar el conjunto de dispositivos de tipo CPE en clases respectivas de la pluralidad de clases de dispositivo de acuerdo con las características relevantes para la velocidad predeterminadas respectivas del conjunto de dispositivos de tipo CPE.
    El sistema de la reivindicación 19, en donde:
    el conformador de dispositivo puede operarse para realimentar la indicación generando una restricción de tráfico detectable por un proveedor de contenido, haciendo la restricción de tráfico que el proveedor de contenido adapte la comunicación del flujo de enlace directo, de tal manera que la conformación de la comunicación posterior del flujo de enlace directo sea de acuerdo con la política de conformación de dispositivo identificada.
    El sistema de la reivindicación 19, que comprende además:
    un nodo (130) de red de lado de proveedor en comunicación con el nodo de red de lado de usuario a través de la red (150) de proveedor, comprendiendo el nodo de red de lado de proveedor un conformador de lado de proveedor,
    en donde la indicación es recibida por el conformador (235) de lado de proveedor a través de la red de proveedor como una instrucción de conformación de dispositivo generada de acuerdo con la política de conformación de dispositivo identificada, haciendo de ese modo que el conformador de lado de proveedor adapte la comunicación posterior del flujo de enlace directo a través de la red de proveedor en respuesta a la instrucción de conformación de dispositivo.
    Un sistema de comunicaciones que comprende:
    un nodo (130) de red de lado de proveedor que comprende:
    una interfaz (472) de red de contenido que comprende un puerto de red de contenido configurado para proporcionar conectividad con una pluralidad de orígenes de contenido a través de una red de contenido;
    una interfaz (452) de red de proveedor que comprende un puerto de red de proveedor configurado para proporcionar conectividad con una pluralidad de nodos (110) de red de lado de usuario a través de una red (150) de proveedor;
    un almacenamiento (450) de datos de flujo operable para almacenar, en respuesta a la recepción de un flujo (710) de enlace de retorno a través de la red de proveedor, un identificador de clase de dispositivo en asociación con un identificador de flujo del flujo de enlace de retorno, etiquetado el flujo de enlace de retorno previamente con el identificador de clase de dispositivo por un nodo de red de lado de usuario para indicar una de una pluralidad de clases de dispositivo en las cuales un dispositivo (117) de tipo de equipos en instalaciones del cliente, CPE de origen, del flujo de enlace de retorno se clasificó previamente de acuerdo con una característica relevante para la velocidad predeterminada del dispositivo de tipo CPE de origen;
    un identificador (445) de flujo de enlace directo acoplado con la interfaz de red de proveedor y operable para determinar que un flujo de enlace directo recibido a través de la red de contenido corresponde al flujo de enlace de retorno de acuerdo con el identificador de flujo almacenado; y un conformador de dispositivo acoplado con el identificador de flujo de enlace directo y el almacenamiento de datos de flujo, configurado el conformador de dispositivo para:
    identificar una de una pluralidad de políticas de conformación de dispositivo almacenadas como correspondiente a la una de una pluralidad de clases de dispositivo del dispositivo de tipo CPE de origen de acuerdo con el identificador de clase de dispositivo almacenado en asociación con el identificador de flujo almacenado; y
    conformar la comunicación del flujo de enlace directo a través de la red de proveedor de acuerdo con la política de conformación de dispositivo identificada.
    El sistema de la reivindicación 23, que comprende además:
    un nodo (110) de red de lado de usuario en comunicación con el nodo de red de lado de proveedor a través de la red de proveedor, comprendiendo el nodo de red de lado de usuario un marcador (425) de flujo de enlace de retorno operable para rotular el flujo de enlace de retorno con el identificador de clase de dispositivo en respuesta a la recepción del flujo de enlace de retorno desde el dispositivo de tipo CPE de origen y antes de que el flujo de enlace de retorno se comunique a través de la red de proveedor al nodo de red de lado de proveedor.
ES17758330T 2016-08-24 2017-08-11 Conformación a nivel de dispositivo en una red de comunicaciones Active ES2887650T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662379055P 2016-08-24 2016-08-24
PCT/US2017/046506 WO2018038939A1 (en) 2016-08-24 2017-08-11 Device shaping in a communications network

Publications (1)

Publication Number Publication Date
ES2887650T3 true ES2887650T3 (es) 2021-12-27

Family

ID=59714111

Family Applications (1)

Application Number Title Priority Date Filing Date
ES17758330T Active ES2887650T3 (es) 2016-08-24 2017-08-11 Conformación a nivel de dispositivo en una red de comunicaciones

Country Status (8)

Country Link
US (2) US10924415B2 (es)
EP (1) EP3504896B1 (es)
CN (1) CN110089146B (es)
AU (2) AU2017317018B2 (es)
BR (1) BR112019003675A2 (es)
CA (1) CA3034237C (es)
ES (1) ES2887650T3 (es)
WO (1) WO2018038939A1 (es)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3504896B1 (en) 2016-08-24 2021-06-09 ViaSat, Inc. Device shaping in a communications network
CN110661896B (zh) * 2018-06-29 2021-06-22 网宿科技股份有限公司 一种确定数据流的映射地址的方法及服务器
WO2021106201A1 (ja) * 2019-11-29 2021-06-03 日本電信電話株式会社 制御装置、通信システム、制御方法、及びプログラム
US11924172B1 (en) * 2021-10-27 2024-03-05 Graphiant, Inc. System and method for instantiation of stateless extranets
US11979304B1 (en) * 2022-11-03 2024-05-07 Verizon Patent And Licensing Inc. System and method for estimating network performance

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7010611B1 (en) 1999-12-21 2006-03-07 Converged Access, Inc. Bandwidth management system with multiple processing engines
AU2001232776A1 (en) 2000-02-23 2001-09-03 Jean Pierre Bordes Method and device for data traffic shaping
US20030147349A1 (en) 2002-02-01 2003-08-07 Burns Daniel J. Communications systems and methods utilizing a device that performs per-service queuing
US7310309B1 (en) 2002-07-17 2007-12-18 Foundry Networks, Inc. Dynamic rate limiting adjustment
US7715380B2 (en) * 2003-06-19 2010-05-11 Cisco Technology, Inc. Apparatus and methods for handling shared services through virtual route forwarding (VRF)-aware-NAT
CN100358291C (zh) * 2004-09-08 2007-12-26 华为技术有限公司 下一代网络中动态协商服务质量的系统及其实现方法
EP1662715A1 (en) 2004-11-29 2006-05-31 Siemens Aktiengesellschaft Method and apparatus for providing ingress traffic shaping
US7756026B2 (en) * 2005-04-20 2010-07-13 At&T Intellectual Property I, L.P. Providing a quality of service for various classes of service for transfer of electronic data packets
US7821941B2 (en) * 2006-11-03 2010-10-26 Cisco Technology, Inc. Automatically controlling operation of a BRAS device based on encapsulation information
US8537676B1 (en) 2007-07-09 2013-09-17 Juniper Networks, Inc. Rate limiting for DTCP message transport
US8331231B2 (en) * 2008-09-09 2012-12-11 Centurylink Intellectual Property Llc System and method for monitoring bursting traffic
KR20100129415A (ko) * 2009-06-01 2010-12-09 삼성전자주식회사 근거리 무선 통신 기반의 오디오 데이터 출력 방법 및 이를 이용한 휴대 단말기
US9071526B2 (en) 2009-06-22 2015-06-30 Citrix Systems, Inc. Systems and methods for platform rate limiting
US20130107707A1 (en) * 2011-11-01 2013-05-02 Tellabs Operations, Inc. Emulating network traffic shaping
US8989818B2 (en) 2011-11-04 2015-03-24 Facebook, Inc. Device actions based on device power
US8432808B1 (en) 2012-06-15 2013-04-30 Viasat Inc. Opportunistically delayed delivery in a satellite network
US9467326B2 (en) 2012-12-03 2016-10-11 Hewlett-Packard Development Company, L.P. Rate limiting mechanism based on device load/capacity or traffic content
US9391749B2 (en) 2013-03-14 2016-07-12 Ashwin Amanna, III System and method for distributed data management in wireless networks
US9455777B1 (en) 2013-03-15 2016-09-27 Viasat, Inc. Satellite network service sharing
US20140355536A1 (en) * 2013-06-04 2014-12-04 Alcatel Lucent System and method providing fixed mobile convergence via bonded services
WO2014200399A1 (en) * 2013-06-13 2014-12-18 Telefonaktiebolaget L M Ericsson (Publ) Traffic optimization in a communications network
US9559969B2 (en) * 2013-07-11 2017-01-31 Viasat Inc. Source-aware network shaping
US9553813B2 (en) 2014-07-23 2017-01-24 Cisco Technology, Inc. Selectively employing dynamic traffic shaping
EP3504896B1 (en) 2016-08-24 2021-06-09 ViaSat, Inc. Device shaping in a communications network

Also Published As

Publication number Publication date
CN110089146A (zh) 2019-08-02
US20210306273A1 (en) 2021-09-30
BR112019003675A2 (pt) 2019-05-21
CA3034237A1 (en) 2018-03-01
AU2022202022A1 (en) 2022-04-14
AU2022202022B2 (en) 2023-12-07
US11722414B2 (en) 2023-08-08
US20190190837A1 (en) 2019-06-20
AU2017317018B2 (en) 2022-03-31
WO2018038939A1 (en) 2018-03-01
US10924415B2 (en) 2021-02-16
EP3504896A1 (en) 2019-07-03
EP3504896B1 (en) 2021-06-09
CN110089146B (zh) 2022-07-01
CA3034237C (en) 2023-06-13
AU2017317018A1 (en) 2019-02-28

Similar Documents

Publication Publication Date Title
ES2887650T3 (es) Conformación a nivel de dispositivo en una red de comunicaciones
US9590916B2 (en) Method and system for dynamically prioritizing user connections on network
US9106711B2 (en) Minimizing mapping and signaling for data path aggregation
US9722923B2 (en) Method operating in a fixed access network and UEs
US20240154905A1 (en) Return-link routing in a hybrid network
US9094482B2 (en) Apparatus and method for controlling data transmission/reception path between server and mobile terminal in heterogeneous network environment
US11356359B2 (en) Methods and network nodes for scalable top-of-chain selection in mobile service chaining
US9641433B2 (en) Method, routing bridge, and system for sending packet
EP3675437B1 (en) Communication method, device and system
US11489930B2 (en) Telecommunication network edge cloud interworking via edge exchange point
US20180359214A1 (en) Device and method for wireless communication in an ip network
US10397791B2 (en) Method for auto-discovery in networks implementing network slicing
US10855491B2 (en) Method for implementing GRE tunnel, access point and gateway
US10454712B2 (en) Access apparatus and access apparatus-performed method for connecting user device to network
JP2015041810A (ja) パケット振り分けシステム及び方法
CN115442289A (zh) 发送和接收消息的方法、装置和通信系统
US20240205048A1 (en) Service discovery across tunnel endpoints in overlays
US8971289B2 (en) Maintaining point of presence for clients roaming within a layer 2 domain
US20110185083A1 (en) Identifier and locator structure, and communication method based on the structure
KR101580635B1 (ko) 이기종 네트워크 기반 데이터 동시 전송 서비스 방법