ES2857723T3 - Soporte de calidad de servicio (QoS) para tráfico táctil - Google Patents

Soporte de calidad de servicio (QoS) para tráfico táctil Download PDF

Info

Publication number
ES2857723T3
ES2857723T3 ES16715898T ES16715898T ES2857723T3 ES 2857723 T3 ES2857723 T3 ES 2857723T3 ES 16715898 T ES16715898 T ES 16715898T ES 16715898 T ES16715898 T ES 16715898T ES 2857723 T3 ES2857723 T3 ES 2857723T3
Authority
ES
Spain
Prior art keywords
node
traffic
network
application
touch
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
ES16715898T
Other languages
English (en)
Inventor
Sumanta Saha
Kazi Wali Ullah
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.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2857723T3 publication Critical patent/ES2857723T3/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
    • 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
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/021—Ensuring consistency of routing table updates, e.g. by using epoch numbers
    • 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/302—Route determination based on requested QoS
    • 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/42—Centralised 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/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • 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/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/106—Packet or message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/108—Source integrity
    • 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/0268—Traffic management, e.g. flow control or congestion control using specific QoS parameters for wireless networks, e.g. QoS class identifier [QCI] or guaranteed bit rate [GBR]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • H04W28/22—Negotiating communication rate

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un método para una red (100) de comunicación, en el que la red de comunicación incluye un nodo (104) de acceso que se comunica con los dispositivos (102) de usuario final, un nodo (106) de retorno y un nodo central (108), en el que el nodo de retorno transmite tráfico entre el nodo de acceso y el nodo central, y en el que un dispositivo electrónico comprende el nodo de acceso o el nodo central, el método comprendiendo: notificar (702), por el dispositivo electrónico, a un controlador (150) que una aplicación ha sido autorizada para transmitir tráfico táctil en la red de comunicación, el controlador comunicándose con uno o más del nodo de acceso, el nodo de retorno y el nodo central, y la aplicación siendo desplegada en un dispositivo de usuario final, en el que el controlador, en respuesta a la notificación, hace que el nodo de retorno instale una entrada de tabla de flujo en una tabla de flujo del nodo de retorno, a través del cual los paquetes de la aplicación se reenviarán dentro de una latencia definida para el tráfico táctil por el nodo de retorno, en el que la entrada de tabla de flujo incluye uno o más bits de calidad de servicio en uno o más de sus campos coincidentes para coincidir al menos una indicación en los paquetes de tráfico táctil recibidos desde el dispositivo electrónico, en el que dicho o más campos coincidentes incluyen solo el ID de abonado o el ID de sesión, y en el que el emparejamiento de uno es suficiente para identificar el tráfico táctil y en el que la latencia de la aplicación en la red de comunicación está dentro de un milisegundo; autenticar (704), por el dispositivo electrónico, un paquete que se origina o está destinado a la aplicación que ha sido autorizada para transmitir el tráfico táctil en la red de comunicación; y reenviar (706), por el dispositivo electrónico, al nodo de retorno, el paquete con la latencia definida para el tráfico táctil usando una prioridad para el tráfico táctil.

Description

