ES2294118T3 - Metodo y aparato para evitar retransmisiones innecesarias en un sistema de radio celular de moviles. - Google Patents
Metodo y aparato para evitar retransmisiones innecesarias en un sistema de radio celular de moviles. Download PDFInfo
- Publication number
- ES2294118T3 ES2294118T3 ES02711598T ES02711598T ES2294118T3 ES 2294118 T3 ES2294118 T3 ES 2294118T3 ES 02711598 T ES02711598 T ES 02711598T ES 02711598 T ES02711598 T ES 02711598T ES 2294118 T3 ES2294118 T3 ES 2294118T3
- Authority
- ES
- Spain
- Prior art keywords
- protocol layer
- entity
- protocol
- accordance
- layer entity
- 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/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]
- H04L1/1816—Hybrid protocols; Hybrid automatic repeat request [HARQ] with retransmission of the same, encoded, message
-
- 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/1845—Combining techniques, e.g. code combining
-
- 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
- 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/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
-
- 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
- H04W24/00—Supervisory, monitoring or testing arrangements
- H04W24/04—Arrangements for maintaining operational condition
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
- H04W84/04—Large scale networks; Deep hierarchical networks
- H04W84/042—Public Land Mobile systems, e.g. cellular systems
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Communication Control (AREA)
- Radar Systems Or Details Thereof (AREA)
Abstract
Un método para coordinar las solicitudes de retransmisión desde una entidad de capa de protocolo inferior y una entidad de capa de protocolo superior implementado en una entidad receptora de un sistema de comunicaciones inalámbricas, estando caracterizado el método por los pasos de: en la entidad de capa de protocolo inferior, identificar las unidades de datos de protocolo superior que faltan o que están dañadas y enviar a una entidad emisora solicitudes de retransmisión de estas unidades de datos de protocolo, y evitar que la entidad de capa de protocolo superior envíe solicitudes de retransmisión con respecto a las mismas unidades de datos de protocolo al menos hasta que la entidad de capa de protocolo inferior haya notificado a la entidad de capa de protocolo superior de un fallo en el envío de la unidad de datos de protocolo.
Description
Método y aparato para evitar retransmisiones
innecesarias en un sistema de radio celular de móviles.
La presente invención versa acerca de las
retransmisiones en un sistema de comunicaciones, y más
específicamente acerca de un sistema de radio celular de móviles,
particularmente acerca de un Sistema de telecomunicaciones móviles
universales, (Universal Mobile Telecommunications System,
UMTS) o acerca de un sistema WCDMA.
Ya es conocida la retransmisión de datos hasta o
desde una estación móvil (mobile station, MS), o equipo de
usuario (user equipment, UE). También se conoce el uso del
control de acceso del medio y de capas de control de enlaces de
radio de una estructura de protocolo UMTS en un modo de acuse de
recibo en canales dedicados.
En el modo de acuse de recibo, se llevan a cabo
retransmisiones en el caso de que se detecten errores de transmisión
que no se hayan recuperado mediante el control de error directo. A
esto también se lo denomina solicitud automática de repetición,
(automatic repeat request, ARQ). Con ARQ, las retransmisiones
se pueden llevar a cabo, a no ser que un mensaje transmitido haya
sido objeto de acuse de recibo (de manera positiva), o si es objeto
de acuse de recibo de manera negativa. Normalmente hay unos límites
de tiempo para que se consideren positivos o negativos los
respectivos acuses de recibo.
En esta solicitud de patente se entiende que un
controlador de red de radio (radio network controller, RNC)
es un elemento de red que incluye un controlador de recursos de
radio. El nodo B es un nodo lógico responsable de la
transmisión/recepción de radio en una o más celdas desde/hacia el
equipo de usuario. Una estación base (base station, BS) es
una entidad física que representa al nodo B.
El control de acceso al medio (medium access
control, MAC) y el control de enlace de radio, (radio link
control, RLC) se utilizan dentro del sistema de comunicaciones
por radio, como los servicios radio-genéricos de
datos por paquetes (General Packet Radio Services, GPRS) y de
UMTS.
La patente estadounidense US5222061 describe un
procedimiento de retransmisión de servicios de datos para controlar
las retransmisiones múltiples innecesarias de un paquete de datos
haciendo un seguimiento de la secuencia de números de los paquetes
transmitidos. El paquete de datos se retransmite si aparece en la
lista antes del último paquete de datos que se haya recibido
correctamente. Con la retransmisión, se cambia la secuencia de los
números de la lista. Un receptor comunica un mensaje de control de
estado a un transmisor de manera periódica. La patente reconoce que
el receptor puede haber recibido correctamente un paquete que haya
sido incluido en un mensaje de control de estado.
La patente estadounidense US6118765 también
reconoce que un receptor puede haber recibido un paquete
correctamente cuya retransmisión se haya solicitado en múltiples
ocasiones después de una primera retransmisión. La patente descarta
los paquetes de datos transmitidos innecesariamente antes de
reenviar el paquete.
El Proyecto de asociación de 3ª generación
(3^{rd} Generation Partnership Project, 3GPP): Technical
Specification Group Radio Access Network, Physical Layer
Procedures [Grupo de especificación técnica de una red de
acceso de radio: Procedimientos de capas físicas], 3G TS 25.301
v3.6.0, Francia, septiembre de 2000, especifica en el capítulo
5 la arquitectura de un protocolo de interfaz de radio de un sistema
UMTS. Existen tres capas de protocolo:
capa física, capa 1 o L1,
capa de enlace de datos, capa 2 o L2, y
capa de red, capa 3 o L3.
La capa 2, L2, y la capa 3, L3, están divididas
en planos de control y de usuario. La capa 2 consiste en dos
subcapas, RLC y MAC, para el plano de control, y en cuatro subcapas,
BMC, PDCP, RLC y MAC, para el plano de usuario. Los acrónimos BMC,
PDCP, RLC y MAC denotan un control de difusión/multidifusión
(Broadcast/Multicast Control), protocolo de convergencia de
paquetes de datos (Packet Data Covergence Protocol), control
de enlace de radio y control de acceso al medio,
respectivamente.
La Figura 1 ilustra las capas 1 y 2 de una
estructura de protocolo simplificado UMTS para un estrato Uu (Uu
Stratum, UuS) o estrato de radio, entre un equipo de usuario UE
y una red de acceso de radio terrestre universal (Universal
Terrestrial Radio Access Network, UTRAN).
Las portadoras de acceso de radio (Radio
Access Bearers, RABs) ponen a disposición de las aplicaciones
de usuario los recursos y servicios de radio. Para cada estación
móvil hay una o más RABs. Los flujos de datos (en forma de
segmentos) de las RABs se pasan al respectivo control de enlace de
radio, RLC, entidades que entre otras tareas acumulan los segmentos
de datos recibidos. Hay una entidad RLC para cada RAB. En la capa
RLC, las RABs tienen establecida una correspondencia con los canales
lógicos respectivos. Una entidad de control de acceso al medio,
MAC, recibe los datos transmitidos en los canales lógicos y
establece además una correspondencia de los canales lógicos con un
conjunto de canales de transporte. En conformidad con la subsección
5.3.1.2 de la especificación técnica 3GPP MAC debería soportar el
servicio de multiplexado, por ejemplo, para que los servicios RLC
guarden una correspondencia en el mismo canal de transporte. En este
caso la identificación del multiplexado está contenida en la
información de control del protocolo MAC.
Los canales de transporte establecen una
correspondencia finalmente con un único canal físico que tiene un
ancho de banda total que le asigna la red. En el modo dúplex de
división de frecuencia, un canal físico se define por código,
frecuencia y, en el enlace ascendente, por fase relativa (I/Q). En
el modo dúplex de división de tiempo, un canal físico se define por
código, frecuencia y ventana temporal. El DSCH (downlink shared
channel, canal compartido de enlace descendente), por ejemplo,
tiene establecida una correspondencia con uno o diversos canales
físicos, de forma que se emplee una parte especificada de los
recursos del enlace descendente. Como se describe adicionalmente en
la subsección 5.2.2 de la especificación técnica 3GPP, la capa L1 es
responsable de la detección de errores en los canales de transporte
y de la indicación a una capa superior, de la
codificación/decodificación FEC y del entrelazado/desentrelazado de
los canales de transporte.
El PDCP establece una correspondencia entre las
PDUs de red (Protocol Data Units, unidades de datos de
protocolo) de un protocolo de red, por ejemplo, el protocolo de
Internet, y una entidad RLC. El PDCP comprime y descomprime la
información de control redundante PDU de red (compresión y
descompresión de la cabecera).
Para las transmisiones en canales lógicos punto
a multipunto, el BMC almacena en el lado UTRAN los mensajes
transmitidos recibidos desde un RNC, calcula la tasa de transmisión
requerida y solicita los recursos de canal apropiados. Recibe
información de planificación desde el RNC, y genera mensajes de
planificación. Para la transmisión los mensajes tienen establecida
una correspondencia en un canal lógico punto a multipunto. En el
lado UE, el BMC evalúa los mensajes de planificación y entrega los
mensajes de transmisión a la capa superior en el UE.
El documento 3G TS 25.301 también describe el
protocolo de terminación, o sea, en qué nodo de la UTRAN encuentran
su terminación los protocolos de interfaz de radio, o, de manera
equivalente, dónde dentro de la UTRAN son accesibles los
respectivos servicios de protocolo.
El Proyecto de asociación de 3ª generación
(3GPP): Technical Specification Group Radio Access Network,
Physical Layer Procedures, 3G TS 25.322 v3.5.0, Francia,
diciembre de 2000, especifica el protocolo RLC. La capa RLC
proporciona tres servicios a las capas superiores:
servicio de transferencia de datos
transparente,
servicio de transferencia de datos sin acuse de
recibo, y
servicio de transferencia de datos con acuse de
recibo.
\vskip1.000000\baselineskip
En la subsección 4.2.1.3 se describe una entidad
de modo de acuse de recibo, entidad AM (véase la figura 4.4 de la
especificación técnica 3GPP). En el modo de acuse de recibo se
utiliza la solicitud automática de repetición, ARQ. La subcapa RLC
proporciona una funcionalidad ARQ estrechamente asociada a la
técnica de transmisión de radio que se esté utilizando. La
especificación técnica 3GPP también revela diversos desencadenantes
para un informe de estado que se vaya a transmitir. Si recibe una
solicitud de interrogación, el receptor siempre enviará un informe
de estado. También hay tres desencadenantes de informe de estado,
que se pueden configurar:
- 1.
- Detectada la falta de una(s) PU(s),
- 2.
- Informe de estado iniciado por un temporizador, y
- 3.
- Contador PDU estimado.
\vskip1.000000\baselineskip
Para el desencadenante 1, el receptor pone en
marcha la transmisión de un informe de estado al remitente si se
detecta que falta una unidad de carga útil, (payload unit,
PU). (Se incluye una PU en una PDU de RLC.) Con el desencadenante
2, un receptor pone en marcha la transmisión de un informe de estado
de manera periódica de acuerdo con un temporizador. Finalmente, el
desencadenante 3, resumidamente, tiene que ver con un temporizador
que se corresponde con un número estimado de PUs recibidas antes de
que se reciban las PUs solicitadas.
Ninguno de los documentos citados anteriormente
revelan un método y sistema de eliminar las retransmisiones
innecesarias para una estructura de protocolo por capas, para la que
dos o más subcapas pueden solicitar retransmisiones.
Las referencias citadas del estado previo de la
especialidad describen retransmisiones entre un UE y un RNC. En
conformidad con los ejemplos de realización preferidos de la
invención, las retransmisiones se terminan en el nodo B y en el UE,
respectivamente.
En UMTS solo se permite que retransmitan
unidades de transmisión específicas. En conformidad con la
invención, una unidad de transmisión preferiblemente comprende una
ventana. Cada unidad de transmisión está compuesta de uno o más
bloques de transporte, (transport blocks, TBs). Cada TB
comprende una o más unidades de datos de protocolo, PDUs.
Si una unidad de transmisión contiene uno o más
errores, la capa L2 MAC del protocolo del lado receptor solicita
preferiblemente la retransmisión de esa unidad de transmisión,
incluyendo todos los TBs que comprenda. Los TBs retransmitidos
llegarán después de un retraso debido al tiempo de propagación y de
procesamiento.
El siguiente escenario ilustra el concepto de
retransmisiones innecesarias: la capa L2 MAC entrega PDUs de TBs
recibidos correctamente a la capa L2 RLC. La capa L2 RLC identifica
las PDUs ausentes de los TBs para los que se la capa MAC ha
solicitado la retransmisión, pero que no han llegado aún. La RLC
genera informes de estado, como se prescribe en la especificación
técnica 3GPP 25.322. Por esta razón, se pueden solicitar las PDUs
para retransmisión, tanto por parte de la subcapa MAC como por parte
de la subcapa RLC. Si una unidad de transmisión, que retransmite al
recibir una solicitud en la capa L2 MAC, no contiene ningún error a
su llegada, la solicitud del RLC de que retransmitan las PDUs,
llevada por la unidad de transmisión, es innecesaria. Las
retransmisiones innecesarias provocan un retraso y desperdicio
excesivo de la capacidad del canal.
Por consiguiente, un objeto de esta invención es
eliminar las retransmisiones RLC innecesarias.
También es un objeto presentar un método de
entrega de paquetes consecutivos para el traspaso de paquetes a la
capa RLC.
Otro objeto adicional es mantener un seguimiento
de las PDUs incluidas en los TBs retransmitidos pero que no se han
recibido en la subcapa RLC en el momento del inicio del informe de
estado del RLC.
Finalmente, es un objeto retransmitir solo PDUs
en la subcapa RLC si la última transmisión TB que incluía las PDUs
se ha recibido a tiempo para ser considerada cuando se estable el
informe de estado de RLC.
Estos objetos se llevan a cabo con un método y
un aparato en conformidad con las reivindicaciones independientes 1
y 20, respectivamente, en las que solo una de las subcapas MAC y RLC
es responsable de la retransmisión de una PDU en particular en un
instante concreto.
La invención está particularmente bien adaptada
para un canal de acceso de enlace descendente de paquetes de alta
velocidad de un sistema de telecomunicaciones móviles universales
evolucionado.
Se describen los ejemplos de realización
preferidos de la invención, por medio de ejemplos, haciendo
referencia a los dibujos adjuntos que aparecen más abajo.
La figura 1 muestra una estructura de protocolo
por capas, en conformidad con el estado previo de la especialidad,
en un sistema de comunicaciones de radio.
La figura 2 muestra una comunicación, en
conformidad con la invención, entre un UE y una estación base
involucrada en una conexión entre un RNC y el UE.
La figura 3 ilustra de manera esquemática las
capas de protocolo MAC y RLC, en conformidad con la invención, en
una estructura de protocolo de capas múltiples.
La figura 4 ilustra de manera esquemática las
ventanas y los bloques de transporte con respecto al tiempo en un
canal físico, en conformidad con la invención.
La figura 5 ilustra de manera gráfica el
establecimiento del informe de estado para las PDUs de RLC
retrasadas en una capa MAC, en conformidad con un primer ejemplo de
realización de la invención.
La figura 6 muestra un diagrama de flujo de las
operaciones de capas L1 y L2 MAC en una unidad de transmisión,
recibida en conformidad con el primer ejemplo de realización de la
invención.
La figura 7 muestra las PDUs de RLC según se
aceptan en una capa MAC y tal como se reciben en una capa RLC
superior, en conformidad con un segundo ejemplo de realización de la
invención.
La figura 8 muestra las PDUs de RLC según se
aceptan en una capa MAC y tal como se reciben en una capa RLC
superior, en conformidad con un tercer ejemplo de realización de la
invención.
La figura 9 muestra un diagrama de flujo de las
operaciones de las capas L1 y L2 MAC en una unidad de transmisión
recibida en conformidad con el segundo ejemplo de realización de la
invención.
La figura 10 muestra un diagrama de flujo de las
operaciones de las capas L1 y L2 MAC en una unidad de transmisión
recibida en conformidad con el tercer ejemplo de realización de la
invención.
La figura 11 ilustra un aparato en conformidad
con el primer ejemplo de realización de la invención.
La figura 12 muestra un aparato en conformidad
con los ejemplos de realización segundo y tercero de la
invención.
Haciendo referencia a la figura 2, el nodo B 1 y
el nodo B 2 son nodos lógicos responsables de la
transmisión/recepción de radio en una o más celdas hacia/desde el
equipo de usuario UE. La BS 1 y la BS 2 son entidades físicas que
representan el nodo B 1 y el nodo B 2, respectivamente. El nodo B 1
y el nodo B 2 dan terminación a la interfaz de aire, llamada
interfaz Uu dentro del UMTS, entre el UE y el nodo B respectivo
hacia el controlador de red de radio RNC. En UMTS, a la interfaz
entre un nodo B y un RNC se la llama interfaz Iub.
En una situación ejemplar, el UE se comunica por
un enlace de radio asociado con la BS 1. Se transmiten datos
conmutados por paquetes en unidades de datos de protocolo, PDUs, en
ambas direcciones. Se transporta cada PDU en un canal de transporte
en un bloque de transporte, TB. Como se ha descrito anteriormente,
los errores de transmisión en el canal de transporte se corrigen y
detectan en la capa L1 de las figuras 1 y 3. A cada bloque de
transporte, TB, en la figura 3 se le puede proporcionar una suma de
verificación individual de detección de errores por CRC antes de la
transmisión por el canal físico. Sin embargo, se proporciona
preferiblemente una unidad de transmisión que tenga uno o más TBs,
que solo tenga una suma de verificación CRC de detección de
errores. Si se detecta que la unidad de transmisión está equivocada
en el lado de la recepción, se informa de esto a la capa L2
MAC.
La capa L2 MAC puede solicitar una retransmisión
de las unidades de transmisión recibidas de manera errónea. Las
unidades de transmisión detectadas erróneas aún llevan información
que no se debería perder. Preferiblemente se utiliza un ARQ
híbrido, utilizando información disponible de una(s)
transmisión(es) anterior(es) de una unidad de
transmisión combinándola de manera adecuada con la última
retransmisión, antes de que la capa L2 MAC solicite una
retransmisión.
La detección de errores, en el extremo de
recepción, también la lleva a cabo la capa L2 RLC de la figura 3.
Si se recibe erróneamente una unidad de datos de protocolo RLC, PDU,
y el error no se recupera mediante una corrección de error directa
de la PDU, o falta la PDU, se solicitará una retransmisión en un
momento en el tiempo cuando la capa RLC establezca un informe de
estado. Las PDUs de RLC se transfieren hacia/desde las SDUs de la
capa MAC. La SDU de MAC incluye posiblemente una cabecera no
incluida en la PDU de RLC. Como se ha descrito anteriormente, las
PDUs de RLC se transfieren en bloques de transporte, TBs, en el
canal físico. La capa L2 MAC transfiere TBs a la capa física
L1.
Una PDU de la capa de la red o la PDU L3 pueden
comprender diversas PDUs de RLC, como se ilustra en la figura 3.
Las PDUs de RLC están reunidas en unidades de datos de servicio RLC,
RLC de SDU (service data units, unidades de datos de
servicio), antes de la entrega a una capa superior de la PDU. El
protocolo L3 puede ser, por ejemplo, el protocolo de internet
(Internet Protocol, IP). A la recepción de L3, las SDUs de
RLC se segmentan en PDUs de RLC.
La figura 4 ilustra tres de entre una pluralidad
de ventanas temporales en un canal físico, representando cada
ventana una unidad de transmisión. Por propósitos ilustrativos, a
cada ventana temporal, Ventana1, Ventana2 y Ventana3, se le indica
que transporte tres bloques de transporte y una suma de verificación
CRC, TB1-TB3 & CRC1, TB4-TB6
& CRC2 y TB7-TB9 & CRC3, respectivamente. La
presente invención evita retransmisiones innecesarias de unidades
de ventana/retransmisión que lleven bloques de transporte y las PDUs
de RLC incluidas en las mismas, en conformidad con los datos
transmitidos y de los propios códigos adicionales transmitidos para
propósitos de control y de verificación de errores.
En un sistema WCDMA evolucionado, un canal de
acceso de enlace descendente de paquetes de alta velocidad, canal
HSDPA (high-speed downlink packet access), es
un canal que comparte similitudes con el DSCH. Sin embargo, está
basado en un tipo de canal de transporte novedoso. Un canal HSDPA
soporta muchas características nuevas no soportadas por el DSCH,
pero también hereda algunas de las características de un DSCH. Hay
distintas características importantes de un canal HSDPA. Esta es
una muestra de las características:
Altas tasas de datos con picos de tasas de datos
hasta decenas de Mbit/s.
Los datos se transmiten a múltiples usuarios en
un canal compartido por medio de un multiplexado por división de
tiempo, (time-division multiplex, TDM).
Una modulación de rango más elevado.
Una retransmisión rápida con una combinación
flexible de los datos retransmitidos en el UE, también llamado ARQ
híbrido rápido o HARQ rápido.
Retraso pequeño de
aire-interfaz, con un retraso máximo de ida y vuelta
de unos diez milisegundos.
Se prefiere que el ARQ híbrido rápido encuentre
su terminación en el nodo B.
En conformidad con un primer ejemplo de
realización preferido, como se ha explicado en relación con la
figura 5, a todas las PDUs de RLC, recibidas por la capa MAC, se
les adjunta un indicador. Este indica a la capa L2 RLC si la PDU de
RLC está incluida en una solicitud de retransmisión en la capa MAC.
La retransmisión se inicia en la capa MAC si, en un conjunto de
bloques de transporte incluido en la unidad de transmisión, se
detecta un error al decodificar. En la figura 5, el indicador
utilizado se "retrasa". Por supuesto, se podría utilizar
cualquier indicador apropiado para este propósito. En la figura 5,
las unidades de retransmisión que lleven PDUs de RLC 1, 2, 3, 13 y
14 tienen la indicación de que están solicitadas para una
retransmisión. En consecuencia, estas PDUs de RLC se retrasan. Los
bloques de transporte que llevan PDUs de RLC 4, 5, 6, 10, 11 y 12
han sido recibidos y se indica que no tienen errores de acuerdo a la
suma de verificación CRC. Las PDUs de RLC 7, 8 y 9 no han sido
recibidas correctamente y no se ha transmitido ninguna solicitud de
retransmisión al lado transmisor de estas PDUs. Están identificados
como "fallos". Podría haber diversas razones para que no se
solicite una retransmisión de las PDUs 7, 8 y 9. Una de las razones
podría ser que el número de ventana de la ventana, que forma la
unidad de transmisión, que lleva las PDUs se haya corrompido durante
la transmisión. Un fallo durante la solicitud de retransmisión
podría ser otra de las razones. La capa L2 RLC debería encargarse
de las retransmisiones fallidas, al igual que las de las PDUs de RLC
7, 8 y 9. Sin embargo, las PDUs de RLC retrasadas ya están siendo
retransmitidas y no deberían ser solicitadas también por la capa L2
RLC, para que se eviten las retransmisiones innecesarias, a no ser
que la capa MAC indique un fallo. Consecuentemente, en conformidad
con un primer ejemplo de realización de la invención, las PDUs de
RLC que tienen la indicación de que han sido retrasadas que no
hayan llegado, solo se solicitarán para retransmisión si la capa L2
MAC indica un fallo antes de la llegada de las PDUs de RLC
retrasadas. Haciendo referencia a la figura 5, las PDUs de RLC 1, 2
y 3 no estarán incluidas en un informe de estado RLC (o sea, la capa
L2 RLC no solicitará que se retransmitan) si el informe de estado
se establece antes del momento en el tiempo cuando se indique un
fallo MAC de las PDUs de RLC 7, 8 y 9. Sin embargo, si se establece
un informe de estado después del fallo MAC, estarían incluidas en
el informe de estado, ya que el informe abarcará todas las PDUs que
no hayan sido incluidas en el informe de estado anterior y que
tengan la indicación de estar retrasadas, o en las que se ha dado
un fallo. Se detectará la ausencia de las PDUs de RLC ausentes 7, 8
y 9 al recibir correctamente las ventanas que lleven las PDUs de
RLC 10 y superiores. Por lo tanto, también las PDUs de RLC 7, 8 y 9
están incluidas en el informe de estado que solicita la
retransmisión de las unidades de retransmisión con retraso o con
fallo en conformidad con el primer ejemplo de realización de la
invención.
La figura 6 muestra un diagrama de flujo de las
operaciones de las capas L1 y L2 MAC en una unidad de transmisión
recibida en conformidad con el primer ejemplo de realización de la
invención. Tan pronto como se detecta un fallo en la capa L2 MAC,
esto se le indica a la capa L2 RLC. Si no se detecta ningún fallo,
la capa L2 MAC continua buscando errores en la unidad de
transmisión. Si la capa L1 reporta alguna detección de error, la
capa L2 MAC inicia una solicitud de retransmisión de la unidad de
transmisión detectada que tiene el error e indica a la L2 RLC todos
los TBs, o sus correspondientes PDUs de RLC, solicitados para ser
retransmitidos con la indicación de que han sufrido un retraso.
El principio de un segundo y tercer ejemplo de
realización de la invención se ilustra en las figuras 7 y 8. Los
TBs que recibe y acepta como libres de error la capa MAC,
posiblemente después de una retransmisión, que se corresponden con
las PDUs de RLC, se denominan "llegadas MAC". Asumiendo que las
PDUs de RLC hayan sido enviadas originalmente de forma consecutiva,
una o más unidades de transmisión que llevan PDUs de RLC 1, 2 y 3
han sido aparentemente retransmitidas y llegaron después de una o
más ventanas que llevan PDUs de RLC 4, 5 y 6. Si, a la llegada del
TB que lleva la PDU de RLC 4, esta PDU de RLC (o su correspondiente
SDU de MAC) ha sido transferida al RLC antes de la llegada de las
PDUs de RLC 1, 2 y 3, un informe de estado posiblemente
desencadenado hubiese indicado que faltaban las PDUs de RLC 1, 2 y
3, incluyéndose estas PDUs en una solicitud de retransmisión. Sin
embargo, la unidad o unidades de retransmisión que llevan estas PDUs
ya habían sido solicitadas para una retransmisión por la capa L2
MAC y, si se hubiesen recibido correctamente, una solicitud de
retransmisión de la L2 RLC hubiese sido innecesaria. En los ejemplos
de realización segundo y tercero, las retransmisiones innecesarias
se evitan acumulando los TBs recibidos y entregando las SDUs de MAC
a la capa L2 RLC de manera secuencial en conformidad con el número
de PDUs de RLC. Esto introducirá un retraso con respecto al primer
ejemplo de realización. Sin embargo, los ejemplos de realización
segundo y tercero se benefician de no requerir que se transfiera un
indicador de retraso entre las subcapas MAC y RLC. Como todos las
SDUs de MAC/PDUs de RLC se entregan en orden numérico a la capa L2
RLC, un fallo dará como resultado la falta de una o más PDUs de RLC
en la capa RLC. Los desencadenantes de estado ponen en marcha un
informe de estado de la capa L2 RLC similar al de la figura 5 en
conformidad con el estado previo de la especialidad. Las PDUs de
RLC que faltan en el momento del establecimiento del informe de
estado serán objeto de acuse de recibo negativo y se
retransmitirán.
En conformidad con el tercer ejemplo de
realización de la invención, la capa L2 MAC le indica a la capa L2
RLC un fallo tan pronto como sea detectado. Esto se ilustra en la
figura 8 transfiriendo el indicador "Fallo" a la capa RLC.
Cuando la capa L2 MAC detecta un fallo, notifica a la capa L2 RLC,
que preferiblemente pone en marcha el establecimiento de un informe
de estado a la recepción de esta indicación. Por lo tanto, se puede
reducir el retraso de la retransmisión para las PDUs de RLC que
faltan. En conformidad con el segundo ejemplo de realización de la
figura 7, no existe tal indicador.
En las figuras 7 y 8 se detecta un fallo MAC
después de que se haya recibido con éxito una unidad de transmisión
que lleva PDU 3. Si hay un fallo en el contenido del buffer
de la capa MAC, si es que lo hay, se transfiere a la capa RLC,
tanto para el segundo ejemplo de realización como para el
tercero.
Como se podía ver en los ejemplos de realización
segundo y tercero de las figuras 7 y 8, las PDUs de RLC 1, 2 y 3 no
están incluidas en un informe de estado si se desencadena antes del
fallo, ya que la L2 RLC no está al tanto de ninguna de las PDUs de
RLC 1-6 hasta que haya llegado la PDU de RLC 3,
debido al requerimiento de que las PDUs de RLC (o sus SDUs de MAC
correspondientes) sean transferidas desde la subcapa L2 MAC a la
subcapa L2 RLC en orden numérico.
De ahí en adelante, se acumulan los TBs que son
llevados subsiguientemente por unidades de transmisión recibidas
con éxito, y se transfieren las PDUs correspondientes en orden
numérico a la capa RLC.
Las figuras 9 y 10 muestran cada una un diagrama
de flujo de las operaciones de las capas L1 y L2 MAC del segundo y
tercer ejemplo de realización, respectivamente. En las figuras 9 y
10 se detecta un fallo MAC según ocurre en conformidad con un
detector de fallos MAC. Podría haber diversas razones para un fallo
L2 MAC. Una de las razones podría ser que el número de ventana de
la ventana que forma la unidad de transmisión que lleva las PDUs se
haya corrompido durante la transferencia. Otra de las razones podría
ser un fallo durante la solicitud de retransmisión. Para el segundo
ejemplo de realización de la figura 9, tan pronto como se detecta un
fallo MAC se salta la unidad de transmisión al completo y la capa
MAC procede con el análisis de la siguiente unidad de transmisión.
En el tercer ejemplo de realización, tan pronto como se detecta un
fallo MAC la capa MAC entrega todas las PDUs acumuladas (o sus
correspondientes SDUs de MAC) a la capa L2 RLC (véase la figura 10)
acompañadas de un indicador de fallo. La capa RLC solicitará que se
retransmitan las PDUs que faltan, como se describe en relación con
las figuras 7 y 8. Haciendo referencia a las figuras 9 y 10, ambos
ejemplos de realización, segundo y tercero, transferirán PDUs de
RLC acumuladas por TB MAC en casos particulares a la capa L2 RLC.
Cuando se ha transferido el contenido del buffer de MAC, se
borra del buffer de MAC.
Según se detecta una unidad de transmisión
(ventana) errónea a partir de la suma de verificación CRC L1, se
solicita preferiblemente que se retransmitan todos los bloques de
transporte, TBs, llevados por la unidad de transmisión. Por
supuesto, cuando se aplica una suma de verificación CRC individual a
cada TB, los TBs individuales de una unidad de transmisión se
pueden solicitar para que se retransmitan según se necesiten.
Los TBs solicitados para una retransmisión
tienen la indicación de que están retrasados en el buffer de
MAC para hacer un seguimiento de los TBs que se espera que lleguen
en un instante posterior. Los TBs recibidos correctamente se
insertan en el buffer de MAC en conformidad con el número de
secuencia de la PDU de RLC. Las PDUs de RLC marcadas como
retrasadas se reemplazan por sus retransmisiones cuando se reciben
correctamente. Mientras que haya cualquier número de TB precedente,
o su correspondiente PDU de RLC, marcados como retrasados al
insertar un TB/PDU en el buffer de MAC, los TBs/PDUs libres
de error no son de orden consecutivo y no se deberían transferir a
la capa RLC, para evitar así retransmisiones innecesarias.
Consecuentemente, la capa MAC continua procesando la siguiente
unidad de transmisión. Cuando una fracción preestablecida del
buffer de MAC está ordenada de manera consecutiva sin que
haya TBs/PDUs con la indicación de estar retrasados, esta fracción
se transfiere a la capa RLC y se borra del buffer de MAC.
Preferiblemente el contenido de la unidad de transmisión se
transfiere a la capa RLC tan pronto como se verifica que está
precedido por un indicador de retraso en el buffer de MAC, o
sea, la fracción preferida se corresponde con la cantidad de datos
llevados por una unidad de transmisión.
La figura 11 ilustra un equipo de usuario en
conformidad con el primer ejemplo de realización que incluye medios
1 para establecer un indicador que indica un fallo en la capa L2 MAC
y para transferir el indicador a la capa L2 RLC, medios 2 para
establecer un indicador que indica un retraso en la capa L2 MAC y
para transferir el indicador a la capa L2 RLC, medios 3 para
detectar en la capa L2 RLC un indicador de fallo que sea transmitido
desde la capa L2 MAC, y medios 4 para detectar en la capa L2 RLC un
indicador de retraso que esté siendo transferido desde la capa L2
MAC.
La figura 12 muestra un equipo de usuario que
opera en conformidad con el segundo o tercer ejemplo de realización
que incluye medios 5 para establecer un indicador en un
buffer L2 MAC, identificando el indicador las unidades de
datos solicitadas para ser retransmitidas en la capa L2 MAC que
tienen un retraso, medios 6 para establecer un indicador en un
buffer de la capa L2 MAC, señalando el indicador el fallo en
la capa L2 MAC, medios 7 para la inserción de un bloque de
transporte en orden secuencial de la PDU en el buffer de la
capa L2 MAC, y medios 8 para transferir el buffer de la capa
L2 MAC a la capa L2 RLC y para borrar el buffer de la capa
de protocolo de menor nivel. Consecuentemente, si el buffer
L2 MAC solo se transfiere parcialmente, se borra del buffer
el contenido del buffer correspondiente a la parte
transferida del buffer de la capa MAC.
Los medios correspondientes, como se han
ilustrado para un equipo de usuario en las figuras 11 y 12, también
son aplicables en un elemento de red que se comunique con el equipo
de usuario si la invención se aplica en una dirección de enlace
ascendente. Consecuentemente, los medios descritos también se
aplican a un elemento de red que albergue la máquina ARQ del lado
del receptor. En la figura 2, la máquina ARQ del lado de la UTRAN
reside en una estación base BS 1, representando el elemento de red.
Esta solución preferida no excluye que un RNC sea el elemento de
red que albergue a la máquina ARQ del lado del receptor.
Una persona versada en la especialidad
comprenderá rápidamente que las propiedades del receptor y del
transmisor de una BS o de un UE tienen una naturaleza genérica. El
uso de conceptos como BS, UE o RNC en esta solicitud de patente no
pretende limitar la invención solo a los dispositivos asociados con
estos acrónimos. Concierne a todos los dispositivos que operan de
manera correspondiente, o que obviamente puedan ser adaptados en
relación con la invención para esto por una persona versada en la
especialidad. Como un ejemplo no exclusivo, la invención versa
acerca de estaciones móviles sin un módulo de identidad de abonado
(subscriber identity module, SIM), al igual que acerca de un
equipo de usuario que incluya uno o más SIMs. Además, las
referencias a los protocolos y capas se hacen en estrecha relación
con terminología UMTS. Sin embargo, esto no excluye la aplicabilidad
de la invención en otros sistemas con otros protocolos y capas de
similar funcionalidad.
No se pretende que la invención esté limitada
solo a los ejemplos de realización descritos en detalle
anteriormente. Se pueden efectuar cambios y modificaciones sin
salirse de la invención. La invención cubre todas las modificaciones
dentro del ámbito de las siguientes reivindicaciones.
Claims (29)
1. Un método para coordinar las solicitudes de
retransmisión desde una entidad de capa de protocolo inferior y una
entidad de capa de protocolo superior implementado en una entidad
receptora de un sistema de comunicaciones inalámbricas, estando
caracterizado el método por los pasos de: en la entidad de
capa de protocolo inferior, identificar las unidades de datos de
protocolo superior que faltan o que están dañadas y enviar a una
entidad emisora solicitudes de retransmisión de estas unidades de
datos de protocolo, y evitar que la entidad de capa de protocolo
superior envíe solicitudes de retransmisión con respecto a las
mismas unidades de datos de protocolo al menos hasta que la entidad
de capa de protocolo inferior haya notificado a la entidad de capa
de protocolo superior de un fallo en el envío de la unidad de datos
de protocolo.
2. El método, en conformidad con la
reivindicación 1, caracterizado porque las unidades de datos
de protocolo solicitadas para ser retransmitidas se indican
inicialmente a la entidad de la capa de protocolo superior como que
están siendo retrasadas.
3. El método, en conformidad con la
reivindicación 1 o la 2, caracterizado porque si la
información del error en el transporte no indica un error de
transmisión, las unidades de datos de protocolo recibidas por la
entidad de capa de protocolo inferior se transfieren a la entidad
de capa de protocolo superior.
4. El método, en conformidad con cualesquiera de
las reivindicaciones 1-3, caracterizado
porque las unidades de datos de protocolo solicitadas para ser
retransmitidas por la entidad de capa de protocolo inferior se
solicitan para la retransmisión por la entidad de capa de protocolo
superior de manera condicional en una indicación de fallo
subsiguiente desde la entidad de capa de protocolo inferior.
5. El método, en conformidad con cualesquiera de
las reivindicaciones de la 1 a la 4, en el que dicha entidad de capa
de protocolo inferior es una entidad de capa de protocolo L2 MAC y
dicha entidad de capa de protocolo superior es una entidad de capa
L2 RLC en un sistema de protocolo de telecomunicaciones móviles
universales.
6. El método, en conformidad con la
reivindicación 1, caracterizado porque las unidades de datos
de protocolo se entregan en secuencia desde la entidad de capa de
protocolo inferior a la entidad de capa de protocolo superior y, en
el caso de que una unidad de datos de protocolo sea identificada
como dañada o que falta por la entidad de capa de protocolo inferior
recibido, las unidades de datos de protocolo recibidas
subsiguientemente se almacenan en un buffer de la entidad de
capa de protocolo inferior pendientes de ser retransmitidas, y el
contenido del buffer de la capa de protocolo inferior, si lo
hay, se transfiere a la entidad de capa de protocolo superior al
detectar un fallo en la recepción de una unidad de datos de
protocolo retransmitida.
7. El método, en conformidad con la
reivindicación 6, caracterizado porque las unidades de datos
de protocolo para ser retransmitidas por la entidad de capa de
protocolo inferior están indicadas como que están retrasadas en un
buffer de la capa de protocolo inferior.
8. El método, en conformidad con la
reivindicación 7, caracterizado porque si cualquier unidad de
datos de protocolo en el buffer de la capa de protocolo
inferior está indicado como que está retrasado, la entidad de capa
de protocolo inferior continúa procesando la siguiente unidad de
transmisión recibida.
9. El método, en conformidad con la
reivindicación 7, caracterizado porque si no hay una unidad
de datos de protocolo precedente en el buffer de la capa de
protocolo inferior indicada como que está siendo retrasada, el
contenido del buffer de la capa de protocolo inferior se
transfiere a la entidad de capa de protocolo superior.
10. El método, en conformidad con cualesquiera
de las reivindicaciones de la 6 a la 9, caracterizado porque
si la información de error en el transporte de la capa de protocolo
inferior no indica un error en la transmisión, las unidades de datos
de protocolo recibidas por la entidad de capa de protocolo inferior
se insertan en orden secuencial en un buffer de la capa de
protocolo inferior.
11. El método, en conformidad con la
reivindicación 1, caracterizado porque si la entidad de capa
de protocolo inferior detecta un fallo, la entidad de capa de
protocolo inferior indica el fallo en el buffer de la capa
de protocolo inferior.
12. El método, en conformidad con la
reivindicación 11, caracterizado porque si no hay una unidad
de datos de protocolo en el buffer de la capa de protocolo
inferior indicada como que está siendo retrasada, o si hay un
indicador de fallo en el buffer de la capa de protocolo
inferior, el contenido del buffer de la capa de protocolo
inferior se transfiere a la entidad de capa de protocolo
superior.
13. El método, en conformidad con cualesquiera
de las reivindicaciones 1-12, caracterizado
porque la entidad de capa de protocolo superior consigue una
solicitud de retransmisión de una unidad de datos de protocolo al
identificar a la unidad de datos de protocolo en un informe de
estado.
\newpage
14. El método, en conformidad con la
reivindicación 13, caracterizado porque el envío de un
informe de estado es desencadenado por al menos uno de entre:
- una indicación de fallo de la entidad de capa de protocolo inferior,
- la detección de que falta una unidad de datos de protocolo o unidad de carga útil,
- un temporizador de tiempo transcurrido y,
- un contador de unidades de datos de protocolo ya enviadas.
15. El método, en conformidad con cualesquiera
de las reivindicaciones 1-14, caracterizado
porque en la entidad de capa de protocolo inferior, los datos
retransmitidos se combinan con flexibilidad.
16. El método, en conformidad con cualesquiera
de las reivindicaciones 1-15, caracterizado
porque en la entidad de capa de protocolo inferior, las unidades de
transmisión se solicitan para una retransmisión en conformidad con
HARQ.
17. El método, en conformidad con cualesquiera
de las reivindicaciones 1-16, caracterizado
porque la unidad de transmisión es una ventana.
18. El método, en conformidad con cualesquiera
de las reivindicaciones 1-17, caracterizado
porque la unidad de transmisión comprende uno o más bloques de
transporte.
19. El método, en conformidad con cualesquiera
de las reivindicaciones 1-18, caracterizado
porque las transmisiones y retransmisiones son transmisiones en un
canal HSDPA.
20. Un aparato que comprende:
una primera entidad para implementar un
protocolo de capa inferior;
una segunda entidad para implementar un
protocolo de capa superior,
caracterizado porque dicha primera
entidad está concebida para identificar unidades de datos de
protocolo de capa superior que faltan o dañadas y para enviar a una
entidad emisora solicitudes para la retransmisión de estas unidades
de datos de protocolo, y para evitar que la entidad de capa de
protocolo superior envíe solicitudes para una retransmisión con
respecto a las mismas unidades de datos de protocolo al menos hasta
que la entidad de capa de protocolo inferior haya notificado a la
entidad de capa de protocolo superior del fallo en el envío de una
unidad de datos de protocolo.
21. El aparato, en conformidad con la
reivindicación 20, caracterizado porque dicha primera entidad
está concebida para transmitir un indicador de fallo a dicha
segunda entidad.
22. El aparato, en conformidad con la
reivindicación 20, caracterizado porque dicha primera entidad
está concebida para transmitir un indicador de retraso a dicha
segunda entidad.
23. El aparato, en conformidad con la
reivindicación 20, caracterizado porque dicha primera
entidad está concebida para establecer un indicador en un
buffer de la capa de protocolo inferior, indicando el
indicador las unidades de datos de protocolo solicitadas para su
retransmisión en la capa de protocolo inferior como que están
siendo retrasadas.
24. El aparato, en conformidad con la
reivindicación 20, caracterizado porque dicha primera
entidad está concebida para establecer un indicador en un
buffer de la capa de protocolo inferior, señalando el
indicador un fallo en la capa de protocolo inferior.
25. El aparato, en conformidad con cualesquiera
de las reivindicaciones de la 20 a la 24, caracterizado
porque el aparato es un equipo de usuario de un sistema de
comunicaciones.
26. El aparato, en conformidad con la
reivindicación 25, caracterizado porque el aparato es un
equipo de usuario de un sistema de comunicaciones móviles.
27. El aparato, en conformidad con cualesquiera
de las reivindicaciones de la 20 a la 24, caracterizado
porque el aparato es un elemento de red de un sistema de
comunicaciones.
28. El aparato, en conformidad con la
reivindicación 27, caracterizado porque el aparato es un
elemento de red de un sistema de comunicaciones móviles.
29. El aparato, en conformidad con la
reivindicación 28, en el que dicho aparato es una estación base o un
controlador de red de radio de un sistema de telecomunicaciones
móviles universal.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| SE0100739A SE0100739D0 (sv) | 2001-02-28 | 2001-02-28 | Method and system of retransmission |
| SE0100739 | 2001-02-28 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2294118T3 true ES2294118T3 (es) | 2008-04-01 |
Family
ID=20283214
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES02711598T Expired - Lifetime ES2294118T3 (es) | 2001-02-28 | 2002-02-08 | Metodo y aparato para evitar retransmisiones innecesarias en un sistema de radio celular de moviles. |
Country Status (7)
| Country | Link |
|---|---|
| EP (1) | EP1364482B1 (es) |
| AT (1) | ATE374472T1 (es) |
| DE (1) | DE60222637T2 (es) |
| ES (1) | ES2294118T3 (es) |
| SE (1) | SE0100739D0 (es) |
| TW (1) | TW546955B (es) |
| WO (1) | WO2002069547A1 (es) |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2242092C2 (ru) | 2001-07-06 | 2004-12-10 | Самсунг Электроникс Ко., Лтд. | Способ установки в исходное состояние объекта уровня управления доступом к среде в системе связи с широкополосным множественным доступом с кодовым разделением каналов, использующей высокоскоростной пакетный доступ к нисходящей линии связи |
| SE0200308D0 (sv) | 2001-12-27 | 2002-02-04 | Ericsson Telefon Ab L M | A method and apparatus relating to transmission of data |
| US6717927B2 (en) | 2002-04-05 | 2004-04-06 | Interdigital Technology Corporation | System for efficient recovery of node B buffered data following serving high speed downlink shared channel cell change |
| US7706405B2 (en) | 2002-09-12 | 2010-04-27 | Interdigital Technology Corporation | System for efficient recovery of Node-B buffered data following MAC layer reset |
| US7489691B2 (en) * | 2002-12-23 | 2009-02-10 | Nokia Corporation | Scheduling retransmission in access networks |
| CN1926819B (zh) | 2004-03-31 | 2012-02-08 | 艾利森电话股份有限公司 | 用于避免不必要的重传的方法和布置 |
| TWI544453B (zh) * | 2004-05-07 | 2016-08-01 | 內數位科技公司 | 傳輸增強上鏈資料之方法及裝置 |
| JP4499489B2 (ja) * | 2004-06-18 | 2010-07-07 | 株式会社エヌ・ティ・ティ・ドコモ | 送信装置、受信装置、通信システム及び通信方法 |
| GB0415451D0 (en) * | 2004-07-09 | 2004-08-11 | Nokia Corp | Communication system |
| US7558243B2 (en) * | 2004-09-15 | 2009-07-07 | Innovative Sonic Limited | Enhanced polling method for preventing deadlock in a wireless communications system |
| KR100703503B1 (ko) | 2004-11-30 | 2007-04-03 | 삼성전자주식회사 | 통신 시스템에서 데이터 재전송 장치 및 방법 |
| JP2006211632A (ja) * | 2005-01-26 | 2006-08-10 | Asustek Computer Inc | Ｃｒｃ検査範囲外エラーを検出する方法 |
| US8295265B2 (en) | 2005-11-16 | 2012-10-23 | Htc Corporation | Method for handling radio bearer messages during reset and reestablishment in a wireless system |
| JP2008154246A (ja) * | 2006-12-19 | 2008-07-03 | Asustek Computer Inc | プロトコルエラー回復方法及び通信装置 |
| US20100115365A1 (en) * | 2008-11-03 | 2010-05-06 | Industrial Technology Research Institute | System and method for data transmission |
| US11646835B2 (en) | 2018-10-08 | 2023-05-09 | Telefonaktiebolaget Lm Ericsson (Publ) | Transmission of a packet data convergence protocol (PDCP) protocol data unit (PDU) in a wireless communication network |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5677918A (en) * | 1995-07-28 | 1997-10-14 | Motorola, Inc. | Method and device for efficient error correction in a packet-switched communication system |
| JP3001435B2 (ja) * | 1996-10-24 | 2000-01-24 | 日本電気移動通信株式会社 | 確認形情報転送におけるデータ再送方法 |
| WO1999004510A1 (en) * | 1997-07-14 | 1999-01-28 | Hughes Electronics Corporation | Synchronization of a mobile satellite system with satellite switching |
-
2001
- 2001-02-28 SE SE0100739A patent/SE0100739D0/xx unknown
-
2002
- 2002-02-07 TW TW091102194A patent/TW546955B/zh not_active IP Right Cessation
- 2002-02-08 ES ES02711598T patent/ES2294118T3/es not_active Expired - Lifetime
- 2002-02-08 DE DE60222637T patent/DE60222637T2/de not_active Expired - Lifetime
- 2002-02-08 EP EP02711598A patent/EP1364482B1/en not_active Expired - Lifetime
- 2002-02-08 AT AT02711598T patent/ATE374472T1/de not_active IP Right Cessation
- 2002-02-08 WO PCT/SE2002/000230 patent/WO2002069547A1/en active IP Right Grant
Also Published As
| Publication number | Publication date |
|---|---|
| WO2002069547A1 (en) | 2002-09-06 |
| EP1364482A1 (en) | 2003-11-26 |
| DE60222637D1 (de) | 2007-11-08 |
| TW546955B (en) | 2003-08-11 |
| EP1364482B1 (en) | 2007-09-26 |
| ATE374472T1 (de) | 2007-10-15 |
| SE0100739D0 (sv) | 2001-02-28 |
| DE60222637T2 (de) | 2008-07-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10567119B2 (en) | Method and system of retransmission | |
| ES2350476T3 (es) | Método y sistema de retransmisión. | |
| ES2294118T3 (es) | Metodo y aparato para evitar retransmisiones innecesarias en un sistema de radio celular de moviles. | |
| FI106760B (fi) | Menetelmä ja laite tiedonsiirtopakettien uudelleenlähettämiseksi | |
| US9538428B2 (en) | Method and apparatus for performing handover using packet data convergence protocol (PDCP) reordering in mobile communication system | |
| ES2536071T3 (es) | Procedimiento para mover una ventana de recepción en una red de acceso de radio | |
| ES2245935T3 (es) | Protocolo de control flexible de radioenlace. | |
| KR100996069B1 (ko) | 이동통신 시스템에서 라디오 링크 제어 계층의 데이터 전송 방법 및 장치 | |
| ES2393829T5 (es) | Reporte de estado para el protocolo de retransmisión | |
| KR20090122986A (ko) | 패킷통신방법 및 수신측 장치 | |
| US20130294322A1 (en) | Apparatus and method for sequentially transmitting data | |
| KR20090125169A (ko) | 재송요구 송신방법, 송신측장치 및 수신측장치 | |
| KR20090098627A (ko) | 통신 시스템에서 상태 정보 전달 및 구성 방법 및 그시스템 | |
| CN102255714B (zh) | 重传的方法和*** | |
| KR101708786B1 (ko) | 무선링크제어계층에서의 데이터 전송 장치 및 방법 | |
| JP2010045845A (ja) | 再送信の方法とシステム |