ES2758445T3 - Protocolo de control de trasmisión en una red de acceso de radio de evolución a largo plazo - Google Patents

Protocolo de control de trasmisión en una red de acceso de radio de evolución a largo plazo Download PDF

Info

Publication number
ES2758445T3
ES2758445T3 ES14722056T ES14722056T ES2758445T3 ES 2758445 T3 ES2758445 T3 ES 2758445T3 ES 14722056 T ES14722056 T ES 14722056T ES 14722056 T ES14722056 T ES 14722056T ES 2758445 T3 ES2758445 T3 ES 2758445T3
Authority
ES
Spain
Prior art keywords
enodeb
user device
processor
data
server
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
ES14722056T
Other languages
English (en)
Inventor
Kuntal Chowdhury
Ashraf M Dahod
Anupam Kumar Goel
Si Nguyen
Manish Mittal
Pramod Kumar Singh
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.)
Altiostar Networks Inc
Original Assignee
Altiostar Networks Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Altiostar Networks Inc filed Critical Altiostar Networks Inc
Application granted granted Critical
Publication of ES2758445T3 publication Critical patent/ES2758445T3/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
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1812—Hybrid protocols; Hybrid automatic repeat request [HARQ]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1854—Scheduling and prioritising arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/188—Time-out mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/1887—Scheduling and prioritising arrangements
    • 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/19—Flow control; Congestion control at layers above the network layer
    • H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • 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/40—Flow control; Congestion control using split connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • 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/0273—Traffic management, e.g. flow control or congestion control adapting protocols for flow control or congestion control to wireless environment, e.g. adapting transmission control protocol [TCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/06—Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless

Abstract

Un dispositivo (106, 300, 404, 504, 1004, 1204, 1306) para la transmisión de paquetes de datos entre un dispositivo de usuario (402, 502, 1002, 1202, 1304) y un servidor, comprendiendo el dispositivo: un nodo evolucionado, eNodeB una estación base (106, 300, 404, 504, 1004, 1204, 1306), comprendiendo la estación base de eNodeB: al menos una memoria (510, 1214, 1364, 1420); en donde la memoria es un búfer; y al menos un procesador (408, 508, 1208, 1360, 1362, 1410) conectado operativamente con la memoria, estando el al menos un procesador configurado para: establecer un enlace de comunicación entre el dispositivo de usuario y el servidor de acuerdo con el protocolo de control de trasmisión, TCP, para la transmisión de al menos un paquete de datos entre el dispositivo de usuario el servidor; y transmitir el al menos un paquete de datos, recibido desde el servidor, al dispositivo de usuario, utilizando el protocolo de control de transmisión, siendo el al menos un paquete de datos almacenado en la al menos una memoria; determinar el tamaño total de los paquetes de datos que pueden ser recibidos, R-WND, por la estación base; y proporcionar al servidor una indicación del tamaño total determinado; en donde el tamaño total de los paquetes de datos es determinado en base a al menos uno de lo siguiente: una intensidad de señal de radio existente entre el dispositivo de usuario y la estación de base de eNodeB, una calidad de la señal de radio existente entre el dispositivo de usuario y la estación de base de eNodeB, una velocidad de bit estimada de la transferencia de datos entre el dispositivo de usuario y el eNodeB en base a al menos un informe de estado de búfer procedente de al menos uno de lo siguiente: una capa de control de acceso al medio, MAC, de eNodeB, una capa de protocolo de convergencia de datos de paquete, PDCP, de eNodeB, y una capa de control de enlace de radio, RLC, de eNodeB.

Description

DESCRIPCIÓN
Protocolo de control de trasmisión en una red de acceso de radio de evolución a largo plazo
Campo técnico
La materia objeto descrita la presente memoria se refiere generalmente al procesamiento de datos y, en particular, a un protocolo de control de trasmisión en una red de acceso de radio de evolución a largo plazo.
Antecedentes
En la actualidad, las redes de celdas proporcionan capacidades de comunicación a demanda a los individuos y a las entidades de negocios. Típicamente, una red de celdas es una vez inalámbrica que puede estar distribuida sobre áreas de terreno, que se denominan celdas. Cada una de dichas celdas está servida por al menos un transmisorreceptor de localización fija, que se denomina un sitio de celda o una estación base. Cada celda puede utilizar un conjunto de frecuencias diferentes de las celdas vecinas para evitar la interferencia y proporcionar una anchura de banda garantizada dentro de cada celda. Cuando las celdas se unen juntas, proporcionan cobertura de radio en un área geográfica amplia, lo que hace posible que un gran número de teléfonos móviles, y/o otros dispositivos inalámbricos o transmisores-receptores portátiles se comuniquen entre sí y con transmisores-receptores y teléfonos fijos en cualquier lugar dentro de la red. Tales comunicaciones son realizadas a través de estaciones base y son realizadas incluso cuando los transmisores-receptores móviles se están moviendo a través de más de una celda durante la transmisión. Los principales proveedores de comunicaciones inalámbricas han desarrollado tales sitios de celdas en todo el mundo, permitiendo con ello que los teléfonos móviles de comunicaciones y los dispositivos de ordenador móviles sean conectados a una red de teléfono conmutada pública y a la red Internet pública.
Un teléfono móvil es un teléfono portátil y que es capaz de recibir y/o realizar llamadas de teléfono y/o de datos a través de un sitio de celda o de una torre de transmisión utilizando ondas de radio para transfer y señales a y desde el teléfono móvil. En vista de un gran número de usuarios de teléfonos móvil, las redes de teléfono móvil actuales proporcionan un recurso limitado y compartido. En este sentido, los sitios de celda de los dispositivos móviles pueden cambiar la frecuencia y utilizar trasmisores de baja potencia para permitir el uso simultáneo de las redes por muchos usuarios con menos interferencia. La cobertura por un sitio de celda puede depender de una localización geográfica particular y/o del número de usuarios que pueden utilizar potencialmente la red. Por ejemplo, en una ciudad un sitio de celdas puede tener un rango de hasta aproximadamente 0,8 km (1/2 milla); en áreas rurales, el rango puede ser de como mucho 8 Km (5 millas); y en algunas áreas, un usuario puede recibir señales procedentes de un sitio de celda alejado 40 km (25 millas).
Lo que sigue son ejemplos de tecnologías celulares digitales que son utilizadas por proveedores de comunicaciones: Sistema Global para Comunicaciones Móviles ("GSM"), Servicio General de Paquetes vía Radio ("GPRS"),cdmaOne, CDMA2000, Datos de Evolución Optimizada ("EV-DO"), Velocidades de Datos Mejoradas para Evolución GSM ("EDGE"), Sistema de Telecomunicaciones Móvil Universal ("UMTS"), Telecomunicaciones Sin cable Mejoradas Digitales ("DECT"), AMPS digital ("IS-136/TDMA"), y Red Mejorada Digital Integrada ("iDEN"). La Evolución de Largo Plazo o 4G LTE, que fue desarrollada por el cuerpo de estándares Proyecto de Asociación de Tercera Generación ("3GPP") es un estándar para una comunicación inalámbrica de datos de alta velocidad para teléfonos móviles y terminales de datos. LTE está basada en las tecnologías celulares digitales GSM/EDGe y UMTS/HSPA y permite aumentar la capacidad y la velocidad utilizando una interfaz de radio diferente junto con mejoras de la red troncal.
Los enlaces de comunicaciones típicamente conectan dispositivos de punto extremo (por ejemplo teléfonos móviles, ordenadores personales, servidores, etc.) de manera que en los dispositivos puede trasmitir datos de uno a otro. Las transmisiones de datos están típicamente gobernadas por distintos protocolos que son específicos en una "suite" o paquete de aplicaciones de protocolo de Internet, que incluye el modelo de red y un conjunto de protocolos de comunicaciones utilizados para redes de Internet y/o similares. La suite de protocolo de internet está típicamente referida como TCP/IP y contiene sus protocolos más importantes: el Protocolo de Control de Trasmisión ("TCP") o y el protocolo de internet ("IP"). El modelo y protocolos t Cp/IP son mantenidos por "Internet Engineering Task Force" o Grupo de trabajo de Ingeniería de Internet ("IETF"). TVP/IP proporciona una conectividad de extremo a extremo que especifica cómo deberían ser formateados, dirigidos y transmitidos, encaminados y recibidos en el dispositivo de punto de extremo de destino. Los protocolos TCP/IP están organizados en las siguientes cuatro capas de abstracción (de más inferior a más elevada): la capa de enlace (que contiene tecnologías de comunicación para un único un segmento de red (enlace)), la capa de internet (que conecta redes independientes para establecer trabajo entre redes), la capa de transporte (que maneja la comunicación proceso a proceso) y la capa de aplicación (que proporciona interfaces para el usuario y para los servicios de soporte).
En vista de la gran cantidad de datos que son típicamente transmitidos a y/desde dispositivos de punto extremo en los sistemas de comunicaciones inalámbricas existentes, tales sistemas y/o dispositivos de punto extremo asociados están afectados por diversos problemas, tales como la pérdida de datos, congestión, transmisiones redundantes, pérdida de potencia de batería (por ejemplo, en el equipo del usuario), y otros. De este modo, el existe la necesidad de proporcionar un sistema de comunicación inalámbrico que sea capaz de proporcionar una transmisión de datos fiable, eficiente y de coste efectivo entre los dispositivos de punto extremo utilizando TCP.
El documento US 2009/0201813 A1 se refiere a un control de flujo TCP en sistemas de comunicación inalámbricos. El documento XP000543510 "Improving reliable transport and handoff performance in cellular wireless networks" (Balakrishan et al, 1 de diciembre de 1995) se refiere a cambios de protocolo en una estación base y a un anfitrión de móvil para preservar las semánticas de extremo a extremo de TCP.
Compendio
La presente invención proporciona un dispositivo para la transmisión de paquetes de datos, como está definido la reivindicación 1, un correspondiente método implementado por ordenador como está definido la reivindicación 12, y un correspondiente producto de programa de ordenador como está definido en la reivindicación 13. Las realizaciones adicionales están definidas en las reivindicaciones dependientes.
Los detalles de una o más variaciones de la materia objeto descrita la presente memoria están expuestos en los dibujos adjuntos y en la descripción que sigue. Otras características y ventajas de la materia objeto descritas en la presente memoria resultarán evidentes a partir de la descripción y de los dibujos, y a partir de las reivindicaciones.
Breve descripción de los dibujos
Los dibujos adjuntos, que se incorporan aquí y que constituyen una parte el que esta memoria, muestran ciertos aspectos de la materia objeto descritas la presente memoria y, junto con la descripción, ayudan a explicar algunos de los principios asociados con las implementaciones descritas. En los dibujos,
La Fig. 1a ilustran un sistema de comunicaciones de evolución a largo plazo ("LTE") convencional a modo de ejemplo;
La Fig. 1b ilustra un detalle adicional del sistema LTE mostrado en la Fig. 1a;
La Fig. 1c ilustra un detalle adicional del núcleo de paquete evolucionado del sistema LTE a modo de ejemplo mostrado en la Fig. 1a;
La Fig. 1d ilustra un Nodo B evolucionado a modo de ejemplo del sistema LTE a modo de ejemplo mostrado en la Fig. 1a;
La Fig. 2 ilustra un detalle adicional de un nodo B evolucionado mostrado en las Figs. 1a-d;
La Fig. 3 ilustra una red de acceso de radio de evolución a largo plazo inteligente, a modo de ejemplo, de acuerdo con algunas implementaciones de la materia objeto actual;
La Fig. 4 ilustra un sistema de comunicaciones a modo de ejemplo que incluye una funcionalidad de protocolo de control de trasmisión ("TCP") en una estación de base, de acuerdo con algunas implementaciones de la materia objeto actual;
La Fig. 5 ilustra un sistema a modo de ejemplo que incluye funcionalidades de retransmisión de almacenamiento en memoria intermedia, de acuerdo con algunas implementaciones de la materia objeto actual;
La Fig. 6 ilustra un control de ventana de congestión a modo de ejemplo en comunicaciones TCP;
La Fig. 7 ilustra detalles adicionales de control de ventana de congestión en comunicaciones TCP;
La Fig. 8 ilustra un sistema de comunicaciones TCP a modo de ejemplo para la transmisión de paquetes TCP; La Fig. 9 ilustra un sistema de comunicaciones TCP a modo de ejemplo para la transmisión de paquetes TCP, en donde no es recibido un acuse de recibo de recepción para uno de los paquetes TCP;
La Fig. 10 ilustra un diagrama de flujo a modo de ejemplo que muestra la capacidad del eNodeB del sistema de la materia objeto actual para reducir transmisiones duplicadas de paquetes de datos, de acuerdo con algunas implementaciones de la materia objeto actual;
La Fig. 11 ilustra un proceso a modo de ejemplo para determinar un valor de expiración de ida y vuelta para un enlace de comunicación particular entre un equipo de usuario y un eNodeB (como se muestra por ejemplo la Fig. 5), de acuerdo con algunas implementaciones de la materia objeto actual;
La Fig. 12 ilustra un sistema de comunicaciones a modo de ejemplo que puede resolver una situación de desbordamiento de búfer, de acuerdo con algunas implementaciones de la materia objeto actual;
La Fig. 13 ilustra un sistema a modo de ejemplo que incluye un eNodeB para coordinar la comunicación entre un equipo de usuario y una red troncal, de acuerdo con algunas implementaciones de la materia objeto actual;
La Fig. 14 ilustra un sistema a modo de ejemplo, de acuerdo con algunas implementaciones de la materia objeto actual;
La Fig. 15 ilustra un método a modo de ejemplo, de acuerdo con algunas implementaciones de la materia objeto actual.
Descripción detallada
Para afrontar las deficiencias de las soluciones actualmente disponibles, una o más implementaciones de la materia objeto actual proporcionan una red de acceso de radio de evolución a largo plazo que tiene capacidades inteligentes, incluyendo la transmisión de datos utilizando TCP.
I. Sistema de Comunicaciones en de Evolución a Largo Plazo
Las Figs. 1 a-c y 2 ilustran un sistema de comunicación de evolución a largo plazo ("LTE") convencional a modo de ejemplo 100 junto con diversos componentes. Un sistema LTE o un 4G LTE, como es comercialmente conocido, es gobernado por un estándar para comunicación inalámbrica de datos de alta velocidad para teléfonos móviles y terminales de datos. El estándar está basado en GSM/EDGE ("Sistema Global para Comunicaciones Móviles"/" Velocidades de Datos Mejoradas para Evolución GSM") así como tecnologías de redes UTMS/HSPA ("Sistema de Telecomunicaciones Móviles Universal"/"Accesos a Paquetes de Alta Velocidad"). El estándar está desarrollado por el 3GPP ("Proyecto de Asociación de Tercera Generación").
Como se muestra en la Fig. 1a, el sistema 100 puede incluir una red y acceso de radio terrestre universal evolucionada ("EUTRAN") 102, un núcleo de paquete evolucionado ("EPC") 108, y una red datos de paquete ("PDN") 101, en donde la EUTRAN 102 y el EPC 108 proporciona comunicación entre un equipo de usuario 104 y la PDN 101. La EUTRAN 102 puede incluir una pluralidad de nodos B evolucionados ("eNodeB" o "ENODEB" o "enodeb" o "eNB") o estaciones de base 106 (a, b, c) (como se muestra la Fig. 1b) que proporcionan capacidades de comunicación a una pluralidad de equipos de usuario 104 (a, b, c). El equipo de usuario 104 puede ser un teléfono móvil, un "smartphone", una tableta, un ordenador personal, un asistente digital personal ("PDA"), un servidor, un terminal de datos, y/o cualquier otro tipo de equipo de usuario, y/o cualquier combinación de los mismos. El equipo de usuario 104 se puede conectar al EPC 108 y finalmente, a la PDN 101, por medio de cualquier eNodeB 106. Típicamente, el equipo de usuario 104 se puede conectar al eNodeB 106 más cercano, en términos de distancia. El sistema LTE 100, la EUTRAN 102 y el EPC 108 trabajan juntos para proporcionar conectividad, movilidad y servicios al equipo de usuario 104.
La Fig. 1b ilustra un detalle adicional de la red 100 mostrada en la Fig. 1a. Como se ha expuesto anteriormente, la EUTRAN 102 incluye una pluralidad de eNodeBs 106, también conocidos como sitios de celda. Los eNodeBs 106 proporcionan funciones de radio y realizan funciones de control de clave que incluyen programación de recursos de enlace de aire o gestión de recursos de radio, movilidad de modo activo o entrega, y control de admisión para servicios. Los eNodeBs 106 son responsables de seleccionar qué entidades de gestión de movilidad (MMEs, como se muestra en la Fig. 1c) servirán al equipo de usuario 104 y para las características de control similares a la compresión y encriptación de encabezado. Los eNodeBs 106 que forman una EUTRAN 102 colaboran entre sí para la gestión y entrega de recursos de radio.
La comunicación entre el equipo de usuario 104 y el eNodeB 106 se produce por medio de una interfaz de aire 122 (también conocida como interfaz "LTE-Uu"). Como se muestra en la Fig. 1b, la interfaz de aire 122 proporciona comunicación entre el equipo de usuario 104b y el eNodeB 106a. La interfaz de aire 122 utiliza Acceso Múltiple de División de Frecuencia Ortogonal ("OFDMA") y Acceso Múltiple de División de Frecuencia de Única Portadora ("SC-FDMA"), una variante OFDMA, en el enlace de bajada y enlace de subida respectivamente. El OFDMA permite el uso de múltiples tecnologías de antena conocidas, tales como Múltiple Entrada Múltiple Salida ("MIMO").
La interfaz de aire 122 utiliza diversos protocolos, que incluyen un control de recursos de radio ("RRC") para enviar señales entre el equipo de usuario 104 y el eNodeB 106 y el estrato sin acceso ("NAS") para señalizar entre el equipo del usuario 104 y la MME (como se muestra en la Fig. 1c). Además de la señalización, el tráfico de usuario es transferido entre el equipo de usuario 104 y el eNodeB 106. Tanto la señalización como el tráfico que en el sistema 100 son realizados por canales de capa física ("PHY").
Múltiples eNodeBs 106 pueden estar interconectados entre sí utilizando una interfaz X2 130 (a, b, c). Como se muestra en la Fig. 1a, la interfaz X2 130a proporciona interconexión entre el eNodeB 106a y el eNodeB 106b; la interfaz X2 130b proporciona interconexión entre el eNodeB 106a y el eNodeB 106c; y la interfaz X2 130c proporciona interconexión entre el eNodeB 106b y el eNodeB 106c. La interfaz X2 puede ser establecida entre dos eNodeBs con el fin de proporcionar un intercambio de señales, que puede incluir una información relacionada con la carga o con la interferencia, así como una información relacionada con la transferencia. Los eNodeBs 106 se comunican con el núcleo de paquete evolucionado 108 por medio de una interfaz S1 124(a, b, c). La interfaz S1 124 puede estar dividida en dos interfaces: una para el plano de control (mostrado como la interfaz de plano de control (interfaz S1-MME) 128 en la Fig. 1c) y la otra para el plano del usuario (mostrada como interfaz de plano de usuario (interfaz S1-U) 125 en la Fig. 1c).
El EPC 108 establece y hace cumplir el servicio de calidad ("QoS") para los servicios de usuario y permite que el equipo de usuario 104 mantenga una dirección de protocolo de internet ("IP") consistente mientras se está moviendo. Se ha de observar que cada nodo en la red 100 tiene su propia Dirección IP. El EPC 108 está diseñado para trabajar con redes inalámbricas de legado. El EPC 108 está también diseñado para separar el plano de control (es decir, la señalización) y el plano del usuario (es decir, el tráfico) en la arquitectura de red troncal, lo que permite más flexibilidad de la implementación, y escalabilidad independiente de las funciones de control y datos de usuario. La arquitectura de EPC 108 está dedicada a datos de paquete y se muestra con más detalle en la Fig. 1c. El EPC 108 incluye una pasarela de servicio (S-GW) 110, una pasarela PDN (P-GW) 112, una entidad de gestión de movilidad ("MME") 114, un servidor de abonado doméstico ("HSS") 116 (una base de datos de abonado para el EPC 108), y una función de control de política y reglas de pago ("PCRF") 118. Algunos de estos (tales como S-GW, P-GW, MME, y HSS) a menudo están combinados en nodos de acuerdo con la implementación de fabricante.
El S-GW 110 funciona como un rúter entre datos de paquete IP y es el anclaje de trayectoria de portador de equipo de usuario en del EPC 108. De este modo, el equipo de usuario se mueve desde un eNodeB 106 a otro utilizando operaciones de movilidad, el S-GW 110 permanece siendo el mismo y la trayectoria de portador hacia la EUTRAN 102 es conmutada para hablar con el nuevo eNodeB 106 que sirve el equipo de usuario 104. Si el equipo de usuario 104 se mueve al dominio de otro S-GW 110, la MME 114 transferirá todas las trayectorias de portador del equipo de usuario a nuevo S-GW. El S-GW 110 establece trayectorias de portador para el equipo de usuario a uno o más P-GWs 112. Si los datos aguas abajo son recibidos para un equipo de usuario en activo, el S-GW 110 almacena los paquetes aguas abajo y solicita a la MME 114 localizar y restablecer las trayectorias de portador a y a través de la EUTRAN 102.
El P-GW 112 es la pasarela entre el EPC 108 (y el equipo de usuario 104 y la EUTRAN 102) y la PDN 101 (mostrada en la Fig. 1a). El P-GW 112 funciona como un rúter para el tráfico de usuario así como realiza funciones de parte del equipo de usuario. Estas incluyen asignación de dirección IP para el equipo de usuario, filtrado de paquetes de tráfico de usuario aguas abajo para asegurar que está situado en la trayectoria de portador apropiada, hacer cumplir el QoS aguas abajo incluyendo la velocidad de datos. Dependiendo de los servicios que un abonado esté utilizando, puede haber múltiples trayectorias de portador de datos de usuario entre el equipo de usuario 104 y el P-GW 112. El abonado puede utilizar servicios sobre PDNs servidos por diferentes P-GWs, en cuyo caso el equipo de usuario tiene al menos cuna trayectoria de portador establecida para cada P-GW 112. Durante la transferencia del equipo de usuario desde un eNodeB a otro, si el S-GW 110 está también cambiando, la trayectoria de portador desde el P-GW 112 es conmutada al nuevo S-GW.
La MME 114 gestiona el equipo de usuario 104 dentro del EPC 108, incluyendo gestión de autenticación de abonado, manteniendo un contexto para el equipo de usuario autenticado 104, estableciendo trayectorias de portador de datos en la red para el tráfico de usuario, y manteniendo el rastro de la ubicación de los móviles inactivos que no se han separado de la red. Para el equipo de usuario inactivo 104 que necesita ser reiniciado en la red de acceso para recibir datos aguas abajo, la MME 114 iniciará la paginación para localizar el equipo de usuario y restablecer las trayectorias de portador a y a través de la EUTRAN 102. La MME 114 para un equipo de usuario particular 104 es seleccionada por el eNodeB 106, desde el cual, el equipo de usuario 104 inicia el acceso del sistema. La MME es típicamente parte de una colección de MMEs en el EPC 108 con la finalidad de compartir carga y redundancia. En el establecimiento de las trayectorias de portador de datos de usuario, la m Me 114 es responsable de seleccionar el P-GW 112 y el S-GW 110, que formarán los extremos de la trayectoria de datos a través del EPC 108.
El PCRF 118 es responsable de la toma de decisiones de control de política, así como de controlar las funcionalidades de carga basadas en el flujo en la función de cumplimiento de control de política ("PCEF"), que reside en el P-GW 110. El PCRF 118 proporciona la autorización QoS (identificador de clase QoS ("QCI") y velocidades de bit) que decide cómo será cierto flujo de datos tratado en el PCEF y asegura que esto está de acuerdo con el perfil de suscripción del usuario.
Como se ha establecido anteriormente, los servicios de IP 119 son proporcionados por la PDN 101 (como se muestra la Fig. 1a).
II. eNodeB
La Fig. 1d ilustra una estructura a modo de ejemplo del eNodeB 106. El eNodeB 106 puede incluir al menos una cabeza de radio remota ("RRH") 132 (típicamente, puede haber tres RRH 132) y una unidad de banda base ("BBU") 134. La RRH 132 puede estar conectada a las antenas 136. La RRH 132 y la BBU 134 pueden estar conectadas utilizando una interfaz óptica que se amolda con la especificación estándar de interfaz de radio pública común ("CPRI") 142. El funcionamiento del eNodeB 106 puede ser caracterizado utilizando los siguientes parámetros estándar (y especificaciones): banda de radiofrecuencia (Banda4, Banda9, Banda17) anchura de banda ( 5, 10, 15, 20 MHz), esquema de acceso (enlace de bajada: OFDMA; enlace de subida: SC-OFDMA), tecnología de antena (enlace de bajada: 2x2 MIMO; enlace de subida: 1x2 entrada única salida múltiple ("SIMO")), número de sectores (6 máximo), potencia de trasmisión máxima (60W), velocidad de trasmisión máxima (enlace de bajada: 150 Md/s; enlace de subida: 50 Mb/s), interfaz S1/X2 (1000Base-SX, 1000Base-T), y en torno móvil (hasta 350 km/h). La BBU 134 puede ser responsable del procesamiento de señal de banda base digital, terminación de la línea S1, terminación de la línea X2, procesamiento de llamada y procesamiento de control de monitorización. Los paquetes IP que son recibidos desde el EPC 108 (no mostrados en la Fig. 1d) pueden ser modulados a señales de banda base digitales y transmitidos a la RRH 132.
Inversamente, en las señales de banda base digitales recibidas desde la RRH 132 pueden ser desmoduladas a paquetes IP para la transmisión al EPC 108.
La RRH 132 puede trasmitir recibir señales inalámbricas utilizando las antenas 136. La RRH 132 puede convertir (utilizando señales de banda base digitales de convertidor ("CONV") 140) procedentes de la BBU 134 a señales de radio frecuencia ("RF") y amplificar la potencia (utilizando amplificador ("AMP") 138) para la transmisión al equipo de usuario 104 (no mostrado en la Fig. 1d). Inversamente, las señales RF que son recibidas desde el equipo de usuario 104 son amplificadas (utilizando AMP 138) y convertidas (utilizando CONV 140) a señales de banda base digitales para la transmisión a la BBU 134,
La Fig. 2 ilustra un detalle adicional de un eNodeB 106 a modo de ejemplo. El eNodeB 106 incluye una pluralidad de capas: capa LTE 1202, la capa LTE 2204, y capa LTE 3206. La capa LTE 1 incluye una capa física ("PHY"). La capa LTE 2 incluye un control de acceso al medio ("MAC"), un control de enlace de radio ("r Lc "), un protocolo de convergencia de datos de paquete ("PDCP"). La capa LTE 3 incluye diversas funciones y protocolos, que incluyen un control de recurso de radio ("RRC"), una asignación de recurso dinámica, configuración y provisión de medida de eNodeB, un control de admisión de radio, un control de movilidad de conexión, y una gestión de recurso de radio ("RRM"). El protocolo RLC es un protocolo de fragmentación de solicitud repetida automática ("ARQ") utilizado sobre una interfaz de aire celular. El protocolo RRC maneja la señalización de plano de control de la capa LTE 3 entre el equipo de usuario y la EUTRAN. RRC incluye funciones para el establecimiento y liberación de conexión, difusión de información de sistema, establecimiento/reconfiguración y liberación de portador de radio, procedimientos de movilidad de conexión RRC, notificación y liberación de paginación, y otro control de potencia de bucle exterior. El PDCP realiza la compresión y descompresión del encabezado IP, transferencia de datos de usuario y mantenimiento de números de secuencia de Portadores de Radio. La BBU 134, mostrada en la Fig. 1d, puede incluir capas LTE L1-L3.
Una de las funciones principales del eNodeB 106 es la gestión de recursos de radio, que incluye programación tanto de recursos de interfaz de aire de enlace entre el encale de subida y enlace de bajada para el equipo de usuario 104, el control de recursos de portador, y control de admisión. El eNodeB 106, como agente para el EPC 108, es responsable en de la transferencia de mensajes de paginación que son utilizados para localizar móviles cuando están inactivos. El eNodeB 106 comunica también información de canal de control común en el aire, compresión de encabezado, encriptación y desencriptación de los datos de usuario enviados en el aire, y establece criterios de reporte de transferencia y de desencadenamiento. Como se ha establecido anteriormente, el eNodeB 106 puede colaborar con otro eNodeB 106 sobre la interfaz X2 con el fin de la realizar la gestión de transferencia de interferencia. Los eNodeBs 106 comunican con la MME de EPC por medio de la interfaz S1-MME y con el S-GW con la interfaz S1-U. Además, el eNodeB 106 intercambia datos de usuario con el S-GW sobre la interfaz S1-U. El eNodeB 106 y el EPC 108 tienen una relación mucho con mucho para compartir carga de soporte y redundancia entre las MMEs y los S-GWs. El eNodeB 106 selecciona una MME de un grupo de MMEs de manera que puede ser compartido por múltiples MMEs para evitar la congestión.
III. Red de Acceso de Radio LTE Inteligente
La Fig. 3 ilustra un sistema 300 a modo de ejemplo, de acuerdo con algunas implementaciones de la materia objeto actual. El sistema 300 puede ser implementado como una red de acceso de radio de nube centralizada ("C-RAN"). El sistema 300 puede incluir al menos una unidad de cabeza de radio remota inteligente ("iRRH") 302 y una unidad de banda base inteligente ("iBBU) 304. La iRRH 302 y la iBBU 304 pueden estar conectadas utilizando comunicación de red de enlaces intermedios "fronthaul" de Ethernet ("FH") 306 y la iBBU 304 puede ser conectada al EPC 108 utilizando comunicación de red de retorno "backhaul" ("BH") 308. El equipo de usuario 104 (no mostrado en la Fig. 3) puede comunicar con la iRRH 302.
En algunas implementaciones, la iRRH 302 puede incluir el módulo amplificador de potencia ("PA") 312, el módulo de radiofrecuencia ("RF") 314, la capa LTE l 1 (o la capa PHY) 316, y una parte 318 de la capa LTE L2. La parte 318 de la capa LTE L2 puede incluir la capa MAC y puede incluir además algunas funcionalidades/protocolos asociados con RLC y PDCP, como se describirá más adelante. La iBBU 304 puede ser una unidad centralizada que puede comunicar con una pluralidad de iRRH y puede incluir la capa LTE L3322 (por ejemplo, RRC, RRM etc.) y también puede incluir una parte 320 de la capa LTE L2. Similar a la parte 318, la parte 320 puede incluir diversas funcionalidades/protocolos asociados con RLC y PDCP. De este modo, el sistema 300 puede estar configurado para dividir funcionalidades/protocolos asociados con RLC y PDCP entre la iRRH 302 y la íbBu 304.
IV. TCP en Red de Acceso de radio LTE inteligente
En algunas implementaciones, el sistema de la materia objeto actual puede estar configurado para implementar y/o utilizar de otra forma el protocolo de control de trasmisión ("TCP") con la finalidad de realizar transmisiones de datos entre un equipo de usuario y un servidor por medio de un eNodeB. El eNodeB puede estar configurado para manejar transmisiones TCP y puede incluir un procesador TCP que puede actuar como un componente para la gestión de tales transmisiones de datos.
El TCP es considerado como uno de los protocolos de núcleo de la suite de protocolo de internet ("IP") y proporciona envío fiable, ordenado y con error comprobado de una cadena de octetos entre programas que se ejecutan en dispositivos que pueden estar conectados a una red (por ejemplo, una red de área local, intranet, o Internet pública. El TCP reside en la capa de transporte. El TCP acepta datos procedentes de cadenas de datos, los divide en trozos, y los añade a un encabezado TCP, que crea un segmento TCP. El segmento TCP es entonces encapsulado en un diagrama de datos IP e intercambiado con dispositivos equiparados.
Un segmento TCP incluye un encabezado TCP y una sección de datos. El encabezado TCP contiene diez campos obligatorios y un campo de extensión opcional. La sección de datos sigue el encabezado e incluye datos de carga útil para una aplicación. La longitud de la sección de datos es calculada sustrayendo la longitud combinada del encabezado TCP y el encabezado IP de encapsulado desde una longitud de diagrama de datos IP total (como se especifica en el encabezado IP). Los navegadores de web u otras aplicaciones utilizan TCP, cuando se conectan a servidores en el Word Wide Web, para enviar datos de carga útil (por ejemplo, correo electrónico, archivos, etc.) y/o transferir archivos desde una ubicación a otra.
Las operaciones de protocolo TCP incluyen tres fases: establecimiento de conexión, transferencia de datos, y finalización de la conexión. El establecimiento de conexión implica un proceso de protocolo de intercambio de múltiples etapas que es seguido por la fase de transferencia de datos. Después de que la transmisión de datos se haya completado, la fase determinación de conexión cierra los circuitos virtuales establecidos y libera todos lo recursos asignados. Las conexiones TCP son gestionadas por un sistema de funcionamiento a través de una interfaz de programación que representa un punto final para las comunicaciones, es decir un "socket" de internet. Para establecer una conexión, el TCP utiliza protocolo de intercambio de tres vías. Sin embargo, antes de que un cliente (por ejemplo una aplicación de software, un dispositivo de punto extremo (por ejemplo, un ordenador personal, un dispositivo inalámbrico, un servidor, etc.)) se pueda conectar a un servidor, el servidor realiza un proceso de apertura pasiva (es decir uniéndose a y escuchando en un puerto para abrirlo para las conexiones). Una vez establecida, la aplicación de cliente inicia una apertura activa. Durante la apertura activa, el protocolo de intercambio de tres vías incluye: enviar un paquete SYN desde el cliente al servidor, en donde el cliente establece el número de secuencia de segmento en un valor aleatorio; enviar un paquete SYN-ACK procedente del servidor como respuesta, en donde el paquete incluye un número de acuse de recibo que es establecido en uno más que el número de secuencia recibido y un número de secuencia elegido por el servidor para el paquete, en donde el número de secuencia es otro número aleatorio; y enviar un paquete ACK desde el cliente de nuevo al servidor. En el paquete ACK, el número de secuencia es establecido en el valor de acuse de recibo recibido y el número de acuse de recibo es establecido en uno más que el número de secuencia recibido.
Para terminar una conexión, se utiliza un protocolo de intercambio de cuatro vías, en donde cada lado (cliente y servidor) termina la conexión independientemente. Cuando un dispositivo de punto extremo desea detener su mitad de la conexión, trasmite un paquete FIN, en donde el otro dispositivo de punto extremo realiza acuse de recibo con un paquete ACK. De este modo, la finalización de la conexión típicamente incluye un par de paquetes FIN y ACK procedentes de cada dispositivo de punto extremo TCP.
La transmisión de datos utilizando TCP puede ocurrir entre dispositivos en redes de comunicación por cable y/o inalámbricas. Para permitir el uso del TCP con el fin de realizar transmisión de datos entre el equipo de usuario y una red inalámbrica (tal como una red descrita en combinación con las Figs. 1a-3 anteriores) y servidores, puede estar incluido un procesador TCP en el eNodeB.
La Fig. 4 ilustra un sistema 400 a modo de ejemplo que tiene un procesador TCP 408 en un eNodeB, de acuerdo con algunas implementaciones de la materia objeto actual. El sistema 400 puede incluir un eNodeB 404 y/o cualquier otro tipo de estación base conectada de forma comunicativa con un equipo de usuario 402 por medio de un enlace sobre el aire 410 y con un servidor 406 por medio de un enlace 412. El servidor 406 puede ser parte de la red troncal (no mostrada en la Fig. 4) y/o puede ser un servidor fuera de la red troncal. El servidor puede incluir y/o obtener datos que son deseados por el equipo de usuario 402. El equipo de usuario 402 puede comunicar con el eNodeB 404, como se ha descrito en combinación con las Figs. 1a-3. El eNodeB 404 puede incluir la estructura mostrada en la Fig. 3 y descrita anteriormente.
En algunas implementaciones, el procesador TCP 408 puede ser un módulo de software y/o cualquier combinación de hardware y/o componentes de software que pueden estar dispuestos en una estación base (por ejemplo, el eNodeB 404). Estos componentes pueden estar separados de otros componentes de la estación base y/o compartir componentes con otro hardware y/o software dispuesto en la estación base.
Para establecer conexión con el equipo de usuario 402 y el servidor 406, el equipo de usuario 402 puede establecer conexión con el procesador TCP 408, que también puede establecer conexión con el servidor 406. El procesador TCP 408 puede trasmitir datos recibidos desde el equipo de usuario 402 al servidor 406, así como trasmitir datos recibidos desde el servidor 406 al equipo de usuario 402.
En las transmisiones TCP, la producción de una comunicación puede estar limitada por dos ventanas: una ventana de congestión ("CNWD") y una ventana de recepción ("RW"). La CNWD determina el número de bytes que pueden ser destacados en cualquier momento durante una transmisión TCP. Este es diferente del tamaño de ventana TCP mantenido por el receptor de datos. La CNDW evita que un enlace entre los puntos finales de la conexión sea sobrecargado con demasiado tráfico de datos. El tamaño de la CNDW se calcula estimando cuánta congestión existe entre los dos puntos extremos. El remitente de datos típicamente mantiene la CNDW. Cuando una conexión es establecida, la CNDW (con valor mantenido independientemente de cada anfitrión) es establecida en un múltiplo pequeño de tamaño de segmento máximo ("MSS)" permitido en la conexión. La varianza adicional en la ventana de congestión se determina por el conocido enfoque de aumento aditivo/disminución multiplicativa ("AIMD") (es decir, un algoritmo de control de retroalimentación utilizado para evitar la congestión TCP, que aumenta la velocidad de transmisión (tamaño de ventana) hasta que se produce la pérdida de datos y/o aumenta la CNDW en una cantidad fija cada tiempo de ida y vuelta. Cuando la congestión es detectada, el transmisor disminuye la velocidad de transmisión en un factor multiplicativo (por ejemplo recorta la ventana de congestión a la mitad después de la pérdida de datos)). Si todos los segmentos son recibidos y los acuses de recibo alcanzan el remitente a tiempo, un valor constante es añadido al tamaño de ventana. La ventana crece exponencialmente hasta que se produce una expiración o el receptor alcanza su límite (un valor umbral "sstresh"). Después de esto, la CNDW aumenta linealmente a una velocidad de 1/(ventana de congestión) paquetes en cada nuevo acuse de recibo recibido. Cuando se produce la expiración, sucede lo siguiente: la ventana de congestión es reseteada a 1MSS, "sstresh" es establecido a la mitad del tamaño de ventana antes de que la pérdida de paquete empiece, e inicio lento "slow start" es iniciado. Un administrador del sistema puede ajustar el límite de tamaño de ventana máximo y/o ajustar la constante añadida durante el aumento aditivo, como parte de la sintonización de TCP. El flujo de datos sobre una conexión TCP es también controlado mediante RW, que es proporcionada por el receptor de datos. El remitente determina cuántos datos puede enviar comparando su propia Cn Dw con la RW.
Para evitar la congestión, la CNDW no debería exceder la capacidad de la red en la que los datos son transmitidos. Para controlar el flujo de datos, RW no debería exceder la capacidad del equipo receptor para procesar datos. El equipo receptor puede quedar sobrepasado por los datos si el receptor (por ejemplo, un servido web) está muy atareado. Típicamente, cada segmento TCP puede contener un valor actual de RW. Si un remitente recibe un ACK, acusando recibo de 1000 bytes y especificando tamaño de RW de 5000 bytes, el remitente no enviará paquetes de datos después del byte 6000, incluso si lo permite la CNDW.
Ensamblado TCP o unión retrasada típicamente se refiere a un aplazamiento de una conexión entre dos puntos extremos con el fin de obtener suficiente información acerca de la conexión y/o puntos extremos para tomar una decisión de encaminamiento apropiada. Algunos dispositivos de punto extremo (por ejemplo, computadores de aplicación, rúters, etc.) pueden retrasar la unión de una sesión de cliente (por ejemplo el quipo de usuario) con un servidor hasta que se han completado los protocolos de intercambio adecuados.
A. Almacenamiento y Retransmisión de Segmento TCP Local
La Fig. 5 ilustra un sistema 500 a modo de ejemplo que puede incluir capacidades de procesamiento TCP resaltadas anteriormente, de acuerdo con algunas implementaciones de la materia objeto actual. El sistema 500 puede incluir un eNodeB inteligente 504 (tal como una iBBU 304 mostrada en la Fig. 3) que comunica con un equipo de usuario 502 y una red troncal 506. El equipo de usuario 502 puede recibir y/o transmitir diversos datos desde y/o a un servidor y/o cualquier otro dispositivo de punto extremo (no mostrado en la Fig. 5) o utilizando TCP, en donde el servidor puede ser parte de una red troncal 506 y/o puede estar separado de, pero conectado a, la red troncal 506. El eNodeB 504 puede incluir un procesador TCP 508 que puede proporcionar las capacidades de procesamiento TCP anteriores, que incluyen, pero no se limitan a, establecer y/o gestionar conexión(es) entre el equipo de usuario 502 y el dispositivo del servidor/punto final. El eNodeB 504 también puede incluir un búfer 510 que puede ser utilizado para almacenar temporalmente y/o almacenar segmentos TCP y/o ACKs. El procesador TCP 508 y/o el búfer 510 pueden ser módulos de software y/o una combinación de componentes de software y/o hardware del eNodeB 504. El búfer 510 también puede ser cualquier tipo de hardware y/o software de almacenamiento.
En algunas implementaciones, el procesador TCP 508 puede implementar control de ventana inicial ("IW"), RW, y CNWD y/o realizar otras funciones relacionadas con TCP para evitar la congestión de una conexión y, de este modo, la pérdida de paquetes de datos. Como se muestra en la Fig. 6, en la ventana de inicio lento 602 y antes de alcanzar el valor umbral "ssthresh" 604, el procesador TCP 608 puede realizar asignación de prioridades a paquetes de datos. Adicionalmente, durante la ventana de inicio lento 602, el procesador TCP 508 puede realizar una programación agresiva de paquetes de datos para la transmisión en el caso de que exista una buena señal de frecuencia de radio entre el equipo de usuario 502 y el eNodeB 504. Inversamente, si se detecta una frecuencia de radio pobre entre el equipo de usuario 502 y el eNodeB 504, el procesador TCP 508, durante la ventana de inicio lento 602, puede de manera conservadora programar paquetes de datos para la transmisión. De esta manera, se pueden evitar la congestión de la conexión, las transmisiones múltiples y/o las pérdidas de datos.
Además, durante la ventana de inicio lento, el tamaño de la ventana de congestión puede ser el doble del tamaño con cada ida y vuelta que realiza el paquete de datos, es decir cada vez que un acuse de recibo que es recibido por el servidor de que el paquete ha sido transmitido exitosamente a y recibido por el dispositivo de punto extremo, el tamaño de la ventana de congestión puede aumentar (dependiendo de la implementación TCP, el tamaño de la ventana de congestión puede aumentar de forma acorde). De este modo, el aumento de tamaño de la ventana de congestión puede ser exponencial. Una vez que se ha alcanzado la fase en evitar la congestión, el tamaño de la ventana de congestión solo puede ser incrementado linealmente, como se indica mediante la línea recta en la fase de evitar la congestión 606 en la Fig. 6.
El rendimiento del TCP puede ser penalizado severamente cuando el servidor detecta pérdida de paquetes. En algunas implementaciones TCP, durante la sesión de trasmisión TCP, si el servidor recibe acuses de recibo duplicados (por ejemplo acuses de recibo duplicados ("DUP ACKs")), el servidor puede determinar que el paquete TCP particular no ha sido recibido por el dispositivo de punto extremo y determinar que existe congestión, lo que hará que el servidor reseteé la ventana de congestión y reduzca el valor "sstresh" (por ejemplo, a la mitad). Esta situación se ilustra la Fig. 7.
Como se muestra en la Fig. 7, un rendimiento de la transmisión TCP se ilustra en un gráfico que tiene un tamaño de una ventana de congestión (CNWD) en el eje vertical y un número de tiempos de ida y vuelta ("RTT") (correspondientes al tiempo que tarda al servidor en recibir un acuse de recibo de que un paquete ha sido recibido) en el eje horizontal. En la fase de inicio lento, la ventana de congestión continúa creciendo exponencialmente desde un tamaño inicial de la ventana de congestión 701. El tamaño de la ventana crece hasta un umbral inicial 702, después de lo cual el tamaño de la ventana de congestión crece linealmente hasta que el servidor (que envía los paquetes TCP) recibe una indicación de que han sido recibidos ACKs duplicados, en 707. En ese momento, el tamaño de la ventana de congestión es reseteado al tamaño inicial 703 (que puede ser el mismo que el tamaño 701) y el proceso de crecimiento del tamaño de la ventana de cogestión empieza de nuevo. Sin embargo, dado que el tamaño de la ventana de congestión fue reseteado, el valor ssthresh es reducido para ser más pequeño que el ssthresh inicial 702. El nuevo valor de ssthresh 704 puede ser la mitad del ssthresh inicial 702 (para diferentes implementaciones TCP (por ejemplo, TCP-Reno, TCP-Vegas, etc.) los nuevos valores de ssthresh pueden ser diferentes y/o se puede implementar el hecho de evitar la congestión de una manera diferente). El crecimiento del tamaño de la ventana de congestión puede continuar hasta que otros tres DUP ACKs sean recibidos, en 709. En ese momento, la ventana de congestión es reseteada a 705 y el valor de ssthresh 704 es reducido al ssthresh 706. Después, el proceso de crecimiento de la ventana de congestión puede empezar de nuevo. En algún punto durante este proceso, el servidor puede determinar que el dispositivo de punto extremo es incapaz de recibir sus transmisiones y terminar la sesión de transmisión.
Al contrario que un entorno sin pérdida de transmisión TCP ideal, un ambiente de comunicaciones inalámbrica puede implicar una pérdida sustancial de paquetes. Esto puede hacer que un servidor que trasmita datos de paquete TCP reseteé constantemente la ventana congestión, reduzca las conexiones, etc., causando con ello un sustancial retraso en el envío de paquetes, un drenaje de batería, y otras consecuencias indeseables. La pérdida de datos puede ocurrir como resultado de varios factores asociados con las transmisiones inalámbricas. Por ejemplo, en un ambiente de comunicaciones inalámbrico, el movimiento del equipo del usuario desde un área de radio que tiene una buena señal hasta otra área de radio que tiene una señal pobre puede producir retraso en el envío de paquetes y de los correspondientes ACKs al servidor, haciendo con ello que el servidor determine que existe congestión en la línea. La interferencia procedente de otras fuentes de radio (por ejemplo, otro equipo de usuario) puede también producir pérdidas. Otros factores pueden afectar la pérdida de paquetes también.
En algunos casos el entorno de comunicaciones móvil puede implementar combinación de rechazo de interferencia ("IRC") y/o combinación de relación máxima ("MRC"). Utilizando IRC, la señal trasmitida es regenerada en base a los datos estimados procedentes de recepciones anteriores, la distorsión desde los canales de múltiple trayectoria es emulada y, todas las señales de interferencia regeneradas son sustraídas de las señales recibidas de enlace de subida para obtener una estimación más fiable de los datos del usuario originales. IRC utiliza separación espacial y características de interferencia entre celdas para determinar la potencia del equipo de usuario de interferencia con otra celda. Una vez que el patrón y el nivel de potencia están determinados, la celda que está afectada por la interferencia puede eliminar la interferencia de las señales recibidas. IRC puede ser implementada en el eNodeB y puede reducir el impacto de interferencia de los usuarios vecinos en el enlace de subida. Por tanto, IRC puede aumentar la producción de usuarios de enlace de subida. Cuando se utiliza IRC de enlace de subida una ganancia de relación señal máxima respecto a interferencia más ruido ("SINR") de 7dB se puede conseguir sobre el método de reducción de interferencia MMSE tradicional. En comparación, MRC no hace uso de las características espaciales de la interferencia cuando se calcula la ponderación de la antena. De este modo, en los casos en los que solo hay un pequeño número de fuentes de interferencia dominantes, IRC puede proporcionar un mejor rendimiento que m Rc especialmente cuando hay un número razonable de antenas de recepción para que IRC ejecute la compensación. Inversamente, si hay un gran número de señales de potencia iguales llegando a la antena de recepción, la ganancia de IRC sobre MRC podría no ser tan significativa.
Sin embargo, todos los bordes de celda tanto IRC como MRC causan un régimen de error de bloque residual elevado ("BLER", que es una indicación de sincronía o fuera de sincronía durante la monitorización de enlace de radio ("RLM")). Hacia los bordes de las celdas, el número de retransmisiones puede aumentar junto con una disminución en SINR, produciendo empeoramiento de las transmisiones y aumentando el número de DUP ACKs que están siendo enviados de nuevo al servidor. Esto puede hacer que el servidor determine que existe congestión y reduzca el valor umbral de ventana de congestión y/o caiga una sesión de transmisión. Sin embargo, en la mayoría de los casos la técnica IRC permite un mejor rendimiento del borde de celda que la técnica MRC.
La Fig. 8 ilustra una cadena de trasmisión de datos TCP 802 a modo de ejemplo que contiene paquetes TCP S1, S2, ... S11 que están siendo transmitidos desde un servidor (no mostrado en la Fig. 8) a un equipo de usuario (no mostrado la Fig. 8). Cada paquete transmitido está siendo transmitido con un número de proceso de solicitud de repetición automático híbrido apropiado ("HPN") 804 (es decir, HPN0-HPN7 para cada ocho submarcos (es decir, en este caso los paquetes TCP S1-S8 corresponden a HPN0-HPN7 y los paquetes TCP S9-S11 corresponden a un nuevo conjunto que empieza con HPN0). Como se muestra la Fig. 8, se hace acuse de recibo de los paquetes TCP S1-S7 utilizando ACK HPNs 806 por el receptor (es decir, el equipo de usuario) y son enviados de nuevo al servidor que transmitió los paquetes originales.
Como se muestra la Fig. 8, una solicitud de repetición automática híbrida ("HARQ") se refiere a una combinación de codificación de corrección de error hacia delante de alta velocidad y un control de error de solicitud de repetición automática ("ARQ"). En ARQ, son añadidos bits redundantes a los datos que van a ser transmitidos utilizando un código de detección de error ("ED"), por ejemplo, una comprobación de redundancia cíclica (“CRC”). Usando ARQ, el equipo usuario que detecta un mensaje corrupto solicita un nuevo mensaje del servidor. En HARQ, los paquetes de datos se codifican con un código de corrección de error hacia delante ("FEC"), y los bits de paridad son o bien enviados inmediatamente junto con el mensaje o bien solo transmitidos bajo solicitud cuando el equipo de usuario detecta un mensaje erróneo. El sistema LTE, cuando se transfieren datos utilizando el proceso HARQ, el equipo de usuario y el servidor típicamente conoce un identificador de proceso para cada uno de los procesos HARQ, de manera que el equipo de usuario puede mantener de manera exitosa cada uno de los datos de proceso sin que se mezclen. El servidor también informa al equipo de usuario del número de procesador HARQ(es decir, HPN) explícitamente, como se muestra en la Fig. 8. En el enlace de subida, el mismo número HPN tiene que ser utilizado por el equipo de usuario cada 8 submarcos, como también se muestra en la Fig. 8, para permitir que el eNodeB determine qué proceso HARQ está siendo transmitido.
Aunque la Fig. 8 ilustra una situación ideal para la transmisión sin pérdida de paquetes TCP, en el mundo real, dicha transmisión sin pérdida es normalmente muy rara, ya que los paquetes transmitidos se pueden perder, las transmisiones pueden encontrar interferencias procedentes de otro equipo de radio, y/o otras interrupciones pueden dar lugar a transmisiones inapropiadas, retrasos, etc.
La Fig. 9 ilustra una transmisión a modo de ejemplo de segmentos TCP S1-S11 902 procedentes de un remitente TCP 904 (por ejemplo, un servidor). En este caso, un paquete TCP S2903 no es transmitido (por ejemplo, se pierde, etc.), haciendo que un receptor TCP 908 (por ejemplo el equipo de usuario) no reciba el paquete TCP S2 y en su lugar, reciba la secuencia de paquetes t Cp con un "agujero" 912. El paquete TCP S2 puede ser transmitido al receptor TCP 908, pero fuera de orden, es decir, el paquete TCP retransmitido S2 911 puede aparecer entre los paquetes TCP transmitidos S9 y S10. El fallo en la recepción del paquete TCP S2 da lugar a una secuencia ACK HPN 906 que tiene un NACK (ACK negativo) HPN1 907, en lugar de un ACK HPN1, y hace que e1HPN asociado del remitente 913 retransmita el paquete TCP S2 junto con HPN1 que corresponde al paquete TCP S2. En algunos casos, han dicha primera retransmisión puede producir un retraso de 8 ms en el envío del paquete TCP S2 así como un envío fuera de orden de los paquetes TCP en la secuencia TCP original. Debido a que los paquetes están siendo ahora enviados fuera de orden, son generados ACKs duplicados ("DUP ACKs") y enviados de nuevo al remitente (lo que da lugar a que en el remitente TCP reduzca la ventana de congestión). Cualesquiera retransmisiones posteriores pueden producir retrasos adicionales de 8 ms cada una, donde tres transmisiones pueden producir un retraso total de 24 ms.
En algún caso, las retransmisiones pueden ser o no exitosas. Además, un gran número de retransmisiones puede además producir aumento en RTT, creando con ello retraso adicional, haciendo que caiga la conexión, etc. Dada la naturaleza favorable a la pérdida del entorno de comunicación inalámbrico, las retransmisiones pueden ocurrir de forma muy frecuente como resultado de recibir DUP ACKs por parte el de los remitentes TCP y haciendo que los remitentes TCP retransmitan paquetes TCP innecesariamente.
En algunas implementaciones, para evitar las retransmisiones innecesarias desde el servidor, el sistema de la materia objeto actual (como se muestra, por ejemplo, en las Figs. 4 y 5 anteriores) puede permitir que el eNodeB almacene segmentos TCP y DUP ACKs, que están siendo transmitidos de nuevo desde el receptor TCP (por ejemplo, el equipo de usuario) al remitente TCP localmente en el eNodeB por el procesador TCP. En algunas implementaciones, el número predeterminado puede corresponder a la recepción de tres DUP ACKs antes de que se pueda realizar una determinación consistente en que un paquete puede necesitar ser retransmitido desde un búfer local. El sistema de la materia objeto actual puede mantener también el rastreo de un tiempo de ida y vuelta que tarda un paquete en ser transmitido y un ACK que va a ser recibido entre el eNodeB y el equipo de usuario. Esto asegura que los segmentos TCP no son retransmitidos innecesariamente.
En algunas implementaciones, el procesador TCP en el eNodeB puede mantener el rastreo (por ejemplo, almacenando en una ubicación de memoria y/o una base de datos situada en el eNodeB) de una información de tiempo de ida y vuelta ("RTT") indicativa de que un tiempo que ha tardado que los paquetes sean enviados al receptor TCP y que un ACK sea recibidos en el eNodeB. Si el eNodeB recibe una indicación DUP ACK (que puede ser indicativa de una desaparición de paquete) más temprana que el RTT, entonces el procesador TCP en el eNodeB puede determinar que el DUP ACK fue enviado por error y de este modo, el DUP a Ck puede ser ignorado. El eNodeB también puede almacenar el segmento TCP asociado con el DUP ACK recibido en el caso de que tal segmento pueda necesitar ser retransmitido. Además, el procesador TCP también puede evitar enviar el DUP ACK al remitente TCP, que también puede evitar que el remitente TCP determine que hay cogestión y, como consecuencia, reducir el valor ssthresh. En algunas implementaciones, si un número predeterminado de DUP ACKs (por ejemplo, tres) es recibido y RTT no ha expirado para un segmento TCP particular, el eNodeB no retransmitirá el segmento. En algunas implementaciones, si un NACK explícito es recibido desde la capa 2 en el eNodeB para un segmento TPC particular, ese segmento TPC puede ser retransmitido de forma forzada por el eNodeB. Si el segmento TPC es almacenado en el eNodeB, entonces el eNodeB puede retransmitir el segmento al equipo de usuario.
En algunas implementaciones, el procesador TPC en el eNodeB puede recibir una información de retroalimentación HARQ/ARQ procedente de la Capa 2 asociada con el equipo de usuario. La información de retroalimentación HARQ/ARQ puede ser indicativa de si un paquete particular fue trasmitido exitosamente al equipo de usuario o no. En base a la información de retroalimentación HARQ/ARQ recibida, el procesador TPC puede determinar si existe o no la necesidad de retransmitir un segmento TPC particular. La información de retroalimentación HARQ/ARQ puede ser utilizada en lugar de y/o junto con la recepción de tres DUP ACKs para determinar si puede ser requerida o no una retransmisión de un segmento particular.
La Fig. 10 ilustra un diagrama de flujo 1000 a modo de ejemplo que muestra la capacidad del eNodeB 1004 del sistema de la materia objeto actual para reducir transmisiones duplicadas de paquetes de datos, de acuerdo con algunas implementaciones de la materia objeto actual. El proceso 1000 puede empezar por el servidor 1006 enviando paquetes de datos (llevando el número de secuencia X) al equipo de usuario 1002 por medio del eNodeB 1004. Después de la recepción de estos paquetes de datos, el equipo de usuario 1002 puede entonces enviar un acuse de recibo (llevando el acuse de recibo ACK = X) al servidor por medio del eNodeB 1004. El eNodeB 1004 puede determinar si existe una coincidencia con la información RLC-ARQ y MAC-HARQ, en 1008. Si el servidor 1006 fracasa en recibir un ACK procedente del equipo de usuario 1002, el servidor retransmite los mismos paquetes de datos, en 1010. Después de determinar que existe una coincidencia de información RLC-ARQ y MAC-HArQ o un acuse de recibo (llevando el acuse de recibo ACK = X) y la recepción de paquetes de datos retransmitidos procedentes del servidor 1006, el eNodeB 1004 puede suprimir en el envío de paquetes de datos retransmitidos al equipo de usuario 1002 y en su lugar, enviar un acuse de recibo (ACK = X) al servidor 1006 indicando que los paquetes de datos originales fueron recibidos por el equipo de usuario 1002. Este paquete de datos (que lleva el número de secuencia X) puede ser enviado solo una vez desde el eNodeB, conservando con ello los recursos de radio asociados con la conexión entre el equipo de usuario 1002 y el eNodeB 1004.
En algunas implementaciones, el sistema de la materia objeto actual puede utilizar la información de expiración de ida y vuelta ("RTO") para determinar si puede ser requerida o no una retransmisión de un segmento TPC particular. La información RTO puede ser determinada en base a la expiración del RTT asociado con los segmentos TCP. Únicamente con fines ilustrativos, se supone que una pluralidad de segmentos TCP son transmitidos al equipo de usuario y es recibida una indicación en el eNodeB de que uno de los segmentos TCP ("segmento A)" podría haber sido perdido. Un DUP ACK para el siguiente segmento TCP ("segmento B") es generado. El procesador TCP (por ejemplo, el procesador TCP 508 mostrado en la Fig. 5) puede almacenar el segmento A y esperar la recepción de tres ACKs antes de retransmitir el segmento A desde su búfer (por ejemplo, el búfer 510 mostrado en la Fig. 5). El procesador TCP en el eNodeB también puede mantener el rastreo de la información RTT indicativa de las transmisiones de segmento TCP y puede retransmitir los segmentos TCP después de que RTT haya expirado.
En algunas implementaciones, el RTO puede ser determinado en base a la información RTT asociada con el último segmento TCP que ha sido retransmitido al equipo de usuario y los valores de desviación estándar asociados con un RTT esperado para una comunicación particular entre el eNodeB y los equipos de usuario.
La Fig. 11 ilustra un proceso a modo de ejemplo 1100 para determinar una espiración de tiempo de ida y vuelta para un enlace de comunicación particular entre un equipo de usuario y un eNodeB (como se muestra por ejemplo en la Fig. 5), de acuerdo con algunas implementaciones de la materia objeto actual. En 1102, el procesador TCP (por ejemplo, el procesador TCP 508 como se muestra en la Fig. 5) puede obtener y/o medir un valor de tiempo de ida y vuelta de muestra ("rttM") asociado con la trasmisión de paquetes TCP en un enlace de comunicaciones entre el eNodeB y un equipo de usuario. El rttM puede ser determinado en base a una diferencia de tiempo entre un tiempo de recepción de un ACK ("Trecepción ") y un tiempo de muestra de enviar un paquete TCP al equipo de usuario ( Tenvío ).
rttM — dif (Trecepción, Tenvío) (1)
En 1104, a un valor de desviación estándar ("rttD") puede ser determinado para los tiempos de ida y vuelta asociados con el enlace de comunicaciones entre el eNodeB y el equipo de usuario. El rttD puede ser determinado utilizando el valor del valor de desviación estándar existente ("rttDexstente), que puede haber sido calculado previamente para otros paquetes de datos en el enlace de comunicación, y una diferencia absoluta entre el tiempo de y devuelta suavizado ("rttS") y el rttM. El rrtD puede ser determinado en base a lo siguiente:
rttD — a*rttD p*\rttS- rttM\ (2)
en donde a ¡5 — 1, y a y 5 pueden ser determinados experimentalmente para un enlace de comunicaciones particular. En algunas implementaciones, a > p. únicamente con fines ilustrativos, a = 0,75 y p = 0,25. Son posibles otros valores.
El tiempo de ida y vuelta suavizado puede ser determinado en base al valor existente del tiempo de ida y vuelta suavizado ("rrtSexistente)" y un valor medido, en 1106, utilizando lo siguiente:
rttS — Y*rttSexistente + 5*rttM (3)
en donde y 6 = 1, y Y y 5 pueden ser determinados experimentalmente para un enlace de comunicaciones particular. En algunas implementaciones, Y > p. Únicamente con fines ilustrativos, y = 0,875 y p = 0,125. Son posibles otros valores.
El valor de expiración de ida y vuelta ("rttO)" puede ser determinado en base al valor de tiempo de ida y vuelta suavizado y el valor de desviación estándar calculado, en 1108, como sigue:
rttO — rttS e*rttD (4)
en donde £ puede ser determinado experimentalmente para un enlace de comunicaciones particular. En algunas implementaciones y únicamente con fines ilustrativos, £ = 4. Son posibles otros valores.
En algunas implementaciones, para la primera muestra, rttS — 0 y rttD — rttM/2. Como se puede entender, se pueden utilizar otros valores basados en los requerimientos, condiciones, equipo de usuario particular, eNodeB, transmisiones, etc., en el enlace de comunicación entre el eNodeB y el equipo de usuario.
En algunas implementaciones, utilizando el valor de expiración de ida y vuelta, el procesador TCP en el eNodeB puede determinar si retransmite o no un segmento TCP particular almacenado. El procesador TCP puede utilizar la expiración de ida y vuelta determinada sola en esta determinación para retransmitir o no un segmento TCP particular, y/o en combinación recibir un número predeterminado de DUP ACKs y/o valores particulares del tiempo de ida y vuelta, y/o recibir un ACK/NACK procedente de la capa 2.
En algunas implementaciones, en procesador TCP en el eNodeB puede recibir un NACK, que puede indicar que un segmento TCP correspondiente al NACK no alcanzó el equipo de usuario. Si es recibido dicho NACK desde el búfer del eNodeB. En algunas implementaciones, después de determinar que una retransmisión de un segmento es requerida, el procesador TCP en el eNodeB también puede asignar una prioridad más elevada (por ejemplo, colocar un identificador de prioridad elevada en el encabezado del paquete) al paquete retransmitido y programar su retransmisión delante de otros paquetes. En algunas implementaciones, el paquete retransmitido que lleva la prioridad más elevada puede ser retransmitido antes que el tiempo de ida y vuelta para ese enlace de comunicaciones.
De este modo, la materia objeto actual puede permitir el almacenamiento de segmentos TCP y la determinación de qué segmentos necesitan ser retransmitidos, protegiendo por tanto el servidor de envío TCP de la retransmisión innecesaria de paquetes y de la reducción de la ventana de congestión. Como se ha establecido anteriormente, esto se puede realizar mediante un componente de inteligencia de aplicación de una estación base (por ejemplo, como se muestra en la Fig. 5, el procesador TCP 508 en el eNodeB 504) que puede utilizar indicador de calidad de canal ("CQI"), información de retroalimentación HARQ/ARQ (que incluye información BLER) desde los componentes de la capa 2, información de tiempo de ida y vuelta promedio para el envío de segmentos TCP, número de DUP ACKs que recibe, una recepción de un NACK, una información de expiración de tiempo de ida y vuelta, y/o cualquier otra información para determinar si es retransmitido o no un segmento TCP particular. La capa de inteligencia de aplicación puede retransmitir automáticamente un paquete después de verificar que se cumplen ciertas condiciones. Éstas pueden incluir, pero no están limitadas a, una preselección de un número predeterminado de DUP ACKs, una recepción de NACK, a una determinación de un RTO particular, y/o cualesquiera otras. Las retransmisiones pueden ocurrir automáticamente, manualmente, y/o ambas. Eliminando retransmisiones innecesarias, la materia objeto actual puede mejorar la calidad del servicio ("QoE") e incrementar la capacidad de transmisión.
B. Adaptación del Tamaño de Ventana de Recepción
En algunos casos, enviando demasiados paquetes, el remitente TCP (por ejemplo, un servidor TCP) puede hacer que un búfer del eNodeB (por ejemplo, el búfer 510 del eNodeB 504 como se muestra la Fig. 5) se desborde. Esto puede ocurrir a la vista de que el búfer tenga una cantidad limitada de espacio (o una ventana de recepción ("R-WND")) que puede alojar paquetes entrantes procedentes del remitente TCP.
La Fig. 12 ilustra un ejemplo de un sistema de comunicación 1200 que puede resolver una situación de desbordamiento de búfer, de acuerdo con algunas implementaciones de la materia objeto actual. El sistema 1200 puede incluir un equipo de usuario 1202, una estación base 1204 (por ejemplo, un eNodeB), y un servidor TCP 1206. El equipo de usuario 1202 puede comunicar con el eNodeB 1204 por medio del enlace de comunicaciones 1210. El eNodeB 1204 puede comunicar con el servidor TCP 1206 por medio del enlace de comunicaciones 1212. El servidor TCP 1206 puede enviar paquetes TCP al eNodeB 1204 para la transmisión al equipo de usuario 1202. El eNodeB 1204 puede almacenar los paquetes en un búfer 1214. Como se muestra en la Fig. 12, aunque los paquetes TCP 1220 pueden ser almacenados en el búfer 1214, otros paquetes TCP 1222 pueden ser expulsados en vista de que el buffer 1214 esté desbordado (por ejemplo, no teniendo suficiente memoria para almacenar los datos). El desbordamiento del búfer puede estar causado por las condiciones de los enlaces de comunicación (por ejemplo, CQI, etc.), por la incapacidad del equipo de usuario para manejar cierta cantidad de datos (por ejemplo, anchura de banda del equipo de usuario), por la falta de espacio utilizable en el búfer del eNodeB, etc. Los paquetes 1222 pueden ser desechados por fallo al ser almacenados en el búfer 1214. Tal desecho puede indicar pérdida de paquetes, que puede hacer que el servidor TCP 1206 determine que existe congestión.
En algunas implementaciones, para evitar el desbordamiento del búfer, el procesador TCP 1206 puede estar provisto de información de informe de estado de buffer ("BSR") del búfer de la capa inferior (por ejemplo, el búfer RLC/MAC de la Capa 2), que puede indicar si el búfer 1214 puede aceptar o no una cantidad particular de datos que están siendo enviados por el servidor 1206. El informe de estado de búfer puede ser proporcionado por los componentes de las Capas inferiores tales como los componentes de la Capa 2 del eNodeB 1204. El informe del estado del búfer puede ser utilizado para determinar una anchura de banda asociada con el equipo de usuario particular y un umbral de ocupación de buffer (que puede estar basado en la anchura de banda determinada asociada con el equipo de usuario) para el búfer 1214 del procesador TCP. En algunas implementaciones, diferentes umbrales de ocupación de búfer pueden ser establecidos para diferentes paquetes de prioridad. Una vez que el valor(es) del umbral(es) de ocupación de búfer es determinado, la información puede ser proporcionada por el eNodeB 1208 al servidor TCP 1206 junto con un ACK de que una transmisión particular de segmentos TCP procedentes del servidor TCP 1206 ha sido recibida por el eNodeB 1204. Esta información puede indicar al servidor TCP 1206 que el eNodeB 1204 tiene una ventana de recepción particular ("R-WND"), más allá de la cual se puede producir un desbordamiento del búfer. Esto puede permitir que el servidor TCP 1206 modere la cantidad de datos que están siendo enviados al eNodeB 1204.
La R-WND puede ser determinada utilizando un tiempo de ida y vuelta ("rft") asociado con un enlace de comunicación entre el equipo de usuario 1202 y el eNodeB 1204. La determinación también puede utilizar una velocidad de enlace promedio ("Renlace"), que puede ser proporcionada por el componente PDCP del eNodeB 1204 y determinada en base a una velocidad a la cual el búfer es limpiado por los componentes MAC/RLC del eNodeB 1204. La R-WND también puede estar basada en un parámetro de control de cola ("Qcontrol") que puede ser determinado en base al enlace de comunicaciones particular, y un máximo tamaño de cola por portador ("Qmax"), que puede estar basado en el tamaño de cola total. Únicamente para fines ilustrativos, Qcontrol = 2. Son posibles otros valores. El número total de bytes almacenado ("Tbúfer"), que puede ser determinado en base a una combinación de tamaños de búfer de los búferes en el componente PDCP (como se muestra la Fig. 12) y el búfer 1214, y un número de flujo de trasmisión activos ("Nactivo") también puede ser utilizado para determinar la R-WND. De este modo, la R-WND puede ser determinada por utilizando lo siguiente:
R-WND — (rtt * (Renlace + (Qcontrol * (Qmax - Tbúfer)))) / Nactivo (5)
La R-WND determinada puede ser suministrada al servidor TCP 1206. El servidor TCP 1206 puede ajustar la cantidad de datos que está siendo enviada al equipo de usuario por medio del eNodeB. Éste puede eliminar perdidas de paquetes, mantener los tiempos de ida y vuelta consistentes para transmisiones de paquete TCP, así como mantener un caudal que paquetes TCP constante desde el servidor TCP hasta el equipo de usuario y por medio del eNodeB.
C. Programador consciente del estado TCP
Una de las funciones del eNodeB 106 relacionadas con la Capa 3 de la Fig. 1C es la gestión de recursos de radio ("RRM"), que incluye programar tanto los recursos de interfaz de enlace de subida como de enlace de bajada para el equipo de usuario 104, controlar los recursos de portador, y el control de admisión. La función RRM asegura un uso eficiente entre los recursos de red disponibles. En particular, RRM en E-UTRAN gestiona (por ejemplo, la ME y asigna, reasigna, y libera) los recursos de radio en ambientes de una única celda y de múltiples celdas. RRM es tratada como una aplicación central en el eNodeB responsable del trabajo entre diferentes protocolos de manera que los mensajes son transferidos adecuadamente a los diferentes nodos a través de las interfaces Uu, S1 y X2. La RRM interactúa con funciones de operación y gestión para controlar, monitorizar, auditar, o resetear los estados debido a errores en una pila de protocolos.
La RRM incluye módulos para el control de portador de radio ("RBC"). El módulo funcional RBC gestiona el establecimiento, mantenimiento, y liberación de los portadores de radio. La RRM incluye también módulos para el control de movilidad de conexión ("CMC"). El módulo CMC gestiona los recursos de radio en los modos inactivo y conectado. En el modo inactivo, este módulo define criterios y algoritmos para la selección de celdas, reselección, y registro de ubicación que ayuda al equipo de usuario a seleccionar o establecerse en la mejor celda. Además, el eNodeB difunde parámetros que configuran la gestión de equipo de usuario e informa de procedimientos. En el modo conectado, este módulo gestiona la movilidad de las conexiones de radio sin perturbar los servicios.
La RRM también incluye módulos para la asignación dinámica de recursos ("DRA") y/o programación de paquetes ("PS"). La tarea de DRA y PS es asignar y desasignar recursos (que incluyen bloques de recursos físicos) al usuario y a los paquetes del plano de control. La función de programación típicamente considera los requisitos QoS asociados con los portadores de radio, la retroalimentación de calidad de canal procedente de los equipos de usuario, el estado del búfer, la condición de interferencia entre celdas/en una misma celda, y similares. La función DRA tiene en cuenta las restricciones o preferencias en algunos de los bloques de recursos disponibles o conjuntos de bloques de recursos debido a consideraciones de coordinación de interferencia entre celdas ("ICIC").
La red de acceso de radio que incluye el eNodeB dispuesto en la misma es responsable del manejo de toda la funcionalidad relacionada con la radio incluyendo la programación de recursos de radio. La red troncal es responsable de encaminar las llamadas y las conexiones de datos con las redes externas.
El programador en el eNodeB es generalmente responsable de asignar recursos de radio a todos los equipos de usuario y portadores de radio tanto en el enlace de subida como en el enlace de bajada. El programador en el eNodeB asigna bloques de recurso (que son los elementos más pequeños de la asignación de recursos) a los usuarios durante unas cantidades de tiempo predeterminadas.
Los paquetes de datos en una red de comunicación corresponden a diferentes aplicaciones que tienen diferentes, y en algunos casos, formatos no estandarizados para la carga útil de datos subyacente. Sin conocimiento de la carga útil de paquete de datos, y su aplicación correspondiente, la coordinación de comunicación de un paquete de datos es proporcionada de una forma genérica. En un eNodeB, la asignación de bloques de recursos se produce aproximadamente en intervalos de 1 ms. La detección de datos de paquete y las correspondientes aplicaciones fuera del eNodeB, tales como utilización de servicios en la red troncal o en el dispositivo de usuario, no puede tener en cuenta de forma precisa los cambios en las condiciones del canal que se producen en los intervalos de 1 ms en los que el eNodeB asigna bloques de recurso. Por ejemplo, un eNodeB puede decidir el tipo de mecanismo de codificación de modulación para una transmisión de paquetes de datos, por ejemplo, utilizando modulación de amplitud de cuadratura QAM - que incluye 16-QAM, 64-QAM, o similares) y/o modulación de desplazamiento de fase de cuadratura (QPSK) cada 1 ms. Tales decisiones están basadas en las condiciones del canal presentes durante la rebanada del tiempo en el que la estación base está asignando los bloques de recurso.
En algunas implementaciones, con el fin de asignar de forma precisa bloques de recurso en base a las condiciones de canal en tiempo real en la estación pase, el eNodeB incluye un módulo y/o procesador para inspeccionar el paquete de datos, que incluye el tipo de aplicación del paquete de datos, y un modelo y/o procesador para programar y asignar bloques de recurso.
La Fig. 13 ilustra un sistema a modo de ejemplo 1300 que incluye un eNodeB 1306 para coordinar la comunicación entre un equipo de usuario 1304 y una red troncal 1308, de acuerdo con algunas implementaciones de la materia objeto actual. El eNodeB 1306 puede corresponder con un eNodeB mostrado y descrito anteriormente con referencia la Fig. 3. En el caso de arquitectura C-RAN, tal como la mostrada en la Fig. 3, el eNodeB 1306 puede corresponder con una unidad de banda base inteligente 304. El eNodeB 1306 puede incluir un procesador de inspección de paquetes 1360, un procesador de programación de paquetes 1362, y una memoria 1364. Aunque se muestran como componentes separados en la Fig. 13, el procesador de inspección de paquetes 1360, un procesador de programación de paquete 1362, y la memoria 1364 pueden estar integrados en uno o más componentes de procesamiento. En algunas implementaciones, el procesador de inspección de paquetes 1360 y el procesador de programación de paquete 1362 pueden ser proporcionados como módulos de software en un procesador que está específicamente programado para implementar las funciones descritas en la presente memoria con referencia a estos procesadores.
En algunas implementaciones, el procesador de inspección de paquetes 1360 puede realizar una inspección de paquetes en cada paquete de datos que es transmitido entre el equipo de usuario 1304 y la red troncal 1308 con el fin de determinar, por ejemplo, el tipo de aplicación del paquete de datos. Un tipo de aplicación puede corresponder a, por ejemplo, audio, video, correo electrónico, y/o cualquier otro tipo. El procesador de inspección de paquetes 1360 comunica el tipo de aplicación detectada y/o otra información que es enviada desde el paquete de datos al procesador de programación de paquetes 1362. El procesador de programación de paquetes 1362 puede asignar bloques de recursos en base a los ajustes para definidos almacenados en la memoria 1364 correspondientes a la información detectada a través de la inspección del paquete de datos y en base a las condiciones de canal del enlace de comunicación con el equipo de usuario y/o la red troncal.
El procesador de programación de paquete 1362 puede tener en cuenta el tipo de aplicación, el tamaño del archivo asociado con el paquete de datos, el proveedor del contenido, el tipo de dispositivo de usuario o información de perfil asociada con el usuario, requisitos QoS para el paquete de datos, una indicación de calidad de canal ("CQI") determinada por el eNodeB 1306, un informe de estado del búfer ("BSR") del búfer del eNodeB, un informe del margen de potencia ("PHR"), y/o una prioridad predefinida para el contenido correspondiente al contenido de paquete de datos.
Haciendo de nuevo referencia las Figs. 2 y 3, el procesador de inspección de paquete 1360 puede corresponder con una función que es parte de las funciones de la capa 3 en la estación base 106, 306. En algunas implementaciones, el procesador de inspección de paquete 1360 también puede estar dispuesto en una capa funcional separada de las capas funcionales descritas con referencia las Figs. 2 y 3.
El procesador de inspección de paquete 1360 se puede comunicar y coordinarse con otras funciones realizadas por la estación base 1306. Por ejemplo, el procesador discreción de paquete 1360 se puede coordinar con las funciones de gestión de recursos de radio descritas anteriormente con referencia la Fig. 2.
En algunas implementaciones, el procesador de programación de paquete 1362 puede estar dispuesto en la capa 2 de la estación base como se muestra en las Figs. 2 y 3. En algunas implementaciones en las que las funciones de la capa 2 están subdivididas entre la iBBU 306 y la iRRHs 302, el procesador de programación de paquete 1362 también puede ser implementado como parte de las funciones de la capa 2 que permanecen con la iBBU 306. El procesador de programación de paquete 1362 también puede estar dispuesto en una capa funcional separada de las capas funcionales descritas con referencia a las Figs. 2 y 3. El procesador de programación de paquete 1362 puede estar configurado para comunicar y coordinarse con otras funciones realizadas por la estación base 1306. En algunas implementaciones, el procesador de programación de paquete 1362 puede coordinarse con la capa MAC, y en particular, con un gestor de solicitud de repetición automática híbrida ("HARQ") de la capa MAC, así como, con una capa física de la estación base.
En algunas implementaciones, el procesador de programación 1360 en el eNodeB 1306 también determina al estado de las transmisiones de datos TCP, al realizar control de la ventana inicial, de la ventana de recepción, y de la ventana de congestión, realiza el ensamblado TCP en el eNodeB 1306, a incluye un modelo de menos clientes para aplicabilidad máxima, reduce los desplazamientos de ida y vuelta por página de datos, permite la interpretación progresiva, y paraliza la obtención de datos (por ejemplo, objetos web).
En algunas implementaciones, la materia objeto actual puede estar configurada para ser implementada en un sistema 1400, como se muestra la Fig. 14. El sistema 1400 puede incluir uno o más de un procesador 1410, una memoria 1420, un dispositivo de almacenamiento 1430, y un dispositivo de entrada/salida 1440. Cada uno de los componentes 1410, 1420, 1430 y 1440 pueden estar interconectados utilizando un bus de sistema 1450. El procesador 1410 puede estar configurado para procesar instrucciones para la ejecución dentro del sistema 600. En algunas implementaciones, el procesador 1410 puede ser un procesador de hilo único. En implementaciones alternativas, el procesador 1410 puede ser un procesador de múltiples hilos. El procesador 1410 puede estar además configurado para procesar instrucciones almacenadas en la memoria 1420 o en el dispositivo de almacenamiento 1430, incluyendo información de recepción o envío a través del dispositivo de entrada/salida 1440. La memoria 1420 puede almacenar información dentro del sistema 1400. En algunas implementaciones, la memoria 1420 puede ser un medio leíble por ordenador. En realizaciones alternativas, la memoria 1420 puede ser una unidad de memoria volátil. En todavía algunas implementaciones, la memoria 1420 puede ser una unidad de memoria no volátil. El dispositivo de almacenamiento 1430 puede ser capaz de proporcionar almacenamiento en masa para el sistema 1400. En algunas implementaciones, el dispositivo de almacenamiento 1430 puede ser un medio leíble por un ordenador. En implementaciones alternativas, el dispositivo de almacenamiento 1430 puede ser un dispositivo de disco blando, un dispositivo de disco duro, un dispositivo de disco óptico, un dispositivo de cinta, una memoria de estado sólido no volátil, o cualquier otro tipo de dispositivo de almacenamiento. El dispositivo de entrada/salida 1440 puede estar configurado para proporcionar operaciones de entrada/salida para el sistema 1400. En algunas implementaciones, el dispositivo de entrada/salida 1440 puede incluir un teclado y/o un dispositivo de puntero. En realizaciones alternativas, el dispositivo de entrada/salida 1440 puede incluir una unidad de presentación para presentar interfaces de usuario gráficas.
La Fig. 15 ilustra un método 1500 a modo de ejemplo para la transmisión de paquetes de datos entre un dispositivo de usuario y un servidor, de acuerdo con algunas implementaciones de la materia objeto actual. El método 1500 puede ser realizado utilizando una estación base (por ejemplo, un eNodeB como se ha descrito anteriormente y mostrado en las Figs. 3-14). En 1502, un enlace de comunicación puede ser establecido entre el dispositivo de usuario y el servidor de acuerdo con un protocolo de control de transmisión para la transmisión de un paquete de datos entre el dispositivo de usuario y el servidor. En 1504, el paquete de datos puede ser transmitido utilizando el protocolo de control de transmisión. Al menos uno del establecimiento y la transmisión puede ser realizado utilizando al menos un procesador de al menos un sistema de ordenador.
En algunas implementaciones, la materia objeto actual puede incluir una o más de las siguientes características opcionales. Una estación base de nodo evolucionado (eNodeB) puede realizar operaciones del método 1500, en donde la estación base de eNodeB puede incluir el al menos un procesador y la al menos una memoria.
En algunas implementaciones, el método puede incluir además almacenar, utilizando la al menos una memoria de la estación base, paquetes de datos recibidos desde servidor, los paquetes de datos almacenados incluyen al menos un paquete de datos de protocolo de control de trasmisión (TCP). El método puede incluir además transmitir, utilizando el al menos un procesador de la estación base, al menos un paquete de datos almacenado en la al menos una memoria desde la estación base al dispositivo de usuario. El método también puede incluir retransmitir, utilizando el al menos un procesador de la estación base, al menos un paquete de datos almacenado en la al menos una memoria desde la estación base al dispositivo de usuario. En algunas implementaciones, el método puede incluir recibir, utilizando el al menos un procesador de la estación base, al menos un acuse de recibo procedente del dispositivo de usuario que indica que el al menos un paquete de datos ha sido recibido por el dispositivo de usuario. En algunas implementaciones, el método también puede incluir recibir, utilizando el al menos un procesador de la estación base, al menos un acuse de recibo duplicado procedente del dispositivo de usuario que indica que el al menos un paquete de datos ha sido recibido por el dispositivo de usuario, y retransmitir, después de recibir un número predeterminado de acuses de recibo duplicados procedentes del dispositivo de usuario, utilizando el al menos un procesador de la estación base, el al menos un paquete de datos almacenado en la al menos una memoria del dispositivo de usuario.
En algunas implementaciones, el método también puede incluir recibir, utilizando el al menos un procesador de la estación base, al menos un acuse de recibo negativo procedente de la capa inferior del eNodeB que indica que el al menos un paquete de datos no ha sido recibido por el dispositivo de usuario, retransmitir, después de recibir el acuse de recibo negativo procedente de la capa inferior del eNodeB, utilizando el al menos un procesador, el al menos un paquete de datos almacenado en la al menos una memoria del dispositivo de usuario. El acuse de recibo negativo puede ser generado por al menos uno de los siguientes: una capa de protocolo de convergencia de datos de paquete (PDCP) del eNodeB, una capa de control de acceso al medio (MAC) del eNodeB, y una capa de control de enlace de radio (RLC) del eNodeB.
En algunas implementaciones, el método puede incluir determinar, utilizando el al menos un procesador de la estación base, una información de tiempo de ida y vuelta para el al menos un paquete de datos, la información de tiempo de ida y vuelta incluye el tiempo empleado por una transmisión de la al menos un paquete de datos hasta el dispositivo de usuario y una transmisión de un acuse de recibo por el dispositivo de usuario indicativo de la recepción de paquete de datos; y retransmitir, en base al tiempo de ida y vuelta determinado, utilizando el al menos un procesador de la estación base, el al menos un paquete de datos almacenado en la al menos una memoria al dispositivo de usuario.
En algunas implementaciones, el método también puede incluir retransmitir, utilizando el al menos un procesador de la estación base, el al menos un paquete de datos almacenado en la al menos una memoria al dispositivo de usuario utilizando indicación de prioridad alta.
En algunas implementaciones, el al menos un procesador de la estación base puede evitar la retransmisión del paquete de datos desde el servidor al dispositivo de usuario después de que el servidor fracase en la recepción de un acuse de recibo procedente del dispositivo de usuario dentro de un período de tiempo predeterminado. El procesador de la estación base puede enviar al servidor el acuse de recibo que indica la recepción del paquete de datos por el dispositivo de usuario después de que el procesador envíe un paquete de datos de solicitud de repetición automática híbrida (HARQ) al dispositivo de usuario, y la recepción, como respuesta al envío, de una confirmación procedente del dispositivo de usuario de que el paquete de datos fue recibido por el dispositivo de usuario.
En algunas implementaciones, el procesador de estación base puede enviar al servidor un acuse de recibo que indica la recepción del paquete en datos por el dispositivo el usuario después de recibir una confirmación de que el paquete de datos fue recibido por el dispositivo de usuario, siendo la confirmación generada por al menos uno de los siguientes: una capa de control de acceso al medio (MAC) del eNodeB, una capa de protocolo de convergencia de datos de paquete (PDCP) del eNodeB, y una capa de control de enlace de radio (RLC) del eNodeB.
En algunas implementaciones, el procesador de estación base puede programar la transmisión del paquete de datos desde el servidor al dispositivo de usuario utilizando el protocolo de control de trasmisión. El procesador de estación base puede realizar la evitación de la congestión en el enlace de comunicación durante la transmisión del paquete de datos utilizando el protocolo de control de trasmisión.
En algunas implementaciones, el procesador de estación base puede determinar un tamaño total de paquetes de datos que puede ser recibido por la estación base, y puede proporcionar una indicación del tamaño total determinado al servidor. El tamaño total de los paquetes de datos puede ser determinado en base a al menos uno de lo siguiente: un umbral de almacenamiento de la al menos una memoria, una capacidad actual de la al menos una memoria en base a los datos existentes almacenados en la al menos una memoria, una intensidad de una señal de radio existente entre el dispositivo de usuario y la estación base de eNodeB, una calidad de una señal de radio existente entre el dispositivo de usuario y la estación base de eNodeB, una velocidad de bit calculada de los datos que se desplazan entre el dispositivo de usuario y el eNodeB en base a al menos un informe de estado del búfer desde al menos uno de lo siguiente: una capa de control de acceso al medio (MAC) del eNodeB, una capa de protocolo de convergencia de datos de paquete (PDCP), una capa de control de enlace de radio (RLC), y una capacidad del dispositivo de usuario para recibir paquetes de datos que tienen un tamaño predeterminado.
Los sistemas y métodos descritos en la presente memoria pueden ser llevados a la práctica de distintas formas que incluyen, por ejemplo, un procesador de datos, tal como un ordenador que también incluye una base de datos, circuitos electrónicos digitales, firmware, software, o combinaciones de los mismos. Además, las características anteriormente mencionadas y otros aspectos y principios de las presentes implementaciones descritas pueden ser implementados en diversos entornos. Tales entornos y aplicaciones relacionadas pueden ser construidos fácilmente para realizar los diversos procesos y operaciones de acuerdo con las implementaciones descritas o pueden incluir un ordenador de finalidad general o una plataforma de computación selectivamente activada o reconfigurada por código para proporcionar la funcionalidad necesaria. Los procesos descritos en la presente memoria no están referidos inherentemente a cualquier ordenador, red, arquitectura, entorno, u otro aparato particulares, y pueden ser implementados mediante una combinación adecuada de hardware, software, y/o firmware. Por ejemplo, varias máquinas de finalidad general pueden ser utilizadas con programas escritos de acuerdo con las enseñanzas de las implementaciones descritas, o puede ser más conveniente construir un aparato o sistema especializado para realizar los métodos y técnicas requeridos.
Los sistemas y métodos descritos en la presente memoria pueden ser implementados como un producto de programa de ordenador, es decir, un programa de ordenador encarnado tangiblemente en un portador de información, por ejemplo, en un dispositivo de almacenamiento leíble por una máquina o en una señal programada, para la ejecución por, o para controlar la información de, el aparato de procesamiento de datos, por ejemplo, un procesador programable, un ordenador, o múltiples ordenadores. Un programa de ordenador puede ser escrito en cualquier forma de lenguaje de programación, incluyendo lenguajes compilados o interpretados, y puede ser desplegado de cualquier forma, incluyendo un programa independiente o como un módulo, componente, subrutina, u otra unidad adecuada para ser utilizado en un entorno de computación. Un programa de ordenador puede ser desplegado para ser ejecutado en un ordenador o en múltiples ordenadores en una ubicación o múltiples ubicaciones distribuidas e interconectados mediante una red de comunicación.
Como se ha utilizado la presente memoria, el término "usuario" se puede referir a cualquier entidad que incluye una persona o un ordenador.
Aunque los números ordinales tales como primero, segundo, y similares, pueden en algunas situaciones, referirse a un orden, como se ha utilizado en este documento los números ordinales no necesariamente implican un orden. Por ejemplo, los números ordinales pueden ser utilizados únicamente para distinguir un artículo de otro. Por ejemplo, para distinguir un primer evento de un segundo evento, pero no necesariamente implican una ordenación cronológica o un sistema de referencia fijo (de manera que un primer evento en un párrafo de la descripción puede ser diferente de un primer evento en otro párrafo de la descripción).
La descripción anterior está destinada a ilustrar pero no a limitar el campo de la invención, que está definido por el alcance de las reivindicaciones adjuntas. Otras implementaciones están dentro del campo de las siguientes reivindicaciones.
Estos programas de ordenador, que también pueden ser referidos como programas, software, aplicaciones de software, aplicaciones, componentes, o código, incluyen instrucciones de máquina para un procesador programable, y pueden ser implementados en un lenguaje de programación de procedimiento de alto nivel y/o orientados a un objeto, y/o el lenguaje de ensamblado/máquina. Como se ha utilizado en la presente memoria, el término "medio leíble por una máquina" se puede referir a cualquier producto de programa de ordenador, aparato y/o dispositivo, tal como por ejemplo discos magnéticos, discos ópticos, memoria, y dispositivos lógicos programables (PLDs), utilizados para proporcionar instrucciones y/o datos de máquina a un procesador programable, que incluye un medio leíble por una máquina que recibe las instrucciones de máquina como una señal leíble por una máquina. El término "señal leíble por una máquina" se refiere a cualquier señal utilizada para proporcionar instrucciones y/o datos de máquina a un procesador programable. El medio leíble por una máquina puede almacenar tales instrucciones de máquina de forma no transitoria, tal como por ejemplo una memoria de estado sólido no transitoria o un disco duro magnético o cualquier medio de almacenamiento equivalente. El medio leíble por una máquina puede almacenar alternativamente o adicionalmente tales instrucciones de máquina de una manera transitoria, tal como por ejemplo como sería un caché de procesador u otra memoria de acceso aleatorio asociada con uno o más y núcleos de procesador físicos.
Para proporcionar interacción con el usuario, la materia objeto descrita en la presente memoria puede ser implementada en un ordenador que tenga un dispositivo de pantalla, tal como por ejemplo un tubo de rayos catódicos (CRT), o un monitor de pantalla de cristal líquido (LCD) para presentar la información al usuario y un teclado y un dispositivo de puntero, tal como por ejemplo un ratón o una bola de desplazamiento, mediante el cual el usuario puede proporcionar datos de entrada al ordenador. Pueden ser utilizados también otros tipos de dispositivos para proporcionar interacción con el usuario. Por ejemplo, la retroalimentación proporcionada al usuario puede ser cualquier forma de retroalimentación sensorial, tal como por ejemplo retroalimentación visual, retroalimentación auditiva, o retroalimentación táctil; y los datos de entrada procedentes del usuario pueden ser recibidos de cualquier forma, que incluye, pero no se limita a, entradas de datos acústicas, de voz, o táctiles.
La materia objeto descrita en la presente memoria puede ser implementada en un sistema de computación que incluye un componente de soporte, tal como por ejemplo uno o más servidores de datos, o que incluye un componente de middleware, tal como por ejemplo uno o más servidores de aplicación, o que incluye un componente de extremo delantero, tal como por ejemplo uno o más ordenadores de cliente que tienen interfaz de usuario gráfica o un navegador de web a través del cual un usuario puede interactuar con una implementación de la materia objeto descrita la presente memoria, o cualquier combinación tal como componentes de soporte, de middleware, componentes de extremo delantero. Los componentes del sistema pueden estar interconectados mediante cualquier forma o medio de comunicación de datos digital, tal como por ejemplo una red de comunicación. Ejemplos de redes de comunicación incluyen, pero no se limitan a, una red de área local ("LAN"), una red de área amplia ("WAN)", o Internet.
El sistema de computación puede incluir clientes y servidores. Un cliente y un servidor están generalmente, pero no exclusivamente, remotos uno respecto al otro y típicamente interactúan a través de una red de comunicación. La relación del cliente y el servidor surge por medio de programas de ordenador que se ejecutan en los respectivos ordenadores y que tienen una relación cliente-servidor entre sí.
Las implementaciones expuestas en la descripción anterior no representan todas las implementaciones acordes con la materia objeto descrita en la presente memoria. En su lugar, únicamente son ejemplos de acuerdo con aspectos relacionados con la materia objeto descrita. Aunque han sido descritas anteriormente con detalle unas pocas variaciones, son posibles otras modificaciones o adiciones.
Por ejemplo, las implementaciones descritas anteriormente pueden estar dirigidas a las diversas combinaciones o subcombinaciones de las características y/o combinaciones y subcombinaciones descritas de diversas características adicionales descritas anteriormente. Además, los flujos lógicos expuestos en las figuras adjuntas y/o descritos en la presente memoria no necesariamente requieren el orden particular mostrado, o el orden secuencial, para conseguir los resultados deseados. Otras implementaciones pueden estar dentro del alcance de las siguientes reivindicaciones.

Claims (13)

REIVINDICACIONES
1. Un dispositivo (106, 300, 404, 504, 1004, 1204, 1306) para la transmisión de paquetes de datos entre un dispositivo de usuario (402, 502, 1002, 1202, 1304) y un servidor, comprendiendo el dispositivo:
un nodo evolucionado, eNodeB
una estación base (106, 300, 404, 504, 1004, 1204, 1306), comprendiendo la estación base de eNodeB:
al menos una memoria (510, 1214, 1364, 1420); en donde la memoria es un búfer; y
al menos un procesador (408, 508, 1208, 1360, 1362, 1410) conectado operativamente con la memoria, estando el al menos un procesador configurado para:
establecer un enlace de comunicación entre el dispositivo de usuario y el servidor de acuerdo con el protocolo de control de trasmisión, TCP, para la transmisión de al menos un paquete de datos entre el dispositivo de usuario el servidor; y
transmitir el al menos un paquete de datos, recibido desde el servidor, al dispositivo de usuario, utilizando el protocolo de control de transmisión, siendo el al menos un paquete de datos almacenado en la al menos una memoria;
determinar el tamaño total de los paquetes de datos que pueden ser recibidos, R-WND, por la estación base; y
proporcionar al servidor una indicación del tamaño total determinado;
en donde el tamaño total de los paquetes de datos es determinado en base a al menos uno de lo siguiente: una intensidad de señal de radio existente entre el dispositivo de usuario y la estación de base de eNodeB, una calidad de la señal de radio existente entre el dispositivo de usuario y la estación de base de eNodeB, una velocidad de bit estimada de la transferencia de datos entre el dispositivo de usuario y el eNodeB en base a al menos un informe de estado de búfer procedente de al menos uno de lo siguiente: una capa de control de acceso al medio, MAC, de eNodeB, una capa de protocolo de convergencia de datos de paquete, PDCP, de eNodeB, y una capa de control de enlace de radio, RLC, de eNodeB.
2. El dispositivo de acuerdo con la reivindicación 1, en donde la al menos una memoria está configurada para almacenar paquetes de datos recibidos desde el servidor, los paquetes de datos almacenados incluyen al menos un paquete de datos de protocolo de control de trasmisión, TCP; y
en donde el al menos un procesador produce la transmisión del al menos un paquete de datos almacenado en la al menos una memoria desde la estación base al dispositivo de usuario.
3. El dispositivo de acuerdo con la reivindicación 1, en donde el al menos un procesador produce la retransmisión del al menos un paquete de datos almacenado en la al menos una memoria desde la estación base hasta el dispositivo de usuario.
4. El dispositivo de acuerdo con la reivindicación 3, en donde el al menos un procesador recibe al menos un acuse de recibo procedente del dispositivo de usuario que indica que el al menos un paquete de datos ha sido recibido por el dispositivo de usuario;
en donde el al menos un procesador recibe al menos un acuse de recibo duplicado procedente del dispositivo de usuario que indica que el al menos un paquete de datos ha sido recibido por el dispositivo de usuario;
en donde, después de la recepción de un número predeterminado de acuses de recibo duplicados procedentes del dispositivo de usuario, el al menos un procesador produce la transmisión del al menos un paquete de datos almacenado en la al menos una memoria al dispositivo de usuario.
5. El dispositivo de acuerdo con la reivindicación 3, en donde el al menos un procesador recibe al menos un acuse de recibo negativo procedente de la capa inferior del eNodeB que indica que el al menos un paquete de datos no ha sido recibido por el dispositivo de usuario;
en donde, después de la recepción de acuses de recibo negativo procedente de la capa inferior del eNodeB, el al menos un procesador produce la retransmisión del al menos un paquete de datos en la al menos una memoria al dispositivo del usuario;
en donde el acuse de recibo negativo es generado por al menos uno de los siguientes: una capa de protocolo de convergencia de datos de paquete, PDCP, del eNodeB, una capa de control de acceso al medio, MAC, del eNodeB, y una capa de control de enlace de radio, RLC, del eNodeB.
6. El dispositivo de acuerdo con la reivindicación 3, en donde el al menos un procesador determina una información de tiempo de ida y vuelta para el al menos un paquete de datos, la información de tiempo de ida y vuelta incluye el tiempo que tarda una transmisión del al menos un paquete de datos al dispositivo de usuario y una transmisión de un acuse de recibo por parte del dispositivo de usuario indicativo de la recepción del paquete de datos;
en donde, en base al tiempo de ida y vuelta determinado, el al menos un procesador produce la retransmisión del al menos un paquete de datos almacenados en la al menos una memoria al dispositivo de usuario.
7. El dispositivo de acuerdo con la reivindicación 3, en donde el al menos un procesador produce la retransmisión del al menos un paquete de datos almacenado en la al menos una memoria, al dispositivo de usuario utilizando indicación de prioridad alta.
8. El dispositivo de acuerdo con la reivindicación 3, en donde el al menos un procesador que está configurado para evitar la retransmisión del paquete de datos desde el servidor al dispositivo de usuario después de que el servidor fracase en la recepción de un acuse de recibo procedente del dispositivo de usuario dentro de un período de tiempo predeterminado.
9. El dispositivo de acuerdo con la reivindicación 8, en donde el al menos un procesador está configurado para enviar al servidor el acuse de recibo indicando la recepción del paquete de datos por el dispositivo de usuario después de que el al menos un procesador envíe el paquete de datos de solicitud de repetición automática híbrida, HARQ, al dispositivo de usuario; y reciba, como respuesta al envío, una confirmación procedente del dispositivo de usuario de que el paquete de datos ha sido recibido por el dispositivo de usuario.
10. El dispositivo de acuerdo con la reivindicación 8, en donde el al menos un procesador está configurado para enviar al servidor un acuse de recibo que indica una recepción del paquete de datos por el dispositivo de usuario después de recibir una confirmación de que el paquete de datos fue recibido por el dispositivo de usuario, siendo la confirmación generada por al menos uno de los siguientes: una capa de control de acceso al medio, MAC, del eNodeB, una capa de protocolo de convergencia de datos de paquete, PDCP, del eNodeB, y una capa de control de enlace de radio, RLC, del eNodeB.
11. El dispositivo de acuerdo con la reivindicación 1, en donde el al menos un procesador está configurado para programar la transmisión del paquete de datos desde el servidor al dispositivo de usuario utilizando el protocolo de control de trasmisión;
estando el al menos un procesador configurado para evitar la congestión en el enlace de comunicación durante la transmisión del paquete de datos utilizando protocolo de control de trasmisión.
12. Un método implementado por ordenador para la transmisión de paquetes de datos entre un dispositivo de usuario y un servidor de acuerdo con cualquiera de las reivindicaciones precedentes.
13. Un producto de programa de ordenador, para la transmisión de paquetes de datos entre un dispositivo de usuario y un servidor, que comprende instrucciones de almacenamiento de medio leíbles por una máquina que, cuando son ejecutadas por al menos un procesador programable, hacen que el al menos un procesador programable realice las operaciones de acuerdo con cualquiera de las reivindicaciones precedentes.
ES14722056T 2013-03-25 2014-03-25 Protocolo de control de trasmisión en una red de acceso de radio de evolución a largo plazo Active ES2758445T3 (es)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201361804991P 2013-03-25 2013-03-25
US201361804920P 2013-03-25 2013-03-25
US201361804893P 2013-03-25 2013-03-25
US201361804932P 2013-03-25 2013-03-25
PCT/US2014/031753 WO2014160722A1 (en) 2013-03-25 2014-03-25 Transmission control protocol in long term evolution radio access network

Publications (1)

Publication Number Publication Date
ES2758445T3 true ES2758445T3 (es) 2020-05-05

Family

ID=50549493

Family Applications (2)

Application Number Title Priority Date Filing Date
ES14722056T Active ES2758445T3 (es) 2013-03-25 2014-03-25 Protocolo de control de trasmisión en una red de acceso de radio de evolución a largo plazo
ES14719499T Active ES2810159T3 (es) 2013-03-25 2014-03-25 Proxy de protocolo de control de trasmisión en una red de acceso de radio de evolución a largo plazo

Family Applications After (1)

Application Number Title Priority Date Filing Date
ES14719499T Active ES2810159T3 (es) 2013-03-25 2014-03-25 Proxy de protocolo de control de trasmisión en una red de acceso de radio de evolución a largo plazo

Country Status (5)

Country Link
US (2) US9860024B2 (es)
EP (2) EP2979513B1 (es)
ES (2) ES2758445T3 (es)
PT (2) PT2979513T (es)
WO (2) WO2014160722A1 (es)

Families Citing this family (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10326569B2 (en) 2013-02-12 2019-06-18 Altiostar Networks, Inc. Inter-site carrier aggregation with physical uplink control channel monitoring
EP2957141B1 (en) 2013-02-12 2019-01-02 Altiostar Networks, Inc. Long term evolution radio access network
MX351978B (es) 2013-02-21 2017-11-06 Altiostar Networks Inc Sistemas y métodos para la programación de paquetes de datos con base en la detección de aplicación en una estación base.
EP2959693B1 (en) 2013-02-21 2017-11-22 Altiostar Networks, Inc. Systems and methods for coordinating transmission of data packets based on frame type detection in a base station
US9774525B2 (en) 2013-03-25 2017-09-26 Altiostar Networks, Inc. Systems and methods for scheduling of data packets based on delay tolerance of applications
WO2014160718A1 (en) 2013-03-25 2014-10-02 Altiostar Networks, Inc. Optimization of a backhaul connection in a mobile communications network
US9860024B2 (en) 2013-03-25 2018-01-02 Altiostar Networks, Inc. Transmission control protocol in long term evolution radio access network
US10079771B2 (en) * 2013-05-20 2018-09-18 Telefonaktiebolaget Lm Ericsson (Publ) Congestion control in a communications network
WO2015041740A1 (en) * 2013-09-20 2015-03-26 Oracle International Corporation Techniques for reliable messaging for an intermediary in a network communication environment
KR20150051746A (ko) * 2013-11-05 2015-05-13 엘지전자 주식회사 무선 통신 시스템에서 페이징 메시지를 전송하는 방법 및 장치
KR20150084307A (ko) * 2014-01-13 2015-07-22 삼성전자주식회사 네트워크에서 웹 로딩 시간 제어 방법 및 장치
US9654341B2 (en) * 2014-02-20 2017-05-16 Cisco Technology, Inc. Client device awareness of network context for mobile optimzation
CA2939003C (en) * 2014-02-26 2020-07-28 Landis+Gyr Innovations, Inc. Data and event gap reconciliation across networks using different communication technologies
US9491269B2 (en) * 2014-04-11 2016-11-08 Apple Inc. Uplink transmission rate in a wireless communication device
US20150296418A1 (en) * 2014-04-15 2015-10-15 Nokia Solutions And Networks Oy Methods and Apparatus for Handover Management of Transfer Control Protocol Proxy Communications
US9961585B2 (en) * 2014-05-16 2018-05-01 Nokia Solutions And Networks Oy Network-side buffer management
US9894552B2 (en) * 2014-10-21 2018-02-13 Saguna Networks Ltd. Regulating data communication between a mobile data client and a remote server
KR102342144B1 (ko) 2014-12-01 2021-12-22 삼성전자주식회사 통신 시스템에서 분리된 ｔｃｐ 연결을 설정하는 방법 및 장치와 이를 위한 핸드 오버 지원 방법 및 장치
WO2016121809A1 (ja) * 2015-01-29 2016-08-04 株式会社Ｎｔｔドコモ 端末及び通信システム
JP6432377B2 (ja) * 2015-02-09 2018-12-05 富士通株式会社 メッセージログ除去装置、メッセージログ除去方法、及びメッセージログ除去プログラム
US10111130B2 (en) 2015-02-23 2018-10-23 Telefonaktiebolaget Lm Ericsson (Publ) Supporting delivery of data packets using transmission control protocol in a wireless communication network
JP6896640B2 (ja) * 2015-03-04 2021-06-30 アップル インコーポレイテッドＡｐｐｌｅ Ｉｎｃ． エッジクラウドモバイルプロキシに基づくミリ波無線アクセス技術の便宜的アクセス
US10355895B2 (en) 2015-03-11 2019-07-16 Phluido, Inc. Baseband unit with adaptive fronthaul link for a distributed radio access network
CN104796918B (zh) * 2015-03-17 2018-09-28 无锡北邮感知技术产业研究院有限公司 无线通信组网的方法
JP2016208193A (ja) * 2015-04-20 2016-12-08 富士通株式会社 基地局及び通信制御方法
JP6464911B2 (ja) * 2015-05-01 2019-02-06 富士通株式会社 情報処理システム、情報処理システムの制御方法及び受信装置
KR102358232B1 (ko) * 2015-05-15 2022-02-04 삼성전자주식회사 무선 통신 시스템에서 초기 윈도우 값을 설정하는 방법 및 장치
KR102298991B1 (ko) * 2015-05-22 2021-09-07 삼성전자 주식회사 무선 통신 시스템에서 버퍼 관리 방법 및 장치
WO2016200305A1 (en) * 2015-06-12 2016-12-15 Telefonaktiebolaget Lm Ericsson (Publ) Methods and network nodes for evaluating a connection
US10004019B2 (en) 2015-09-08 2018-06-19 Parallel Wireless, Inc. RAN for multimedia delivery
US9880870B1 (en) * 2015-09-24 2018-01-30 Amazon Technologies, Inc. Live migration of virtual machines using packet duplication
CN105224246B (zh) * 2015-09-25 2018-11-09 联想(北京)有限公司 一种信息以及内存配置方法和装置
US10608734B2 (en) 2015-10-22 2020-03-31 Phluido, Inc. Virtualization and orchestration of a radio access network
US10419967B2 (en) * 2015-10-29 2019-09-17 Altiostar Networks, Inc. Video pacing based on radio conditions
US10397978B2 (en) * 2015-11-06 2019-08-27 Flash Networks, Ltd Method and system for signaling optimization of IP connection over a mobile-radio network
US10419968B2 (en) * 2016-03-30 2019-09-17 International Business Machines Corporation Dynamic selection of TCP congestion control for improved performances
WO2017177224A1 (en) 2016-04-08 2017-10-12 Altiostar Networks, Inc. Wireless data priority services
WO2017177223A1 (en) 2016-04-08 2017-10-12 Altiostar Networks, Inc. Dual connectivity
US10887061B2 (en) 2016-07-13 2021-01-05 Cable Television Laboratories, Inc. Systems and methods for packet segmentation in standalone small cell
US10868655B2 (en) 2016-07-13 2020-12-15 Cable Television Laboratories, Inc. System and method for pipelining HARQ retransmissions for small cell backhaul
US10721169B2 (en) * 2016-09-02 2020-07-21 Telefonaktiebolaget Lm Ericsson (Publ) TCP proxy using a communication distance indicator
US10154431B2 (en) * 2016-09-27 2018-12-11 Verizon Patent And Licensing Inc. Congestion mitigation based on user device and base station condition information
EP4009693A1 (en) 2016-10-26 2022-06-08 Telefonaktiebolaget LM Ericsson (publ) 5g congestion control
US10624034B2 (en) 2016-12-13 2020-04-14 Altiostar Networks, Inc. Power control in wireless communications
EP3556064B1 (en) * 2016-12-19 2021-09-22 Telefonaktiebolaget LM Ericsson (publ) Method of controlling traffic flows in a radio communications network, remote node and radio communications network
EP3560207A1 (en) * 2016-12-21 2019-10-30 British Telecommunications Public Limited Company Managing congestion response during content delivery
CN110115042B (zh) 2016-12-29 2023-02-21 英国电讯有限公司 在网络中输送视频序列的方法、数据发送器
US10334287B2 (en) * 2017-04-17 2019-06-25 Plex, Inc. Digital data streaming using server driven adaptive bitrate
WO2019004013A1 (ja) * 2017-06-26 2019-01-03 日本電気株式会社 データ送信装置、方法および記録媒体
IT201700073442A1 (it) 2017-06-30 2018-12-30 Telecom Italia Spa Controllo di congestione del fronthaul in una rete di comunicazione mobile
US10623980B1 (en) 2018-03-12 2020-04-14 Sprint Communications Company L.P. Transmission control protocol (TCP) based control of a wireless user device
US11438243B2 (en) * 2019-04-12 2022-09-06 EMC IP Holding Company LLC Adaptive adjustment of links per channel based on network metrics
CN112399412B (zh) 2019-08-19 2023-03-21 阿里巴巴集团控股有限公司 会话建立的方法及装置、通信系统
US11456938B2 (en) * 2019-09-25 2022-09-27 Arista Networks, Inc. Quantifying performance of a connection by monitoring duplicate acknowledgement numbers
US11134020B1 (en) * 2020-04-16 2021-09-28 Morgan Stanley Services Group Inc. Flow control of two TCP streams between three network nodes
US11856415B2 (en) * 2020-05-15 2023-12-26 Huawei Technologies Co., Ltd. Method, apparatus, and system utilizing lower layer signalling for mobility beam management
EP4282098A1 (en) * 2021-01-19 2023-11-29 QUALCOMM Incorporated Techniques for transmission control protocol (tcp) packet loss recovery

Family Cites Families (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5473602A (en) * 1994-03-04 1995-12-05 Nova-Net Communications, Inc. Wireless radio packet switching network
US5983278A (en) * 1996-04-19 1999-11-09 Lucent Technologies Inc. Low-loss, fair bandwidth allocation flow control in a packet switch
TW513635B (en) * 2000-11-24 2002-12-11 Ibm Method and structure for variable-length frame support in a shared memory switch
JP4015428B2 (ja) * 2001-05-16 2007-11-28 株式会社日立コミュニケーションテクノロジー インアクティビティタイマを備えた無線基地局／無線基地局制御装置、無線端末及び状態制御方法
US7289480B2 (en) 2002-06-24 2007-10-30 Telefonaktiebolaget Lm Ericsson (Publ) Applications based radio resource management in a wireless communication network
US8594043B2 (en) 2007-03-21 2013-11-26 Telefonaktiebolaget Lm Ericsson (Publ) Selective packet forwarding for LTE mobility
JP2008289080A (ja) * 2007-05-21 2008-11-27 Ntt Docomo Inc 端末装置、ネットワーク装置およびデータ通信方法
US8320250B2 (en) * 2008-02-12 2012-11-27 Nvidia Corporation Method and arrangement for TCP flow control
US8165024B2 (en) * 2008-04-03 2012-04-24 Alcatel Lucent Use of DPI to extract and forward application characteristics
US8289864B2 (en) * 2008-08-28 2012-10-16 Alcatel Lucent DPI-triggered application-aware dormancy timer adjustment for mobile data bearers
US8179846B2 (en) 2008-09-08 2012-05-15 Alcatel Lucent DPI-driven bearer termination for short-lived applications
ES2359522B1 (es) 2008-12-18 2012-04-02 Vodafone España, S.A.U. Procedimiento y estación base de radio para planificar tr�?fico en redes telefónicas celulares de �?rea amplia.
US8531961B2 (en) 2009-06-12 2013-09-10 Cygnus Broadband, Inc. Systems and methods for prioritization of data for intelligent discard in a communication network
CA2785842A1 (en) * 2009-12-31 2011-07-07 Bce Inc. Method and system for increasing performance of transmission control protocol sessions in data networks
ES2856326T3 (es) 2009-12-31 2021-09-27 Allot Ltd Dispositivo, sistema y método de optimización de entrega de multimedia
EP2532142A1 (en) 2010-02-01 2012-12-12 Telefonaktiebolaget LM Ericsson (publ) Caching in mobile networks
US8531947B2 (en) 2010-03-31 2013-09-10 Qualcomm Incorporated Single and dual internet protocol bearer support
JP5041035B2 (ja) 2010-06-04 2012-10-03 住友電気工業株式会社 無線装置及び無線基地局装置
US9282135B2 (en) * 2010-10-29 2016-03-08 Israel L'Heureux Enhanced computer networking via multi-connection object retrieval
US8843160B2 (en) 2010-12-23 2014-09-23 International Business Machines Corporation Location based wireless tower caching
CN102075566A (zh) 2010-12-24 2011-05-25 华为技术有限公司 业务的分流处理方法、通信设备及网络系统
ES2401270B1 (es) 2011-03-17 2014-02-25 Vodafone España, S.A.U. Método y entidad de red para descargar vídeo en redes móviles
KR20140035364A (ko) 2011-04-07 2014-03-21 인터디지탈 패튼 홀딩스, 인크 로컬 데이터 캐싱 방법 및 장치
US20120257581A1 (en) 2011-04-11 2012-10-11 Continuous Computing India Private Limited Femto Cluster Architecture for WCDMA and LTE
WO2012139664A1 (en) 2011-04-14 2012-10-18 Telefonaktiebolaget L M Ericsson (Publ) Qoe-aware traffic delivery in cellular networks
US20120300710A1 (en) 2011-05-27 2012-11-29 Nokia Siemens Networks Oy Distributing L2 Baseband Processing in a Radio Network
ES2556381T3 (es) 2011-06-04 2016-01-15 Alcatel Lucent Un concepto de planificación
US9490948B2 (en) 2011-06-20 2016-11-08 Vid Scale, Inc. Method and apparatus for video aware bandwidth aggregation and/or management
CN103959741B (zh) 2011-09-12 2017-09-08 Sca艾普拉控股有限公司 内容数据从本地数据存储器通信至通信终端的方法及设备
US9345024B2 (en) 2012-04-13 2016-05-17 Intel Corporation Exchanging configuration data
EP2957141B1 (en) 2013-02-12 2019-01-02 Altiostar Networks, Inc. Long term evolution radio access network
US8873455B2 (en) * 2013-02-15 2014-10-28 General Dynamics C4 Systems, Inc. Communication units and methods for relay-assisted uplink communication
EP2959693B1 (en) 2013-02-21 2017-11-22 Altiostar Networks, Inc. Systems and methods for coordinating transmission of data packets based on frame type detection in a base station
MX351978B (es) 2013-02-21 2017-11-06 Altiostar Networks Inc Sistemas y métodos para la programación de paquetes de datos con base en la detección de aplicación en una estación base.
US9774525B2 (en) 2013-03-25 2017-09-26 Altiostar Networks, Inc. Systems and methods for scheduling of data packets based on delay tolerance of applications
US9860024B2 (en) 2013-03-25 2018-01-02 Altiostar Networks, Inc. Transmission control protocol in long term evolution radio access network
WO2014160718A1 (en) 2013-03-25 2014-10-02 Altiostar Networks, Inc. Optimization of a backhaul connection in a mobile communications network
US9118569B2 (en) * 2013-04-06 2015-08-25 Citrix System, Inc. Systems and methods for TCP Westwood hybrid approach

Also Published As

Publication number Publication date
EP2979514A1 (en) 2016-02-03
PT2979513T (pt) 2020-08-26
US9860024B2 (en) 2018-01-02
PT2979514T (pt) 2019-12-03
EP2979513A1 (en) 2016-02-03
US20140286258A1 (en) 2014-09-25
ES2810159T3 (es) 2021-03-08
EP2979513B1 (en) 2020-05-20
US10069602B2 (en) 2018-09-04
US20140286239A1 (en) 2014-09-25
WO2014160719A1 (en) 2014-10-02
EP2979514B1 (en) 2019-08-28
WO2014160722A1 (en) 2014-10-02
WO2014160722A8 (en) 2015-05-07

Similar Documents

Publication Publication Date Title
ES2758445T3 (es) Protocolo de control de trasmisión en una red de acceso de radio de evolución a largo plazo
US11652751B2 (en) Maintenance of downlink throughput
US9980156B2 (en) Optimization of downlink throughput
AU2018215661B2 (en) Multi-technology aggregation architecture for long term evolution communications systems
US20210112453A1 (en) Dual Connectivity
US20220295340A1 (en) Video pacing based on radio conditions
US20230121685A1 (en) Power control in wireless communications
US20170366374A1 (en) Gateway apparatus and control method thereof
JP6646585B2 (ja) ある範囲のシーケンスナンバーの確認
US20220225163A1 (en) Communications device, infrastructure equipment and methods
US10326569B2 (en) Inter-site carrier aggregation with physical uplink control channel monitoring
Kucera et al. Latency as a service: Enabling reliable data delivery over multiple unreliable wireless links
WO2017106711A1 (en) Inter-site carrier aggregation with physical uplink control channel monitoring
Sang Fair TCP Channel Access for IEEE 802.11 WLANs