DESCRIPCIÓN
Soporte de calidad de servicio (QoS) para tráfico táctil
Campo de la invención
Las realizaciones de la invención están relacionadas con el campo de las redes. Más específicamente, las realizaciones de la invención se refieren a un sistema, un método, y programa informático para proporcionar soporte de calidad de servicio (QoS) para tráfico táctil.
Antecedentes
Si bien las personas pueden tolerar aproximadamente 100 milisegundos (ms) de retraso al interactuar con una conversación de audio y 10 ms para reaccionar a un incidente visual, solo en el orden de unos pocos milisegundos es el retraso que las personas pueden tolerar mientras realizan algunas tareas hápticas como hacer malabares o conducir un coche. Cualquier retraso mayor es notable y crea perturbaciones en el trabajo que realiza una persona.
Los requisitos de retraso son específicos del caso de uso. Por ejemplo, para lograr la alta fidelidad requerida para aplicaciones telemédicas, es necesario lograr una latencia de extremo a extremo de 1 a 10 ms. En otro caso de uso de maniobras automáticas de accionamiento cooperativo con un intercambio bidireccional de datos, se necesitaría una latencia de menos de 1 ms. Aunque diferentes casos de uso pueden funcionar con latencia diferente, un informe de la Unión Internacional de Telecomunicaciones (ITU), "El Internet táctil - Informe de vigilancia tecnológica de la ITU-T" con fecha de agosto de 2014, indica que la latencia no debe ser superior a 1 ms de extremo a extremo para tal aplicación.
Esta limitación física tiene un impacto profundo en cómo diseñamos nuestras tecnologías para que funcionen. Por ejemplo, el audio en una conversación telefónica puede demorarse 100 ms sin que la experiencia sea desagradable. Del mismo modo, la imagen de la televisión puede demorarse 10 ms sin causar ningún problema a la audiencia. Sin embargo, si una persona intenta controlar de forma remota un equipo que requiere la combinación de retroalimentación visual y control físico, 1 ms de retraso es suficiente para crear una perturbación notable en la experiencia del usuario. También son necesarios requisitos de retraso similares cuando una máquina usa retroalimentación visual y control físico para realizar una tarea háptica, por ejemplo, coches autónomos que se comunican entre sí con retroalimentación visual para evitar colisiones.
Con el advenimiento de las redes de alta velocidad como 5G (en referencia a las redes móviles de quinta generación o los sistemas inalámbricos de quinta generación) y el alcance y la velocidad asociados de Internet, los investigadores están visualizando una red que podrá soportar características táctiles de Internet. Por ejemplo, los usuarios deben poder realizar tareas físicas como conducir o controlar una máquina a través de Internet usando controladores y actuadores sin experimentar retrasos o demoras notables debido al ancho de banda de la red. Por lo tanto, las redes de alta velocidad deben proporcionar aplicaciones móviles con una latencia de ida y vuelta de alrededor de 1 ms (por ejemplo, no mayor de 2 ms), robustez y disponibilidad de grado de portadora (por ejemplo, recuperación de fallos no mayor a 50 ms y disponibilidad de 99% a 99,999%). Estas aplicaciones se acuñan como las aplicaciones táctiles que transportan tráfico táctil y la red proporciona estas aplicaciones como "Internet táctil" o "red táctil". En este documento, la latencia de ida y vuelta de alrededor de 1 ms (por ejemplo, no más de 2 ms) se denomina latencia ultrabaja.
Un documento de MANABU ITO titulado "Tecnologías de virtualización de red móvil específicas de servicio" describe una técnica de antecedente de tecnologías de control de flujo de servicio. Un documento de SIMSEK MERYEM ET AL titulado "Internet táctil activado por 5G" describe el reenvío de tráfico táctil sin el nodo de retorno. El documento US 2013/266017 A1 describe una técnica de antecedente de un método para realizar la comunicación usando un nodo de reenvío que procesa un paquete recibido de acuerdo con una regla de proceso que coincide con el paquete recibido. Es un reto priorizar el tráfico táctil en una red para que se pueda cumplir su requisito de calidad de servicios (QoS).
Sumario
La invención es definida por las reivindicaciones independientes. Además, las realizaciones de la invención son definidas por las reivindicaciones dependientes. Cualquier referencia a las invenciones o realizaciones que no entran dentro del alcance de las reivindicaciones independientes ha de ser interpretada como ejemplos útiles para comprender la invención. Un aspecto divulga un método para una red de comunicación, donde la red de comunicación incluye un nodo de acceso que se comunica con dispositivos de usuario final, un nodo de retorno y un nodo central, donde el nodo de retorno transmite tráfico entre el nodo de acceso y el nodo central, y donde un dispositivo electrónico comprende el nodo de acceso o el nodo central, el método comprendiendo:
notificar, por el dispositivo electrónico, a un controlador que una aplicación ha sido autorizada para transmitir tráfico táctil en la red de comunicación, el controlador comunicándose con uno o más del nodo de acceso, el nodo de retorno y el nodo central, y la aplicación siendo desplegada en un dispositivo de usuario final, en el que el controlador, en respuesta a la notificación, hace que el nodo de retorno instale una entrada de tabla de flujo en una tabla de flujo del nodo de retorno, a través del cual los paquetes de la aplicación se reenviarán dentro de una latencia definida para el tráfico táctil por el nodo de retorno, en el que la entrada de tabla de flujo incluye uno o más bits de calidad de servicio en uno o más de sus campos coincidentes para coincidir al menos una indicación en los paquetes de tráfico táctil recibidos desde el dispositivo electrónico, en el que dicho o más campos coincidentes incluyen solo el ID de abonado o el ID de sesión, y en el que el emparejamiento de uno es suficiente para identificar el tráfico táctil y en el que la latencia de la aplicación en la red de comunicación está dentro de un milisegundo;
autenticar, por el dispositivo electrónico, un paquete que se origina o está destinado a la aplicación que ha sido autorizada para transmitir el tráfico táctil en la red de comunicación;
y reenviar, por el dispositivo electrónico, al nodo de retorno, el paquete con la latencia definida para el tráfico táctil usando una prioridad para el tráfico táctil.
Una red de comunicación configurada para incluir un nodo de acceso que se comunica con los dispositivos de usuario final, un nodo de retorno y un nodo central, en el que el nodo de retorno está configurado para transmitir tráfico entre el nodo de acceso y el nodo central, en el que el dispositivo electrónico está configurado para servir como el nodo de acceso o el nodo central; la red de comunicación está además configurada para comprender una pluralidad de procesadores; por lo que un procesador está comprendido en cada uno de los nodos y un procesador está comprendido en el controlador, y el medio de almacenamiento legible por máquina no transitorio respectivo estando acoplado a cada uno de los procesadores respectivos, el medio de almacenamiento legible por máquina no transitorio respectivo conteniendo instrucciones, que cuando son ejecutadas por el respectivo procesador, hacen que el dispositivo electrónico:
notifique a un controlador que una aplicación ha sido autorizada para transmitir tráfico táctil en la red de comunicación, el controlador se comunica con uno o más del nodo de acceso, el nodo de retorno y el nodo central, y la aplicación siendo desplegada en un dispositivo de usuario final,
autentique un paquete que se origina o está destinado a la aplicación que ha sido autorizada para transmitir el tráfico táctil en la red de comunicación, y reenvíe el paquete al nodo de retorno con la latencia definida para el tráfico táctil usando una prioridad para el tráfico táctil;
haga que el controlador, en respuesta a la notificación, haga que el nodo de retorno instale una entrada de tabla de flujo en una tabla de flujo del nodo de retorno, a través del cual los paquetes de la aplicación han de ser reenviados por el nodo de retorno dentro de una latencia definida para el tráfico táctil, en el que la entrada de tabla de flujo incluye uno o más bits de calidad de servicio en uno o más de sus campos coincidentes para coincidir al menos una indicación en los paquetes del tráfico táctil recibidos desde el dispositivo electrónico, en el que dicho o más campos coincidentes incluyen solo el ID de abonado o el ID de sesión, y en el que el emparejamiento de uno es suficiente para identificar el tráfico táctil y en el que la latencia de la aplicación en la red de comunicación está dentro de un milisegundo.
Un tercer aspecto divulga medios legibles por máquina no transitorios que tienen instrucciones almacenadas en los mismos para proporcionar suporte de calidad de servicio para tráfico táctil, las instrucciones haciendo que una pluralidad de procesadores ejecuten el método de la reivindicación 1.
Las realizaciones de las técnicas divulgadas proporcionan formas eficientes de proporcionar soporte de calidad de servicio para el tráfico táctil en una red.
Breve descripción de los dibujos
La invención puede entenderse mejor haciendo referencia a la siguiente descripción y los dibujos adjuntos que se usan para ilustrar las realizaciones de la invención. Los números de referencia y las designaciones similares en los diversos dibujos indican elementos similares. En los dibujos:
La figura 1 ilustra las operaciones de aprovisionamiento de soporte de QoS para tráfico táctil de acuerdo con una realización de la invención.
La figura 2 ilustra las operaciones de reenvío de soporte de QoS para tráfico táctil de acuerdo con una realización de la invención.
La figura 3 ilustra campos en un encabezado de paquete que pueden usarse para la transmisión de tráfico táctil de acuerdo con una realización de la invención.
La figura 4 ilustra una entrada de tabla de flujo para un nodo de retorno de acuerdo con una realización de la invención.
La figura 5 ilustra las operaciones de aprovisionamiento de soporte de QoS para tráfico táctil de acuerdo con otra realización de la invención.
La figura 6 ilustra las operaciones de reenvío de soporte de QoS para tráfico táctil de acuerdo con otra realización de la invención.
La figura 7 es un diagrama de flujo que ilustra las operaciones de soporte de QoS para tráfico táctil de acuerdo con una realización de la invención.
La figura 8 es un diagrama de flujo que ilustra la autenticación de un paquete para el soporte de QoS de tráfico táctil de acuerdo con una realización de la invención.
La figura 9A ilustra la conectividad entre dispositivos de red (ND) dentro de una red de ejemplo, así como tres implementaciones de ejemplo de los ND, de acuerdo con algunas realizaciones de la invención.
La figura 9B ilustra una forma de ejemplo de implementar un dispositivo de red de propósito especial de acuerdo con algunas realizaciones de la invención.
La figura 9C ilustra varias formas de ejemplo en las que los elementos de red virtual (VNE) pueden acoplarse de acuerdo con algunas realizaciones de la invención.
La figura 9D ilustra una red con un solo elemento de red (NE) en cada uno de los ND, y dentro de este enfoque directo contrasta un enfoque distribuido tradicional (comúnmente usado por los enrutadores tradicionales) con un enfoque centralizado para mantener la accesibilidad y el reenvío de información (también llamado control de red), de acuerdo con algunas realizaciones de la invención.
La figura 9E ilustra el caso simple de dónde cada uno de los ND implementa un solo NE, pero un plano de control centralizado ha abstraído varios de los NE en diferentes ND en (para representar) un solo NE en una de la red o redes virtuales, de acuerdo con algunas realizaciones de la invención.
La figura 9F ilustra un caso en el que se implementan múltiples VNE en diferentes ND y están acoplados entre sí, y donde un plano de control centralizado ha abstraído estos múltiples VNE de manera que aparecen como un único VNE dentro de una de las redes virtuales, de acuerdo con algunas realizaciones de la invención.
La figura 10 ilustra un dispositivo de plano de control de propósito general con software de plano de control centralizado (CCP) de acuerdo con algunas realizaciones de la invención.
Descripción detallada
En la siguiente descripción, se exponen numerosos detalles específicos. Sin embargo, se entiende que las realizaciones de la invención se pueden poner en práctica sin estos detalles específicos. En otros casos, los circuitos, estructuras y técnicas bien conocidos no se han mostrado en detalle para no complicar la comprensión de esta descripción. Sin embargo, un experto en la técnica apreciará que la invención se puede poner en práctica sin tales detalles específicos. Los expertos en la técnica, con las descripciones incluidas, podrán implementar la funcionalidad apropiada sin experimentación indebida.
Términos
Las referencias en la especificación a "una sola realización", "una realización", "una realización de ejemplo", etc., indican que la realización descrita puede incluir un rasgo, estructura o característica particular, pero cada realización puede no incluir necesariamente el rasgo, estructura o característica particular. Además, tales frases no se refieren necesariamente a la misma realización. Además, cuando se describe un rasgo, estructura o característica particular en relación con una realización, se afirma que está dentro del conocimiento de un experto en la técnica realizar tal rasgo, estructura o característica en relación con otras realizaciones, ya se describa explícitamente o no.
En la siguiente descripción y reivindicaciones, pueden usarse los términos "acoplado" y "conectado", junto con sus derivados. Debe entenderse que estos términos no pretenden ser sinónimos entre sí. "Acoplado" se usa para indicar que dos o más elementos, que pueden estar o no en contacto físico o eléctrico directo entre sí, cooperan o interactúan entre sí. "Conectado" se usa para indicar el establecimiento de comunicación entre dos o más elementos que están acoplados entre sí. Un "conjunto", como se usa en el presente documento, se refiere a cualquier número entero positivo de elementos, incluido un solo elemento.
Un dispositivo electrónico almacena y transmite (internamente y/o con otros dispositivos electrónicos a través de una red) código (que se compone de instrucciones de software y que a veces se denomina código de programa informático o programa informático) y/o datos usando medios legibles por máquina (también llamados medios legibles por computadora), como medios de almacenamiento legibles por máquina (por ejemplo, discos magnéticos, discos ópticos, memoria de solo lectura (ROM), dispositivos de memoria flash, memoria de cambio de fase) y medios de transmisión legibles por máquina (también llamados una portadora) (por ejemplo, señales eléctricas, ópticas, de radio, acústicas u otras formas de propagación, como ondas de portadora, señales infrarrojas). Por lo tanto, un dispositivo electrónico (por ejemplo, una computadora) incluye hardware y software, como un conjunto de uno o más procesadores acoplados a uno o más medios de almacenamiento legibles por máquina para almacenar código para su ejecución en el conjunto de procesadores y/o almacenar datos. Por ejemplo, un dispositivo electrónico puede incluir una memoria no volátil que contiene el código, ya que la memoria no volátil puede conservar el código/datos incluso cuando el dispositivo electrónico está apagado (cuando se desconecta la potencia), y mientras el dispositivo electrónico está encendido esa parte del código que ha de ser ejecutada por el procesador o los procesadores de ese dispositivo electrónico se copia típicamente de la memoria no volátil más lenta a la memoria volátil (por ejemplo, memoria dinámica de acceso aleatorio (DRAM), memoria estática de acceso aleatorio (SRAM)) de ese dispositivo electrónico. Los dispositivos electrónicos típicos también incluyen un conjunto o una o más interfaces de red físicas para establecer conexiones de red (para transmitir y/o recibir código y/o datos usando señales de propagación) con otros dispositivos electrónicos.
Un dispositivo de red (ND) es un dispositivo electrónico que interconecta comunicativamente otros dispositivos electrónicos en la red (por ejemplo, otros dispositivos de red, dispositivos de usuario final). Algunos dispositivos de red son "dispositivos de red de servicios múltiples" que proporcionan soporte para múltiples funciones de red (por ejemplo, enrutamiento, puenteo, conmutación, agregación de capa 2, control de borde de sesión, calidad de servicio y/o gestión de abonados) y/o proporcionan soporte para múltiples servicios de aplicaciones (por ejemplo, datos, voz y video). Un nodo, como un nodo de radio, un nodo de retorno o un nodo central, incluye uno o más dispositivos de red.
El término "equipo de usuario" (UE) se refiere a un dispositivo, por ejemplo, usado por una persona para su comunicación personal. Puede ser un dispositivo de tipo telefónico, por ejemplo, un teléfono o un teléfono SIP, un teléfono celular, una estación móvil, un teléfono inalámbrico o un tipo de dispositivo de asistente digital personal, como una computadora portátil, un cuaderno portátil, un bloc de notas portátil equipado con una conexión de datos inalámbrica. El UE también puede estar asociado con humanos, pero también con no humanos, como animales, plantas o incluso máquinas (la denominada comunicación de tipo máquina (MTC) o máquina a máquina (M2M)). Un UE puede estar equipado con un SIM (módulo de identidad de abonado) que comprende identidades únicas como IMSI (identidad de abonado móvil internacional) y/o TMSI (identidad de abonado móvil temporal) asociada con la persona que usa el UE, como un abonado que usa el UE. La presencia de un SIM dentro de un UE personaliza el UE de forma única con una suscripción del abonado. Tal abonado también puede usar múltiples dispositivos/UE al mismo tiempo.
El término "abonado" puede referirse a un ser humano que tiene un acuerdo de servicio con un proveedor de servicios, como un operador. El abonado también puede ser una entidad legal, como una empresa que opera un grupo de dispositivos MTC, y estos dispositivos operan independientemente de cualquier abonado humano. En este caso, el dispositivo MTC es el receptor directo del servicio, mientras que la suscripción del servicio es centralizada por la empresa (receptor indirecto de tal servicio) que opera el grupo de dispositivos MTC. Un dispositivo de usuario final, también denominado dispositivo de usuario final de un abonado o dispositivo electrónico de usuario final, es un dispositivo electrónico asociado con un abonado y los tipos de dispositivo de usuario final se describen con más detalle en relación con la figura 9A.
El término "red de comunicación" o "red" corta puede denotar en particular una colección de nodos o entidades, enlaces de transporte relacionados y gestión asociada necesaria para ejecutar un servicio o una aplicación (en esta especificación, los términos "servicio" y "aplicación" se usan indistintamente), por ejemplo, un servicio de telefonía o un servicio de transporte de paquetes. Dependiendo del servicio, se pueden utilizar diferentes tipos de nodos o entidades para realizar el servicio. Un operador de red es propietario de la red de comunicación y ofrece los servicios implementados a sus abonados. Los ejemplos típicos de una red de comunicación son la red de acceso de radio (como 2G (segunda generación), GSM (sistema global para comunicaciones móviles), 3G (tercera generación), WCDMA (acceso múltiple por división de código de banda ancha), CDMA (acceso múltiple por división de código), LTE (evolución a largo plazo), WLAN (red de área local inalámbrica), Wi-Fi (fidelidad inalámbrica)), red de retorno móvil o red central como IMS (sistema multimedia IP), centro de CS (circuito conmutado), centro de PS (paquete conmutado) y 5G. La red de comunicación también puede incluir las que usan otros protocolos de comunicación inalámbrica (como Bluetooth, ZigBee (ZigBee 2004, 2006, PRO), Z-wave (Z-Wave Alliance), Wi-Fi (IEEE 802.11), tecnología de red de área personal inalámbrica (por ejemplo, IEEE 801.15.4), telecomunicaciones digitales inalámbricas europeas (DECT) y WiMax) y las que usan medios alámbricos como fibras ópticas, líneas de cobre o líneas eléctricas y los protocolos correspondientes.
Calidad de servicio (QoS) en tres segmentos de redes de comunicación
Para soportar aplicaciones táctiles en una red, la infraestructura de red debe poder reconocer y/o soportar la priorización del tráfico táctil. Con este reconocimiento y/o soporte, el tráfico táctil tendría entonces una prioridad estricta sobre el resto del tráfico en la red, lo que asegurará que el tráfico táctil se reenvíe hacia el destino lo antes posible. Una forma posible de garantizar un retraso tan bajo es colocar la aplicación táctil lo más cerca posible del usuario. Sin embargo, eso por sí solo no es suficiente para proporcionar un retraso tan bajo como el requerido por el tráfico táctil. Los nodos de red también deben reconocer la necesidad de una latencia muy baja y actuar en consecuencia.
En la actualidad, existen métodos inconexos para proporcionar calidad de servicio (QoS) en una red. Una red de acceso (interactuar directamente con los abonados y sus dispositivos electrónicos) tiene sus propias formas de proporcionar QoS al tráfico de abonados, mientras que una red de retorno (a veces denominada red de transmisión), conecta el tráfico de abonados desde una o más redes de acceso a una red central, desconoce en gran medida la QoS del tráfico de abonados; la red de retorno puede proporcionar QoS a los agregados de tráfico sin conocimiento de la QoS a nivel de abonado. Más abajo, la red central tiene nuevamente sus propios mecanismos para clasificar y priorizar el tráfico. Entre estas tres partes de la red (de acceso, de retorno y central), la de acceso y la central tienen conocimiento a nivel de abonado y pueden identificar el tráfico de abonados, mientras que la de retorno solo ve una agregación de tráfico proveniente de la de acceso o la central sin conocimiento de nivel de abonado. En consecuencia, la red de retorno puede clasificar el tráfico basándose en la clase de QoS del tráfico (por ejemplo, bits de puntos de código de servicio diferenciado (DSCP) en paquetes IP o bits de puntos de código de prioridad (PCP) en paquetes Ethernet), pero no basándose en desde qué abonado proviene.
Un posible enfoque en este caso es marcar el tráfico en el lado de la red de acceso con el conocimiento del abonado, y luego el marcado se respeta en la red de retorno. Para que este enfoque funcione, es necesaria una granularidad adecuada de marcado para comunicar las clases de tráfico que necesita una aplicación táctil. Por otro lado, los bits de indicación de QoS de los protocolos de paquetes existentes (Ethernet, IP, etc.) ya se han usado ampliamente para comunicar clases de servicio, y ahora es difícil reservar una combinación de bits en particular para el tráfico que requiere tan poco retraso como tráfico táctil. Por ejemplo, en la red IP de retorno, ya existen expectativas bien conocidas sobre cómo funciona la priorización de QoS y qué marca debe recibir qué tratamiento. Por lo tanto, garantizar la QoS para el tráfico táctil en una red de alta velocidad como 5G requiere métodos de comunicación adicionales, lo que garantizará que, además de las clases de QoS existentes, los dispositivos de red de retorno puedan soportar posibilidades de QoS más detalladas.
Garantizar los requisitos de QoS del tráfico táctil requiere recursos y potencia de procesamiento de los dispositivos de red en su ruta y, por lo tanto, se necesita un mecanismo para garantizar que nadie pueda hacer un mal uso del aprovisionamiento. Para evitar tal uso indebido en el que el dispositivo de usuario final de un abonado simplemente establece el bit de indicación para el tráfico táctil (incluso cuando su tráfico no requiere la latencia ultrabaja) para recibir la QoS más alta, es necesario que haya una capa adicional de autorización para el tráfico táctil. Es decir, primero se debe confirmar si la fuente desde donde se origina el tráfico está autorizada para enviar tal tráfico. Sin embargo, las soluciones anteriores no tienen esta capacidad en la red de retorno, porque esas redes no tienen ningún conocimiento de nivel de abonado. Sin embargo, los nodos de acceso y los nodos centrales tienen conocimiento a nivel de abonado, y es posible que con ese conocimiento, estos nodos marquen los paquetes y la red de retorno respete el marcado.
Gran parte del tráfico existente requiere QoS acelerada en la red de retorno, como el tráfico de tiempo (por ejemplo, protocolo de tiempo de red (NTP) y protocolo de tiempo de precisión (PTP)), y otros tráficos requieren un límite de retraso estricto, como voz y vídeo. Sin embargo, este tráfico existente se acelera o se le da la calidad de servicio adecuada al agruparlos dentro de un determinado valor de indicador de QoS en el paquete IP o Ethernet.
Además, para el tráfico con un requisito de retraso extremadamente bajo (como PTP, donde se puede requerir que la precisión del reloj esté en nanosegundos), normalmente se añade soporte de hardware a los chips del conmutador y hay filtros de nivel de protocolo disponibles para filtrar esos paquetes. Esta clase de tráfico no requiere ningún marcado de nivel de abonado ni autorización para usar los indicadores de QoS.
Por lo tanto, un marcado de nivel de paquete (indicador de QoS) en los campos de QoS de un paquete o un filtro de protocolo en un nodo es suficiente para que los paquetes de un flujo de tráfico particular reciban la garantía de QoS del mejor esfuerzo. Sin embargo, para el tráfico táctil, el escenario es más complejo. Requiere QoS aún más estricta y no contiene ninguna indicación clara para que un dispositivo de red, como un conmutador/enrutador, lo filtre, lo que dificulta que una red de retorno proporcione el servicio QoS requerido. Además, las expectativas de la clase QoS para el tráfico táctil pueden variar ampliamente basándose en el caso de uso y el servicio proporcionado por el operador.
Se han propuesto soluciones con un marcado de paquete similar anteriormente. Sin embargo, esas soluciones abordan un conjunto diferente de problemas y funcionan con la calidad de servicio de nodo a nodo, o un algoritmo de selección interno del dispositivo en lugar de la transferencia de conocimientos a nivel de abonado a una red como la red de retorno. Para el tráfico táctil, es deseable procesar el tráfico usando el conocimiento del nivel de abonado en los tres segmentos de las redes de comunicación.
Operaciones de soporte de QoS para tráfico táctil
La figura 1 ilustra las operaciones de aprovisionamiento de soporte de QoS para tráfico táctil de acuerdo con una realización de la invención. El sistema 100 incluye un dispositivo 102 de usuario final, que está acoplado a una red que incluye un nodo 104 de acceso, un nodo 106 de retorno, un nodo central 108, todos los cuales se comunican con uno o más controladores tales como el controlador 150.
El nodo 104 de acceso puede ser un nodo de acceso inalámbrico o por cable. Un nodo de acceso inalámbrico a menudo se denomina nodo de acceso de radio que se comunica con el dispositivo 102 del usuario final a través de señales de radio. El nodo 104 de acceso es el nodo de entrada de datos desde el dispositivo 102 de usuario final a la red, y la comunicación entre el dispositivo 102 de usuario final y el nodo 104 de acceso puede ser a través de varios protocolos explicados en relación con la definición del término "comunicación red" anteriormente en el presente documento. El nodo 104 de acceso puede ser consciente de un abonado, es decir, puede identificar de qué dispositivo de usuario final proviene ese tráfico particular. El nodo 104 de acceso también puede identificar dicha o más aplicaciones para las que es el tráfico particular. Por tanto, el nodo 104 de acceso puede ser consciente del requisito de QoS del tráfico particular para una aplicación particular de un abonado particular. Sabiendo esto, el nodo 104 de acceso puede reenviar un tráfico particular con una prioridad adecuada de modo que se pueda satisfacer el requisito de QoS del tráfico particular.
El nodo central 108 está en el centro de la red. El nodo central 108 puede estar conectado con otros nodos centrales (no mostrados) en una topología de malla para reenviar tráfico desde una parte de la red a otra parte y el tráfico puede llegar al dispositivo de usuario final destinado. El nodo central 108 puede ser consciente de un abonado o de la aplicación del abonado. Por ejemplo, un nodo central, como una pasarela de servicio (S-GW), una pasarela de red de paquetes de datos (P-GW) o una entidad de gestión de movilidad (MME), típicamente identifica una sesión mediante un identificador de sesión asociado con un abonado o aplicación de abonado. Tal identificación es necesaria al menos para fines de gestión de la red (como facturación, autorización de servicio). Por tanto, el nodo central 108 puede ser consciente del requisito de QoS del tráfico particular para una aplicación particular de un abonado particular. Sabiendo esto, el nodo central 108 también puede reenviar el tráfico particular con una prioridad adecuada de modo que se pueda satisfacer el requisito de QoS del tráfico particular.
El nodo 106 de retorno agrega el tráfico de uno o más nodos de acceso, como el nodo 104 de acceso. Un nodo de retorno puede estar conectado con uno o más nodos de acceso a través de cable o de forma inalámbrica. Por ejemplo, un nodo de retorno puede conectar una estación base (un tipo de nodo de acceso) en un extremo, y conectar un nodo central en el otro extremo, de modo que el tráfico desde un UE pueda transmitirse al nodo central. Por tanto, un nodo de retorno puede ser un intermediario entre un nodo de acceso y un nodo central. El nodo de retorno típicamente no es consciente de un abonado en particular cuyo tráfico el nodo de retorno reenvía o se origina desde este. El nodo de retorno puede ser consciente del requisito de QoS para un agregado de flujos de tráfico, donde los flujos de tráfico provienen de diferentes dispositivos de usuario final o diferentes aplicaciones del mismo dispositivo de usuario final, pero ese conocimiento por sí solo sería insuficiente para cumplir con el requisito de QoS de un flujo de tráfico táctil particular dentro del agregado de flujo de tráfico que contiene múltiples flujos de tráfico. Por tanto, como se ilustra en la referencia 120, el nodo 106 de retorno está en el segmento de nodo/red que, por sí mismo, no reconoce el tráfico táctil.
Un controlador 150 está en comunicación con el nodo 104 de acceso, el nodo 106 de retorno y/o el nodo central 108. Cada nodo tiene una interfaz para comunicarse con un controlador, aunque es posible que no todos los nodos se comuniquen con el mismo controlador. Un controlador es responsable de coordinar el reenvío de tráfico en varios nodos. El controlador es un controlador de red definida por software (SDN) en una realización. El controlador SDN (también denominado controlador de red y los dos términos se usan indistintamente) se puede renombrar como otras entidades, como controlador de red de área amplia (WAN) de múltiples capas (MLWC). Independientemente de los diferentes nombres, el controlador de red/SDN realiza las funciones descritas con más detalle en relación con las figuras 9A-F y 10.
Un operador 152 es el operador del sistema 100. El operador 152 gestiona el dispositivo 102 de usuario final, que obtiene una autorización del operador 152 para transmitir tráfico táctil para una o más aplicaciones. El operador 152 también puede informar a los nodos (que son conscientes de los abonados, tales como el nodo 104 de acceso y el nodo central 108) que dicha o más aplicaciones del dispositivo 102 de usuario final pueden transmitir el tráfico táctil. Debe observarse que pueden existir múltiples operadores en el sistema 100, y el operador que gestiona el dispositivo 102 de usuario final puede ser diferente del operador que gestiona otros nodos. Además, el operador que gestiona el nodo 106 de retorno puede ser diferente del que gestiona el nodo 104 de acceso o el nodo central 108. Además, el operador 152 y el controlador 150 pueden implementarse en un solo dispositivo electrónico.
Aunque solo se ilustra uno de cada tipo de dispositivo, un sistema típico contiene una pluralidad de dispositivos de usuario final, nodos de acceso, nodos de retorno y/o nodos centrales. Además, el tráfico de un dispositivo de usuario final puede reenviarse a través de múltiples nodos de acceso, nodos de retorno y/o nodos centrales. Cuando varios nodos son del mismo tipo de nodos, esa pluralidad de nodos del mismo tipo se denomina red, por ejemplo, una red de acceso con una pluralidad de nodos de acceso, una red de retorno con una pluralidad de nodos de retorno y una red central con una pluralidad de nodos centrales.
La figura 1 incluye los cuadros 1 a 4 de tareas que ilustran una secuencia de operaciones de provisión de acuerdo con una realización de la invención. En el cuadro 1 de tareas, el dispositivo 102 de usuario final obtiene una autorización del operador 152 para transmitir tráfico táctil. El dispositivo 102 de usuario final puede iniciar una aplicación que requiera una latencia ultrabaja de tráfico táctil. La aplicación puede ser cualquiera de las tareas hápticas a través de Internet, incluidas las aplicaciones telemédicas explicadas anteriormente en el presente documento. La aplicación inicia una sesión de comunicación en el sistema 100. El operador 152 puede conceder la autorización basándose en una variedad de factores. Por ejemplo, el abonado que usa el dispositivo 102 de usuario final puede proporcionar una compensación monetaria específicamente para la aplicación, y tras el acuerdo del abonado para pagar, el operador 152 concede la autorización. El abonado también puede pertenecer a una clase de abonados privilegiados y/o la aplicación puede pertenecer a una clase de aplicaciones privilegiadas que requieren una QoS que incluye la latencia ultrabaja. El operador 152 también puede verificar el estado de la red, determinar si la red tiene suficientes recursos para soportar la aplicación o no y solo concede la autorización si la red tiene suficientes recursos.
En el cuadro 2 de tareas, se notifica al nodo 104 de acceso que la aplicación requiere un retraso definido para tráfico táctil. La notificación puede ser del dispositivo 102 del usuario final o del operador 152. La notificación puede especificar un identificador de sesión (ID) de la sesión de comunicación para la aplicación. El ID de sesión puede tener la forma de identificador de punto final de túnel (TEID) cuando se usa el protocolo de tunelación (GTP) del servicio de radio por paquetes general (GPRS) para la aplicación. La notificación puede especificar, alternativa o adicionalmente, un ID de abonado del abonado que usa el dispositivo 102 de usuario final.
La notificación también puede especificar requisitos de una QoS particular del tráfico táctil. El nodo 104 de acceso puede soportar una pluralidad de QoS para tráfico táctil, y la notificación puede indicar cuál de las QoS para esta aplicación es aplicable. Por ejemplo, el nodo 104 de acceso puede soportar diferentes latencias ultrabajas tales como 0,2 ms, 0,5 ms y 1 ms, y la notificación usa uno o más bits de QoS que indican el requisito de latencia de la aplicación. Por ejemplo, el valor de bit de 00 representa que la latencia ultrabaja requerida es de 0,2 ms, el valor de bit de 01 representa la latencia ultrabaja requerida de 0,5 ms y el valor de bit de 10 representa la latencia ultrabaja requerida de 1 ms. En una realización, solo hay un requisito de latencia de QoS para el tráfico táctil, por lo que un solo bit indica si el tráfico que es táctil es suficiente o no.
La figura 3 ilustra campos en un encabezado de paquete que pueden usarse para la transmisión de tráfico táctil de acuerdo con una realización de la invención. La figura ilustra un encabezado de paquete IPv4. Dentro del encabezado de paquete IPv4, como se conoce en la técnica, el campo DSCP identifica el tipo de servicio para el paquete. Los bits DSCP se usan como indicación de QoS basada en estándares (por ejemplo, solicitud de comentarios de IETF (RFC) 2983) para aplicaciones existentes, por lo que no se pueden usar para indicar el requisito de QoS de tráfico táctil. En cambio, el tráfico táctil puede usar otros campos para su indicación de QoS y para indicar que el abonado y/o la aplicación pueden transmitir tráfico táctil. Cabe señalar que los otros campos y los patrones de bits en los otros campos para indicar la QoS y el abonado y/o la aplicación permitidos pueden ser elegidos por el operador 152. Siempre que la selección sea conocida por los nodos que son conscientes de los abonados y los campos y patrones de bits en los campos no se usen para otros fines que no sean la transmisión de tráfico táctil en la red, la elección debería ser aceptable.
Por ejemplo, la referencia 302 ilustra los campos de ejemplo para la indicación de autorización para transmitir tráfico táctil. El campo puede ser el campo de notificación de congestión explícita (ECN) y/o el campo de opciones, que existe cuando la longitud del encabezado de Internet (IHL) es superior a 20 bytes (5x32 = 160 bits = 20 bytes). En una realización, el campo ECN indica el requisito de QoS del tráfico táctil, por lo que funciona como bits de QoS, mientras que el campo de opciones indica el ID de sesión y/o el ID de abonado, cuya sesión/abonado puede transmitir el tráfico táctil. En una realización alternativa, cualquier campo puede incluir tanto el requisito de QoS como el ID de sesión/abonado.
Si bien se ilustra el encabezado de paquete IPv4, debe tenerse en cuenta que el campo o campos en el encabezado de paquete IPv6 también se pueden usar como bits de QoS para el tráfico táctil e ID de sesión/abonado. De hecho, no solo se puede usar el encabezado de paquete en la capa IP (que está en la capa 3 de interconexión de sistemas abiertos (OSI)), sino que también se puede usar el encabezado de trama en la capa Ethernet (que está en la capa 2 OSI) como bits de QoS para tráfico táctil e ID de sesión/abonado. De hecho, el principio de la invención puede usarse en protocolos propietarios y campo o campos en sus encabezados de paquete, donde el campo o campos se usan como bits de QoS para tráfico táctil e ID de sesión/abonado.
Con la notificación, el nodo 104 de acceso sabe que la aplicación tiene la autorización para transmitir tráfico táctil, y el nodo 104 de acceso reenviará paquetes de la aplicación como tráfico táctil al recibir los paquetes de la aplicación. Para hacer eso, el nodo 104 de acceso puede establecer reglas de reenvío y/o generar entradas de reenvío. Por ejemplo, cuando el nodo 104 de acceso es un dispositivo de red tradicional como un enrutador o un conmutador, el nodo 104 de acceso puede programar la adyacencia y la información de ruta con respecto al tráfico táctil y el sistema 100 en una o más estructuras de reenvío (por ejemplo, base de información de reenvío (FIB), base de información de reenvío de etiquetas (LFIB) y una o más estructuras de adyacencia) para reenviar el tráfico táctil. Cuando el nodo 104 de acceso es un dispositivo de red gestionado por un controlador SDN (una realización del controlador 150), el nodo 104 de acceso puede, basándose en la entrada del controlador SDN, instalar una tabla de flujo y una o más entradas de tabla de flujo dentro de la tabla de flujo para reenviar el tráfico táctil.
En el cuadro 3 de tareas, el nodo 104 de acceso notifica al controlador 150 que la aplicación requiere un retraso definido para el tráfico táctil. La notificación del nodo 104 de acceso puede contener la misma información con respecto a la aplicación que la notificación que el nodo 104 de acceso recibió en el cuadro 2 de tareas, o la notificación del nodo 104 de acceso puede contener más o menos información que la notificación que recibe el nodo 104 de acceso. En una realización, la notificación toma la forma de un mensaje PACKET_IN de acuerdo con los estándares de fundación de red abierta (ONF).
En el cuadro 4 de tareas, el controlador hace que el nodo 106 de retorno instale una entrada de tabla de flujo en una tabla de flujo, a través de la cual los paquetes de la aplicación desde el dispositivo de usuario final se reenviarán dentro de la latencia definida para el tráfico táctil por el nodo de retorno. Como se explicó anteriormente en el presente documento, el nodo 106 de retorno, por sí mismo, no reconoce el tráfico táctil que tiene la autorización del operador 152 para transmitir dentro del retraso definido para el tráfico táctil. Sin embargo, en una realización, basándose en la notificación del cuadro 3 de tareas, el controlador 150 reconoce el tráfico táctil que tiene la autorización para transmitir dentro del retraso definido para el tráfico táctil. Por tanto, el controlador envía un mensaje al nodo 106 de retorno, donde el mensaje toma la forma de PACKET_OUT de acuerdo con los estándares ONF. El mensaje hace que el nodo 106 de retorno instale la entrada de tabla de flujo en la tabla de flujo del nodo 106 de retorno.
La figura 4 ilustra una entrada de tabla de flujo para un nodo de retorno de acuerdo con una realización de la invención. Una entrada 400 de tabla de flujo en un nodo de retorno tal como el nodo 106 de retorno se ilustra para incluir los siguientes campos:
• Campos coincidentes 402: para comparar con paquetes. La composición de los campos coincidentes se detalla en el presente documento a continuación.
• Prioridad 403: precedencia de emparejamiento de la entrada de tabla de flujo.
• Contadores 404: contando el número de emparejamiento de paquetes; actualizado cuando los paquetes coinciden.
• Instrucciones 406: acciones para modificar el conjunto de acciones o el procesamiento de la canalización de paquetes de un paquete coincidente. La instrucción 406 se genera para reenviar los paquetes coincidentes dentro de la latencia definida para el tráfico táctil.
• Vida útil 407: cantidad máxima de tiempo o tiempo de inactividad antes de que el elemento de red expire el flujo. La vida útil también puede denominarse tiempo de espera en algunas realizaciones.
• Cookie 408: valor de datos opaco elegido por el controlador SDN. Puede ser usado por el controlador para filtrar estadísticas de flujo, modificación de flujo y eliminación de flujo.
Los campos coincidentes 402 incluyen uno o más subcampos tales como el ID 412 de abonado, el ID 414 de sesión y/o los bits 416 de QoS. Los valores de estos campos se basan en los valores correspondientes de estos campos de la notificación procedente del controlador 150 en una realización. Dado que la notificación se basa en la información recibida del nodo 104 de acceso, el nodo 106 de retorno puede instalar la entrada de tabla de flujo de modo que el nodo 106 de retorno reenvíe paquetes del tráfico táctil de manera similar al nodo 104 de acceso, a pesar de que el nodo 106 de retorno por sí mismo no reconoce el tráfico táctil.
Debe observarse que los subcampos 412 a 416 son solo para ilustración y pueden usarse más o menos subcampos para los campos coincidentes en una realización diferente. Por ejemplo, los campos coincidentes pueden incluir solo el ID de abonado o el ID de sesión, cuando el emparejamiento de uno es suficiente para identificar el tráfico táctil. Además, puede haber solo un solo bit de QoS (en lugar de una pluralidad de bits de QoS 416 que indican una de las latencias ultrabajas soportadas) para verificar que un paquete coincidente requiere ser reenviado dentro de la latencia definida para el tráfico táctil.
La figura 2 ilustra las operaciones de reenvío de soporte de QoS para tráfico táctil de acuerdo con una realización de la invención. El sistema 100 de la figura 2 es el mismo que el de la figura 1, y referencias iguales o similares indican elementos o componentes que tienen funcionalidades iguales o similares. Los cuadros 1 a 3 de tareas ilustran una secuencia de operaciones de reenvío de tráfico de acuerdo con una realización de la invención.
En el cuadro 1 de tareas, el dispositivo 102 de usuario final transmite un paquete de la aplicación que está autorizado para transmitir el tráfico táctil. La transmisión del paquete puede ocurrir inmediatamente después de que el dispositivo 102 de usuario final obtenga la autorización para transmitir el tráfico táctil y puede ocurrir en algún momento posterior cuando se genera el paquete del tráfico táctil. El paquete puede incluir la información relativa a la autorización para transmitir el tráfico táctil. En una realización, la información incluye el ID de sesión/abonado de la aplicación y uno o más bits de QoS del tráfico táctil. El ID de sesión/abonado y uno o más bits de QoS se explican con más detalle en relación con las figuras 1 y 3. La información relativa a la autorización para transmitir el tráfico táctil se puede marcar en el paquete a través de aplicaciones certificadas por un operador que pueden marcar los paquetes salientes con la información en una realización.
En el cuadro 2 de tareas, el nodo 104 de acceso autentica el paquete (1) que se indica como para un tráfico táctil y (2) desde una aplicación autorizada. Si el paquete es autenticado, el paquete se reenvía al nodo 104 de acceso dentro de una latencia definida para el tráfico táctil. En una realización, si el nodo de acceso determina que el paquete no se ha indicado como para el tráfico táctil (por ejemplo, no hay indicación de uno o más bits de QoS para el tráfico táctil) en el paquete (por ejemplo, el encabezado de paquete) para transmitir el táctil, el paquete se reenviará como tráfico regular en lugar del tráfico táctil.
Si el paquete no es de una aplicación autorizada, cuyo nodo de acceso determina al encontrar el ID de sesión/abonado en el paquete (por ejemplo, el encabezado de paquete) que no está autorizado para transmitir el tráfico táctil, sino que el paquete está indicado para la aplicación táctil, el paquete se descarta en una realización. En una realización alternativa, el paquete se reenvía sin tener prioridad como tráfico táctil. Cuando el paquete se reenvía al nodo 104 de acceso dentro de la latencia definida para el tráfico táctil, el nodo 104 de acceso utiliza la programada o más estructuras de reenvío o la tabla de flujo o las entradas de tabla de flujo instaladas durante la fase de provisión explicada en relación con el cuadro 2 de tareas de la figura 1 explicado anteriormente en el presente documento, de modo que el paquete se reenvíe al siguiente nodo (el nodo 106 de retorno en este ejemplo) dentro de la latencia definida para el tráfico táctil.
En el cuadro 3 de tareas, el paquete se recibe en el nodo 106 de retorno, y el nodo 106 de retorno reenvía el paquete según los campos coincidentes en una entrada de tabla de flujo sin reconocer el tráfico táctil. La entrada de tabla de flujo y la tabla de flujo asociada se instalan en la fase de provisión explicada en relación con las figuras 1 y 4. El emparejamiento en el nodo 106 de retorno es para autenticar que el paquete puede transmitirse dentro de la latencia definida para el tráfico táctil y puede verse como una autenticación de dos pasos que verifica que el paquete (1) es para una aplicación táctil (por ejemplo, mediante el emparejamiento con los bits de QoS 416) y (2) desde una aplicación autorizada (por ejemplo, mediante el emparejamiento con el ID 412 de abonado y/o el ID 414 de sesión).
La figura 5 ilustra las operaciones de aprovisionamiento de soporte de QoS para tráfico táctil de acuerdo con otra realización de la invención. La figura 5 es similar a la figura 1 y referencias iguales o similares indican elementos o componentes que tienen funcionalidades iguales o similares. Solo se explica la diferencia entre las dos figuras. La figura 5 incluye los cuadros 1 a 4 de tareas que ilustran una secuencia de operaciones de provisión de acuerdo con una realización de la invención. En contraste con la figura 1, la solicitud de transmisión de tráfico táctil proviene del nodo central 108.
En el cuadro 1 de tareas, una aplicación que se origina o está destinada a un dispositivo de usuario final (por ejemplo, el dispositivo 102 de usuario final) obtiene una autorización del operador 152 para transmitir tráfico táctil en el nodo central 108. Como se explicó anteriormente en el presente documento, un nodo central puede ser consciente un abonado o la aplicación de abonado. El abonado que usa el dispositivo de usuario final y/o la aplicación del abonado puede obtener la autorización para transmitir el tráfico táctil. El operador 152 puede conceder la autorización se origina o está destinada de la aplicación, y el operador 152 puede conceder la autorización basándose en factores iguales o diferentes a la variedad de factores explicados anteriormente en el presente documento en relación con el cuadro 1 de tareas de la figura 1.
En el cuadro 2 de tareas, el nodo central 108 prepara el reenvío de paquetes de la aplicación con un retraso definido para el tráfico táctil. En una realización, el nodo central 108 puede establecer reglas de reenvío y/o generar entradas de reenvío, similar al nodo 104 de acceso en el cuadro 2 de tareas como se explicó anteriormente en el presente documento.
En el cuadro 3 de tareas, el nodo central 108 notifica al controlador 150 que la aplicación requiere un retraso definido para el tráfico táctil. En cuadro 4 de tareas, el controlador hace que el nodo 106 de retorno instale una entrada de tabla de flujo en una tabla de flujo, a través de la cual los paquetes de la aplicación se reenviarán dentro de la latencia definida para el tráfico táctil por el nodo de retorno. Las operaciones en ambos cuadros de tareas son similares a los cuadros de tareas correspondientes en la figura 1, por lo que no se repiten aquí.
La figura 6 ilustra las operaciones de reenvío de soporte de QoS para tráfico táctil de acuerdo con otra realización de la invención. La figura 6 es similar a la figura 2 y referencias iguales o similares indican elementos o componentes que tienen funcionalidades iguales o similares. Solo se explica la diferencia entre las dos figuras. La figura 6 incluye cuadros 1 a 3 de tareas que ilustran una secuencia de operaciones de reenvío de acuerdo con una realización de la invención. En contraste con la figura 2, el paquete es del nodo central 108.
En el cuadro 1 de tareas, el nodo central 108 recibe un paquete de la aplicación que está autorizado para transmitir el tráfico táctil. El tráfico táctil es para la aplicación autorizada en la figura 5. El paquete puede incluir la información relativa a la autorización para transmitir el tráfico táctil similar al paquete recibido desde el nodo 104 de acceso en el cuadro 1 de tareas de la figura 2.
En el cuadro 2 de tareas, el nodo central 108 autentica el paquete (1) que se indica como tráfico táctil y (2) desde una aplicación autorizada. Si el paquete es autenticado, el paquete se reenvía al nodo central 108 dentro de una latencia definida para el tráfico táctil. En el cuadro 3 de tareas, el paquete se recibe en el nodo 106 de retorno, y el nodo 106 de retorno reenvía el paquete según los campos coincidentes en una entrada de tabla de flujo sin reconocer el tráfico táctil. Las operaciones en ambos cuadros de tareas son similares a los cuadros de tareas correspondientes en la figura 2, por lo que no se repiten aquí.
Diagramas de flujo
La figura 7 es un diagrama de flujo que ilustra las operaciones de soporte de QoS para tráfico táctil de acuerdo con una realización de la invención. El método 700 puede implementarse en un dispositivo electrónico de una red de comunicación. El dispositivo electrónico puede comprender el nodo 104 de acceso o el nodo central 108 como se ilustra en las figuras 1-2 y 5-6 de acuerdo con las realizaciones de la invención. En una realización, la red de comunicación es una red móvil de quinta generación (5G).
En la referencia 702, el dispositivo electrónico notifica a un controlador que se ha autorizado una aplicación para transmitir tráfico táctil en una red de comunicación. El controlador se comunica con uno o más de los nodos de acceso, el nodo de retorno y el nodo central de la red de comunicación. La aplicación se desplegará en un dispositivo de usuario final. En una realización, el usuario final solicita una autorización (por ejemplo, de un operador de la red de comunicación) para que la aplicación transmita el tráfico táctil. Una vez que se obtiene la autorización, el dispositivo de usuario final puede notificar al dispositivo electrónico que la aplicación ha sido autorizada en una realización.
El controlador es un controlador SDN en una realización de la invención. El controlador, en respuesta a la notificación, hace que el nodo de retorno instale una entrada de tabla de flujo en una tabla de flujo del nodo de retorno, a través del cual los paquetes de la aplicación se reenviarán dentro de una latencia definida para el tráfico táctil por el nodo de retorno. En una realización, la latencia definida para el tráfico táctil es inferior a un milisegundo. En una realización, el nodo de retorno reenvía los paquetes de la aplicación basándose en la entrada de tabla de flujo con uno o más campos coincidentes de un identificador de abonado, un identificador de sesión y uno o más bits de calidad de servicio. Los valores del identificador de abonado, el identificador de sesión y dicho o más bits de calidad de servicio se establecen basándose en la notificación que el controlador recibió del dispositivo electrónico como se explicó anteriormente en el presente documento.
En la referencia 704, el dispositivo electrónico recibe un paquete, y el dispositivo electrónico autentica que el paquete se origina o está destinado a la aplicación que ha sido autorizada para transmitir el tráfico táctil en la red de comunicación. Se explican más detalles de las operaciones en la referencia 704 en relación con las figuras 2, 6 y 8. En una realización, se establece una indicación del paquete para indicar la autorización de la aplicación para transmitir el tráfico táctil, y el dispositivo electrónico autentica el paquete basándose en la indicación. En una realización, la indicación incluye uno o más de un identificador de abonado, un identificador de sesión; y uno o más bits de calidad de servicio.
En la referencia 806, el dispositivo electrónico reenvía el paquete con la latencia definida para el tráfico táctil. El reenvío de paquetes se describe con más detalle en relación con la figura 2.
La figura 8 es un diagrama de flujo que ilustra la autenticación de un paquete para el soporte de QoS de tráfico táctil de acuerdo con una realización de la invención. El método 800 es una realización de las operaciones de la referencia 704.
En la referencia 802, la electrónica recibe un paquete. En la referencia 804, el dispositivo electrónico identifica si el paquete incluye o no una indicación para transmitir tráfico táctil. En una realización, la indicación para transmitir el tráfico táctil incluye uno o más bits de QoS en un campo (por ejemplo, el campo ECN explicado anteriormente en el presente documento) se establecen para indicar la autorización para la aplicación. Si el paquete no incluye la indicación para transmitir el tráfico táctil, el flujo pasa a la referencia 812, en el que el paquete se reenvía como tráfico normal, sin ser acelerado y reenviado dentro de la latencia definida para el tráfico táctil. Si el paquete incluye la indicación para transmitir el tráfico táctil, el flujo va a la referencia 806.
En la referencia 806, el dispositivo electrónico verifica si la aplicación ha sido autorizada para transmitir el tráfico táctil. En una realización, la indicación de autorización para transmitir el tráfico táctil incluye uno o más de (1) un ID de abonado que identifica al abonado usando la aplicación desplegada en el dispositivo de usuario final; (2) un ID de sesión que identifica la sesión de comunicación de la aplicación transmitiendo en la red de comunicación.
Mediante realizaciones de la invención, los nodos que por sí mismos no reconocen el tráfico táctil pueden reenviar el tráfico táctil basándose en las entradas de tabla de flujo instaladas, que es información basada en la instalación de un controlador tal como un controlador SDN. El controlador, a su vez, obtiene información sobre el tráfico táctil de un nodo que es consciente del tráfico táctil.
Entorno SDN y NFV que utiliza realizaciones de la invención
Las realizaciones de la invención pueden utilizarse en una red SDN y NFV que contenga dispositivos de red. La figura 9A ilustra la conectividad entre dispositivos de red (ND) dentro de una red de ejemplo, así como tres implementaciones de ejemplo de los ND, de acuerdo con algunas realizaciones de la invención. La figura 9A muestra los ND 900A-H y su conectividad por medio de líneas entre A-B, B-C, C-D, D-E, E-F, F-G y A-G, así como entre H y cada uno de A, C, D y G. Estos ND son dispositivos físicos y la conectividad entre estos ND puede ser inalámbrica o por cable (a menudo denominada enlace). Una línea adicional que se extiende desde los ND 900A, E y F ilustra que estos ND actúan como puntos de entrada y salida para la red (y, por lo tanto, estos ND a veces se denominan ND de borde; mientras que los otros ND pueden llamarse ND centrales). Sin embargo, en algunas realizaciones, los ND como S-GW y P-GW están en el borde de la red del operador de conexión, pero todavía se denominan ND centrales y no ND de borde.
Dos de las implementaciones de ND de ejemplo en la figura 9A son: 1) un dispositivo 902 de red de propósito especial que usa circuitos integrados de aplicación específica (ASIC) personalizados y un sistema operativo (OS) patentado; y 2) un dispositivo 904 de red de uso general que usa procesadores comunes existentes (COTS) y un sistema operativo estándar.
El dispositivo 902 de red de propósito especial incluye hardware 910 de red que comprende el recurso o recursos informáticos 912 (que típicamente incluyen un conjunto de uno o más procesadores), el recurso 914 o recursos de reenvío (que típicamente incluyen uno o más ASIC y/o procesadores de red), e interfaces 916 de red físicas (NI) (a veces denominadas puertos físicos), así como medios 918 de almacenamiento no transitorios legibles por máquina que tienen almacenado software 920 de red, incluyendo nodo de acceso, nodo de retorno y/o software 925 de nodo central. Cuando el nodo de acceso, el nodo de retorno y el código central funcionan como un elemento de red de un sistema SDN, sus funcionalidades pueden ser similares, particularmente en el reenvío de paquetes basados en la tabla de flujo y las entradas de tabla de flujo. Una NI física es hardware en un ND a través del cual se realiza una conexión de red (por ejemplo, de forma inalámbrica a través de un controlador de interfaz de red inalámbrica (WNIC) o mediante la conexión de un cable a un puerto físico conectado a un controlador de interfaz de red (NIC)), como los que muestra la conectividad entre los ND 900A-H. Durante el funcionamiento, el software 925 de nodo de acceso/retorno/central puede ser ejecutado por el hardware 910 de red para crear una instancia de software de nodo, que realiza operaciones como se explicó anteriormente en el presente documento en relación con las figuras 1-2 y 5-8. La instancia de software de nodo y esa parte del hardware 910 de red que ejecuta esa instancia (ya sea hardware dedicado a esa instancia de software de red y/o porciones de tiempo de hardware compartidas temporalmente por esa instancia de software de red con otras de la instancia 922 de software de red), forman un elemento de red virtual independiente 930A-R. Cada uno de los elementos de la red virtual (VNE) 930A-R incluye un módulo 932A-R de comunicación y configuración de control (a veces denominado módulo de control local o módulo de comunicación de control) y una tabla o tablas 934A-R de reenvío, como que un elemento de red virtual dado (por ejemplo, 930A) incluye el módulo de comunicación y configuración de control (por ejemplo, 932A), un conjunto de una o más tablas de reenvío (por ejemplo, 934A), y esa parte del hardware 910 de red que ejecuta el elemento de red virtual (por ejemplo, 930A).
El dispositivo 902 de red de propósito especial a menudo se considera física y/o lógicamente que incluye: 1) un plano 924 de control de ND (a veces denominado plano de control) que comprende el recurso o recursos informáticos 912 que ejecutan el módulo o módulos 932A-R de configuración y comunicación de control; y 2) un plano 926 de reenvío de ND (a veces denominado plano de reenvío, plano de datos o plano de medios) que comprende el recurso o recursos 914 de reenvío que usan la tabla o tablas 934A-R de reenvío y las NI físicas 916. A modo de ejemplo, cuando el ND es un enrutador (o está implementando la funcionalidad de enrutamiento), el plano 924 de control de ND (el recurso o recursos informáticos 912 que ejecutan los módulos 932A-R de configuración y comunicación de control) es típicamente responsable de participar en el control de cómo se enrutan los datos (por ejemplo, paquetes) (por ejemplo, el próximo salto para los datos y la NI física saliente para esos datos) y almacenar esa información de enrutamiento en la tabla o tablas 934A-R de reenvío, y el plano 926 de reenvío de ND es responsable de recibir esos datos en las NI físicas 916 y de reenviar esos datos a las apropiadas de las NI físicas 916 basándose en la tabla o tablas 934A-R de reenvío.
La figura 9B ilustra una forma de ejemplo de implementar un dispositivo de red de propósito especial de acuerdo con algunas realizaciones de la invención. La figura 9B muestra el dispositivo de red de propósito especial, incluidas las tarjetas 938 (típicamente conectables en caliente). Mientras que en algunas realizaciones las tarjetas 938 son de dos tipos (una o más que funcionan como el plano 926 de reenvío de ND (a veces llamadas tarjetas de línea), y una o más que funcionan para implementar el plano 924 de control de ND (a veces llamadas tarjetas de control)), las realizaciones alternativas pueden combinar la funcionalidad en una sola tarjeta y/o incluir tipos de tarjetas adicionales (por ejemplo, un tipo adicional de tarjeta se denomina tarjeta de servicio, tarjeta de recursos o tarjeta de múltiples aplicaciones). Una tarjeta de servicio puede proporcionar procesamiento especializado (por ejemplo, servicios de capa 4 a capa 7 (por ejemplo, cortafuegos, seguridad de protocolo de Internet (IPsec), capa de conector seguro (SSL)/seguridad de capa de transporte (TLS), sistema de detección de intrusiones (IDS), entre pares (P2P), controlador de borde de sesión de voz sobre IP (VoIP), pasarelas inalámbricas móviles (nodo de soporte de servicio de radio de paquetes general de pasarela (GPRS) (GGSN), pasarela básica por paquetes evolucionada (EPC))). A modo de ejemplo, se puede usar una tarjeta de servicio para terminar túneles IPsec y ejecutar los algoritmos de autenticación y encriptación asociados. Estas tarjetas se acoplan entre sí a través de uno o más mecanismos de interconexión ilustrados como placa base 936 (por ejemplo, una primera malla completa que acopla las tarjetas de línea y una segunda malla completa que acopla todas las tarjetas).
Volviendo a la figura 9A, el dispositivo 904 de red de uso general incluye hardware 940 que comprende un conjunto de uno o más procesadores 942 (que a menudo son procesadores COTS) y controladores 944 de interfaz de red (NIC; también conocidos como tarjetas de interfaz de red) (que incluyen las NI físicas 946), así como los medios 948 de almacenamiento no transitorios legibles por máquina que tienen almacenado el software 950, que también puede contener el software 925 de nodo de acceso/retorno/central. Durante el funcionamiento, el procesador o procesadores 942 ejecutan el software 950 para instanciar uno o más conjuntos de una o más aplicaciones 964A-R. Si bien una realización no implementa la virtualización, las realizaciones alternativas pueden usar diferentes formas de virtualización. Por ejemplo, en una de estas realizaciones alternativas, la capa 954 de virtualización representa el kernel de un sistema operativo (o una corrección que se ejecuta en un sistema operativo base) que permite la creación de múltiples instancias 962A-R denominadas contenedores de software que pueden usarse para ejecutar uno (o más) de los conjuntos de aplicaciones 964A-R; donde los múltiples contenedores de software (también llamados motores de virtualización, servidores privados virtuales o cárceles) son espacios de usuario (típicamente un espacio de memoria virtual) que están separados entre sí y separados del espacio del kernel en el que se ejecuta el sistema operativo; y donde el conjunto de aplicaciones que se ejecutan en un espacio de usuario determinado, a menos que se permita explícitamente, no puede acceder a la memoria de los otros procesos. En otra realización alternativa, la capa 954 de virtualización representa un hipervisor (a veces denominado monitor de máquina virtual (VMM)) o un hipervisor que se ejecuta en la parte superior de un sistema operativo anfitrión, y cada uno de los conjuntos de aplicaciones 964A-R se ejecuta en la parte superior de un sistema operativo invitado dentro de una instancia 962A-R llamada máquina virtual (que en algunos casos puede considerarse una forma muy aislada de contenedor de software) que se ejecuta en la parte superior del hipervisor; es posible que el sistema operativo invitado y la aplicación no sepan que se ejecutan en una máquina virtual en lugar de ejecutarse en un dispositivo electrónico anfitrión "desnudo", o mediante la paravirtualización, el sistema operativo y/o la aplicación pueden ser conscientes de la presencia de virtualización con fines de optimización. En otras realizaciones alternativas, una, algunas o todas las aplicaciones se implementan como unikernel(s), que se pueden generar compilando directamente con una aplicación solo un conjunto limitado de bibliotecas (por ejemplo, desde un sistema operativo de biblioteca (LibOS) que incluye drivers/bibliotecas de servicios de OS) que proporcionan los servicios de OS particulares que necesita la aplicación. Como un unikernel se puede implementar para ejecutarse directamente en el hardware 940, directamente en un hipervisor (en cuyo caso el unikernel a veces se describe como ejecutándose dentro de una máquina virtual LibOS), o en un contenedor de software, las realizaciones se pueden implementar completamente con unikernel ejecutándose directamente. en un hipervisor representado por la capa 954 de virtualización, los unikernel que se ejecutan dentro de contenedores de software representados por instancias 962A-R, o como una combinación de los unikernel y las técnicas descritas anteriormente (por ejemplo, los unikernel y máquinas virtuales, ambos se ejecutan directamente en un hipervisor, los unikernel y sets de aplicaciones que se ejecutan en diferentes contenedores de software).
La instanciación de uno o más conjuntos de una o más aplicaciones 964A-R, así como la virtualización, si se implementa, se denominan colectivamente instancia o instancias 952 de software. Cada conjunto de aplicaciones 964A-R, la construcción de virtualización correspondiente (por ejemplo, instancia 962A-R) si se implementa, y la parte del hardware 940 que las ejecuta (ya sea hardware dedicado a esa ejecución y/o porciones de tiempo de hardware compartido temporalmente), forma un elemento o elementos 960A-R de red virtual separados.
El elemento o elementos 960A-R de red virtual realizan una funcionalidad similar al elemento o elementos 930A-R de red virtual, por ejemplo, similar al módulo o módulos 932A de comunicación y configuración de control y la tabla o tablas 934A de reenvío (esta virtualización del hardware 940 se denomina a veces virtualización de funciones de red (NFV). Por lo tanto, NFV puede usarse para consolidar muchos tipos de equipos de red en hardware de servidor de alto volumen de estándar de la industria, conmutadores físicos y almacenamiento físico, que podrían ubicarse en centros de datos, los ND, y equipo local del cliente (CPE). Si bien las realizaciones de la invención se ilustran con cada instancia 962A-R correspondiente a un VNE 960A-R, las realizaciones alternativas pueden implementar esta correspondencia en un nivel de granularidad más fino (por ejemplo, las máquinas virtuales de tarjeta de línea virtualizan tarjetas de línea, la máquina virtual de tarjetas de control virtualiza tarjetas de control, etc.); debe entenderse que las técnicas descritas en el presente documento con referencia a una correspondencia de las instancias 962A-R con VNE también se aplican a realizaciones en las que se usa un nivel más fino de granularidad y/o los unikernel.
En ciertas realizaciones, la capa 954 de virtualización incluye un conmutador virtual que proporciona servicios de reenvío similares a los de un conmutador de Ethernet físico. Específicamente, este conmutador virtual reenvía el tráfico entre los contenedores 962A-R de software y el o los NIC 944, así como opcionalmente entre los contenedores 962A-R de software; además, este conmutador virtual puede imponer el aislamiento de la red entre los VNE 960A-R que, por política, no pueden comunicarse entre sí (por ejemplo, respetando las redes de área local virtuales (VLa N)).
La tercera implementación de ND de ejemplo en la figura 9A es un dispositivo 906 de red híbrido, que incluye ASIC personalizados/SO patentados y procesadores COTS/SO estándar en un solo ND o una sola tarjeta dentro de un ND. En ciertas realizaciones de tal dispositivo de red híbrido, una VM de plataforma (es decir, una VM que implementa la funcionalidad del dispositivo 902 de red de propósito especial) podría proporcionar paravirtualización al hardware de red presente en el dispositivo 906 de red híbrido.
Independientemente de las implementaciones de ejemplo anteriores de un ND, cuando se está considerando uno de los múltiples VNE implementados por un ND (por ejemplo, solo uno de los VNE es parte de una red virtual dada) o cuando solo se está implementando un único VNE por un ND, el término elemento de red abreviado (NE) se usa a veces para referirse a ese VNE. También en todas las implementaciones de ejemplo anteriores, cada uno de los VNE (por ejemplo, el o los VNE 930A-R, los VNE 960A-R y los del dispositivo 906 de red híbrido) recibe datos en las NI físicas (por ejemplo, 916, 946) y reenvía esos datos a las correspondientes de las NI físicas (por ejemplo, 916, 946). Por ejemplo, un VNE que implementa la funcionalidad de enrutador IP reenvía paquetes IP basándose en parte de la información del encabezado IP en el paquete IP; donde la información del encabezado IP incluye la dirección IP de origen, la dirección IP de destino, el puerto de origen, el puerto de destino (donde "puerto de origen" y "puerto de destino" se refieren en el presente documento a puertos de protocolo, a diferencia de los puertos físicos de un ND), protocolo de transporte (por ejemplo, valores de protocolo de datagramas de usuario (UDP), protocolo de control de transmisión (TCP) y puntos de código de servicios diferenciados (DSCP).
La figura 9C ilustra varias formas de ejemplo en las que los VNE se pueden acoplar de acuerdo con algunas realizaciones de la invención. La figura 9C muestra los VNE 970A.1-970A.P (y opcionalmente los VNE 970A.Q-970A.R) implementados en ND 900A y VNE 970H.1 en ND 900H. En la figura 9C, los VNE 970A.1-P están separados entre sí en el sentido de que pueden recibir paquetes desde fuera del ND 900 A y reenviar paquetes fuera del ND 900 A; VNE 970 A.1 está acoplado con v Ne 970H.1 y, por lo tanto, comunican paquetes entre sus respectivos ND; VNE 970A.2-970A.3 puede opcionalmente reenviar paquetes entre ellos sin reenviarlos fuera del ND 900 A; y VNE 970 A. P puede ser opcionalmente el primero en una cadena de VNE que incluye VNE 970A.Q seguido de VNE 970A.R (esto a veces se denomina encadenamiento de servicio dinámico, donde cada uno de los VNE en la serie de VNE proporciona un servicio diferente, por ejemplo, uno o más servicios de red de capa 4 a 7). Si bien la figura 9C ilustra varias relaciones de ejemplo entre los VNE, las realizaciones alternativas pueden soportar otras relaciones (por ejemplo, más/menos VNE, más/menos cadenas de servicios dinámicos, múltiples cadenas de servicios dinámicos diferentes con algunos VNE comunes y algunos VNE diferentes).
Los ND de la figura 9A, por ejemplo, pueden formar parte de Internet o de una red privada; y otros dispositivos electrónicos (no mostrados; tales como dispositivos de usuario final que incluyen estaciones de trabajo, computadoras portátiles, ultraportátiles, tabletas, miniportátiles, teléfonos móviles, teléfonos inteligentes, teléfonos multimedia, teléfonos con protocolo de voz sobre Internet (VOIP), terminales, reproductores multimedia portátiles, unidades GPS, dispositivos llevables, sistemas de juego, decodificadores, electrodomésticos habilitados para Internet) se pueden acoplar a la red (directamente o a través de otras redes como redes de acceso) para comunicarse a través de la red (por ejemplo, Internet o redes privadas virtuales (VPN)) superpuestos (por ejemplo, a través de un túnel) en Internet) entre sí (directamente o a través de servidores) y/o acceder a contenido y/o servicios. Tal contenido y/o servicios son proporcionados típicamente por uno o más servidores (no mostrados) que pertenecen a un proveedor de servicios/contenido o uno o más dispositivos de usuario final (no mostrados) que participan en un servicio entre pares (P2P), y puede incluir, por ejemplo, páginas web públicas (por ejemplo, contenido gratuito, tiendas, servicios de búsqueda), páginas web privadas (por ejemplo, nombre de usuario/contraseña a las páginas web que proporcionan servicios de correo electrónico) y/o redes corporativas a través de VPN. Por ejemplo, los dispositivos de usuario final pueden estar acoplados (por ejemplo, a través de equipos local del cliente acoplados a una red de acceso (por cable o inalámbrica)) a los ND de borde, que están acoplados (por ejemplo, a través de uno o más ND de núcleo) a otros ND de borde, que están acoplados a dispositivos electrónicos que actúan como servidores. Sin embargo, a través de la virtualización informática y almacenamiento, uno o más de los dispositivos electrónicos que operan como los ND en la figura 9A también pueden alojar uno o más de tales servidores (por ejemplo, en el caso del dispositivo 904 de red de propósito general, una o más de las máquinas virtuales 962A-R pueden operar como servidores; lo mismo sería cierto para el dispositivo 906 de red híbrido; en el caso del dispositivo 902 de red de propósito especial, uno o más de dichos servidores también podrían ejecutarse en un hipervisor ejecutado por el recurso o recursos informáticos 912); en cuyo caso se dice que los servidores están coubicados con los VNE de ese ND.
Una red virtual es una abstracción lógica de una red física (como la de la figura 9A) que proporciona servicios de red (por ejemplo, servicios L2 y/o L3). Una red virtual se puede implementar como una red superpuesta (a veces denominada superposición de virtualización de red) que proporciona servicios de red (por ejemplo, servicios de capa 2 (L2, capa de enlace de datos) y/o capa 3 (L3, capa de red)) sobre una red subyacente (por ejemplo, una red L3, como una red de protocolo de Internet (IP) que usa túneles (por ejemplo, encapsulación de enrutamiento genérico (GRE), protocolo de túnel de capa 2 (L2TP), IPSec) para crear la red superpuesta).
Un borde de virtualización de red (NVE) se encuentra en el borde de la red subyacente y participa en la implementación de la virtualización de red; el lado orientado a la red del NVE usa la red subyacente para hacer túneles de tramas hacia y desde otros NVE; el lado externo del NVE envía y recibe datos hacia y desde sistemas fuera de la red. Una instancia de red virtual (VNI) es una instancia específica de una red virtual en un NVE (por ejemplo, un NE/VNE en un ND, una parte de un NE/VNE en un ND donde ese NE/VNE se divide en múltiples VNE a través de emulación); se pueden crear instancias de una o más VNI en un NVE (por ejemplo, como diferentes VNE en un ND). Un punto de acceso virtual (VAP) es un punto de conexión lógica en el NVE para conectar sistemas externos a una red virtual; un VAP puede ser puertos físicos o virtuales identificados mediante identificadores de interfaz lógica (por ejemplo, un ID de VLAN).
Los ejemplos de servicios de red incluyen: 1) un servicio de emulación de LAN de Ethernet (un servicio multipunto basado en Ethernet similar a un servicio de conmutación de etiquetas de multiprotocolo (MPLS) del grupo de trabajo de ingeniería de Internet (IETF) o VPN de Ethernet (EVPN)) en el que los sistemas externos están interconectados a través de la red mediante un entorno LAN a través de la red subyacente (por ejemplo, un NVE proporciona VNI (instancias de conmutación virtual) L2 independientes para diferentes redes virtuales, y encapsulación de túnel L3 (por ejemplo, IP/MPLS) a través de la red subyacente); y 2) un servicio de reenvío de iP virtualizado (similar a IETF IP VPN (por ejemplo, protocolo de pasarela de borde (BGP)/MPLS IP VPN) desde una perspectiva de definición de servicio) en el que los sistemas externos están interconectados a través de la red por un entorno L3 a través de la red subyacente(por ejemplo, un NVE proporciona VNI de L3 (instancias de enrutamiento y reenvío) independientes para diferentes redes virtuales, y encapsulación de túnel L3 (por ejemplo, IP/MPLS) a través de la red subyacente)). Los servicios de red también pueden incluir capacidades de calidad de servicio (por ejemplo, marcado de clasificación de tráfico, acondicionamiento y planificación del tráfico), capacidades de seguridad (por ejemplo, filtros para proteger las instalaciones del cliente de ataques originados en la red, para evitar anuncios de ruta mal formados) y capacidades de gestión (por ejemplo, detección y procesamiento completos).
La figura 9D ilustra una red con un solo elemento de red en cada uno de los ND de la figura 9A. Específicamente, la figura 9D ilustra los elementos 970A-H de red (NE) con la misma conectividad que los ND 900A-H de la figura 9A con un enfoque centralizado para mantener la accesibilidad y el reenvío de información (también llamado control de red), de acuerdo con algunas realizaciones de la invención.
La figura 9D ilustra que un enfoque centralizado 974 (también conocido como redes definidas por software (SDN)) que desacopla el sistema que toma decisiones sobre dónde se envía el tráfico desde los sistemas subyacentes que reenvía el tráfico al destino seleccionado. El enfoque centralizado 974 ilustrado tiene la responsabilidad de generar la accesibilidad y reenvío de información en un plano 976 de control centralizado (a veces denominado módulo de control SDN, controlador, controlador de red, controlador OpenFlow, controlador SDN, nodo de plano de control, autoridad de virtualización de red, o entidad de control de gestión) y, por tanto, el proceso de descubrimiento de vecinos y descubrimiento de topología está centralizado. El plano 976 de control centralizado tiene una interfaz 982 con límite sur con un plano 980 de datos (en ocasiones denominado capa de infraestructura, plano de reenvío de red o plano de reenvío (que no debe confundirse con un plano de reenvío de ND)) que incluye los NE 970A- H (a veces denominados conmutadores, elementos de reenvío, elementos de plano de datos, o nodos). El plano 976 de control centralizado incluye un controlador 978 de red, que incluye un módulo 979 de información de reenvío y accesibilidad centralizada que determina la accesibilidad dentro de la red y distribuye la información de reenvío a los NE 970A-H del plano 980 de datos a través de la interfaz 982 con límite sur (que puede usar el protocolo OpenFlow). El módulo 979 de información de reenvío y accesibilidad centralizada contiene un gestor 975 de tráfico táctil. El gestor 975 de tráfico táctil dentro del controlador 978 de red recibe una notificación desde el nodo de acceso o el nodo central de que una aplicación requiere un retraso definido para el tráfico táctil, y el gestor 975 de tráfico táctil a su vez hace que un nodo de retorno instale una entrada de tabla de flujo en una tabla de flujo del nodo de retorno, a través de la cual los paquetes de la aplicación se reenviarán dentro de una latencia definida para el tráfico táctil. La notificación y la instalación se explican con más detalle en relación con las figuras 1 y 5.
La inteligencia de red está centralizada en el plano 976 de control centralizado que se ejecuta en dispositivos electrónicos que típicamente están separados de los ND. Por ejemplo, cuando el dispositivo 902 de red de propósito especial se usa en el plano 980 de datos, cada uno del módulo o módulos 932A-R de comunicación y configuración de control del plano 924 de control de ND típicamente incluye un agente de control que proporciona el lado VNE de la interfaz con límite sur 982. En este caso, el plano 924 de control de ND (el recurso o recursos informáticos 912 que ejecutan el módulo o módulos 932A-R de comunicación y configuración de control) realiza su responsabilidad de participar en el control de cómo los datos (por ejemplo, paquetes) deben enrutarse ( por ejemplo, el siguiente salto para los datos y la NI física saliente para esos datos) a través del agente de control que se comunica con el plano 976 de control centralizado para recibir la información de reenvío (y en algunos casos, la información de accesibilidad) del módulo 979 de información de reenvío y accesibilidad centralizada (debe entenderse que en algunas realizaciones de la invención, el módulo o módulos 932A-R de comunicación y configuración de control, además de comunicarse con el plano 976 de control centralizado, también pueden desempeñar algún papel en la determinación de la accesibilidad y/o calcular la información de reenvío, aunque menos que en el caso de un enfoque distribuido; generalmente se considera que tales realizaciones caen bajo el enfoque centralizado 974, pero también puede considerarse un enfoque híbrido).
Si bien el ejemplo anterior usa el dispositivo 902 de red de propósito especial, el mismo enfoque centralizado 974 se puede implementar con el dispositivo 904 de red de propósito general (por ejemplo, cada uno de los VNE 960A-R realiza su responsabilidad de controlar cómo se procesan los datos (por ejemplo, los paquetes) para ser enrutado (por ejemplo, el próximo salto para los datos y la Ni física saliente para esos datos) comunicándose con el plano 976 de control centralizado para recibir la información de reenvío (y en algunos casos, la información de accesibilidad) desde el módulo 979 de información de reenvío y accesibilidad centralizada; debe entenderse que en algunas realizaciones de la invención, los VNE 960A-R, además de comunicarse con el plano 976 de control centralizado, también pueden desempeñar algún papel en la determinación de la accesibilidad y/o el cálculo de la información de reenvío, aunque menos así que en el caso de un enfoque distribuido) y el dispositivo 906 de red híbrido. De hecho, el uso de técnicas SDN puede mejorar las técnicas NFV que se usan típicamente en las implementaciones del dispositivo 904 de red de propósito general o del dispositivo 906 de red híbrido, ya que NFV es capaz de soportar SDN proporcionando una infraestructura sobre la cual se puede ejecutar el software SDN, y NFV y SDN tienen como objetivo hacer uso de conmutadores físicos y hardware de servidor básico.
La figura 9D también muestra que el plano 976 de control centralizado tiene una interfaz 984 con límite norte a una capa 986 de aplicación, en la que reside la aplicación o aplicaciones 988. El plano 976 de control centralizado tiene la capacidad de formar redes virtuales 992 (a veces denominadas plano de reenvío lógico, servicios de red o redes superpuestas (siendo los NE 970A-H del plano 980 de datos la red subyacente)) para la aplicación o aplicaciones 988. Por lo tanto, el plano 976 de control centralizado mantiene una vista global de todos los ND y los NE/VNE configurados, y mapea las redes virtuales a los ND subyacentes de manera eficiente (incluido el mantenimiento de estos mapeos a medida que la red física cambia a través del fallo, adición o eliminación de hardware (ND, enlace, o componente ND)).
Mientras que la figura 9D ilustra el caso simple en el que cada uno de los ND 900A-H implementa un solo NE 970A-H, debe entenderse que los enfoques de control de red descritos con referencia a la figura 9D también funcionan para redes donde uno o más de los ND 900A-H implementan múltiples VNE (por ejemplo, los VNE 930A-R, los VNE 960A -R, los del dispositivo 906 de red híbrido). Alternativamente o además, el controlador 978 de red también puede emular la implementación de múltiples VNE en un solo ND. Específicamente, en lugar de (o además de) implementar múltiples VNE en un solo ND, el controlador 978 de red puede presentar la implementación de un VNE/NE en un solo ND como múltiples VNE en las redes virtuales 992 (todas en la misma red o redes virtuales 992, cada una en diferente red o redes virtuales 992, o alguna combinación). Por ejemplo, el controlador 978 de red puede hacer que un ND implemente un solo VNE (un NE) en la red subyacente, y luego dividir lógicamente los recursos de ese NE dentro del plano 976 de control centralizado para presentar diferentes VNE en la red o redes virtuales 992 (donde estos diferentes VNE en las redes superpuestas comparten los recursos de la implementación única VNE/NE en el ND en la red subyacente).
Por otro lado, las figuras 9E y 9F ilustran respectivamente abstracciones de ejemplo de NE y VNE que el controlador 978 de red puede presentar como parte de diferentes redes virtuales 992. La figura 9E ilustra el caso simple en el que cada uno de los ND 900A-H implementa un solo NE 970A-H (véase la figura 9D), pero el plano 976 de control centralizado ha abstraído múltiples NE en diferentes ND (los NE 970A-C y G-H) en (para representar) un único NE 9701 en una de las redes virtuales 992 de la figura 9D, de acuerdo con algunas realizaciones de la invención. La figura 9E muestra que en esta red virtual, el NE 9701 está acoplado al NE 970D y 970F, que todavía están acoplados al NE 970E.
La figura 9F ilustra un caso en el que varios VNE (VNE 970A.1 y VNE 970H.1) se implementan en diferentes ND (ND 900A y ND 900H) y están acoplados entre sí, y donde el plano 976 de control centralizado ha abstraído estos múltiples VNE de manera que aparecen como un solo VNE 970T dentro de una de las redes virtuales 992 de la figura 9D, de acuerdo con algunas realizaciones de la invención. Por tanto, la abstracción de un NE o VNE puede abarcar varios ND.
Si bien algunas realizaciones de la invención implementan el plano 976 de control centralizado como una entidad única (por ejemplo, una única instancia de software que se ejecuta en un solo dispositivo electrónico), las realizaciones alternativas pueden extender la funcionalidad a través de múltiples entidades con fines de redundancia y/o escalabilidad (por ejemplo, múltiples instancias de software que se ejecutan en diferentes dispositivos electrónicos).
De manera similar a las implementaciones de dispositivos de red, el dispositivo o dispositivos electrónicos que ejecutan el plano 976 de control centralizado y, por lo tanto, el controlador 978 de red que incluye el módulo 979 de información de reenvío y accesibilidad centralizada, se pueden implementar de diversas formas (por ejemplo, un dispositivo de propósito especial, un dispositivo de uso general (por ejemplo, COTS) o dispositivo híbrido). Este dispositivo o dispositivos electrónicos incluirían de manera similar un recurso o recursos informáticos, un conjunto o una o más NIC físicas, y un medio de almacenamiento legible por máquina no transitorio que tiene almacenado en el mismo el software de plano de control centralizado. Por ejemplo, la figura 10 ilustra un dispositivo 1004 de plano de control de propósito general que incluye hardware 1040 que comprende un conjunto de uno o más procesadores 1042 (que a menudo son procesadores COTS) y controlador o controladores 1044 de interfaz de red (NIC; también conocidos como tarjetas de interfaz de red) (que incluyen las NI físicas 1046), así como medios 1048 de almacenamiento no transitorios legibles por máquina que tienen almacenado en ellos el software 1050 de plano de control centralizado (CCP). El software 1050 de CCP incluye el gestor 975 de tráfico táctil explicado anteriormente en el presente documento.
En las realizaciones que usan la virtualización informática, el procesador o los procesadores 1042 típicamente ejecutan software para instanciar una capa 1054 de virtualización y un contenedor o contenedores 1062A-R de software (por ejemplo, con virtualización a nivel de sistema operativo, la capa 1054 de virtualización representa el kernel de un sistema operativo (o una corrección que se ejecuta en un sistema operativo base) que permite la creación de múltiples contenedores 1062A-R de software (que representan instancias de espacio de usuario separadas y también llamados motores de virtualización, servidores privados virtuales o cárceles) que pueden usarse para ejecutar un conjunto de una o más aplicaciones; con virtualización completa, la capa 1054 de virtualización representa un hipervisor (a veces denominado monitor de máquina virtual (VMM)) o un hipervisor que se ejecuta sobre un sistema operativo anfitrión, y los contenedores 1062A-R de software cada uno representa una forma muy aislada de contenedor de software llamado máquina virtual que es ejecutada por el hipervisor y puede incluir un sistema operativo invitado; con la paravirtualización, un sistema operativo o una aplicación que se ejecuta con una máquina virtual puede ser consciente de la presencia de virtualización con fines de optimización). De nuevo, en las realizaciones en las que se usa la virtualización informática, durante el funcionamiento se ejecuta una instancia del software CCP 1050 (ilustrada como instancia CCP 1076 A) dentro del contenedor 1062A de software en la capa 1054 de virtualización. En realizaciones en las que no se usa virtualización informática, la instancia 1076A de CCP en la parte superior de un sistema operativo anfitrión se ejecuta en el dispositivo 1004 de plano de control de propósito general "desnudo". La instanciación de la instancia 1076A de CCP, así como la capa 1054 de virtualización y los contenedores 1062A-R de software, si se implementan, se denominan colectivamente instancia o instancias 1052 de software.
En algunas realizaciones, la instancia 1076A de CCP incluye una instancia 1078 de controlador de red. La instancia 1078 de controlador de red incluye una instancia de módulo 1979 de información de reenvío y accesibilidad centralizada (que es una capa de middleware que proporciona el contexto del controlador 978 de red al sistema operativo y se comunica con los diversos NE), y una capa 1080 de aplicación de CCP (a veces denominada como capa de aplicación) sobre la capa de middleware (proporcionando la inteligencia necesaria para diversas operaciones de red, como protocolos, conciencia de la situación de la red e interfaces de usuario). Una instancia 1075 de gestor de tráfico táctil se incluye en la capa 1080 de aplicación de CCP en una realización. En un nivel más abstracto, esta capa 1080 de aplicación de CCP dentro del plano 976 de control centralizado funciona con vista o vistas de red virtual (vista o vistas lógicas de la red) y la capa de middleware proporciona la conversión de las redes virtuales a la vista física.
El plano 976 de control centralizado transmite mensajes relevantes al plano 980 de datos basándose en los cálculos de la capa 1080 de aplicación de CCP y el mapeo de la capa de middleware para cada flujo. Un flujo puede definirse como un conjunto de paquetes cuyos encabezados coinciden con un patrón de bits dado; en este sentido, el reenvío tradicional de IP también es un reenvío basado en flujo donde los flujos están definidos por la dirección IP de destino, por ejemplo; sin embargo, en otras implementaciones, el patrón dado de bits usado para una definición de flujo puede incluir más campos (por ejemplo, 10 o más) en los encabezados del paquete. Diferentes ND/NE/VNE del plano 980 de datos pueden recibir diferentes mensajes y, por tanto, diferente información de reenvío. El plano 980 de datos procesa estos mensajes y programa la información de flujo apropiada y las acciones correspondientes en las tablas de reenvío (a veces denominadas tablas de flujo) de los Ne /VNE apropiados, y luego los NE/VNE mapean los paquetes entrantes a los flujos representados en las tablas de reenvío y paquetes de reenvío basándose en los emparejamientos en las tablas de reenvío.
Estándares como OpenFlow definen los protocolos usados para los mensajes, así como un modelo para procesar los paquetes. El modelo para procesar paquetes incluye el análisis de encabezado, la clasificación de paquetes y la toma de decisiones de reenvío. El análisis de encabezados describe cómo interpretar un paquete basándose en un conjunto de protocolos bien conocido. Algunos campos de protocolo se usan para construir una estructura de emparejamiento (o clave) que se usará en la clasificación de paquetes (por ejemplo, un primer campo clave podría ser una dirección de control de acceso al medio (MAC) de origen, y un segundo campo clave podría ser una dirección MAC de destino).
La clasificación de paquetes implica ejecutar una búsqueda en la memoria para clasificar el paquete determinando qué entrada (también conocida como entrada de tabla de reenvío o entrada de flujo) en las tablas de reenvío coincide mejor con el paquete basándose en la estructura de emparejamiento, o clave, de las entradas de tabla de reenvío. Es posible que muchos flujos representados en las entradas de tabla de reenvío puedan corresponder/coincidir con un paquete; en este caso, el sistema se configura típicamente para determinar una entrada de tabla de reenvío de las muchas de acuerdo con un esquema definido (por ejemplo, seleccionando una primera entrada de tabla de reenvío que coincida). Las entradas de tabla de reenvío incluyen un conjunto específico de criterios de emparejamiento (un conjunto de valores o comodines, o una indicación de qué porciones de un paquete deben compararse con un valor/valores/comodines en particular, según lo definido por las capacidades de emparejamiento, para campos específicos en el encabezado de paquete, o para algún otro contenido de paquete), y un conjunto de una o más acciones para que el plano de datos realice al recibir un paquete coincidente. Por ejemplo, una acción puede ser insertar un encabezado en el paquete, para el paquete que usa un puerto en particular, inundar el paquete o simplemente descartar el paquete. Por lo tanto, una entrada de tabla de reenvío para paquetes IPv4/IPv6 con un puerto de destino de protocolo de control de transmisión (TCP) particular podría contener una acción que especifique que estos paquetes deben descartarse.
Se toman decisiones de reenvío y se llevan a cabo acciones, basándose en la entrada de tabla de reenvío identificada durante la clasificación de paquetes, ejecutando el conjunto de acciones identificadas en la entrada de tabla de reenvío coincidente en el paquete.
Sin embargo, cuando un paquete desconocido (por ejemplo, un "paquete perdido" o una "pérdida de emparejamiento" como se usa en el lenguaje OpenFlow) llega al plano 980 de datos, el paquete (o un subconjunto del encabezado y contenido del paquete) es típicamente enviado al plano 976 de control centralizado. El plano 976 de control centralizado programará entonces entradas de tabla de reenvío al plano 980 de datos para acomodar los paquetes que pertenecen al flujo del paquete desconocido. Una vez que se ha programado una entrada de tabla de reenvío específica en el plano 980 de datos por el plano 976 de control centralizado, el siguiente paquete con credenciales coincidentes coincidirá con esa entrada de tabla de reenvío y tomará el conjunto de acciones asociadas con esa entrada coincidente.
Una interfaz de red (NI) puede ser física o virtual; y en el contexto de IP, una dirección de interfaz es una dirección IP asignada a una NI, ya sea una NI física o virtual. Una NI virtual puede estar asociado con una NI física, con otra interfaz virtual, o ser independiente (por ejemplo, una interfaz de bucle invertido, una interfaz de protocolo de punto a punto). Una NI (física o virtual) puede estar numerada (una NI con una dirección IP) o no numerada (una NI sin una dirección IP). Una interfaz de bucle invertido (y su dirección de bucle invertido) es un tipo específico de NI virtual (y dirección IP) de un NE/VNE (físico o virtual) que se usa a menudo con fines de gestión; donde dicha dirección IP se denomina dirección de bucle invertido nodal. Las direcciones IP asignadas a las NI de un ND se denominan direcciones IP de ese ND; a un nivel más granular, las direcciones IP asignadas a las NI asignadas a un NE/VNE implementado en un ND pueden denominarse direcciones IP de ese NE/VNE.
Cada VNE (por ejemplo, un enrutador virtual, un puente virtual (que puede actuar como una instancia de conmutador virtual en un servicio de LAN privada virtual (VPLS)) se puede administrar típicamente de forma independiente. Por ejemplo, en el caso de múltiples enrutadores virtuales, cada uno de los enrutadores virtuales puede compartir recursos del sistema pero está separado de los otros enrutadores virtuales con respecto a su dominio de gestión, espacio de nombres AAA (autenticación, autorización y contabilización), dirección IP y base o bases de datos de enrutamiento. Pueden emplearse múltiples VNE en un ND de borde para proporcionar acceso directo a la red y/o diferentes clases de servicios para abonados de servicios y/o proveedores de contenido.
Dentro de ciertos ND, las "interfaces" que son independientes de las NI físicas pueden configurarse como parte de los VNE para proporcionar información de servicio y protocolo de capa superior (por ejemplo, direccionamiento de capa 3). Los registros de abonado en el servidor AAA identifican, además de los otros requisitos de configuración de abonado, a qué contexto (por ejemplo, cuál de los VNE/NE) los abonados correspondientes deben estar vinculados dentro del ND. Como se usa en el presente documento, un enlace forma una asociación entre una entidad física (por ejemplo, NI física, canal) o una entidad lógica (por ejemplo, un circuito como un circuito de abonado o circuito lógico (un conjunto de uno o más circuitos de abonado)) y una interfaz del contexto sobre la cual se configuran los protocolos de red (por ejemplo, protocolos de enrutamiento, protocolos de puente) para ese contexto. Los datos del abonado fluyen en la entidad física cuando alguna interfaz de protocolo de capa superior está configurada y asociada con esa entidad física.
Algunos ND incluyen funcionalidad para protocolos de autenticación, autorización y contabilización (AAA) (por ejemplo, RADIUS (servicio de usuario de acceso telefónico de autenticación remota), Diameter y/o TACACS (sistema de control de acceso plus de controlador de acceso de terminal). AAA se puede proporcionar a través de un modelo de cliente/servidor, donde el cliente AAA se implementa en un ND y el servidor AAA se puede implementar localmente en el ND o en un dispositivo electrónico remoto acoplado con el ND. La autenticación es el proceso de identificación y verificación de un abonado. Por ejemplo, un abonado puede identificarse mediante una combinación de un nombre de usuario y una contraseña o mediante una clave única. La autorización determina qué puede hacer un abonado después de ser autenticado, como obtener acceso a ciertos recursos de información de dispositivos electrónicos (por ejemplo, mediante el uso de políticas de control de acceso). La contabilización consiste en registrar la actividad del usuario. A modo de ejemplo resumido, los dispositivos de usuario final se pueden acoplar (por ejemplo, a través de una red de acceso) a través de un ND de borde (que soporta procesamiento AAA) acoplado a ND centrales acoplados a dispositivos electrónicos que implementan servidores de proveedores de servicios/contenido. El procesamiento AAA se realiza para identificar para un abonado el registro de abonado almacenado en el servidor AAA para ese abonado. Un registro de abonado incluye un conjunto de atributos (por ejemplo, nombre de abonado, contraseña, información de autenticación, información de control de acceso, información de limitación de velocidad, información de vigilancia) usados durante el procesamiento del tráfico de ese abonado.
Las operaciones de los diagramas de flujo de las figuras 7-8 se describen con referencia a la realización de ejemplo de las figuras 9A-F y 10. Sin embargo, debe entenderse que las operaciones de los diagramas de flujo se pueden realizar mediante realizaciones de la invención distintas de las explicadas con referencia a la realización de ejemplo de las figuras 9A-F y 10, y la realización de ejemplo de las figuras 9A-F y 10 puede realizar operaciones diferentes a las explicadas con referencia a los diagramas de flujo de las figuras 7-8.
Si bien los diagramas de flujo de las figuras anteriormente en el presente documento muestran un orden particular de operaciones realizadas por determinadas realizaciones de la invención, debe entenderse que tal orden es de ejemplo (por ejemplo, realizaciones alternativas pueden realizar las operaciones en un orden diferente, combinar ciertas operaciones, superponer ciertas operaciones, etc.).
Se pueden implementar diferentes realizaciones de la invención usando diferentes combinaciones de software, firmware y/o hardware. Por tanto, las técnicas mostradas en las figuras pueden implementarse usando código y datos almacenados y ejecutados en uno o más dispositivos electrónicos (por ejemplo, un sistema final, un dispositivo de red). Tales dispositivos electrónicos almacenan y comunican (internamente y/o con otros dispositivos electrónicos a través de una red) códigos y datos usando medios legibles por computadora, como medios de almacenamiento no transitorios legibles por computadora (por ejemplo, discos magnéticos; discos ópticos; memoria de acceso aleatorio ; memoria de solo lectura; dispositivos de memoria flash; memoria de cambio de fase) y medios de transmisión transitorios legibles por computadora (por ejemplo, señales eléctricas, ópticas, acústicas u otras formas de propagación, como ondas portadoras, señales infrarrojas, señales digitales). Además, tales dispositivos electrónicos típicamente incluyen un conjunto de uno o más procesadores acoplados a uno o más componentes, como uno o más dispositivos de almacenamiento (medios de almacenamiento no transitorios legibles por máquina), dispositivos de entrada/salida del usuario (por ejemplo, un teclado, pantalla táctil y/o pantalla) y conexiones de red. El acoplamiento del conjunto de procesadores y otros componentes se realiza típicamente a través de uno o más buses y puentes (también denominados controladores de bus). Por tanto, el dispositivo de almacenamiento de un dispositivo electrónico dado típicamente almacena código y/o datos para su ejecución en el conjunto de uno o más procesadores de ese dispositivo electrónico.
Si bien la invención se ha descrito en términos de varias realizaciones, los expertos en la técnica reconocerán que la invención no se limita a las realizaciones descritas, sino que puede practicarse con modificaciones y alteraciones dentro del alcance de las reivindicaciones adjuntas. Por tanto, la descripción debe considerarse ilustrativa en lugar de limitativa.

Claims (9)

REIVINDICACIONES
1. - Un método para una red (100) de comunicación, en el que la red de comunicación incluye un nodo (104) de acceso que se comunica con los dispositivos (102) de usuario final, un nodo (106) de retorno y un nodo central (108), en el que el nodo de retorno transmite tráfico entre el nodo de acceso y el nodo central, y en el que un dispositivo electrónico comprende el nodo de acceso o el nodo central, el método comprendiendo:
notificar (702), por el dispositivo electrónico, a un controlador (150) que una aplicación ha sido autorizada para transmitir tráfico táctil en la red de comunicación, el controlador comunicándose con uno o más del nodo de acceso, el nodo de retorno y el nodo central, y la aplicación siendo desplegada en un dispositivo de usuario final, en el que el controlador, en respuesta a la notificación, hace que el nodo de retorno instale una entrada de tabla de flujo en una tabla de flujo del nodo de retorno, a través del cual los paquetes de la aplicación se reenviarán dentro de una latencia definida para el tráfico táctil por el nodo de retorno, en el que la entrada de tabla de flujo incluye uno o más bits de calidad de servicio en uno o más de sus campos coincidentes para coincidir al menos una indicación en los paquetes de tráfico táctil recibidos desde el dispositivo electrónico, en el que dicho o más campos coincidentes incluyen solo el ID de abonado o el ID de sesión, y en el que el emparejamiento de uno es suficiente para identificar el tráfico táctil y en el que la latencia de la aplicación en la red de comunicación está dentro de un milisegundo;
autenticar (704), por el dispositivo electrónico, un paquete que se origina o está destinado a la aplicación que ha sido autorizada para transmitir el tráfico táctil en la red de comunicación;
y reenviar (706), por el dispositivo electrónico, al nodo de retorno, el paquete con la latencia definida para el tráfico táctil usando una prioridad para el tráfico táctil.
2. - El método de la reivindicación 1, en el que la aplicación obtiene una autorización para transmitir el tráfico táctil, y en el que se establece una indicación del paquete para indicar la autorización para la aplicación.
3. - El método de la reivindicación 2, en el que la indicación del paquete incluye uno o más de un identificador de abonado, un identificador de sesión; y uno o más bits de calidad de servicio.
4. - El método de la reivindicación 1, en el que la autenticación del paquete comprende:
identificar (804) que el paquete incluye una indicación para transmitir el tráfico táctil; y
verificar (806) que la aplicación ha sido autorizada para transmitir el tráfico táctil.
5. - El método de la reivindicación 1, en el que la red de comunicación es una red móvil de quinta generación.
6. - Una red (100) de comunicación configurada para incluir un nodo (104) de acceso que se comunica con los dispositivos (102) de usuario final, un nodo (106) de retorno y un nodo central (108), en el que el nodo de retorno está configurado para transmitir tráfico entre el nodo de acceso y el nodo central, en el que el dispositivo electrónico está configurado para servir como el nodo de acceso o el nodo central; la red de comunicación está además configurada para comprender una pluralidad de procesadores; por lo que un procesador está comprendido en cada uno de los nodos y un procesador está comprendido en el controlador, y el medio de almacenamiento legible por máquina no transitorio respectivo estando acoplado a cada uno de los procesadores respectivos, el medio de almacenamiento legible por máquina no transitorio respectivo conteniendo instrucciones, que cuando son ejecutadas por el respectivo procesador, hacen que el dispositivo electrónico:
notifique (150) a un controlador que una aplicación ha sido autorizada para transmitir tráfico táctil en la red de comunicación, el controlador se comunica con uno o más del nodo de acceso, el nodo de retorno y el nodo central, y la aplicación siendo desplegada en un dispositivo de usuario final,
autentique un paquete que se origina o está destinado a la aplicación que ha sido autorizada para transmitir el tráfico táctil en la red de comunicación, y
reenvíe el paquete al nodo de retorno con la latencia definida para el tráfico táctil usando una prioridad para el tráfico táctil;
haga que el controlador, en respuesta a la notificación, haga que el nodo de retorno instale una entrada de tabla de flujo en una tabla de flujo del nodo de retorno, a través del cual los paquetes de la aplicación han de ser reenviados por el nodo de retorno dentro de una latencia definida para el tráfico táctil, en el que la entrada de tabla de flujo incluye uno o más bits de calidad de servicio en uno o más de sus campos coincidentes para coincidir al menos una indicación en los paquetes del tráfico táctil recibidos desde el dispositivo electrónico, en el que dicho o más campos coincidentes incluyen solo el ID de abonado o el ID de sesión, y en el que dicho o más campos coincidentes incluyen solo el ID de abonado o el ID de sesión, y en el que el emparejamiento de uno es suficiente para identificar el tráfico táctil y en el que la latencia de la aplicación en la red de comunicación está dentro de un milisegundo.
7. - La red de comunicación de la reivindicación 6, en el que el dispositivo electrónico debe además identificar que el paquete incluye una indicación para transmitir el tráfico táctil, y verificar que la aplicación haya sido autorizada para transmitir el tráfico táctil.
8. - La red de comunicación de la reivindicación 6, en el que la red de comunicación es una red móvil de quinta generación.
9. - Medios legibles por máquina no transitorios que tiene instrucciones almacenadas en el mismo, que cuando son ejecutadas por una pluralidad de procesadores, hacen que los procesadores realicen un método como se mencionó en cualquiera de las reivindicaciones 1 a 5.
ES16715898T 2016-04-04 2016-04-04 Soporte de calidad de servicio (QoS) para tráfico táctil Active ES2857723T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IB2016/051907 WO2017175027A1 (en) 2016-04-04 2016-04-04 Quality of service (qos) support for tactile traffic

Publications (1)

Publication Number Publication Date
ES2857723T3 true ES2857723T3 (es) 2021-09-29

Family

ID=55745789

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16715898T Active ES2857723T3 (es) 2016-04-04 2016-04-04 Soporte de calidad de servicio (QoS) para tráfico táctil

Country Status (5)

Country Link
US (1) US10805826B2 (es)
EP (1) EP3440810B1 (es)
DK (1) DK3440810T3 (es)
ES (1) ES2857723T3 (es)
WO (1) WO2017175027A1 (es)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113472673A (zh) * 2016-08-27 2021-10-01 华为技术有限公司 一种获取控制信息的方法和设备
DE102019210225A1 (de) * 2019-07-10 2021-01-14 Robert Bosch Gmbh Verfahren und Vorrichtung zur Analyse dienste-orientierter Kommunikation
CN112448885B (zh) * 2019-08-27 2023-06-06 华为技术有限公司 一种业务报文传输的方法及设备
US11916796B2 (en) * 2021-12-23 2024-02-27 Versa Networks, Inc. End-to-end data packets flow control through an overlay environment of a wide area network

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8214536B2 (en) 2003-09-16 2012-07-03 Research In Motion Limited Methods and apparatus for selecting a wireless network based on quality of service (QoS) criteria associated with an application
ES2391993T3 (es) 2008-01-17 2012-12-03 Nokia Siemens Networks Oy Asignación de un identificador de flujo de servicio a un anfitrión detrás de una pasarela MS
US8346225B2 (en) * 2009-01-28 2013-01-01 Headwater Partners I, Llc Quality of service for device assisted services
US9392462B2 (en) * 2009-01-28 2016-07-12 Headwater Partners I Llc Mobile end-user device with agent limiting wireless data communication for specified background applications based on a stored policy
US8797867B1 (en) 2010-10-18 2014-08-05 Juniper Networks, Inc. Generating and enforcing a holistic quality of service policy in a network
JP5825351B2 (ja) 2010-12-16 2015-12-02 日本電気株式会社 通信システム、制御装置、通信方法及びプログラム
FR3031425A1 (fr) * 2015-01-05 2016-07-08 Orange Dispositif et procede de controle d'un coeur de reseau ip

Also Published As

Publication number Publication date
EP3440810A1 (en) 2019-02-13
EP3440810B1 (en) 2020-12-30
US20200205025A1 (en) 2020-06-25
DK3440810T3 (da) 2021-01-18
US10805826B2 (en) 2020-10-13
WO2017175027A1 (en) 2017-10-12

Similar Documents

Publication Publication Date Title
US11777783B2 (en) Network slicing with smart contracts
ES2905499T3 (es) Nodos SDN híbridos divididos horizontalmente configurados por Openflow
US10819833B2 (en) Dynamic re-route in a redundant system of a packet network
US10581726B2 (en) Method and apparatus for supporting bidirectional forwarding (BFD) over multi-chassis link aggregation group (MC-LAG) in internet protocol (IP) multiprotocol label switching (MPLS) networks
US10257162B2 (en) Method and system for providing “anywhere access” for fixed broadband subscribers
US10291555B2 (en) Service based intelligent packet-in buffering mechanism for openflow switches by having variable buffer timeouts
EP3692685B1 (en) Remotely controlling network slices in a network
US9167501B2 (en) Implementing a 3G packet core in a cloud computer with openflow data and control planes
EP3304812B1 (en) Method and system for resynchronization of forwarding states in a network forwarding device
US20150350912A1 (en) Residential service delivery based on unique residential apn
US10904802B2 (en) Service delivery to handed over user equipment (UE) using a software-defined networking (SDN) controller
US20220007251A1 (en) Using location indentifier separation protocol to implement a distributed user plane function architecture for 5g mobility
US20170070416A1 (en) Method and apparatus for modifying forwarding states in a network device of a software defined network
EP3140964B1 (en) Implementing a 3g packet core in a cloud computer with openflow data and control planes
US10841207B2 (en) Method and apparatus for supporting bidirectional forwarding (BFD) over multi-chassis link aggregation group (MC-LAG) in internet protocol (IP) networks
US9774504B2 (en) Route refresh mechanism for border gateway protocol link state
WO2021009553A1 (en) Method and system for in-band signaling in a quic session
WO2021134434A1 (en) Method and system for ethernet virtual private network (evpn) split-horizon filtering
ES2857723T3 (es) Soporte de calidad de servicio (QoS) para tráfico táctil
US20220141761A1 (en) Dynamic access network selection based on application orchestration information in an edge cloud system
US11669256B2 (en) Storage resource controller in a 5G network system
US11784797B2 (en) Serving-network based perfect forward security for authentication