ES2272350T3 - Metodo para realizar una transmision de datos mas eficaz y protocolo de transmision de datos. - Google Patents
Metodo para realizar una transmision de datos mas eficaz y protocolo de transmision de datos. Download PDFInfo
- Publication number
- ES2272350T3 ES2272350T3 ES00987526T ES00987526T ES2272350T3 ES 2272350 T3 ES2272350 T3 ES 2272350T3 ES 00987526 T ES00987526 T ES 00987526T ES 00987526 T ES00987526 T ES 00987526T ES 2272350 T3 ES2272350 T3 ES 2272350T3
- Authority
- ES
- Spain
- Prior art keywords
- layer
- errors
- rlc
- data
- data unit
- 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.)
- Expired - Lifetime
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/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
- H04L1/0079—Formats for control data
- H04L1/0082—Formats for control data fields explicitly indicating existence of error in data being transmitted, e.g. so that downstream stations can avoid decoding erroneous packet; relays
-
- 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/1809—Selective-repeat protocols
-
- 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/1835—Buffer management
- H04L1/1838—Buffer management for semi-reliable protocols, e.g. for less sensitive applications such as streaming video
-
- 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/187—Details of sliding window management
-
- 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/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/321—Interlayer communication protocols or service data unit [SDU] definitions; Interfaces between layers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- 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/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
-
- 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/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/02—Data link layer protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Multimedia (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Communication Control (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Método en una red de telecomunicaciones, comprendiendo la red de telecomunicaciones unos medios de protocolo en estructura de capas para la transmisión de datos, y comprendiendo los medios de protocolo por lo menos una capa superior y una capa inferior, en el que la capa inferior (12) elabora una unidad de datos elaborada (6) que se debe transmitir hacia la capa superior (14) a partir de uno o más segmentos (9a, 9b), comprendiendo el método: detectar uno o más errores (5a) que se producen en unidades de datos recibidas (1a, 1b), caracterizado por las etapas que consisten en elaborar la unidad de datos elaborada (6) que se debe transmitir a la capa superior a partir de uno o más segmentos (9a, 9b) que contienen dichos uno o más errores (5a), y transmitir a la capa superior (14) información sobre errores referente a la ubicación de dichos uno o más errores (5a).
Description
Método para realizar una transmisión de datos
más eficaz y protocolo de transmisión de datos.
La presente invención se refiere a un método en
una red de telecomunicaciones. La invención se refiere asimismo a
unos medios de protocolo. Además, la invención se refiere a un
dispositivo de comunicaciones inalámbricas dispuesto para funcionar
en una red de telecomunicaciones.
En la red GSM (Sistema Global para
Comunicaciones Móviles), la velocidad de transferencia de datos de
9,6 kbit/s es lenta incluso según los criterios actuales, y en un
mundo con un crecimiento constante de productos multimedia, la
capacidad de transferencia de las redes móviles actuales está
resultando insuficiente. Para los teléfonos móviles de la siguiente
generación, la simple transmisión de voz no es suficiente, sino que
el sistema debe ser asimismo capaz de gestionar conexiones de datos
y vídeo. El UMTS (Sistema de Telecomunicaciones Móviles
Universales) es un sistema multimedia inalámbrico mundial que
proporciona a la comunicación inalámbrica, por ejemplo, una
transferencia de datos muy rápida, y al usuario unas posibilidades
más versátiles en forma de tipos nuevos de servicio. Los requisitos
básicos de la red UMTS incluyen la capacidad de proporcionar una
calidad de servicio mejor que la de las redes móviles actuales, un
área de cobertura más amplia, un número elevado de servicios
adicionales, así como una capacidad, tanto en la velocidad de
transferencia como en el número de conexiones de abonado, mayor que
en los sistemas actuales.
La red UMTS es un canal flexible de transmisión
de datos que se puede usar para transmitir voz, multimedia u otra
información representada en formato digital. En su forma más
sencilla, el UMTS es un teléfono o un ordenador portátil que
funciona prácticamente en todo el mundo y que presenta una conexión
rápida constante con la red de Internet. El UMTS presenta una
velocidad de datos tan alta que resulta adecuada para la transmisión
de, por ejemplo, imágenes de vídeo de buena calidad.
La solución básica de la red del sistema UMTS se
basa en el sistema GSM. El UMTS funcionará a una frecuencia de
aproximadamente incluso 2 gigahercios, es decir, por encima de la
actual red DCS-1800 (Sistema Celular Digital para
1800 MHz). El UMTS dispone de la capacidad para una velocidad de
transferencia de 2 Mbit/s, que es aproximadamente 200 veces mayor
que la capacidad de transferencia de datos del GSM. Esta velocidad
es suficiente para la transmisión de imágenes de vídeo de una
calidad bastante buena, y posibilita la transmisión de, por
ejemplo, gráficos y multimedia. La velocidad superior se obtiene por
medio de un ancho de banda mayor, una compresión eficaz de datos y
la tecnología de radiocomunicaciones WCDMA (Acceso Múltiple por
División de Código de Banda Ancha). Cuando se compara con la
tecnología CDMA (Acceso Múltiple por División de Código)
convencional, las diferencias incluyen una mayor capacidad de
transferencia, una mejor calidad, un menor consumo de potencia así
como un dominio de frecuencia aproximadamente dos veces mayor. Si
la aplicación que se va a utilizar requiere una menor capacidad, se
asigna menos capacidad, quedando disponible para otros el resto de
la capacidad.
Una de las ventajas del UMTS cuando se compara
con teléfonos móviles de segunda generación, tales como las
conexiones de abonado GSM, será la velocidad de transferencia
potencial de 2 Mbit/s así como el soporte IP (Protocolo de
Internet). Estas opciones proporcionan conjuntamente una
posibilidad de suministrar servicios multimedia así como nuevos
servicios de banda ancha, tales como vídeollamadas y
vídeoconferencias.
El GPRS (Servicio General de Radiocomunicaciones
por Paquetes) es un servicio de datos por conmutación de paquetes
relacionado con la tecnología de la red GSM, que resulta
especialmente adecuado para la transmisión de paquetes IP. La
tecnología nueva de transmisión de datos requiere cambios en la red
GSM actual. En la red se requieren dos nodos nuevos que se ocupen
de la transmisión de paquetes. La finalidad de los nodos es
ocuparse de la transmisión y la recepción de los paquetes de un
teléfono GSM así como de la conversión y la transmisión de
paquetes, por ejemplo, a otras redes basadas en IP. El GPRS
determina cuatro métodos diferentes de codificación de canales por
medio de los cuales se puede controlar la cantidad de datos a
transferir según la recepción de la red. La capacidad de
transferencia de un intervalo de tiempo está comprendida entre 9,05
kbit/s y 21,4 kbit/s, y la velocidad de transferencia máxima es
aproximadamente 164 kbit/s, cuando se están usando simultáneamente
la totalidad de los ocho intervalos de tiempo. El tamaño máximo de
los paquetes que se deben transmitir es 2 kb. Por medio del GPRS,
es posible utilizar mejor la capacidad de la red, ya que los
intervalos de tiempo individuales se pueden dividir entre varias
conexiones.
La pila de protocolos UMTS contiene unos pocos
cambios sustanciales cuando se compara con el GPRS. Esto es debido
a que el UMTS plantea unos requisitos considerablemente mayores
para la calidad de servicio (QoS), y en el UMTS se usa una nueva
interfaz de radiocomunicaciones (WCDMA). Uno de los cambios más
significativos es el hecho de que la capa LLC (Capa de Control del
Enlace) se ha eliminado de debajo de la capa PDCP (Protocolo de
Convergencia de Datos por Paquetes). En el GPRS, esta capa se
sustituye por una capa SNDCP (Protocolo de Convergencia Dependiente
de la Subred). En el UMTS, esta capa LLC no es necesaria, ya que la
codificación se realiza en la RAN (Red de Acceso de
Radiocomunicaciones). En la transmisión de mensajes de
señalización, no se usan protocolos al nivel del usuario. Además, el
entrelazado relacionado con la calidad de servicio es
responsabilidad de una capa MAC (Control de Acceso al Medio) y una
capa L1 (Capa 1 = Capa Física).
En la Fig. 1 se ilustra la arquitectura de los
protocolos de la interfaz de radiocomunicaciones UMTS. La
arquitectura se implementa en un dispositivo de comunicaciones
inalámbricas, tal como un teléfono móvil, que funcione en una red y
que comprenda los medios de protocolo necesarios para permitir la
transferencia de datos. Los bloques del dibujo se corresponden con
la manifestación de cada protocolo. Los puntos de acceso al
servicio 20 (SAP) en conexiones de
punto-a-punto se muestran como
óvalos ubicados entre diferentes subcapas de la figura. La interfaz
de radiocomunicaciones UMTS se divide en tres capas de protocolo
diferentes L1 (Capa 1 = Capa Física) 10, L2 (Capa 2 = Capa de
Enlace de Datos) y L3 (Capa 3 = Capa de Red). La capa L2 se divide
en las subcapas MAC (Control de Acceso al Medio) 11, RLC (Control de
Enlace de Radiocomunicaciones) 12, PDCP (Protocolo de Convergencia
de Datos por Paquetes) 14 y BMC (Control de Difusión/Multidifusión)
13. La capa L3 se divide en un nivel de control 17 y un nivel de
usuario 16. Las subcapas PDCP 14 y BMC 13 están únicamente
presentes en el nivel de usuario 16. La L3 se divide asimismo en
subcapas, siendo la más baja de ellas la RRC (Control de Recursos
de Radiocomunicaciones) 15, y viene seguida por otras subcapas de
L3, por ejemplo, la CC (Control de Llamadas) y la MM (Gestión de
Movilidad), las cuales no se muestran en la Fig. 1.
La finalidad del protocolo RLC es establecer,
mantener y liberar la conexión RLC. Como la subcapa PDCP superior
14 puede proporcionar unidades SDU (Unidades de Datos de Servicio)
RLC 6 (Fig. 3b) más largas de lo que puede aceptar una PDU (Unidad
de Datos de Protocolo) RLC 1a ó 1b (Fig. 3a), las unidades SDU RLC
6, es decir, las unidades PDU PDCP, se dividen en secciones de un
tamaño adecuado, es decir, en unidades PU (Unidad de Carga Útil),
es decir, segmentos, cada uno de los cuales cabe en cada PDU RLC 1a
ó 1b. Asimismo es posible que varias unidades PU quepan en una PDU
RLC 1a ó 1b, si se usa una compresión del encabezamiento. De forma
correspondiente, en la recepción o en el otro extremo de la
conexión, dichas subdivisiones se combinan nuevamente para formar
una SDU RLC 6. Comprimiendo el encabezamiento, varias unidades PU
pueden caber en una PDU RLC 1a, 1b. Mediante una concatenación, es
posible elaborar diferentes unidades SDU RLC 6 de tal manera que si
la última PU de la primera SDU RLC 6 no llena toda la PDU RLC, 1a ó
1b, la primera PU de la siguiente SDU RLC puede llenar el resto de
esta PDU RLC 1a ó 1b. Si no se utiliza ninguna concatenación, y la
última PU no llena toda la PDU RLC 1a, 1b, el resto de la misma se
puede llenar con bits de relleno. La PDU y la SDU comprenden una
cantidad predeterminada de información en una configuración
predeterminada, codificada en un formato de bits.
Los datos de usuario se pueden transferir desde
un punto a otro usando una transmisión de datos con acuse de
recibo, sin acuse de recibo o transparente, en la que las SDU RLC
se transfieren sin añadir información de protocolo RLC. La
transmisión de datos se puede controlar usando valores de
configuración de la calidad de servicio. Si se producen errores en
la transmisión de datos cuando se usan acuses de recibo, los errores
se pueden corregir retransmitiendo la PDU RLC. Las SDU RLC se
pueden entregar al receptor de una manera fiable en el orden
correcto, cuando se usan acuses de recibo y números de secuencia.
Si no se utiliza esta función, el receptor puede recibir las SDU RLC
en un orden incorrecto. Es posible que el receptor reciba la misma
PDU RLC dos veces, transmitiéndose esta PDU RLC a la subcapa PDCP
superior solamente una vez. El receptor puede asimismo ajustar la
velocidad de transmisión del emisor si la misma no es adecuada.
Cuando se recibe la PDU RLC, se comprueba su corrección basándose en
una suma de comprobación relacionada con la misma. Si alguna parte
de la PDU RLC es defectuosa, se vuelve a transmitir toda la SDU RLC
relacionada con la misma en caso de que se pueda disponer de una
capacidad de retransmisión, y no se ha alcanzado el número máximo
fijado de retransmisiones. En caso contrario, esta SDU RLC se
descarta. Como en la función de este protocolo se pueden asimismo
producir errores, el objetivo consiste en hallar y corregir
estos
errores.
errores.
El protocolo RLC proporciona servicios para la
subcapa PDCP superior los cuales incluyen:
- \bullet
- establecimiento y liberación de la conexión RLC, por medio de los cuales es posible establecer y cortar conexiones RLC,
- \bullet
- transferencia transparente de datos por medio de la cual es posible transferir unidades SDU RLC sin añadir ninguna información del protocolo RLC, aunque de tal manera, sin embargo, que es posible la segmentación y el ensamblaje de las unidades SDU RLC,
- \bullet
- transferencia de datos sin acuse de recibo, por medio de la cual es posible transferir información al receptor sin garantizar su llegada de tal manera que todas las unidades SDU RLC correctas se transmiten a la subcapa PDCP superior inmediatamente sólo una vez,
- \bullet
- transferencia de datos con acuse de recibo, por medio de la cual es posible transferir información al receptor de una manera segura por medio de retransmisiones de tal modo que todas las unidades SDU RLC correctas que han llegado se transmiten a la subcapa PDCP superior inmediatamente solo una vez en el orden correcto o en el orden de llegada,
- \bullet
- valores de configuración de la calidad de servicio, por medio de los cuales es posible determinar la calidad de servicio que se puede utilizar para proporcionar una transmisión de datos garantizada para el receptor de tal manera que por medio de retransmisiones, se pueden transmitir todas las unidades SDU RLC hacia la subcapa PDCP en el orden de transmisión correctamente sólo una vez, o en el orden de llegada correctamente sólo una vez,
- \bullet
- notificación de errores no recuperables, por medio de la cual es posible notificar a la subcapa PDCP que no se puede transmitir la SDU RLC ya que la subcapa RLC no ha podido corregir las unidades PDU RLC incorrectas dentro de los límites de las retransmisiones determinadas y el retardo fijado.
La finalidad principal del protocolo PDCP es
comprimir la información de control relacionada con las capas de
protocolos superiores. Otra de las finalidades del protocolo PDCP
es establecer una correspondencia de la PDU del protocolo de capa
superior en forma de un entero, es decir, la SDU RLC, el cual pueda
ser entendido por la subcapa RLC, para comprimir la información de
control redundante en la entidad transmisora y descomprimirla en la
entidad receptora.
En general, se usan ventanas deslizantes para el
control del flujo y la recuperación de situaciones de error. En
este mecanismo, cada emisor usa una ventana denominada de
transmisión de un tamaño predeterminado. De forma similar, cada
receptor usa una ventana denominada de recepción de un tamaño
predeterminado. Se realiza un acuse de recibo para el emisor, de
los bloques de datos recibidos correctamente, y de este modo la
ventana se traslada hacia delante lo cual posibilita la transmisión
de bloques de datos nuevos. Además de esto, el receptor puede
transmitir solicitudes de retransmisión de bloques de datos
incorrectos y después de que se haya realizado el acuse de recibo de
los mismos, la ventana también se "traslada". En algunas
situaciones, la ventana "se estanca" interrumpiéndose la
transmisión de bloques de datos nuevos.
Haciendo referencia a la Fig. 2, la ventana de
transmisión mencionada anteriormente se comporta de la siguiente
manera. Cada paquete al lado izquierdo de la ventana ha sido
transmitido, y ha llegado un acuse de recibo correspondiente al
mismo. Dentro de la ventana, en el lado izquierdo extremo, existe
el primer paquete sin acuse de recibo, transmitido. Fuera de la
ventana en el lado derecho, están los paquetes que todavía no han
sido transmitidos. Además, dentro de la ventana hay un cursor que
indica el límite para los paquetes que han sido transmitidos y que
no han sido transmitidos. Habitualmente, el cursor se desliza muy
rápidamente hacia el lado derecho extremo.
Uno de los objetivos más importantes de la
subcapa RLC es proporcionar una conexión de transferencia de datos
fiable, ya que en general, los servicios de la capa subyacente no
son fiables, es decir, se pueden perder mensajes, o los mismos
pueden ser alterados. De la retransmisión de unidades PDU RLC
recibidas incorrectamente se ocupa la capa RLC del protocolo de
transferencia de datos. El mecanismo de la retransmisión se basa en
las ventanas de transmisión y recepción mencionadas anteriormente.
El tamaño de esta ventana es siempre un compromiso entre el
protocolo de transferencia de datos usado y los requisitos de la
capacidad de almacenamiento disponible. Una ventana de transmisión
demasiado pequeña provoca un estancamiento de la ventana, e
interrumpe con frecuencia la transferencia de datos, lo cual hace
que se reduzca considerablemente la cantidad de datos
transferidos.
En el caso del UMTS, el mecanismo de la
retransmisión se basa en una solicitud automática de repetición
(ARQ), la cual funciona básicamente de la siguiente manera. Si el
tamaño de la ventana de recepción es uno, el receptor no acepta las
PDU RLC que llegan si las mismas no llegan en orden. De este modo,
si en el proceso se pierde una PDU RLC, el receptor descartará
todas las PDU RLC transmitidas posteriormente, antes de que se
llene la ventana de transmisión. Para el receptor este método es
sencillo, ya que no se requiere ningún espacio de memoria
intermedia. El emisor es además consciente del hecho de que si no
llega un acuse de recibo correspondiente a las PDU RLC en el límite
inferior de la ventana, todas las PDU RLC transmitidas
posteriormente deben volverse a transmitir. De este modo, para el
emisor es suficiente solamente un temporizador, estando activado
siempre dicho temporizador cuando se traslada el límite inferior de
la ventana. Cuando el temporizador se pone en marcha, se
retransmitirá una ventana completa de unidades PDU RLC.
Por otro lado, si el tamaño de la ventana de
recepción es mayor que uno, la pérdida de una trama no requiere
necesariamente la retransmisión de las tramas siguientes. Si las
mismas son correctas cuando son recibidas por el receptor, el
receptor almacena en memoria intermedia las tramas que encajan en
la ventana de recepción. Una trama que se pierda o que contenga
errores cuando llega, permanece en el límite inferior de la ventana
de recepción, y dicha ventana de recepción no se trasladará hasta
que se reciba la trama que falta.
La Fig. 2 ilustra el mecanismo de retransmisión
descrito anteriormente usando un ejemplo en el cual el tamaño de la
ventana de transmisión y recepción es 4. El ejemplo se revisa en
orden cronológico, en primer lugar desde el punto de vista del
emisor y a continuación desde el punto de vista del receptor. En el
ejemplo, las unidades PDU RLC 1a y 1b a transmitir se indican con
la referencia DATOS (x), en la cual x es el número de secuencia de
la PDU RLC. De forma correspondiente, los acuses de recibo se
indican con la referencia ACK (x) en la cual x es el número de
secuencia de la PDU RLC de la cual se debe realizar el acuse de
recibo.
El emisor transmite DATOS (0), en los que la
ventana de transmisión es [0,1,2,3]. A continuación, de una manera
correspondiente el emisor transmite DATOS (1). Seguidamente, el
emisor recibe un acuse de recibo ACK (0) en el que en este momento
la ventana de transmisión es [1, 2, 3, 4]. El emisor transmite
DATOS (2). A continuación, el emisor recibe un acuse de recibo ACK
(1), en el que la ventana de transmisión es en este momento [2, 3,
4, 5]. El emisor no tiene conocimiento del hecho de que DATOS (2)
nunca alcanza su destino, y por lo tanto el proceso continúa con la
transmisión de DATOS (3) y DATOS (4). La ventana de transmisión
sigue siendo [2, 3, 4, 5], ya que DATOS (2) no ha llegado. A
continuación se pone en marcha el temporizador de DATOS (2), con lo
cual la transmisión se inicia a partir del comienzo de la ventana
de transmisión, es decir, por la transmisión de DATOS (2). Después
de esto, el emisor espera hasta que se reciba un acuse de recibo, o
hasta que se ponga en marcha el siguiente temporizador. En esta
situación, no resulta ventajoso que el emisor retransmita los
siguientes paquetes. Habitualmente, es razonable esperar para ver
si en el siguiente acuse de recibo llega una notificación que
indique que se ha recibido correctamente la totalidad de la ventana
o por lo menos una parte de la misma. En este caso, el acuse de
recibo ACK (4) tiene tiempo de llegar antes de que se ponga en
marcha el temporizador de DATOS (3), y por lo tanto la ventana de
transmisión es [5, 6, 7, 8]. A continuación, el emisor puede
transmitir DATOS (5). Después de esto, el proceso continúa según la
manera descrita anteriormente.
Cuando el receptor recibe DATOS (0), la ventana
de recepción es [1, 2, 3, 4]. A continuación, el receptor transmite
un acuse de recibo ACK (0). A continuación, el receptor recibe
DATOS (1), y por lo tanto la ventana de recepción es [2, 3, 4, 5].
Se transmite al emisor un acuse de recibo ACK (1). Después de esto,
el receptor recibe DATOS (3) en lugar de los DATOS (2) esperados, y
por lo tanto la ventana de recepción no se traslada, y DATOS (3) se
almacena en memoria intermedia. El receptor sigue esperando DATOS
(2), pero en su lugar recibe DATOS (4), y por lo tanto la ventana
de recepción no se traslada, y en DATOS (4) se almacena en memoria
intermedia. Seguidamente, el receptor recibe los DATOS (2)
esperados y la memoria intermedia contiene DATOS (3) y DATOS (4), y
por lo tanto en este momento la ventana de recepción es [5, 6, 7,
8]. Como en este momento los paquetes se han recibido hasta DATOS
(4), es posible transmitir un acuse de recibo ACK (4) al emisor. A
continuación de esto, el receptor recibe DATOS (5), y por lo tanto
en este momento la ventana de recepción es [6, 7, 8, 9]. Después de
esto, el proceso continúa según la manera descrita
anteriormente.
Cada PDU RLC contiene una suma de comprobación
por medio de la cual es posible comprobar que la PDU RLC no
contiene ningún error. De forma más precisa, en el UMTS, la suma de
comprobación se añade y se comprueba en la capa L1, aunque teniendo
en cuenta la operación lógica, esta recuerda a una característica
del protocolo RLC. No obstante, esta situación da como resultado
que el bloque de datos protegido por la suma de comprobación
contenga además la información de encabezamiento del RLC, y
posiblemente también la información de encabezamiento del protocolo
MAC. Normalmente, cuando se usan acuses de recibo, las unidades PDU
RLC incorrectas se transmiten una y otra vez hasta que las mismas
llegan de forma correcta, o hasta que se alcanza el número máximo
fijado de retransmisiones. Cuando todas las PDU RLC de la SDU RLC
se han transmitido de forma correcta al receptor, las SDU RLC se
pueden elaborar y transmitir hacia una subcapa PDCP superior. Si no
se usan acuses de recibo, se comprueba la corrección de todas las
PDU RLC de la SDU RLC. Si una PDU RLC es incorrecta, se descarta
toda la SDU RLC.
Debido al entorno inalámbrico, el UMTS tiene un
ancho de banda limitado y una probabilidad de errores mayor y unos
retardos más largos en comparación con una red fija. A su vez, las
aplicaciones de tiempo real requieren retardos lo más pequeños
posibles. Cuando se descartan y se vuelven a transmitir paquetes que
contienen un único error, es probable que se produzcan situaciones
en las cuales no se disponga de tiempo para transmitir el paquete
de forma correcta antes de que sea demasiado tarde.
El documento WO 99/43133 A2 da a conocer un
sistema en el cual se corrigen errores de transmisión usando
protocolos de retransmisión automática.
Una de las finalidades de la presente invención
es producir una conexión de transmisión de datos con retardos
pequeños entre dos puntos, que resulte adecuada para aplicaciones
de tiempo real y que permita la transmisión de datos ligeramente
alterados hacia la aplicación. Además, uno de los objetivos de la
invención consiste en mejorar la calidad de la transmisión de datos
de tiempo real.
Según la invención, estos objetivos se pueden
alcanzar de tal manera que no se descartan automáticamente todas
las SDU RLC erróneas. Las PDU RLC se transmiten siempre en forma de
SDU RLC hacia la subcapa PDCP, pero si en las PDU RLC se detectan
errores, además de la SDU RLC elaborada hacia la subcapa PDCP se
transmite información sobre la ubicación del punto erróneo en la
SDU RLC. Basándose en esta información, la subcapa PDCP puede
asimismo descartar la SDU RLC si fuera necesario, en el caso de que
el error esté ubicado por ejemplo junto a la información de control
de las capas de protocolo superiores.
De forma más precisa, el método según la
invención se caracteriza en la reivindicación 1. Los medios de
protocolo según la invención se caracterizan en la reivindicación
11. El dispositivo de comunicaciones inalámbricas según la invención
se caracteriza en la reivindicación 12.
Con la presente invención, se consiguen ventajas
notables en comparación con las soluciones según la técnica
anterior. Cuando la subcapa RLC es capaz de aceptar unidades PDU
RLC que contienen una carga útil errónea y de elaborarlas formando
la SDU RLC, se reduce considerablemente el número de unidades PDU
RLC descartadas. De este modo, se reduce considerablemente la
probabilidad de una situación en la que una SDU RLC no se transmita
a tiempo hacia la subcapa superior. Además, la carga útil se puede
transferir de forma satisfactoria en tiempo real asimismo a través
de conexiones defectuosas. En este caso, debería indicarse que en
relación con servicios de tiempo real, habitualmente se usa la
transmisión de datos sin acuse de recibo. De este modo, las SDU RLC
llegan a descartarse fácilmente ya que las PDU RLC se pueden alterar
con facilidad y su retransmisión ni siquiera se intenta. De este
modo, la presente invención proporciona una posibilidad de no
descartar la SDU, sino de, por el contrario, realizar un intento de
utilizar datos con una carga útil errónea.
A continuación se describirá la invención con
mayor detalle haciendo referencia a los dibujos adjuntos, en los
cuales
la Fig. 1 muestra las capas más bajas en la pila
de protocolos UMTS,
la Fig. 2 muestra un ejemplo de un método de
retransmisión que utiliza la solicitud automática de
repetición,
la Fig. 3a ilustra una situación en la cual una
SDU RLC se divide en dos segmentos, y uno de los segmentos contiene
un punto erróneo,
la Fig. 3b ilustra la SDU RLC de la Fig. 3a, la
cual se transmite hacia una subcapa PDCP, y un modo, según una de
las formas de realización preferidas de la invención, para
presentar el punto erróneo en esta subcapa PDCP, y
la Fig. 3c ilustra la SDU RLC de la Fig. 3a que
se transmite hacia la subcapa PDCP, y otra manera, según una de las
formas de realización preferidas de la invención, para presentar el
punto erróneo en esta subcapa PDCP.
La transmisión de datos en tiempo real plantea
unas exigencias elevadas sobre el retardo, y por lo tanto no
siempre es posible retransmitir todos los paquetes erróneos (PDU
RLC) dentro de los límites del retardo permitido de tal manera que
se pueda elaborar una SDU RLC completamente exenta de errores. Por
esta razón, en la mayoría de los casos, resulta más ventajoso que
en la transmisión de datos de tiempo real las SDU RLC erróneas se
transmitan también hacia la subcapa superior con la información
sobre los errores. Según la técnica anterior, la subcapa PDCP no es
capaz de determinar en dónde está ubicado el error. En otras
palabras, es posible que el error esté ubicado en la información de
encabezamiento de las capas PDCP o de protocolos superiores, tales
como el TCP/IP, cuya información de encabezamiento puede asimismo
estar comprimida. Este error en el encabezamiento puede provocar
problemas importantes en las subcapas superiores. Por esta razón,
es extremadamente importante que la información del encabezamiento
sea completamente correcta. La mayoría de las aplicaciones de tiempo
real funcionan de forma razonablemente satisfactoria en una
situación en la que la carga útil es ligeramente errónea en
comparación con una situación en la durante su transcurso se pierde
un paquete completo. Por esta razón, resulta extremadamente útil
conocer en dónde están ubicados los posibles errores en la SDU RLC
recibida.
Por ejemplo, cuando se desea transmitir una
imagen de vídeo en tiempo real a través de una conexión de
transmisión de datos, una carga útil ligeramente errónea no afecta
de forma importante a la calidad de la imagen de vídeo que se debe
transmitir. Es probable que el espectador no pueda ni siquiera
detectar un error en la imagen de vídeo. Por otro lado, si un
paquete no puede ser transmitido hacia la aplicación debido a que no
se ha transmitido de forma correcta con la suficiente prontitud, se
pueden producir distorsiones importantes en la imagen de vídeo así
como alguna interrupción en su transmisión. Esta situación puede
molestar al usuario considerablemente más que los cambios casi
invisibles en la imagen de vídeo. De forma similar, cuando se
reproduce sonido, es poco probable que los errores pequeños puedan
ser oídos, aunque si se pierde una trama, se puede producir un
corte en la reproducción del sonido, o el mismo se puede
distorsionar en un nivel considerablemente mayor que en una
situación en la que la carga útil contenga un único error. Además,
muchas aplicaciones de tiempo real son capaces de corregir errores
hasta cierto nivel, de tal manera que el error puede ser incluso
imperceptible para el usuario. Naturalmente, si la conexión de
transmisión de datos es muy deficiente, con frecuencia se deben
descartar unidades SDU RLC erróneas. De este modo, la imagen o
sonido que se reproduce es inevitablemente de una calidad inferior a
la de una situación en la que hay disponible una conexión de
transmisión de datos satisfactoria.
Haciendo referencia a las Figs. 3a a 3c, se
comprueba la corrección de los datos para cada PDU RLC, y de este
modo se puede detectar un área errónea 5a con la precisión de un
segmento 9a, 9b (PDU RLC 1a, 1b sin el encabezamiento RLC 2).
También es posible utilizar un método por medio del cual se puede
detectar con precisión el área errónea 5a, es decir, es posible
determinar el punto en el que comienza el error 7a y en dónde
finaliza 7b. El error también puede ser la PDU RLC perdida, en donde
en la SDU RLC 6 que se debe codificar, el punto completo del
segmento que contiene la PDU RLC perdida constituye el área errónea
5a. Si se produce un error en el encabezamiento RLC de una PDU RLC,
esta PDU RLC debe ser descartada. De este modo, en la SDU RLC este
segmento contenido en la PDU RLC debe señalarse como área errónea,
en el caso de que esta PDU RLC no pueda volverse a transmitir.
En las Figs. 3a y 3b se muestra el primer caso.
Cuando en este caso todavía no se han retransmitido todas las
unidades PDU RLC erróneas 1a, 1b de tal manera que todas las
unidades PDU RLC 1a, 1b pertenecientes a la SDU RLC hayan sido
recibidas de forma completamente correcta, se debe transmitir hacia
la subcapa PDCP superior 14 una SDU RLC 6 que contenga por lo menos
un punto erróneo. Adicionalmente, hacia la subcapa PDCP superior se
transmite información sobre el error o errores 5a. Se dispone de dos
alternativas para esta operación. La primera alternativa es que el
número del segmento 9a, 9b en el que está ubicado este error 5a se
transmita hacia la subcapa superior. En este caso, la subcapa PDCP
debe tener conocimiento del tamaño exacto del segmento 9a, 9b. Como
alternativa, la subcapa RLC puede transmitir el punto de inicio 8a y
el final 8b del segmento erróneo hacia la subcapa PDCP. Basándose
en la información transmitida sobre los errores, la subcapa PDCP
sabe que el error está ubicado dentro de un segmento específico, es
decir, en la subcapa PDCP se presenta como errónea toda el área 5b
entre el punto de inicio 8a y el final 8b del segmento. Esta
situación da como resultado que si el error 5a se produce en el
segmento 9a, 9b que contiene información de control del
encabezamiento PDCP y/o de capas de protocolo superiores 4, debe
descartarse la SDU RLC 6 completa.
En las Figs. 3a y 3c se muestra otro caso. En
este caso, es posible transmitir información hacia la subcapa
superior para indicar la ubicación exacta del error 5a en la SDU
RLC. En este momento se transmite hacia la subcapa PDCP la ubicación
de los bits de la SDU RLC a partir de los cuales comienza 7a el
error 5a y en donde finaliza 7b el error 5a. En este caso, la
subcapa PDCP conoce, basándose en la información transmitida sobre
los errores, la ubicación exacta 5b del error, es decir, la
ubicación del error 5a así como la ubicación 5b del error observado
por la subcapa PDCP es la misma. De este modo, no es necesario que
la subcapa PDCP tenga algún conocimiento sobre la segmentación de
la subcapa RLC. Para implementar este mecanismo, la subcapa RLC
debe ser capaz de calcular eficazmente una suma de comprobación,
sobre la base de la cual es posible hallar de forma precisa las
áreas erróneas 5a. Naturalmente, es posible que la subcapa RLC sea
capaz de detectar los errores 5a con una precisión de áreas
predeterminadas, cuya longitud puede ser, por ejemplo, 1/8 de la
longitud de la SDU RLC. En este caso, es posible que el error 5a se
encuentre en el segmento 9a, 9b que contiene información de control
4 del encabezamiento PDCP y/o capas de protocolo superiores, aunque
la SDU RLC 6 no debe descartarse necesariamente siempre que el área
5b que se señala como errónea no esté ubicada junto con el
encabezamiento PDCP 4.
Haciendo referencia a la Fig. 1, la SDU RLC 6
(Figs. 3a a 3c) recibida y elaborada a partir de la subcapa RLC 12
se transmite a través de la interfaz PDCP RLC hacia la subcapa PDCP
14 por medio de una primitiva
RLC-AM-DATA-Ind,
RLC-UM-DATA-Ind o
RLC-TR-DATA-Ind.
También se puede usar la misma primitiva para la transmisión de
información sobre errores desde la subcapa RLC 12 hacia la subcapa
PDCP 14. La siguiente tabla presenta las primitivas entre la
subcapa RLC 12 y la subcapa PDCP 14. La información sobre errores a
transmitir hacia la subcapa PDCP 14 puede ser la ESI (Indicación de
Segmento Erróneo) mencionada en la tabla. La ESI puede ser por
ejemplo el número de secuencia del segmento 9a, 9b que contiene el
error, o el número de los bits en el comienzo de la SDU RLC 6 a
partir de los cuales comienza el área errónea 5b, y la longitud de
esta área en bits.
A continuación se describe asimismo la función
de diferentes primitivas:
- \bullet
- RLC-AM-DATA-Req: por medio de esta primitiva la subcapa PDCP 14 solicita una transmisión de datos con acuse de recibo de la subcapa RLC 12,
- \bullet
- RLC-AM-DATA-Ind: por medio de esta primitiva la subcapa RLC 12 transmite información sobre errores (ESI) y unidades SDU RLC 6 de la subcapa PDCP 14 las cuales se transfieren usando acuses de recibo,
- \bullet
- RLC-AM-DATA-Conf: por medio de esta primitiva la subcapa RLC 12 confirma la transmisión de la SDU RLC 6 hacia la subcapa PDCP 14,
- \bullet
- RLC-UM-DATA-Req: por medio de esta primitiva la subcapa PDCP 14 solicita una transmisión de datos sin acuse de recibo de la subcapa RLC 12
- \bullet
- RLC-UM-DATA-Ind: por medio de esta primitiva la subcapa RLC 12 transmite información sobre errores (ESI) y unidades SDU RLC 6 de la subcapa PDCP 14, las cuales se transmiten sin acuses de recibo,
- \bullet
- RLC-TR-DATA-Req: por medio de esta primitiva la subcapa PDCP 14 solicita a la subcapa RLC 12 una transmisión de datos transparente,
- \bullet
- RLC-TR-DATA-Ind: por medio de esta primitiva la subcapa RLC 12 transmite información sobre errores (ESI) y unidades SDU RLC 6 de la subcapa PDCP 14, las cuales se transfieren usando una transmisión de datos transparente.
| Nombre general | Parámetro | |||
| Req. | Ind. | Resp. | Conf. | |
| RLC-AM-DATA | Datos, CFN, MUI | Datos, ESI | Sin definir | MUI |
| RLC-UM-DATA | Datos | Datos, ESI | Sin definir | Sin definir |
| RLC-TR-DATA | Datos | Datos, ESI | Sin definir | Sin definir |
Como la subcapa PDCP 14 contiene la información
sobre errores proporcionada por la subcapa RLC 12, la subcapa PDCP
14 puede decidir qué debe hacerse en relación con las SDU PDCP 6
erróneas. La decisión se toma basándose en el punto en el que se
produce el error en la SDU. Por ejemplo, si el error se produce en
la parte inicial de la SDU PDCP, es decir, en la información de
control 4 de capas de protocolos superiores, es probable que el
encabezamiento no se pueda descomprimir, y por lo tanto no resulta
ventajoso transmitir la SDU PDCP a una capa superior. De este modo,
resulta ventajoso descartar esta SDU PDCP. Por ejemplo, si el error
se produce en la carga útil, la SDU PDCP se puede transmitir a la
capa superior.
La presente invención no se limita únicamente a
las formas de realización presentadas anteriormente, sino que se
puede modificar dentro del alcance de las reivindicaciones
adjuntas.
Claims (12)
1. Método en una red de telecomunicaciones,
comprendiendo la red de telecomunicaciones unos medios de protocolo
en estructura de capas para la transmisión de datos, y
comprendiendo los medios de protocolo por lo menos una capa superior
y una capa inferior, en el que la capa inferior (12) elabora una
unidad de datos elaborada (6) que se debe transmitir hacia la capa
superior (14) a partir de uno o más segmentos (9a, 9b),
comprendiendo el método:
detectar uno o más errores (5a) que se producen
en unidades de datos recibidas (1a, 1b),
caracterizado por las etapas que
consisten en
elaborar la unidad de datos elaborada (6) que se
debe transmitir a la capa superior a partir de uno o más segmentos
(9a, 9b) que contienen dichos uno o más errores (5a), y
transmitir a la capa superior (14) información
sobre errores referente a la ubicación de dichos uno o más errores
(5a).
2. Método según la reivindicación 1, que se
detecta asimismo que falta una unidad de datos completa (1a, 1b)
que debe ser recibida, y la ubicación del segmento (9a, 9b) de la
unidad de datos (1a, 1b) que falta, en la unidad de datos elaborada
(6), se interpreta como un área errónea (5b).
3. Método según la reivindicación 1 ó 2, en el
que las unidades de datos recibidas erróneas (1a, 1b) se corrigen
en la capa inferior (12) dentro de un retardo determinado usando
acuses de recibo y retransmisiones, y en la capa inferior (12) la
unidad de datos elaborada (6) que se debe transmitir hacia la capa
superior (14) se elabora a partir de segmentos (9a, 9b) ubicados en
las unidades de datos recibidas (1a, 1b) después de que se reciban
correctamente todas las unidades de datos recibidas (1a, 1b) o
después de un retardo dado cuando no se dispone de tiempo
suficiente para corregir las unidades de datos recibidas erróneas o
las unidades de datos que faltan (1a, 1b), que deben ser recibidas
por medio de la retransmisión.
4. Método según cualquiera de las
reivindicaciones 1 a 3, en el que el tamaño del segmento (9a, 9b)
ubicado en la unidad de datos recibida se determina en la capa
superior (14), y la información sobre errores que se debe transmitir
hacia la capa superior (14) comprende un número de secuencia del
segmento (9a, 9b) ubicado en la unidad de datos recibida (1a, 1b) y
que contiene el error (5a), en el que en la capa superior (14) se
calculan áreas erróneas (5b) que contienen los errores (5a)
basándose en la información sobre errores y en el tamaño del
segmento (9a, 9b).
5. Método según cualquiera de las
reivindicaciones 1 a 3, en el que en la capa superior (14) se
determinan un punto de inicio (8a) y un final (8b) del segmento (9a,
9b) ubicado en la unidad de datos recibida y que contiene dichos
uno o más o errores, y la información sobre errores que se debe
transmitir hacia la capa superior (14) contiene un número de
secuencia del segmento (9a, 9b) ubicado en la unidad de datos
recibida (1a, 1b) en el que está ubicado el error (5a), en el que
en la capa superior (14) se calculan áreas erróneas (5b) dentro de
las cuales están ubicados los errores (5a) basándose en la
información sobre errores y el punto de inicio (8a) y el final (8b)
del segmento (9a, 9b).
6. Método según la reivindicación 4 ó 5, en el
que el segmento (9a, 9b) contiene además por lo menos información
de control (4) de una capa de protocolo superior o un
encabezamiento (3), y la unidad de datos elaborada (6) se descarta
cuando el error (5a) está ubicado por lo menos parcialmente en una
sección de la unidad de datos elaborada (6) tal que contiene la
información de control (4) de la capa de protocolo superior o el
encabezamiento (3).
7. Método según cualquiera de las
reivindicaciones 1 a 3, en el que en la capa inferior (12) se
determinan un punto de inicio (7a) y un final (7b) del error, y la
información sobre errores que se debe transmitir hacia la capa
superior (14) comprende el punto de inicio (7a) y el final (7b) del
error (5a) de la unidad de datos elaborada (6).
8. Método según la reivindicación 7, en el que
el segmento (9a, 9b) comprende además por lo menos información de
control (4) de una capa de protocolo superior o un encabezamiento
(3), y la unidad de datos elaborada (6) se descarta cuando el error
(5a) está ubicado por lo menos parcialmente en una sección de la
unidad de datos elaborada (6) tal que contiene la información de
control (4) de la capa de protocolo superior o el encabezamiento
(3).
9. Método según cualquiera de las
reivindicaciones 1 a 8, en el que la capa inferior es una capa RLC
y la capa superior es una capa PDCP.
10. Método según cualquiera de las
reivindicaciones 1 a 9, en el que la unidad de datos recibida es
una unidad PDU RLC y la unidad de datos elaborada es una unidad SDU
RLC.
11. Medios de protocolo para la transmisión de
datos, comprendiendo dichos medios de protocolo en estructura de
capas por lo menos una capa superior y una capa inferior, en los
que la capa inferior (12) está dispuesta para elaborar una unidad de
datos elaborada (6) que se debe transmitir hacia la capa superior
(14) a partir de uno o más segmentos (9a, 9b) contenidos en las
unidades de datos recibidas (1a, 1b) y para detectar uno o más
errores (5a) que se produzcan en las unidades de datos recibidas
(1a, 1b), caracterizados porque la capa inferior (12) está
dispuesta para elaborar la unidad de datos elaborada (6) que se
debe transmitir hacia la capa superior a partir de uno o más
segmentos (9a, 9b) que contienen dichos uno o más errores (5a), y
para transmitir hacia la capa superior (14) información sobre
errores referente a la ubicación de dichos uno o más errores
(5a).
12. Terminal inalámbrico dispuesto para
funcionar en una red de telecomunicaciones y que comprende unos
medios de protocolo estructurados en capas para la transmisión de
datos, comprendiendo dichos medios de protocolo por lo menos una
capa superior y una capa inferior, en el que la capa inferior (12)
está dispuesta para elaborar una unidad de datos elaborada (6) que
se debe transmitir hacia la capa superior (14) a partir de uno o
más segmentos (9a, 9b) contenidos en las unidades de datos
recibidas (1a, 1b) y para detectar uno o más errores (5a) que se
produzcan en las unidades de datos recibidas (1a, 1b),
caracterizado porque la capa inferior (12) está dispuesta
para elaborar la unidad de datos elaborada (6) que se debe
transmitir hacia la capa superior a partir de uno o más segmentos
(9a, 9b) que contienen dichos uno o más errores (5a), y para
transmitir hacia la capa superior (14) información sobre errores
referente a la ubicación de dichos uno o más errores (5a).
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FI992837 | 1999-12-31 | ||
| FI992837A FI110831B (fi) | 1999-12-31 | 1999-12-31 | Menetelmä tiedonsiirron tehostamiseksi ja tiedonsiirtoprotokolla |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2272350T3 true ES2272350T3 (es) | 2007-05-01 |
Family
ID=8555849
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES00987526T Expired - Lifetime ES2272350T3 (es) | 1999-12-31 | 2000-12-18 | Metodo para realizar una transmision de datos mas eficaz y protocolo de transmision de datos. |
Country Status (14)
| Country | Link |
|---|---|
| US (1) | US6857095B2 (es) |
| EP (1) | EP1243144B1 (es) |
| JP (1) | JP3735067B2 (es) |
| KR (1) | KR100621150B1 (es) |
| CN (1) | CN1191725C (es) |
| AT (1) | ATE341904T1 (es) |
| AU (1) | AU2377601A (es) |
| BR (1) | BR0016735A (es) |
| CA (1) | CA2395615C (es) |
| DE (1) | DE60031167T2 (es) |
| ES (1) | ES2272350T3 (es) |
| FI (1) | FI110831B (es) |
| WO (1) | WO2001050789A1 (es) |
| ZA (1) | ZA200205137B (es) |
Families Citing this family (88)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FI106504B (fi) * | 1998-10-06 | 2001-02-15 | Nokia Networks Oy | Datan segmentointimenetelmä tietoliikennejärjestelmässä |
| DE10008148A1 (de) * | 2000-02-22 | 2001-08-23 | Bosch Gmbh Robert | Verfahren zum Betreiben eines Mobilfunknetzes |
| KR20070090252A (ko) * | 2000-04-17 | 2007-09-05 | 노오텔 네트웍스 리미티드 | 무선 에어 인터페이스를 위한 이중 프로토콜층 자동 재송신요청 방법 |
| KR100644594B1 (ko) * | 2000-06-10 | 2006-11-13 | 삼성전자주식회사 | 무선 데이터 송수신 장치 및 그 방법 |
| FI112995B (fi) * | 2001-01-16 | 2004-02-13 | Nokia Corp | Virheellisen datan käsittely pakettivälitteistä tiedonsiirtoa tarjoavassa tietoliikennejärjestelmässä |
| US20020163908A1 (en) * | 2001-05-07 | 2002-11-07 | Ari Lakaniemi | Apparatus, and associated method, for synchronizing operation of codecs operable pursuant to a communicaton session |
| US7165112B2 (en) * | 2001-06-22 | 2007-01-16 | Motorola, Inc. | Method and apparatus for transmitting data in a communication system |
| US7242670B2 (en) | 2001-07-07 | 2007-07-10 | Lg Electronics Inc. | Method for controlling retransmission of information using state variables in radio communication system |
| KR100883062B1 (ko) * | 2001-07-07 | 2009-02-10 | 엘지전자 주식회사 | 무선 통신 시스템에서 무선 링크 제어 계층의 정보를 전송하는 방법 |
| US6725040B2 (en) * | 2001-07-09 | 2004-04-20 | Asustek Computer Inc. | Lossless SRNS relocation procedure in a wireless communications system |
| KR100595583B1 (ko) * | 2001-07-09 | 2006-07-03 | 엘지전자 주식회사 | 이동통신시스템에서 핸드오버에 따른 패킷 데이터 전송 방법 |
| US6839566B2 (en) * | 2001-08-16 | 2005-01-04 | Qualcomm, Incorporated | Method and apparatus for time-based reception of transmissions in a wireless communication system |
| US7542482B2 (en) * | 2001-08-16 | 2009-06-02 | Qualcomm Incorporated | Method and apparatus for message segmentation in a wireless communication system |
| DE10141092A1 (de) * | 2001-08-22 | 2003-03-06 | Siemens Ag | Verfahren zur Übertragung von Datenpaketen in einem Funk-Kommunikationssystem |
| US6874113B2 (en) * | 2001-09-17 | 2005-03-29 | Interdigital Technology Corporation | Radio resource control-service data unit reception |
| SE0103506D0 (sv) * | 2001-10-19 | 2001-10-19 | Ericsson Telefon Ab L M | HARQ stall avoidance |
| EP1440534B1 (en) | 2001-10-19 | 2008-09-17 | Telefonaktiebolaget LM Ericsson (publ) | Avoiding stall conditions and sequence number ambiguity in an automatic repeat request protocol |
| US6904016B2 (en) * | 2001-11-16 | 2005-06-07 | Asustek Computer Inc. | Processing unexpected transmission interruptions in a wireless communications system |
| ATE502472T1 (de) * | 2001-11-24 | 2011-04-15 | Lg Electronics Inc | Verfahren zur übertragung von paketdaten in komprimierter form in einem kommunikationssystem |
| US7515557B1 (en) | 2002-01-11 | 2009-04-07 | Broadcom Corporation | Reconfiguration of a communication system |
| US7149196B1 (en) | 2002-01-11 | 2006-12-12 | Broadcom Corporation | Location tracking in a wireless communication system using power levels of packets received by repeaters |
| US7689210B1 (en) * | 2002-01-11 | 2010-03-30 | Broadcom Corporation | Plug-n-playable wireless communication system |
| US6788658B1 (en) * | 2002-01-11 | 2004-09-07 | Airflow Networks | Wireless communication system architecture having split MAC layer |
| US7876704B1 (en) | 2002-01-11 | 2011-01-25 | Broadcom Corporation | Tunneling protocols for wireless communications |
| US8027637B1 (en) | 2002-01-11 | 2011-09-27 | Broadcom Corporation | Single frequency wireless communication system |
| US7672274B2 (en) | 2002-01-11 | 2010-03-02 | Broadcom Corporation | Mobility support via routing |
| EP1343267A3 (en) * | 2002-02-08 | 2005-08-03 | ASUSTeK Computer Inc. | Data transmission confirmation in a wireless communication system |
| EP1337065A1 (en) | 2002-02-13 | 2003-08-20 | Telefonaktiebolaget L M Ericsson (Publ) | Semi-reliable ARQ method and device thereof |
| KR100896484B1 (ko) | 2002-04-08 | 2009-05-08 | 엘지전자 주식회사 | 이동통신시스템에서 데이터 전송 무선통신방법 및 무선통신장치 |
| DE10215567A1 (de) * | 2002-04-09 | 2003-10-23 | Siemens Ag | Verfahren zur Übertragung von Daten, insbesondere mit multimedialen Inhalten, in einem Mobilfunknetz |
| US8484370B1 (en) * | 2002-04-16 | 2013-07-09 | Trimble Navigation Limited | Method and system for efficient extended data communications using GPRS |
| US8171300B2 (en) * | 2002-04-30 | 2012-05-01 | Qualcomm Incorporated | Security method and apparatus |
| US7113498B2 (en) * | 2002-06-05 | 2006-09-26 | Broadcom Corporation | Virtual switch |
| US7542471B2 (en) | 2002-10-30 | 2009-06-02 | Citrix Systems, Inc. | Method of determining path maximum transmission unit |
| US7630305B2 (en) | 2003-07-29 | 2009-12-08 | Orbital Data Corporation | TCP selective acknowledgements for communicating delivered and missed data packets |
| US7616638B2 (en) | 2003-07-29 | 2009-11-10 | Orbital Data Corporation | Wavefront detection and disambiguation of acknowledgments |
| US8233392B2 (en) | 2003-07-29 | 2012-07-31 | Citrix Systems, Inc. | Transaction boundary detection for reduction in timeout penalties |
| US8270423B2 (en) | 2003-07-29 | 2012-09-18 | Citrix Systems, Inc. | Systems and methods of using packet boundaries for reduction in timeout prevention |
| US7269760B2 (en) * | 2003-02-05 | 2007-09-11 | Innovative Sonic Limited | Scheme to discard an erroneous PDU received in a wireless communication system |
| KR100498347B1 (ko) * | 2003-04-01 | 2005-07-01 | 엘지전자 주식회사 | Ａｍｒ 코덱을 지원하기 위한 데이터 처리방법 |
| JP4449901B2 (ja) * | 2003-04-09 | 2010-04-14 | 日本電気株式会社 | 無線ネットワーク制御装置及びそれに用いるＱｏＳ制御方法 |
| US8238241B2 (en) | 2003-07-29 | 2012-08-07 | Citrix Systems, Inc. | Automatic detection and window virtualization for flow control |
| US7698453B2 (en) * | 2003-07-29 | 2010-04-13 | Oribital Data Corporation | Early generation of acknowledgements for flow control |
| US8437284B2 (en) | 2003-07-29 | 2013-05-07 | Citrix Systems, Inc. | Systems and methods for additional retransmissions of dropped packets |
| US7656799B2 (en) | 2003-07-29 | 2010-02-02 | Citrix Systems, Inc. | Flow control system architecture |
| US8432800B2 (en) | 2003-07-29 | 2013-04-30 | Citrix Systems, Inc. | Systems and methods for stochastic-based quality of service |
| DE10345438B4 (de) * | 2003-09-30 | 2005-09-15 | Siemens Ag | Verfahren und Vorrichtung zum Dekodieren von mittels paketorientierten Datenübertragungsnetzen übertragenen kodierten Datenpaketen und Verfahren und Vorrichtung zum Kodieren und Dekodieren von über paketorientierte Datenübertragungsnetze zu übertragende Datenpaketen |
| FI20031853A (fi) * | 2003-12-18 | 2005-06-19 | Nokia Corp | Tiedonsiirtomenetelmä langatonta pakettidatapohjaista tiedonsiirtoa varten |
| JP4417733B2 (ja) * | 2004-01-15 | 2010-02-17 | ソニー・エリクソン・モバイルコミュニケーションズ株式会社 | 伝送方法及び装置 |
| DE602004005566T2 (de) * | 2004-02-06 | 2008-01-24 | M-Stack Ltd. | Bahandlung eines SDU Verwurfs in einer RRC Einheit eines UMTS Geräts |
| EP1562330B1 (en) * | 2004-02-06 | 2007-01-03 | M-Stack Limited | Handling a service data unit discard in the radio resource control entity of a UMTS device |
| KR101058729B1 (ko) * | 2004-05-19 | 2011-08-22 | 삼성전자주식회사 | 패킷 망을 이용하여 음성 서비스를 제공하는이동통신시스템에서 음성 패킷 데이터를 효율적으로처리하는 장치 및 방법 |
| EP1780984A4 (en) * | 2004-08-06 | 2012-05-30 | Sharp Kk | TRANSMITTER, RECEIVER, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND COMMUNICATION PROGRAM |
| US7360140B2 (en) * | 2004-09-23 | 2008-04-15 | International Business Machines Corporation | Apparatus and method for tracking packets in a reliably connected transmission system |
| JP5033424B2 (ja) * | 2004-09-29 | 2012-09-26 | 富士通株式会社 | 秘匿通信システム |
| US7787391B2 (en) * | 2005-01-28 | 2010-08-31 | Sharp Kabushiki Kaisha | Communication device, communication system, communication method, communication program, and communication circuit |
| US8291273B2 (en) * | 2005-01-28 | 2012-10-16 | Sharp Kabushiki Kaisha | Communication device, non-transitory computer-readable medium storing a communication program |
| KR100902341B1 (ko) * | 2005-01-28 | 2009-06-12 | 샤프 가부시키가이샤 | 통신기기, 통신시스템, 통신방법, 통신 프로그램을 기록한 컴퓨터독취가능한 기록매체, 통신회로 |
| US8051182B2 (en) * | 2005-01-28 | 2011-11-01 | Sharp Kabushiki Kaisha | Communication device, communication system, communication method, communication program, and communication circuit |
| KR100748342B1 (ko) * | 2005-09-14 | 2007-08-09 | 매그나칩 반도체 유한회사 | 씨모스 이미지 센서의 제조방법 |
| WO2007040330A1 (en) * | 2005-10-05 | 2007-04-12 | Electronics And Telecommunications Research Institute | Method and apparatus for error correction in mbms receipt system |
| US20090262661A1 (en) * | 2005-11-10 | 2009-10-22 | Sharp Kabushiki Kaisha | Data transmission device and method of controlling same, data receiving device and method of controlling same, data transfer system, data transmission device control program, data receiving device control program, and storage medium containing the programs |
| US8839065B2 (en) * | 2011-07-29 | 2014-09-16 | Blackfire Research Corporation | Packet loss anticipation and pre emptive retransmission for low latency media applications |
| KR101259514B1 (ko) | 2006-03-23 | 2013-05-06 | 삼성전자주식회사 | 이기종 이동통신 시스템 간의 무손실 핸드오버 방법 및장치 |
| EP1850522A3 (en) * | 2006-04-27 | 2007-12-05 | Innovative Sonic Limited | Method and apparatus for handling segmentation and numbering of SDUS in wireless communications systems |
| WO2007148630A1 (ja) * | 2006-06-20 | 2007-12-27 | Ntt Docomo, Inc. | 移動通信システムで使用される無線通信装置及び方法 |
| US8379646B2 (en) * | 2006-07-31 | 2013-02-19 | Lg Electronics Inc. | Method of processing control information in a mobile communication system |
| CN101518149B (zh) * | 2006-09-20 | 2011-06-08 | 日本电气株式会社 | 移动通信系统、用户设备和通信结束时段缩短方法 |
| JP4219950B2 (ja) * | 2006-10-16 | 2009-02-04 | シャープ株式会社 | 通信機器、通信方法、通信回路、携帯電話機、プログラム、およびプログラムを記録したコンピュータ読み取り可能な記録媒体 |
| WO2008085908A1 (en) * | 2007-01-05 | 2008-07-17 | Interdigital Technology Corporation | Method and apparatus for indicating a transmission status to a higher layer |
| US7706266B2 (en) * | 2007-03-12 | 2010-04-27 | Citrix Systems, Inc. | Systems and methods of providing proxy-based quality of service |
| KR101132522B1 (ko) | 2007-10-01 | 2012-04-02 | 인터디지탈 패튼 홀딩스, 인크 | Ｐｄｃｐ를 폐기하기 위한 방법 및 장치 |
| JP5082768B2 (ja) * | 2007-10-29 | 2012-11-28 | 富士通株式会社 | 移動通信システム、移動通信方法、無線基地局装置、および端末 |
| US8208394B2 (en) * | 2007-10-30 | 2012-06-26 | Qualcomm Incorporated | Service data unit discard timers |
| JP2009182459A (ja) * | 2008-01-29 | 2009-08-13 | Sony Corp | 通信装置、通信システム、通信方法及びプログラム |
| CN101795494B (zh) * | 2009-02-03 | 2012-10-10 | 中国移动通信集团公司 | 一种lte-a系统内的数据分流方法、装置及系统 |
| EP2247154B1 (en) * | 2009-04-27 | 2012-05-16 | Telefonaktiebolaget L M Ericsson (PUBL) | Technique for coordinated RLC and PDCP processing |
| WO2015172151A1 (en) * | 2014-05-09 | 2015-11-12 | Futurewei Technologies, Inc. | An extensible solution for device to device discovery message size |
| US10834065B1 (en) | 2015-03-31 | 2020-11-10 | F5 Networks, Inc. | Methods for SSL protected NTLM re-authentication and devices thereof |
| US10172036B2 (en) | 2015-05-22 | 2019-01-01 | Ntt Docomo, Inc. | User equipment, base station, and communication method |
| US10404698B1 (en) | 2016-01-15 | 2019-09-03 | F5 Networks, Inc. | Methods for adaptive organization of web application access points in webtops and devices thereof |
| CN111466153A (zh) * | 2017-12-27 | 2020-07-28 | Oppo广东移动通信有限公司 | 一种srb传输方法和装置 |
| WO2020022849A1 (en) * | 2018-07-27 | 2020-01-30 | Samsung Electronics Co., Ltd. | Method and apparatus for wireless communication of wireless node in wireless communication system |
| GB2576204B (en) | 2018-07-27 | 2021-02-17 | Samsung Electronics Co Ltd | Operation of automatic repeat request (ARQ) |
| CN109531569B (zh) * | 2018-12-05 | 2021-08-31 | 北京爱其科技有限公司 | 基于支持不同电子件互连的接口的机器人 |
| CN111835457B (zh) * | 2019-08-09 | 2022-04-26 | 维沃移动通信有限公司 | 一种数据传输方法、接收设备及发送设备 |
| WO2021148856A1 (en) * | 2020-01-23 | 2021-07-29 | Zeku Inc. | Techniques for queueing packet data units at a medium access control layer |
| WO2024120885A1 (en) * | 2022-12-06 | 2024-06-13 | Sony Group Corporation | Transmission device, receiving device and corresponding methods |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FI105976B (fi) * | 1998-02-09 | 2000-10-31 | Nokia Networks Oy | Matkaviestimen suurinopeuksinen liityntä TCP/IP-verkkoon |
| US6512747B1 (en) * | 1998-03-05 | 2003-01-28 | Nippon Telegraph And Telephone Corporation | ATM transmission system |
| KR100658293B1 (ko) * | 1998-04-03 | 2006-12-14 | 텔레폰악티에볼라겟엘엠에릭슨(펍) | 범용 이동 전화 시스템에서 유연한 무선 액세스 및 자원할당 |
| FI107686B (fi) * | 1998-06-16 | 2001-09-14 | Nokia Mobile Phones Ltd | Menetelmä ja tietoliikennelaite kantajien hallintaa varten kolmannen sukupolven matkaviestinjärjestelmässä |
| US6359901B1 (en) * | 1998-09-02 | 2002-03-19 | General Dynamics Decision Systems, Inc. | Method and apparatus for asynchronous adaptive protocol layer tuning |
| US6160804A (en) * | 1998-11-13 | 2000-12-12 | Lucent Technologies Inc. | Mobility management for a multimedia mobile network |
-
1999
- 1999-12-31 FI FI992837A patent/FI110831B/fi not_active IP Right Cessation
-
2000
- 2000-12-18 ES ES00987526T patent/ES2272350T3/es not_active Expired - Lifetime
- 2000-12-18 DE DE60031167T patent/DE60031167T2/de not_active Expired - Lifetime
- 2000-12-18 AU AU23776/01A patent/AU2377601A/en not_active Abandoned
- 2000-12-18 BR BR0016735-5A patent/BR0016735A/pt not_active Application Discontinuation
- 2000-12-18 CA CA002395615A patent/CA2395615C/en not_active Expired - Fee Related
- 2000-12-18 KR KR1020027008382A patent/KR100621150B1/ko not_active IP Right Cessation
- 2000-12-18 AT AT00987526T patent/ATE341904T1/de not_active IP Right Cessation
- 2000-12-18 CN CNB008192081A patent/CN1191725C/zh not_active Ceased
- 2000-12-18 WO PCT/FI2000/001106 patent/WO2001050789A1/en active IP Right Grant
- 2000-12-18 EP EP00987526A patent/EP1243144B1/en not_active Expired - Lifetime
- 2000-12-18 JP JP2001551041A patent/JP3735067B2/ja not_active Expired - Lifetime
- 2000-12-29 US US09/752,344 patent/US6857095B2/en not_active Expired - Lifetime
-
2002
- 2002-06-26 ZA ZA200205137A patent/ZA200205137B/en unknown
Also Published As
| Publication number | Publication date |
|---|---|
| ATE341904T1 (de) | 2006-10-15 |
| KR20020071908A (ko) | 2002-09-13 |
| FI110831B (fi) | 2003-03-31 |
| CA2395615A1 (en) | 2001-07-12 |
| EP1243144B1 (en) | 2006-10-04 |
| EP1243144A1 (en) | 2002-09-25 |
| WO2001050789A1 (en) | 2001-07-12 |
| CA2395615C (en) | 2007-01-30 |
| DE60031167T2 (de) | 2007-06-21 |
| AU2377601A (en) | 2001-07-16 |
| KR100621150B1 (ko) | 2006-09-13 |
| FI19992837A (fi) | 2001-07-01 |
| US6857095B2 (en) | 2005-02-15 |
| CN1191725C (zh) | 2005-03-02 |
| US20010007137A1 (en) | 2001-07-05 |
| CN1437830A (zh) | 2003-08-20 |
| BR0016735A (pt) | 2002-09-03 |
| JP2003519998A (ja) | 2003-06-24 |
| DE60031167D1 (de) | 2006-11-16 |
| JP3735067B2 (ja) | 2006-01-11 |
| ZA200205137B (en) | 2003-02-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2272350T3 (es) | Metodo para realizar una transmision de datos mas eficaz y protocolo de transmision de datos. | |
| ES2316361T3 (es) | Notificacion de descarte de paquete para protocolo de retransmision semifiable. | |
| ES2604981T3 (es) | Procedimiento para desplazar una ventana de recepción en una red de acceso de radio | |
| ES2272691T3 (es) | Reubicacion de la informacion de contexto en la compresion de encabezamientos. | |
| ES2350476T3 (es) | Método y sistema de retransmisión. | |
| US9629036B2 (en) | Method and apparatus for performing handover using packet data convergence protocol (PDCP) reordering in mobile communication system | |
| ES2788874T3 (es) | Transmisión de un informe de estado PDCP | |
| JP5363633B2 (ja) | カバレッジ拡張のための自律送信方法 | |
| ES2388750T3 (es) | Modo de RCL bidireccional no persistente para servicios de bajo retardo | |
| ES2730886T3 (es) | ARQ flexible para transmisión de datos por paquetes | |
| ES2292990T3 (es) | Compresion de encabezamientos de extension. | |
| JP2002237864A (ja) | 非同期移動通信システムの物理階層での適応コーディングを利用したデータ伝送方法及び基地局装置 | |
| ES2357045T3 (es) | Método y dispositivo para reensamblaje de datos en un sistema de comunicación inalámbrica. | |
| CA2193511A1 (en) | Non-transparent data transmission in a digital telecommunications system | |
| KR20060120604A (ko) | 무선 링크 제어 레이어 상의 순방향 에러 정정 코딩을 위한방법 및 관련 장치 | |
| RU2601175C2 (ru) | Способ и система передачи данных от контроллера радиосети к пользовательскому устройству | |
| TW546955B (en) | Method and system of retransmission | |
| US7924710B2 (en) | Method for transmitting data including an error control mechanism designed for unreliable networks and error resilience applications | |
| KR100352895B1 (ko) | 비동기 이동 통신 시스템에서의 하이브리드 에이알큐의적용을 위한 부가 정보 전송 방법 | |
| ES2353634T3 (es) | Mejoras del protocolo de enlace de radio para reducir el tiempo de configuración para llamadas de datos. | |
| ES2974523T3 (es) | Método para transmitir informe de estado PDCP | |
| KR101708786B1 (ko) | 무선링크제어계층에서의 데이터 전송 장치 및 방법 |