ES2393829T5 - Reporte de estado para el protocolo de retransmisión - Google Patents
Reporte de estado para el protocolo de retransmisión Download PDFInfo
- Publication number
- ES2393829T5 ES2393829T5 ES08870289.9T ES08870289T ES2393829T5 ES 2393829 T5 ES2393829 T5 ES 2393829T5 ES 08870289 T ES08870289 T ES 08870289T ES 2393829 T5 ES2393829 T5 ES 2393829T5
- Authority
- ES
- Spain
- Prior art keywords
- terminal
- status report
- rlc
- protocol
- layer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
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/1607—Details of the supervisory signal
-
- 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/1848—Time-out mechanisms
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
Description
5
10
15
20
25
30
35
40
45
50
DESCRIPCION
Reporte de estado para el protocolo de retransmision Campo tecnico
La presente invencion se refiere generalmente a protocolos de retransmision para Control de Enlace de Radio (RLC - Radio Link Control, en ingles) en sistemas de comunicacion inalambricos y, mas particularmente, a reportar el estado para el protocolo de retransmision de RLC.
Antecedentes
El Proyecto de Colaboracion de Tercera Generacion (3GPP - Third Generation Partnership Project, en ingles) ha lanzado un proyecto, conocido como “Evolucion a Largo Plazo” o LTE (Long Term Evolution, en ingles), para desarrollar especificaciones para un sistema de comunicacion inalambrico avanzado. El estandar de LTE alude a un mecanismo de retransmision sea implementado en el protocolo de control de enlace de radio (RLC - Radio Link Control, en ingles). El protocolo de retransmision especificado es un protocolo de repeticion selectiva utilizado en “Modo de Reconocimiento de RLC”. Cuando se detecta una unidad de datos de protocolo (PDU - Protocol Data Unit, en ingles) faltante, un informe de estado que incluye un NACK de la PDU o las PDUs faltante o faltantes es enviado desde el terminal de recepcion al terminal de transmision. En respuesta al informe de estado, el terminal de transmision puede reenviar cualquier PDU perdida, o llevar a cabo otra accion segun sea apropiado. En LTE, un informe de estado puede ser tambien transmitido en respuesta a una solicitud de pregunta. Un terminal de transmision puede solicitar al terminal de recepcion informacion del estado de RLC. En respuesta a la pregunta, el terminal de recepcion envfa un informe de estado indicando el estado de RLC actual. Actualmente, no hay ningun mecanismo para la retransmision de una PDU de estado.
El documento EP 1641190 describe un metodo para retransmitir un informe de estado en caso de un fallo en la entrega de ese informe de estado. El documento R2-073895, del 3GPP TSG-RAN WG2 Reunion N° 59bis, describe el uso de un temporizador en la capa de RLC para activar una re-transmision de un informe de estado actualizado.
Compendio
La presente invencion se refiere generalmente a protocolos de retransmision para la capa de Control de Enlace de Radio (RLC - Radio Link Control, en ingles) en redes de comunicacion de telefoma movil. La presente invencion resulta util en los sistemas de comunicacion basados en el estandar de Evolucion a Largo Plazo (LTE - Long Term Evolution, en ingles), pero tambien puede ser implementada en sistemas de comunicacion basados en otros estandares. En los sistemas de LTE, PDUs de estado de RLC son transmitidas de un terminal de recepcion a un terminal de transmision cuando se detecta una PDU de datos faltante para indicar el estado del RLC. Los informes de estado pueden ser tambien enviados en respuesta a una senal de pregunta desde el terminal de transmision Las PDUs de estado de RLC son bajadas a la capa de MAC y transmitidas en una o mas PDUs de Control de Acceso a Medio (MAC - Medium Access Control, en ingles). El protocolo de MAC incluye un mecanismo de ARQ hnbrido (HARQ - Hybrid ARQ, en ingles). Si una PDU de MAC que transporta una PDU de estado de RLC no es correctamente recibida por el terminal de transmision, el protocolo de MAC proporciona una indicacion de fallo denominada en esta memoria un NACK local (NACK - Non ACKnowledged, en ingles) al protocolo de RLC. El NACK local indica a la capa de protocolo de RLC que el informe de estado transmitido previamente no fue correctamente proporcionado a la capa de RLC correspondiente en el terminal de transmision. Por lo tanto, en respuesta al nAcK local desde la capa de protocolo de MAC, la capa de protocolo de RLC puede enviar una PDU de estado de RLC actualizada.
De manera mas general, la presente invencion proporciona un mecanismo para la retransmision de un estado de RLC para un protocolo de retransmision. Un informe de estado es generado y enviado a un terminal remoto de acuerdo con el protocolo de capa superior. El informe de estado es transmitido en una o mas PDUs de un protocolo de capa inferior. Si la transmision de una de las PDUs de capa inferior falla, el protocolo de capa inferior proporciona una indicacion de fallo al protocolo de capa superior. En respuesta a la indicacion de fallo, el protocolo de capa superior genera y envfa un informe de estado actualizado. En una realizacion de ejemplo, el protocolo de capa superior comprende un protocolo de control de enlace de radio y el protocolo de capa inferior comprende un protocolo de control de acceso a medio.
Breve descripcion de los dibujos
La Fig. 1 ilustra un sistema de comunicacion simplificado que incluye un terminal de transmision y un terminal de recepcion.
La Fig. 2 ilustra una pila de protocolo de ejemplo para comunicaciones entre un terminal de transmision y un terminal de recepcion.
5
10
15
20
25
30
35
40
45
50
55
La Fig. 3 ilustra un metodo de reportar un estado de ejemplo para un protocolo de enlace de radio implementado por un terminal de comunicacion.
La Fig. 4 ilustra un terminal de comunicacion de ejemplo.
La Fig. 5 ilustra un procesador de ejemplo para un terminal de comunicacion para implementar el metodo de reportar un estado mostrado en la Fig. 3.
Descripcion detallada
En referencia ahora a los dibujos, la presente invencion se describira en el contexto de un sistema de comunicacion mediante telefoma movil 10 de ejemplo basado en los estandares de Evolucion a Largo Plazo (LTE - Long Term Evolution, en ingles) que son desarrollados por el Proyecto de Colaboracion de Tercera Generacion (3GPP - Third Generation Partnership Project, en ingles). Resultara evidente para los expertos en la materia, no obstante, que la presente invencion puede ser utilizada tambien en sistemas de comunicacion de telefoma movil 10 basados en otros estandares conocidos en la actualidad o que se desarrollen posteriormente. Asf, la siguiente descripcion debe verse como ilustrativa y no limitativa.
El sistema de comunicacion 10, mostrado en la Fig. 1, comprende un terminal de transmision 20 y un terminal de recepcion 30. El terminal de transmision 20 transmite datos sobre un canal de comunicacion 40 al terminal de recepcion 30. El terminal de transmision 20 puede comprender una estacion de base en una red de LTE, llamada a veces Nodo B Evolucionado (eNodoB - Evolved Node B, en ingles), y el terminal de recepcion 30 puede comprender un terminal de usuario (por ejemplo, un telefono movil, PDA, ordenador portatil, etc.). Alternativamente, el terminal de transmision 20 puede comprender un terminal de usuario y el terminal de recepcion 30 puede comprender una estacion de base. Resultara tambien evidente que el terminal de transmision 20 y el terminal de recepcion 30 pueden cada uno comprender un terminal de comunicacion 100 (Fig. 4) con un transceptor para comunicaciones en los dos sentidos. Los terminos “de transmision” y “de recepcion” se utilizan asf en esta memoria para indicar la direccion de la comunicacion entre dos terminales de comunicacion.
La Fig. 2 proporciona una vision general de la arquitectura del protocolo de LTE 200, para las comunicaciones entre un terminal de transmision 20 y un terminal de recepcion 30 en los sistemas de LTE.
La pila de protocolo de LTE 200 es una pila de protocolo de capas. Cada capa de la pila de protocolo 200 representa un conjunto de protocolos o funciones necesarios para comunicarse sobre el canal de comunicacion 40. La pila de protocolo 200 en el LTE incluye una capa ffsica (PHY - PHYsical, en ingles) 240, la capa de control de acceso a medio (MAC - Medium Access Control, en ingles) 230, la capa de control de enlace de radio (RLC - Radio Link Control, en ingles) 220 y la capa de protocolo de convergencia de datos en paquetes (PDCP - Packet Data Convergence Protocol, en ingles) 210. La pila de protocolo 200 es tfpicamente implementada por un procesador programado especialmente.
Los datos del plano de usuario en forma de paquetes de IP para ser transmitidos entran en la capa de PDCP 210 donde las cabeceras de IP pueden estar comprimidas para reducir el numero de bits transmitidos sobre la interfaz aerea. La capa de PDCP 210 tambien lleva a cabo el cifrado y el descifrado de los paquetes de IP para seguridad. La capa de RLC 220 asegura una entrega en secuencia, casi libre de errores de paquetes de IP comprimidos a la capa de PDCP 210 en el terminal de recepcion 30, lo cual se necesita para ciertos tipos de comunicacion. En el terminal de transmision 20, la capa de RLC 220 segmenta y/o concatena paquetes de IP comprimidos recibidos sobre portadores de radio desde la capa de PDCP 210 para crear unidades de datos de protocolo (PDUs - Protocol Data Units, en ingles) de RLC. En el terminal de recepcion 30, las PDUs de RLC recibidas son reensambladas en paquetes de IP comprimidos y entregadas a la capa de PDCP 210. La capa de RLC 220 implementa un protocolo de retransmision descrito con mas detalle a continuacion para manejar la retransmision de PDUs de RLC faltantes o recibidas erroneamente. La capa de MAC 230 ofrece servicios a la capa de RLC 220 en forma de canales logicos. La capa de MAC 230 mapea las PDUs de RLC recibidas desde la capa de RLC 220 en varios canales logicos a canales de transporte correspondientes. La capa de MAC 230 es tambien responsable de la planificacion del enlace ascendente y del enlace descendente. Las PDUs de MAC son alimentadas por la capa de MAC 230 a la capa PHY 240. La capa PHY 240 maneja la codificacion / descodificacion, modulacion / desmodulacion, intercalado y difusion antes de la transmision de una o mas PDUs de capa PHY.
En los sistemas de comunicacion 10 que implementan los estandares de LTE, un protocolo de retransmision es implementado tanto en la capa de MAC 230 como en la capa de RLC 220. Un protocolo de ARQ Hfbrida (HARQ - Hybrid ARQ, en ingles) es implementado en la capa de MAC 230 para reducir la tasa de error aproximadamente a 1%. Un segundo protocolo de retransmision es implementado en la capa de RLC 220 para corregir errores residuales y para reducir mas la tasa de error al orden de aproximadamente 10-6. Convencionalmente, el protocolo de HARQ implementado en la capa de MAC 230 y el protocolo de retransmision implementado en la capa de RLC 220 son independientes.
5
10
15
20
25
30
35
40
45
50
55
En LTE, el protocolo de retransmision de RLC es implementado para las PDUs de datos de RLC transmitidas en un modo de reconocimiento (AM - Acknowledged Mode, en ingles)). Cada PDU de datos de RLC incluye un campo de numero de secuencia que contiene el numero de secuencia de la PDU de datos. Los numeros de secuencia son utilizados por la capa de RLC 220 en el terminal de recepcion 30 para detectar PDUs faltantes y para reordenar las PDUs de datos antes de que sean entregadas a la capa de PDCP 210. Cuando se detecta un hueco en el numero de secuencia de las PDUS de datos de RLC recibidas en el terminal de recepcion 30, la capa de RLC 220 en el terminal de recepcion 30 genera y envfa un informe de estado al terminal de transmision 20. Tfpicamente, el informe de estado esta contenido en la pDu de estado de RLC.
La PDU de estado de RLC incluye un campo de Numero de Secuencia de Reconocimiento (ACK_SN - Acknowledgement Sequence Number, en ingles) que indica la secuencia mas baja de entre las PDUs de datos de RLC que no han sido ni recibidas ni detectadas como perdidas por el terminal de recepcion 30. La PDU de estado de RLC incluye tambien uno o mas campos de Numero de Secuencia de Reconocimiento Negativo (NACK_SN - Negative Acknowledgement Sequence Number, en ingles) que identifican las PDUs de datos de RLC detectadas como perdidas por el terminal de recepcion 30. Asf, cuando un terminal de transmision 20 recibe una PDU de estado de RLC, determina que todas las PDUs de datos de RLC hasta, pero que no incluyen a, la PDU correspondiente al NACK_SN han sido recibidas, excepto aquellas PDUS de datos de RLC identificadas por los uno o mas campos de NACK_SN.
Una PDU de estado de RLC puede ser tambien enviada en respuesta a una solicitud de pregunta. En LTE, la capa de RLC 220 en el terminal de transmision 20 puede solicitar una PDU de estado de RLC del terminal de recepcion 30 insertando una solicitud de pregunta en una PDU de datos. Una PDU de datos de RLC puede incluir un campo de pregunta que contiene un indicador de pregunta de un unico bit. Tfpicamente, el indicador de pregunta es puesto a un valor de “1” para solicitar un informe de estado del terminal de recepcion 30. En respuesta a una PDU de datos de RLC en la cual el bit de pregunta P es puesto a “1”, la capa de RLC 220 en el terminal de recepcion 30 puede generar una PDU de estado del RLC.
Convencionalmente, una PDU de estado de RLC es enviada en un modo no reconocido. Por lo tanto, el terminal de recepcion 30 no tiene modo de determinar si la PDU de estado del RLC fue correctamente recibida en el terminal de transmision 20. Asf, no existe ningun mecanismo en el protocolo de retransmision de RLC para la retransmision de una PDU de estado de RLC. Si la PDU de estado de rLc se pierde, entonces la transmision de las PDUs de datos de RLC faltantes del terminal de transmision 20 al terminal de recepcion 30 sera retardada hasta que una nueva PDU de estado de RLC sea transmitida por el terminal de recepcion 30.
De acuerdo con realizaciones de ejemplo de la presente invencion, las indicaciones de fallo de HARQ generadas por la capa de MAC 230 pueden ser utilizadas para activar la transmision de una PDU de estado de RLC actualizada por parte de la capa de RLC 220. La capa de MAC 230 generara la indicacion de fallo de HARQ independientemente de la carga util transportada por la correspondiente PDU de RLC. Estas indicaciones de fallo pueden ser utilizadas para generar una indicacion de NACK local que es proporcionada por la capa de RLC 220 (Fig. 2). Asf, cuando la capa de RLC 220 en el terminal de recepcion 30 recibe un NACK local desde la capa de MAC 230 despues del envfo de la PDU de estado de RLC, la capa de RLC 220 puede generar y transmitir una nueva PDU de estado de RLC. La PDU de estado de RLC antigua puede ser despreciada porque la informacion de estado puede haber cambiado desde la transmision de la PDU de estado de RLC original. Por ejemplo, pueden haberse recibido nuevas PDUs desde el momento en que la PDU de estado de RLC original fue enviada.
La Fig. 3 ilustra un metodo de reportar un estado de ejemplo para un protocolo de retransmision de RLC de acuerdo con una realizacion de ejemplo. En la Fig. 3, se asume que el Terminal A (el terminal de recepcion 30) esta recibiendo PDUs de datos de RLC desde el Terminal B (el terminal de transmision 20). En la Fig. 3, el Terminal A detecta una PDU de datos faltante basandose en los numeros de secuencia de las PDUs de datos de RLC recibidas y genera una PDU de estado de RLC (etapa a) cuando se detecta una PDU de datos faltante. Tanto las capas de RLC como de MAC 220, 230 se muestran al Terminal A, pero solo la capa de MAC 230 se ilustra para el Terminal B. La PDU de estado de RLC es pasada desde la capa de RLC 220 a la capa de MAC 230 en el Terminal A (etapa b). La capa de MAC 230 en el Terminal A crea una o mas PDUs de MAC a partir de la PDU de estado de RLC y transmite las PDUs de MAC que contienen la PDU de estado de RLC al Terminal B (etapa c). Resultara evidente para los expertos en la materia que cada PDU de MAC puede transportar una PDU de estado de RLC. Alternativamente, la capa de MAC 230 puede segmentar la PDU de estado de RLC, o concatenar multiples PDUs de estado de RLC para crear las PDUs de MAC.
En el ejemplo ilustrado, se asume que la capa de MAC 230 en el Terminal B no recibe una PDU de MAC que transporta toda o parte de la PDU de estado de RLC y envfa un NACK a la capa de MAC 230 en el Terminal A para solicitar la retransmision de la PDU de MAC (etapa d). La capa de MAC 230 en el Terminal A retransmitira la PDU de MAC faltante un numero predeterminado de veces (etapa e). El NACK de la retransmision final de la PDU de MAC denota un fallo de HARQ (etapa f). En respuesta al fallo de HARQ, la capa de MAC 230 en el Terminal A genera y envfa un NACK local en la capa de RLC 220 en el Terminal A (etapa g). La capa de RLC 220 interpreta este NACK local como una indicacion de que la transmision de una PDU de ESTADO al Terminal B fue fallida.
5
10
15
20
25
30
35
En respuesta al NACK local, la capa de RLC 220 en el Terminal A desprecia el informe de estado de RLC y crea un nuevo informe de estado de RLC con la ultima informacion (etapa h). Este nuevo informe de estado de RLC es a continuacion transmitido en lugar de retransmits el informe de estado de RLC antiguo, que puede contener informacion imprecisa. El nuevo informe de estado de RLC contenido en una o mas PDUs de estado es pasado de la capa de RLC 220 a la capa de MAC 230 en el Terminal A (etapa i). La capa de MAC 230 en el Terminal A crea una o mas PDUs de MAC a partir de las PDUs de estado de RLC y transmite las PDUs de MAC al Terminal B (etapa
j).
En LTE, un terminal de transmision 20 puede solicitar al terminal de recepcion 30 informacion del estado de RLC. Por ejemplo, una pregunta es tfpicamente enviada por el terminal de transmision 20 al terminal de recepcion 30 despues de transmitir la ultima PDU de datos de RLC en una memoria temporal de transmision. El terminal de transmision 20 inicia un temporizador de pregunta cuando la solicitud de pregunta es enviada. Cuando el terminal de recepcion 30 recibe una solicitud de pregunta, inmediatamente envfa una PDU de estado de RLC al terminal de transmision 20 indicando el estado de RLC e inicia un temporizador de prohibicion de estado para prohibir la transmision de un segundo informe de estado hasta que el temporizador de prohibicion de estado expira. Asf, una PDU de estado de RLC en respuesta a la deteccion de una PDU de datos de RLC faltante puede ser prohibida por el temporizador de prohibicion de estado en algunas circunstancias.
En una realizacion de ejemplo, la capa de RLC 220 en el Terminal A puede distinguir los eventos que activaron la PDU de estado de RLC original. En la situacion en la que la PDU de estado de RLC original fue activada por una solicitud de pregunta, el temporizador de pregunta en el Terminal B excedera el tiempo para activar una nueva solicitud de pregunta. En este caso no necesita enviarse ningun informe de estado nuevo basandose en el NACK local porque una nueva solicitud de pregunta fue activada por el temporizador de pregunta. Cuando una PDU de datos de RLC faltante activa la PDU de estado de RLC original, una nueva PDU de estado de RLC debe ser generada y enviada en respuesta al NACK local porque el otro terminal no detecta la PDU de estado de RLC y no hay ningun temporizador de pregunta corriendo. En situaciones en las que la PDU de estado de RLC original es activada por una solicitud de pregunta, el temporizador de prohibicion de estado permite que una subsiguiente PDU de estado de RLC sea enviada inmediatamente cuando se detecta una PDU de datos de RLC faltante sin tener que esperar a la expiracion del temporizador de prohibicion de estado.
La Fig. 4 ilustra un terminal de comunicacion 100 de ejemplo que implementa el protocolo de retransmision y un metodo de reportar un estado tal como el descrito previamente. El terminal de comunicacion 100 puede funcionar como un terminal de transmision 20, un terminal de recepcion 30 o ambos. El terminal de comunicacion 100 comprende un transceptor 110 conectado a una antena 112, un procesador 120 y memoria 130. El transceptor 110 permite al terminal de comunicacion 100 transmitir senales a y recibir senales desde un terminal remoto. El terminal de comunicacion 100 puede comprender, por ejemplo, un transceptor celular convencional de acuerdo con el estandar de LTE, el estandar de WCDMA u otro estandar de comunicacion no conocido o desarrollado posteriormente. El procesador 120 procesa las senales transmitidas y recibidas por el transceptor 110 y controla la operacion del terminal de comunicacion 100. El procesador 120, mostrado en la Fig. 5, incluye un modulo de PDCP 122, un modulo de RLC 124 y un modulo de Mac 126 para implementar los protocolos de PDCP, RLC y MAC, respectivamente. La memoria 130 almacena programas y datos necesarios para la operacion.
Claims (12)
- 51015202530354045REIVINDICACIONES1. Un metodo de transmitir un informe de estado desde un terminal de recepcion (30) hasta un terminal de transmision (20), comprendiendo el metodo las etapas de:generar, por el citado terminal de recepcion (30), un informe de estado de acuerdo con un protocolo de capa superior;enviar la unidad de datos del informe de estado desde el citado terminal de recepcion (30) al citado terminal de transmision (20) en una o mas unidades de datos de un protocolo de capa inferior;proporcionar una indicacion de fallo desde el citado protocolo de capa inferior al citado protocolo de capa superior indicando que la transmision de las una o mas unidades de datos de capa inferior fue fallida; yen respuesta a la citada indicacion de fallo, generar un informe de estado actualizado en el citado terminal de recepcion (30) y enviar el citado informe de estado actualizado desde el citado terminal de recepcion (30) al citado terminal de transmision (20).
- 2. El metodo de acuerdo con la reivindicacion 1, en el que el citado informe de estado actualizado no es generado o enviado si el citado informe de estado original fue enviado en respuesta a una solicitud de pregunta.
- 3. El metodo de acuerdo con una cualquiera de las reivindicaciones 1-2 que comprende tambien detener un temporizador de prohibicion de estado en respuesta a la citada indicacion de fallo.
- 4. El metodo de acuerdo con una cualquiera de las reivindicaciones 1-3, en el que el citado protocolo de capa superior comprende un protocolo de control de enlace de radio, y en el que el citado protocolo de capa inferior comprende un protocolo de control de acceso a medio.
- 5. El metodo de acuerdo con una cualquiera de las reivindicaciones 1-4, llevado a cabo por un terminal de usuario en comunicacion con una estacion de base.
- 6. El metodo de acuerdo con una cualquiera de las reivindicaciones 1-4 llevado a cabo por una estacion de base en comunicacion con un terminal de usuario.
- 7. Un terminal de comunicacion (100) que comprende: un transceptor (110);un procesador (120) configurado para:generar una unidad de datos de informe de estado de acuerdo con un protocolo de capa superior;enviar la unidad de datos de informe de estado desde un terminal de recepcion (30) hasta un terminal de transmision (20) en una o mas unidades de datos formateadas de acuerdo con un protocolo de capa inferior;proporcionar una indicacion de fallo desde el citado protocolo de capa inferior al citado protocolo de capa superior indicando que la transmision de las una o mas unidades de datos de capa inferior fue fallida; yen respuesta a la citada indicacion de fallo, generar un informe de estado actualizado y enviar el citado informe de estado actualizado desde el citado terminal de recepcion (30) hasta el citado terminal de transmision (20).
- 8. El terminal de comunicacion (100) de acuerdo con la reivindicacion 7, en el que el procesador no genera o envfa el citado informe de estado actualizado si el citado informe de estado original fue enviado en respuesta a una solicitud de pregunta.
- 9. El terminal de comunicacion (100) de acuerdo con una cualquiera de las reivindicaciones 7-8, en el que el procesador esta configurado para detener un temporizador de prohibicion de estado en respuesta a la citada indicacion.
- 10. El terminal de comunicacion (100) de acuerdo con una cualquiera de las reivindicaciones 7-9, en el que el citado protocolo de capa superior comprende un protocolo de control de enlace de radio, y en el que el citado protocolo de capa inferior comprende un protocolo de control de acceso a medio.
- 11. El terminal de comunicacion (100) de acuerdo con una cualquiera de las reivindicaciones 7-10 que comprende un terminal de usuario.
- 12. El terminal de comunicacion (100) de acuerdo con una cualquiera de las reivindicaciones 7-10, que comprende una estacion de base.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US1941708P | 2008-01-07 | 2008-01-07 | |
US19417P | 2008-01-07 | ||
PCT/SE2008/051380 WO2009088343A1 (en) | 2008-01-07 | 2008-12-01 | Status reporting for retransmission protocol |
Publications (2)
Publication Number | Publication Date |
---|---|
ES2393829T3 ES2393829T3 (es) | 2012-12-28 |
ES2393829T5 true ES2393829T5 (es) | 2016-03-08 |
Family
ID=40577941
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES08870289.9T Active ES2393829T5 (es) | 2008-01-07 | 2008-12-01 | Reporte de estado para el protocolo de retransmisión |
Country Status (8)
Country | Link |
---|---|
US (1) | US9871625B2 (es) |
EP (1) | EP2229745B2 (es) |
JP (1) | JP5215413B2 (es) |
DK (1) | DK2229745T4 (es) |
ES (1) | ES2393829T5 (es) |
IL (1) | IL206247A (es) |
TW (1) | TWI486016B (es) |
WO (1) | WO2009088343A1 (es) |
Families Citing this family (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5164976B2 (ja) * | 2007-05-01 | 2013-03-21 | 株式会社エヌ・ティ・ティ・ドコモ | 受信周期制御方法、無線基地局及び移動局 |
CA2692649C (en) * | 2008-02-01 | 2015-07-07 | Lg Electronics Inc. | Method for sending rlc pdu and allocating radio resource in mobile communications system and rlc entity of mobile communications |
KR101531419B1 (ko) | 2008-02-01 | 2015-06-24 | 엘지전자 주식회사 | 시간동기 타이머의 만료 시 상향링크 harq의 동작 방법 |
KR101375936B1 (ko) | 2008-02-01 | 2014-03-18 | 엘지전자 주식회사 | 시간동기 타이머의 만료 시 하향링크 harq의 동작 방법 |
KR20110016455A (ko) | 2008-05-30 | 2011-02-17 | 인터디지탈 패튼 홀딩스, 인크 | 비액세스 계층 재송신의 전달 통지를 위한 방법 및 장치 |
US8565756B2 (en) * | 2011-01-07 | 2013-10-22 | Apple Inc. | Control of measurement messaging in a mobile device |
CN102761905B (zh) * | 2011-04-26 | 2016-03-30 | 华为技术有限公司 | 消息处理方法、设备及系统 |
CN102420828B (zh) * | 2011-12-15 | 2014-11-05 | 华为技术有限公司 | 协议管理状态的设置方法、装置和系统 |
US9172510B2 (en) * | 2011-12-21 | 2015-10-27 | Qualcomm Incorporated | Systems and methods for improved recovery for the downlink |
US20140301362A1 (en) * | 2013-04-04 | 2014-10-09 | Nokia Siemens Networks Oy | Delivery of protocol data units |
WO2016182220A1 (en) * | 2015-05-11 | 2016-11-17 | Lg Electronics Inc. | Method for performing rlc retransmission based on contention-based pusch in a wireless communication system and a device therefor |
CN107094299B (zh) * | 2016-02-18 | 2021-03-12 | 中国移动通信集团公司 | 自适应于接入网架构的数据处理方法及接入网架构 |
CN107592186A (zh) * | 2016-07-08 | 2018-01-16 | 电信科学技术研究院 | 一种进行数据重传的方法和设备 |
KR102392902B1 (ko) * | 2016-10-14 | 2022-05-02 | 가부시키가이샤 엔티티 도코모 | 무선통신장치 |
WO2018204266A1 (en) * | 2017-05-02 | 2018-11-08 | Intel IP Corporation | Methods, systems, and apparatus to aggregate retransmissions |
CN112865930A (zh) * | 2019-11-27 | 2021-05-28 | 上海华为技术有限公司 | 一种发送轮询报文的方法、相关装置和系统 |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1465369A1 (en) * | 2003-03-31 | 2004-10-06 | Matsushita Electric Industrial Co., Ltd. | Reset synchronisation method for a retransmission protocol |
US7525908B2 (en) * | 2004-09-24 | 2009-04-28 | M-Stack Limited | Data unit management in communications |
ATE486430T1 (de) | 2004-09-24 | 2010-11-15 | Research In Motion Ltd | Steuerprotokoll für funkverbindungen |
KR101266207B1 (ko) * | 2005-10-04 | 2013-05-21 | 엘지전자 주식회사 | Rlc 재설정을 위한 무선통신 시스템 및 그 방법 |
CN101346925A (zh) | 2005-11-30 | 2009-01-14 | 诺基亚公司 | 利用多arq机制提供重传的装置、方法和计算机程序产品 |
WO2008024282A2 (en) * | 2006-08-21 | 2008-02-28 | Interdigital Technology Corporation | Method and apparatus for controlling arq and harq transmissions and retranmissions in a wireless communication system |
US8335189B2 (en) | 2007-09-28 | 2012-12-18 | Interdigital Patent Holdings, Inc. | Operation of control protocol data units in packet data convergence protocol |
-
2008
- 2008-12-01 ES ES08870289.9T patent/ES2393829T5/es active Active
- 2008-12-01 JP JP2010541417A patent/JP5215413B2/ja not_active Expired - Fee Related
- 2008-12-01 WO PCT/SE2008/051380 patent/WO2009088343A1/en active Application Filing
- 2008-12-01 DK DK08870289.9T patent/DK2229745T4/en active
- 2008-12-01 US US12/811,732 patent/US9871625B2/en not_active Expired - Fee Related
- 2008-12-01 EP EP08870289.9A patent/EP2229745B2/en not_active Not-in-force
- 2008-12-17 TW TW097149213A patent/TWI486016B/zh not_active IP Right Cessation
-
2010
- 2010-06-08 IL IL206247A patent/IL206247A/en not_active IP Right Cessation
Also Published As
Publication number | Publication date |
---|---|
TWI486016B (zh) | 2015-05-21 |
JP5215413B2 (ja) | 2013-06-19 |
EP2229745B1 (en) | 2012-09-12 |
WO2009088343A1 (en) | 2009-07-16 |
US9871625B2 (en) | 2018-01-16 |
EP2229745B2 (en) | 2015-11-18 |
JP2011509041A (ja) | 2011-03-17 |
IL206247A (en) | 2013-11-28 |
ES2393829T3 (es) | 2012-12-28 |
IL206247A0 (en) | 2010-12-30 |
DK2229745T4 (en) | 2016-02-15 |
DK2229745T3 (da) | 2013-01-07 |
TW200935812A (en) | 2009-08-16 |
EP2229745A1 (en) | 2010-09-22 |
US20100278051A1 (en) | 2010-11-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2393829T5 (es) | Reporte de estado para el protocolo de retransmisión | |
US11849017B2 (en) | Protocol synchronization for HARQ | |
KR101532789B1 (ko) | 재전송 데이터를 처리하는 harq 동작 방법 | |
US6601207B1 (en) | Method and a device for re-transmitting data transfer packets | |
KR101577451B1 (ko) | Rlc 무한 재전송 오류를 검출하고 처리하는 방법 | |
ES2903025T3 (es) | Protocolo de solicitud de repetición automática (ARQ) que tiene múltiples mecanismos de retroalimentación complementarios | |
US8930785B2 (en) | Method for transmitting a data block in radio communication system | |
US8493861B2 (en) | Method and transmitting unit for reducing a risk of transmission stalling | |
US20090319850A1 (en) | Local drop control for a transmit buffer in a repeat transmission protocol device | |
KR100662250B1 (ko) | 서비스데이터유닛의 가변적 분할 송신 방법 및 그를이용한 송신 장치 |