ES2924981T3

ES2924981T3 - Un método y un dispositivo para informes de estado mejorados

Info

Publication number: ES2924981T3
Application number: ES19188004T
Authority: ES
Inventors: Johan Torsner; Michael Meyer; Henning Wiemann
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2007-02-01
Filing date: 2008-01-28
Publication date: 2022-10-13
Anticipated expiration: 2028-01-28
Also published as: JP2012235510A; MA31168B1; CN103905167A; US8982870B2; EP2985941B1; CN103905167B; BRPI0807057A2; US9729278B2; US20150155977A1; ES2754077T3; HUE025844T2; EP3614595B1; PL2985941T3; EP2985941A1; EP2108223B1; JP2010518683A; CN101663850B; US8036150B2; PT2108223E; CA2676002C

Abstract

La invención da a conocer un método (700) para un sistema celular (100), en el que se puede intercambiar tráfico entre el primer (110, 120) y el segundo (110, 120) transceptores. El tráfico se envía en unidades de datos, cada una de las cuales recibe un identificador, y dichas unidades de datos pueden dividirse en segmentos. Un transceptor receptor (110, 120) puede enviar información de estado en tramas de datos o unidades de datos (200, 300) sobre unidades de datos recibidas correctamente, parcialmente recibidas o no recibidas a un transceptor emisor, es decir, el transceptor desde el cual se enviaron los datos. . En el caso (705) de unidades de datos recibidas parcialmente o no recibidas, la información de estado incluye (710) información sobre si la unidad o unidades de datos no se recibieron o se recibieron parcialmente, y en el caso de una o más unidades de datos recibidas parcialmente , que (715) partes de esas unidades de datos que no se recibieron. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Un método y un dispositivo para informes de estado mejorados

Campo técnico

La presente invención divulga un método para su uso en un sistema de comunicaciones celulares, en cuyo sistema se puede intercambiar tráfico entre un primer y un segundo transceptor. El tráfico se envía en unidades de datos, a cada una de las cuales se proporciona un identificador, y las cuales pueden ser divididas en segmentos. Un transceptor de recepción puede enviar información de estado en tramas de datos o en unidades de datos acerca de las unidades de datos transmitidas hasta un transceptor de transmisión, es decir, hasta el transceptor desde el que fueron transmitidos los datos.

Antecedentes

En el proyecto LTE de 3GPP (Proyecto Partnership de 3a Generación, Evolución a Largo Plazo) para sistemas de comunicación celular, se utiliza un protocolo RLC (Control de Enlace de Radio) para la comunicación entre los usuarios de una célula y el nodo controlador de la célula, es decir, el denominado eNodeB, “NodeB evolucionado”. En el RLC, el tráfico se envía según las denominadas PDUs, es decir, Unidades de Datos de Protocolo, las cuales son identificadas dándoles números de secuencia. En respuesta a las PDUs procedentes de una parte transmisora, la parte receptora envía las denominadas PDUs de estado de RLC a la parte transmisora, con los denominados ACKs y/o NACKs, es decir, reconocimientos (ACK) de que los datos han sido recibidos apropiadamente, o información (NACK) de que los datos no han sido recibidos apropiadamente, es decir, recibidos solamente en parte o ninguno en absoluto. Los ACKs y los NACKs en las PDUs de estado de RLC son enviados como números de secuencia de PDU, con el fin de identificar la PDU en cuestión.

En sistemas LTE, las PDUs de RLC pueden ser segmentadas, lo que tiene como consecuencia que existan dos o más segmentos de PDU con el mismo número de secuencia, puesto que el número de secuencia es una propiedad de la PDU. El proceso de segmentación de PDUs se menciona también como re-segmentación.

Debido a la re-segmentación en LTE, los números de secuencia no serán suficientes para identificar los datos para los cuales se envía ACK o NACK.

Sumario

Según se desprende de la explicación que antecede, existe una necesidad de una solución por medio de la cual puedan ser identificados los ACKs y los NACKs que son transmitidos por una parte receptora hasta una parte de envío en sistemas LTE de 3G, con respecto a los segmentos de datos que se envíen como respuesta a los mismos. Además, otra necesidad que podría ser direccionada por la solución en cuestión consiste en que debería ser posible enviar un número variable de NACKs.

La invención está definida por un método, en un equipo de usuario de un sistema de comunicaciones celulares y un equipo de usuario para un sistema de comunicación celular conforme a las reivindicaciones anexas 1 y 11, respectivamente.

Esta necesidad ha sido abordada por la presente invención dado que ésta divulga un método para su uso en un sistema de comunicaciones celulares según la reivindicación anexa 1, en el que se puede intercambiar tráfico de sistema entre un primer y un segundo transceptor. El tráfico es enviado en el sistema en unidades de datos, a cada una de las cuales se ha dado un identificador. Las unidades de datos pueden ser divididas en segmentos, y un transceptor de recepción puede enviar información de estado en tramas de datos o en unidades de datos acerca de las unidades de datos recibidas parcialmente recibidas o no recibidas, hasta un transceptor de envío, es decir, hasta el transceptor desde el que fueron enviados los datos. El transceptor de recepción puede enviar información del estado en tramas de datos o unidades de datos acerca de unidades de datos propiamente recibidas al transceptor de envío.

Conforme al método de la invención, en el caso de una o más unidad o unidades de datos recibidas parcialmente o no recibidas, la información de estado que se envía al transceptor de envío incluye información acerca de si la unidad o unidades de datos no fueron recibidas o fueron recibidas parcialmente, y en el caso de una o más unidad o unidades de datos parcialmente recibidas, qué partes de la unidad o unidades de datos no fueron recibidas.

De ese modo, mediante la invención, resulta posible que el transceptor de recepción identifique claramente las partes no recibidas de las unidades de datos para el transceptor de envío, permitiendo de ese modo, a su vez, que el transceptor de envío retransmita esas partes.

También, la invención hace que sea posible identificar en mayor o menor medida cualquier cantidad de datos no recibidos, lo que ha sido otra de las necesidades a las que va dirigida la invención.

En una realización de la invención, la información acerca de si una unidad datos fue o no recibida o fue parcialmente recibida, se incluye a modo de banderola en dichas tramas de datos o unidades de datos.

En otra realización, la información acerca de qué partes de una unidad de datos no fueron recibidas, se incluye en las tramas de datos o en las unidades de datos a modo de información que indica una primera y una última parte de los datos no recibidos.

Según otra realización más de la presente invención, en el caso de que una trama de datos o una unidad de datos procedente del transceptor de envío hayan sido segmentadas y uno o más de los últimos segmentos no hayan alcanzado el transceptor de recepción, esta circunstancia puede ser indicada por el transceptor de recepción al transceptor de envío.

Dicha indicación acerca de un segmento perdido se puede llevar a cabo mediante un valor predefinido especial para la información acerca de la última parte del segmento perdido.

En una realización adicional de la invención, la información acerca de qué partes de una unidad de datos que no han sido recibidos esté incluida en las tramas de datos o en las unidades de datos como información que indica el identificador de la unidad de datos, así como también información acerca del comienzo de los datos no recibidos en dicha unidad de datos, y la cantidad de datos no recibidos.

De acuerdo con la invención, la información de estado del transceptor de recepción al tr transceptor de envío se envía como un mensaje que comprende

• Un primer indicador de extensión,

• Datos relativos a una unidad o trama de datos no recibida o parcialmente recibida, en forma de un cierto número de secuencia,

• Un segundo indicador de extensión.

En algunas realizaciones, el mensaje tiene la posibilidad de comprender uno o más de los siguientes:

• Información sobre la naturaleza del mensaje, p. ej., mensaje de control o datos,

• Información sobre el tipo de mensaje dentro de dicha naturaleza, p. ej., un mensaje de estado en el caso de un mensaje de control,

• Datos que reconocen unidades o tramas de datos recibidas correctamente en forma de un cierto número de secuencia,

• Información sobre el comienzo y el final de los datos no recibidos.

Según la invención, dicho primer indicador de extensión indica la ausencia o presencia de otro conjunto que comprende otro de dichos primer y segundo indicadores de extensión y datos relativos a una unidad o trama parcialmente o no recibida en forma del identificador de dicha unidad o trama de datos.

Dicho segundo indicador de extensión puede indicar la ausencia o presencia de información sobre el comienzo y el final de los datos no recibidos.

Estos y otros aspectos y ventajas de la presente invención van a ser explicados con mayor detalle en la explicación detallada que se proporciona a continuación.

La invención divulga también un transceptor para su uso en un sistema conforme a la invención. Este transceptor se puede configurar particularmente para llevar a cabo el método anterior.

Breve descripción de los dibujos

La invención va a ser descrita con mayor detalle en lo que sigue, con referencia a los dibujos anexos, en los que:

La Figura 1 muestra una vista esquemática de un sistema al que puede ser aplicada la presente invención, y Las Figuras 2-6 muestran varias realizaciones de la invención, y

La Figura 7 muestra un diagrama de flujo esquemático de un método de la invención, y

La Figura 8 muestra un diagrama de bloques de un transceptor de la invención.

Descripción detallada

La Figura 1 muestra una vista esquemática de un sistema 100 en el que puede ser aplicada la presente invención.

Según se ha mencionado con anterioridad, la invención está destinada principalmente a sistemas del tipo LTE de 3GPP, es decir, sistemas de Evolución a Largo Plazo del Proyecto Partnership de Tercera Generación, mencionados también a veces simplemente como sistemas LTE, pero que oficialmente se conocen en 3GPP como UTRAN evolucionada o E-UTRAN. Estos nombres podrán ser usados de forma intercambiable a través de la presente descripción.

Según se ha mostrado en la Figura 1, un sistema 100 de LTE puede comprender un número de las llamadas células, una de las cuales ha sido mostrada como 130 en la Figura 1. Cada célula de un sistema de LTE puede albergar un número de usuarios, a veces mencionados genéricamente como UEs, Equipos de Usuario. En la Figura 1 se ha mostrado simbólicamente un UE, con el número de referencia 120.

Los sistemas de LTE tales como el 100 de la Figura 1, pueden comprender también uno de los denominados “eNodeB”, NodeB evolucionado, por cada célula. Una de las funciones del eNodeB de una célula consiste en controlar el tráfico hasta, y desde, los usuarios de una célula. En la Figura 1, un eNodeB 110 ha sido mostrado como el eNodeB para la célula 130.

El tráfico desde el eNodeB hasta un UE se menciona como tráfico de enlace descendente, o simplemente tráfico DL, y el tráfico desde los UEs hasta el eNodeB se conoce como tráfico de enlace ascendente, o simplemente tráfico UL. En sistemas de LTE, se usa un protocolo de RLC, Control de Enlace de Radio, para la comunicación entre el eNodeB y los UEs de una célula.

Conforme a RLC, en sistemas de LTE, el tráfico entre dos transceptores, es decir un UE y su eNodeB, se envía en las denominadas PDUs, Unidades de Datos de Protocolo. Según RLC, cada PDU ha sido asignada con un identificador, el denominado número de secuencia, lo que permite que tanto la parte de envío como la parte de recepción identifiquen una PDU.

En la descripción que sigue, se supondrá que las PDUs de datos son enviadas por el eNodeB, es decir en DL, y que las PDUs de estado son enviadas por un UE, es decir en UL. Sin embargo, se debe puntualizar que esto constituye simplemente un ejemplo destinado a facilitar la comprensión de la invención por parte del lector, y que la invención puede ser igualmente aplicada en la otra dirección, es decir, las PDUs de Datos en UL y las PDUs de Estado en DL. Se puede mencionar en este punto que el RLC de E-UTRAN puede operar de diferentes modos, configurados por el eNodeB, principalmente el Modo Reconocido (AM), el Modo No Reconocido (UM) y el modo transparente (TM). Las PDUs de estado se usan en la actualidad solamente en AM.

Si el eNodeB 110 envía una PDU que contiene datos al UE 120, es decir la denominada PDU de datos, el UE puede responder con una denominada PDU de estado, es decir, una PDU que indique al eNodeB el estado de recepción de los datos en la PDU de datos que fue enviada desde el eNodeB.

En la PDU de estado para el eNodeB, las unidades de datos que son recibidas correctamente por el UE son reconocidas por el UE por medio de lo que se denominan mensajes o indicadores de ACK, y las unidades de datos que son recibidas erróneamente, es decir recibidas solamente de forma parcial, o no recibidas en absoluto, son indicadas por el UE mediante el denominado ACK negativo, un NACK. Si el eNodeB desde el que se originan los datos recibe un NACK como retorno para los datos transmitidos, el eNodeB sabrá de ese modo que esta información debe ser retransmitida, habitualmente hasta que se recibida un ACK. En el caso de tráfico de datos de DL, un UE enviará de ese modo PDUs de estado con ACKs y/o NACKs al eNodeB en respuesta a las PDUs de datos procedentes del eNodeB.

Los ACKs proporcionan información acerca de hasta qué número de secuencia han sido recibidas las PDUs correctamente. Esto puede hacerse ya sea proporcionando el número más alto de una PDU recibida con éxito, o ya sea el primer número de una PDU no recibida.

En RLC de UTRAN, las PDUs de datos pueden ser re-segmentadas, es decir, la carga útil de una PDU de RLC previamente creada puede ser dividida, en el momento de la retransmisión, en segmentos que se envían por separado. En LTE, se pretende que los segmentos de PDU del RLC puedan ser identificados por medio del número de secuencia de la PDU de RLC original, así como por el denominado desplazamiento de segmentación, SO, que indica el inicio de los segmentos en la PDU de RLC original. Se envía un ACK o un NACK en forma de número de secuencia de la PDU de RLC original, pero dado que puede ocurrir la re-segmentación, los segmentos a los que se refiere el ACK o el NACK procedente del UE no pueden ser identificados de manera unívoca en el eNodeB por medio del número de secuencia, ni incluso por medio del SO, debido al hecho de que la segmentación puede ocurrir en varias “generaciones”, es decir, pueden ocurrir múltiples re-segmentaciones, y el eNodeB no conoce la generación a la que se refieren los ACK/NACKs.

Este es el problema, es decir la identificación de datos de PDU de RLC asociados a ACK/NACK, que la invención pretende direccionar.

Se pueden discernir diferentes casos cuando se trata de las PDUs de estado.

a. Una PDU de estado solamente con un ACK y sin ningún NACK.

b. Una PDU de estado con un ACK y uno o más NACKs, que tiene dos sub-casos:

i. Uno o más de los NACKs son “NACKs de segmento”

ii. Todos los NACKs son NACKs de no-segmento.

Con el fin de direccionar el caso “a” anterior, la invención propone una PDU de estado que ha sido mostrada en la Figura 2 con el número de referencia 200. Según se muestra en la Figura 2, la PDU de estado 200 comprende un campo D/C 210, el cual indica si la PDU 200 es una PDU de datos o de control. Como se comprenderá, una PDU de estado es una PDU de control.

Además, la PDU de estado 200 incluye un campo de ACK 220, siendo el ACK proporcionado en forma de número de secuencia, SN, de la PDU de RLC a la que se refiere el ACK. La PDU de estado 200 comprende también un indicador, e, p. ej., una banderola o un bit, mostrado en la Figura 2 como “bit E” 230, el cual se usa para indicar la presencia o la ausencia de NACKs en la PDU de estado 200.

En caso de ausencia de NACKs en la PDU de estado, es decir, el caso mostrado en la Figura 2, se puede usar lo que se conoce como “relleno” o “bits ficticios” a efectos de lograr un alineamiento apropiado de los contenidos de la PDU de estado 200. Un ejemplo de tal alineamiento es el llamado “alineamiento de octeto”, es decir, el alineamiento que se usa si la PDU de estado está dividida en octetos de datos. El relleno ha sido mostrado como 240 en la Figura 2.

Volviendo ahora al caso identificado como “b-i” con anterioridad, es decir donde uno o más de los NACKs se refieren a unidades de datos segmentadas, en otras palabras el caso en que los NACKs indican que una unidad de datos ha sido recibida parcialmente, se va a introducir ahora un concepto usado por la invención. Este concepto se menciona en la presente memoria como “pares de Desplazamiento de Segmento”, o “pares de SO”, es decir, un par de datos, de los que uno se utiliza para indicar el primer octeto de datos no recibido de la PDU a la que se refiere el NACK, y de los que el otro se utiliza para indicar el último octeto de datos no recibido al que se refiere el NACK. Se puede añadir en este punto que aunque se usen octetos para ejemplificar la invención, puesto que los octetos se usan en RLC de LTE, la invención puede ser usada naturalmente si los datos son enviados también en otros tamaños.

Un ejemplo de formato 300 de PDU de Estado que puede manejar el caso “b-i” anterior, ha sido mostrado en la Figura 3. De manera similar al formato 200 de PDU de Estado de la Figura 2, el formato 300 de PDU de Estado comprende un campo que indica si la PDU 300 es una PDU de datos o de control, y un campo de ACK siendo proporcionado el ACK en forma de número de secuencia, SN, de la PDU de RLC a la que se refiere el ACK.

La PDU de estado 300 comprende también un indicador, p. ej., una banderola o bit, mostrado en la Figura 3 como un “bit-E”, que se usa para indicar la presencia o la ausencia de NACKs en la PDU de estado 300.

Si se incluye uno o más NACKs, como en la Figura 3, cada NACK va seguido de un bit “E” o una banderola y de un bit “F” o una banderola, donde el bit E/banderola indica si está o no presente otro NACK, y el bit F/banderola indica si está incluido o no un par de SO para el NACK particular. En otras palabras, se puede decir que el bit F/banderola indica si la unidad de datos a la que se refiere el NACK fue segmentada o no, puesto que ése es solamente el caso cuando se usan pares de SO.

Se puede mencionar también que el caso en el que (por ejemplo) falten dos partes pero no consecutivas de una, y la misma, PDU puede ser manejado por la presente invención ya que uno, y el mismo, SN de NACK ocurrirá dos veces, pero con diferentes pares de SO.

De una manera similar a la realización de la Figura 2, los ACKs y los NACKs de la PDU de estado 300 de la Figura 3 son proporcionados en forma de número de secuencia, SN, de la PDU de RLC a la que se refiere el ACK o el NACK, por cuyo motivo los ACK/NACKs se muestran como aCk_Sn o NACK_SN.

Tras el último NACK de la PDU de estado 300 en la Figura 3, se incluyen los pares de SO para los NACKs para los que se han establecido las banderolas “F”/bits. De ese modo, el par de SO mostrado como SO11 y SO12 “pertenece” al NACK1_SN, y el par de SO mostrado como SO21 y SO22 “pertenece” al NACK2_SN. También, según se muestra en la Figura 3, se puede usar “relleno”, PAD, en la PDU de estado 300 de la Figura 3, a efectos de obtener alineamiento de octeto o para un propósito similar.

Volviendo ahora a la información comprendida en los pares de SO, el primer SO de un par de SO indica el primer octeto de datos faltante de la PDU, y el último SO de un par indica el último octeto de datos faltante en la PDU. Debe puntualizarse que si los datos de las PDUs recibidas, es decir, las PDUs a las que se refieren los ACK/NACKs, están dispuestos en grupos distintos de los octetos, la invención puede ser también aplicada, por supuesto, a tales sistemas. Los pares de SO podrían entonces indicar, de una manera similar a la que se ha descrito con anterioridad, el comienzo y el fin de los datos en la PDU a la que se refiere el NACK.

También se puede añadir que las PDUs de estado de la invención pueden también ser expandidas por medio de un campo, por ejemplo después del campo de D/C, que indica la naturaleza de la PDU de estado, por ejemplo si se usan PDUs de control de RLC distintas de las PDUs de ESTADO. Este campo se ha incluido en el ejemplo mostrado en la Figura 3, indicado como “tipo de PDU”. Se puede aplicar el mismo principio, es decir el tipo de PDU, en la versión mostrada en la Figura 2.

Con referencia continuada a las PDUs de estado de la invención, se debe puntualizar también que el orden de los campos de datos de las PDUs de estado mostradas en las Figuras 2 y 3 constituyen simplemente ejemplos de realizaciones adecuadas, de modo que los campos de datos en la PDU de estado de la invención pueden ser desplazados a otras posiciones en la PDU de estado sin que afecte a la funcionalidad de la invención, por ejemplo a efectos de conseguir alineamiento de octeto. Como ejemplo, en un caso con un solo ACK y sin NACKs, es decir la realización mostrada en la Figura 2, la PDU de estado 200 podría empezar con un campo de D/C seguido de un bit E, seguido por relleno y por último el ACK con su número de secuencia.

Volviendo ahora al caso mostrado como b-ii anteriormente, es decir, en el que uno o más NACKs se refieren a PDUs de datos no recibidas, en oposición a las unidades de datos recibidas parcialmente, esto se maneja de la siguiente manera: la banderola F correspondiente a esos NACKs indica que no se ha incluido ningún par de SO en la PDU de estado para esos NACKs.

Un caso especial que está también direccionado por la invención es cuando el último segmento de PDU de una PDU de RLC no ha sido recibido por el UE (supóngase también el caso de PDUs de datos en DL). Supóngase un ejemplo en que una PDU de RLC con número de secuencia 10 ha sido segmentada en 3 PDUs de RLC, conteniendo los segmentos de PDU los octetos 1-10, 11-25 y 26-40, respectivamente.

Considérese ahora el caso de que el UE ha recibido los dos primeros segmentos de la PDU de RLC 10, es decir, los octetos 1-10 y 11-25, y también ha recibido la siguiente PDU de RLC, es decir, la PDU de RLC 11, en su totalidad, pero el UE no ha recibido el último segmento de la PDU de RLC 10, es decir, los octetos 26-40.

En ese caso, el UE sabe que un segmento de RLC se ha perdido, pero no conoce su longitud, de modo que el UE no puede establecer el segundo valor de desplazamiento de segmentación en el par de SO correspondiente en la PDU de estado. Una solución para esto que la invención propone, consiste en permitir que un valor especial de un SO indique que el final del segmento del NACK no es conocido. De ese modo, cuando el eNodeB recibe un NACK para la PDU de RLC 10, se establece un primer SO en 26 y el segundo SO correspondiente se establece en el valor especial que indica al eNodeB que todos los octetos de datos a partir del 26 y siguientes para la PDU de RLC 10 necesitan ser retransmitidos.

En algunos casos, un par de SO no es siempre necesario para obtener el efecto deseado. Según se va a mostrar en lo que sigue usando dos bits en el campo “F”, se puede conseguir una identificación completa de los datos no recibidos.

Esto ha sido representado en el ejemplo de la Figura 4, en la que se ha ilustrado la totalidad de las cuatro combinaciones de dos bits en el campo F, es decir, 00, 01, 10 y 11. Los significados de cada una de esas combinaciones han sido indicados también en la Figura 4, como sigue:

Campo F Significado

00 El NACK se refiere a la PDU de RLC completa de modo que no se necesitan SOs.

01 El NACK se refiere a una primera parte de la PDU de RLC, necesitándose 1 SO a efectos de indicar el último grupo de datos no recibido, tal como, por ejemplo, un octeto.

10 El NACK se refiere a una última parte de la PDU de RLC, necesitándose 1 SO a efectos de indicar el primer grupo de datos no recibido, tal como, por ejemplo, un octeto

11 El NACK se refiere a una parte intermedia de la PDU de RLC, necesitándose 2 octetos a efectos de indicar el primer y el último grupo de datos no recibido, tal como, por ejemplo, un octeto.

Se debe puntualizar que en el caso mostrado en la Figura 4, de forma similar a las realizaciones mostradas previamente, se puede necesitar un “campo tipo” con el fin de separar las PDUs de RLC de estado de las otras PDUs de control de RLC.

En otra realización de la presente invención, las PDUs de datos de RLC de DL parcialmente recibidas son señaladas al eNodeB por el UE en una PDU de RLC de estado de UL de una manera ligeramente diferente a la mostrada con anterioridad, es decir, los pares de SO. En la realización en cuestión, la PDU 500 de RLC de estado que se ha mostrado en la Figura 5, la PDU de RLC de estado de UL procedente del UE comprende un campo de NACK, mostrado como 510, y un campo de número de secuencia, SN, mostrado como 520, el cual indica el número de secuencia de la PDU de datos de RLC de DL a la que se refiere el NACK. Naturalmente, en la realización 500, el SN puede estar también incluido junto con el NACK, según se ha mostrado en realizaciones anteriores.

De forma similar a las realizaciones anteriores, la realización 500 incluye también el uso de un campo “E”, mostrado como 530 en la Figura 5. Sin embargo, el significado del campo E, es decir un bit o una banderola, difiere ligeramente del significado de las realizaciones anteriores: en la realización 500 de la Figura 5, el campo E se utiliza para indicar si el NACK 510 se refiere a una PDU de datos de RLC completa o a datos del interior de una PDU de datos de RLC. Por ejemplo, si el campo E es igual a cero, E=0, esto podría significar que el NACK 510 se refiere a la PDU de datos de RLC completa que está identificada por medio del SN 520.

A la inversa, si E=0 significa una PDU completa, entonces E=1 significa que el NACK 510 se refiere a datos del interior de la PDU identificada por el SN 520. En este caso, la información se incluye en la PDU de estado 500 a efectos de que el eNodeB esté capacitado para identificar los datos en cuestión. Esta información relacionada con los datos en la realización 500 comprende un valor de desplazamiento de segmento, SO, mostrado como 540 en la Figura 5. El SO 540 indica el desplazamiento de byte o el inicio de los datos de DL no recibidos. Sin embargo, en oposición a las realizaciones anteriores, la realización 500 no utiliza pares de SO para indicar la totalidad de los datos no recibidos. Por el contrario, la realización 500 utiliza un Campo de Longitud, LF, 550, cuyo valor indica el comienzo de los datos no recibidos, a partir del valor de SO 540, hasta el último byte de los datos no recibidos. Como se puede apreciar, en esta realización de la invención, es decir la mostrada en la Figura 5, a efectos de lograr una retransmisión eficiente desde el emisor original de los datos, el número exacto de bytes que podrían ser transmitidos hay que indicarlo al emisor. Puesto que las PDUs de RLC de LTE pueden ser muy grandes (p. ej., 32767 bytes), los campos (es decir, SO y LF) necesarios para la indicación de los segmentos de PDU de RLC podrían necesitar ser también muy grandes. Sin embargo, como podrá apreciarse también, en muchos casos, no se necesitará usar el tamaño teórico máximo de los campos de SO y LF, lo que podría conducir por lo tanto a un desperdicio de espacio de datos si el tamaño de esos campos se hiciera estático.

En una realización de la presente invención, los inventores proponen mitigar ese problema, es decir, el uso ineficaz del espacio de datos para los campos de SO y LF. Esta realización va a ser descrita en lo que sigue.

Según este aspecto de la invención un principio básico consiste en que los tañamos de los campos SO y LF en la PDU de estado de RLC se han hecho adaptativos a las necesidades de la PDU de estado de RLC actual. Obviamente, es posible usar dos tamaños diferentes para SO y LF, p. ej., 6 bits para RSO y 4 bits para RSL. Sin embargo, en la descripción que sigue, se supondrá que el tamaño es el mismo.

Si, según se propone en este aspecto de la presente invención, se usa un campo de longitud dinámica para SO y LF, el eNodeB (en el caso de datos en DL y mensajes de estado en UL) debe conocer este tamaño longitudinal de campo con el fin de estar capacitado para leer el mensaje de estado.

Una primera forma de llevar a cabo todo esto consiste en disponer de un campo adicional en la cabecera del mensaje de PDU de estado de RLC que sea indicativa del tamaño de los campos de SO y LF. Por ejemplo, podría existir un campo que indique que todos los campos de longitud en el mensaje actual son de 6 bits. Este tamaño podría diferir de mensaje de estado en mensaje de estado de PDU de RLC.

Si se tuvieran que dar valores de tamaño diferentes a SO y LF, se necesitarían dos de esos campos de longitud o se podría hacer uso de una relación predefinida entre os mismos, p. Ej. SO es siempre x bits más largo/más corto que LF. Sin embargo, puesto que SO y LF son típicamente del mismo orden, podría no requerirse esta optimización. Según un aspecto alternativo de la invención, la indicación explícita del tamaño de los campos de SO y LF resulta superflua, debido a una re-disposición en el mensaje de estado de PDU de RLC. En este aspecto de la invención, se propone mover los “campos de longitud” SO y LF al final del mensaje de estado de PDU de RLC, lo cual se va a describir con referencia a la Figura 6.

En la realización mostrada en la Figura 6, se proporciona en primer lugar la información de estado para todas las PDUs incluidas, es decir, SN (número de segmento), RF (Banderola de Resegmentación) y un bit de extensión, “E”. De esta manera será posible incluir también PDUs completas, donde no necesite ser enviada ninguna información de segmento específico. Para PDUs donde haya ocurrido resegmentación, el RF se usa para indicar que la información de la posición y la longitud del segmento sigue, y que SO y LF están anexados a la trama del mensaje. Por lo tanto, en la realización de la Figura 6, la parte “dinámica” del mensaje de estado, es decir SO y LF, se produce después del último bit de extensión E, es decir, después del primer bit E con un valor que indique que es el último, tal como por ejemplo el valor “0”. Puesto que el tamaño global del mensaje en esta realización necesita ser conocido, por ejemplo a partir de una cabecera MAC o RLC, el receptor conoce cuántos bits se han dejado para los campos de SO y LF. También sabe cuántos pares de SO y LF seguirán después del último bit de extensión. De ese modo, el receptor puede calcular los tamaños de los campos de SO y LF.

En caso de que sea un requisito que la PDU de estado de RLC debe estar alineada en byte, se ha de llevar a cabo una etapa adicional, puesto que el número de bits restantes está también dividido por el número de campos de segmento indicados. El resultado entero se utiliza como longitud, mientras que los bits restantes no se utilizan. Como ejemplo, si la longitud restante es de 51 bits, y se usa alineamiento de byte (8 bits), se puede realizar el cálculo 51/8 = 6 mód 3. De ese modo, en este ejemplo, 3 bits al final de la PDU de estado no serán usados.

En el ejemplo anterior, el LF se usa para determinar el final de un segmento de PDU de RLC. Sin embargo, podría ser posible dentro del alcance de la presente invención usar un desplazamiento absoluto, en similitud al SO. En tal caso, el desplazamiento deberá apuntar a la posición original del último byte en el segmento de PDU de RLC.

El contenido del mensaje de estado podría describir los datos que sean correspondientes a ACK o correspondientes a NACK. También, se podría incluir una mezcla de ACKs y NACKs, con uno o más bit(s) adicional(es) para proporcionar un indicador de ACK/NACK adecuado.

El mensaje de estado descrito de la Figura 6 debe ser apreciado simplemente como ejemplo, pudiéndose requerir en algunas aplicaciones campos adicionales como banderolas tipo para indicar si la PDU contiene datos o un estado, campos de longitud adicionales y así sucesivamente, y estarían dentro del alcance de la presente invención.

Se puede añadir también información de estado explícita a los informes de estado, especialmente en caso de que el estándar o la implementación permitan que se pueda informar acerca de múltiples tipos de estados, por ejemplo NACK y ACK.

Una indicación explícita de un estado puede ser también necesaria si el sistema de LTE está configurado para intercambiar un informe de estado de un solo tipo, p. ej. solamente NACKs. Alternativamente, la entidad de envío del informe de estado puede recibir desde la entidad de envío de PDU una petición para un informe de estado de un cierto tipo (p. ej., solamente NACK) y podría generar de ese modo el informe de estado solamente para el subconjunto de segmentos recibidos que no hayan sido recibidos.

Según un aspecto adicional de la invención, se podría prever enviar el mensaje de estado de PDU de RLC como una PDU separada, o superpuesta a otra PDU.

La Figura 7 muestra un diagrama de flujo en bruto de un método 700 de la invención. Las etapas que sean opciones o alternativas, se muestran con líneas discontinuas.

Según se ha indicado en la descripción que antecede, el método de la invención está previsto para su uso en un sistema de comunicaciones celulares tal como el sistema 100 de la Figura 1, es decir, un sistema en el que se puede intercambiar tráfico entre un primer y un segundo transceptor tal como el UE 120 y el eNodeB 120.

El tráfico en el sistema 100 se envía en unidades de datos, y cada una de esas unidades de datos está dotada de un identificador. Las unidades de datos pueden estar divididas en segmentos, y un transceptor de recepción puede enviar información de estado en tramas de datos o unidades de datos en relación con unidades de datos recibidas apropiadamente, parcialmente recibidas o no recibidas, al transceptor de envío, es decir, al transceptor desde el que se han enviado los datos.

Según el método inventivo 700, según se ha indicado en la etapa 705, en el caso de una unidad o de más unidades parcialmente recibidas o no recibidas, la información de estado que se envía al transceptor de envío incluye, según se ha mostrado en la etapa 710, información acerca de si la unidad o las unidades de datos fue (fueron) no recibida(s) o parcialmente recibida(s), y si es así, según se muestra en la etapa 715, en caso de una o más unidades de datos parcialmente recibidas, qué partes de esas unidades de datos no fueron recibidas.

En una realización de la invención, según se muestra en la etapa 720, la información acerca de si una unidad de datos ha sido recibida parcialmente o no recibida, se incluye en una banderola en dichas tramas de datos o unidades de datos.

Según se ha indicado en la etapa 725, en una realización adicional de la invención, la información acerca de qué partes de una unidad de datos no han sido recibidas se incluye en dichas tramas de datos o unidades de datos como información que indica una primera y una última parte de la unidad de datos no recibida.

La etapa 730 indica que, en un aspecto de la invención, si una trama o una unidad de datos procedente del transceptor de envío ha sido segmentada o re-segmentada, y un último segmento no ha alcanzado el transceptor de recepción, esto puede ser indicado por el transceptor de recepción al transceptor de envío, adecuadamente por medio de un valor predefinido especial para la información acerca de la última parte no recibida de los segmentos recibidos.

La etapa 735 indica que en una realización de la invención, si una trama o unidad de datos procedente del transceptor de envío ha sido segmentada y un último segmento no ha alcanzado el transceptor de recepción, esto puede ser indicado por el transceptor de recepción al transceptor de envío.

Según se ha indicado con anterioridad en la presente descripción, y según se ha mostrado en la etapa 740, el método 700 de la invención puede ser aplicado adecuadamente a un sistema de LTE, Evolución a Largo Plazo, tal como el sistema 100 que se ha mostrado esquemáticamente en la Figura 1.

Si el método inventivo 700 se aplica a un sistema de LTE, las PDUs de datos pueden ser enviadas en DL y las PDUs de estado correspondientes serán enviadas entonces en UL, tal y como se indica en la etapa 750, en cuyo caso el “transceptor de envío” mencionado con anterioridad es el eNodeB de una célula de LTE, y el “transceptor de recepción” es un UE, Equipo de Usuario, de la célula de LTE.

A la inversa, la invención puede ser aplicada igualmente de modo que las PDUs de datos puedan ser enviadas en UL y las PDUs de estado correspondientes sean enviadas entonces en DL, según se indica en la etapa 745, en cuyo caso el “transceptor de envío” mencionado con anterioridad es el UE de una célula de LTE, y el transceptor de recepción es el eNodeB de la célula de LTE.

Con referencia a la PDU de estado 300 mostrada en la Figura 3, se puede puntualizar que la información desde el transceptor de recepción hasta el transceptor de envío puede ser enviada como mensaje que tiene la posibilidad de comprender uno o más de los siguientes:

• Información (D/C) acerca de la naturaleza del mensaje, p. ej., mensaje de datos o de control,

• Información (tipo de PDU) acerca del tipo de mensaje dentro de dicha naturaleza, p. eje. un mensaje de estado en el caso de un mensaje de control,

• Datos (ACK) que reconocen unidades o tramas de datos recibidas apropiadamente en forma de un determinado número de secuencia,

• Un primer indicador de extensión (E),

• Datos (NACK) con relación a una unidad o trama de datos no recibida o recibida parcialmente en forma de un determinado número de secuencia (SN) de dicha unidad o trama de datos,

• Un segundo indicador de extensión (F),

• Información acerca del comienzo (SO11, SO21) y del final (SO12, SO22) de datos no recibidos.

En el ejemplo de PDU de estado mostrada en la Figura 3, el primer indicador de extensión, E, indica la ausencia o la presencia de un conjunto que comprende otro de entre el primer y el segundo indicadores de extensión, es decir E y F, y datos, NACK, en relación con una unidad o trama de datos recibida parcialmente o no recibida, con la forma del identificador, SN, de la unidad o trama de datos. El segundo indicador de extensión, F, indica la ausencia o la presencia de información acerca del principio, SO11, SO21, y del final, SO21, SO22, de datos no recibidos.

La invención divulga también un transceptor para su uso en un sistema al que se aplica la invención. Según se desprende de la descripción que antecede, la invención puede ser aplicada ya sea cuando se envían PDUs de datos en DL y las correspondientes PDUs de estado se envían en UL, en cuyo caso el transceptor de envío de datos (en el caso de aplicaciones de E-UTRAN) es el eNodeB y el transceptor de recepción, es decir, el transceptor que transmite PDUs de estado es el UE, o ya sea a la inversa, cuando las PDUs de datos son enviadas en UL y las correspondientes PDUs de estado son enviadas en DL, en cuyo caso el transceptor que envía datos es el UE y el transceptor de recepción, es decir el transceptor que transmite PDUs de estado, es el eNodeB. De ese modo, el transceptor de la invención puede ser un eNodeB de E-UTRAN o bien un UE de E-UTRAN.

Un diagrama esquemático de bloques de un transceptor genérico de la invención 800 para su uso como eNodeB de E-UTRAN o como UE de E-UTRAN, ha sido mostrado en la Figura 8. Según se indica en la Figura 8, el transceptor 800 comprenderá una antena, mostrada como bloque 810, y también comprenderá una parte de recepción 820 y una parte de transmisión 830. Adicionalmente, el transceptor 800 comprende también un medio de control 840 tal como un microprocesador, así como una memoria 850. Además, si el transceptor 800 va a ser usado como eNodeB, el transceptor 800 comprende también una interfaz 860 hacia otros componentes del sistema aparte de los UEs. Puesto que la interfaz no puede estar presente si el transceptor 800 es un UE, la interfaz 860 ha sido mostrada con líneas discontinuas.

El transceptor 800 puede usar la antena 810, la parte de recepción 820 y la parte de transmisión 830 para enviar tráfico a, y recibir tráfico desde, un segundo transceptor del sistema, y el transceptor 800 puede usar el medio de control 840 junto con la memoria 850 para enviar dicho tráfico en unidades de datos.

El medio de control 840 y la memoria 850 pueden ser usados también para proporcionar un identificador a cada una de las unidades de datos, tal como por ejemplo, un número de secuencia, y los mismos medios, es decir los bloques 840 y 850 pueden ser usados para dividir las unidades de datos en segmentos.

El transceptor 800 de la invención usa también el medio de control 840, la memoria 850, el transmisor 830 y la antena 810 para enviar información en tramas de datos o en unidades de datos acerca de las unidades de datos recibidas apropiadamente, recibidas parcialmente o no recibidas, al segundo transceptor, es decir, al transceptor desde el que se enviaron los datos.

Adicionalmente, el transceptor 800 puede usar el medio de control 840 y la memoria 850, en el caso de una o más unidades de datos no recibidas o recibidas parcialmente, para incluir información en la información de estado acerca de si la unidad o unidades de datos no fueron recibidas o fueron recibidas parcialmente, y en el caso de una o más unidades de datos recibidas parcialmente, qué partes de esas unidades de datos no fueron recibidas.

En una realización, los medios 840 y 850 son usados por el transceptor 800 para incluir la información acerca de si una unidad de datos fue o no recibida parcialmente o no recibida, a modo de banderola en dichas tramas de datos o unidades de datos.

Adicionalmente, en una realización adicional, los bloques 840 y 850 son usados por el transceptor para incluir la información sobre qué partes de una unidad de datos no fueron recibidas en dichas tramas de datos o unidades de datos, como información que indica una primera y una última parte de la unidad de datos no recibida.

En otro aspecto de la invención, el medio de control 840, la memoria 850, el transmisor 830, junto con la antena 810, pueden ser usados por el transceptor 800 para indicar a un transceptor de envío si una trama o unidad de datos procedente del transceptor de envío ha sido segmentada, y un último segmento no ha alcanzado el transceptor 800. La indicación acerca de un segmento faltante se lleva a cabo adecuadamente mediante el uso de un valor predefinido especial para la información acerca de la última parte del segmento faltante.

En una realización, el medio de control 840 y la memoria 850 pueden ser usados por el transceptor 800 para incluir la información acerca de qué partes de una unidad de datos parcialmente recibida no fueron recibidas en dichas tramas de datos o unidades de datos como información que indica el identificador de la unidad de datos, y también como información acerca del comienzo de los datos no recibidos en dicha unidad de datos, y la cantidad de datos no recibidos.

Adicionalmente, la antena 810, el trasmisor 830, el medio de control 840 y la memoria 850 pueden ser usados por el transceptor de la invención para enviar información de estado a un transceptor de envío a modo de mensaje, tal como el mensaje 300 de la Figura 3, el cual puede comprender uno o más de los siguientes:

• Información acerca del tipo de mensaje dentro de dicha naturaleza, p. ej., un mensaje de estado en el caso de un mensaje de control,

• Un primer indicador de extensión (E),

• Datos (NACK) con relación a una unidad o trama de datos no recibida o recibida parcialmente, en forma de un determinado número de secuencia,

• Un segundo indicador de extensión (F),

Adecuadamente, el primer indicador de extensión (E) indica la ausencia o la presencia de un conjunto que comprende otro de dichos primer (E) y segundo (F) indicadores de extensión y datos (NACK) en relación con una unidad o trama recibida parcialmente o no recibida en forma del identificador (SN) de dicha unidad o trama de datos, y dicho segundo indicador de extensión (F) indica la ausencia o la presencia de información acerca del comienzo (SO11, SO21) y del final (SO12, SO22) de datos no recibidos.

Claims

REIVINDICACIONES

1. Un método (700), en un equipo de usuario, UE (120) de un sistema (100) de comunicaciones celulares, comprendiendo el método:

- recibir unidades de datos desde un eNodeB, eNB (110), a cada una de las cuales unidades de datos se le asigna un identificador en forma de un número de secuencia, y cuyas unidades de datos están divididas en segmentos, y

- enviar información de estado en unidades de datos (200, 300) acerca de unidades de datos recibidas parcialmente recibidas o no recibidas, al eNB (110), caracterizado por que en el caso (705) de una unidad o más unidades de datos no recibidas o parcialmente recibidas, la información de estado se envía a modo de un mensaje (300) que comprende

- un primer bit indicador de extensión (E),

- datos (NACK) relativos a una unidad de datos no recibida o parcialmente recibida, en forma de un número de secuencia para la unidad de datos no recibida o parcialmente recibida,

- un segundo bit indicador de extensión (F, RF) que indica una ausencia o presencia de información que indica que partes (715) de una unidad de datos parcialmente recibida no fueron recibidas, y - en el caso de una o más unidades de datos parcialmente recibidas, información de qué partes (715) de una unidad de datos parcialmente recibida no fue recibida,

en donde dicho primer bit indicador de extensión (E) indica la ausencia o la presencia de otro conjunto que comprende otro de dicho primer bit indicador de extensión (E) y otro de dicho segundo bit indicador de extensión (F, RF) y datos (NACK, SN) en relación con una unidad parcialmente o no recibida en forma de un número de secuencia (SN) para la unidad de datos no recibida o parcialmente recibida.

2. El método (700, 720) de la reivindicación 1, según la cual el segundo bit indicador de extensión (F, RF) indicativo de si una unidad de datos fue o no recibida parcialmente o no recibida, está incluido a modo de banderola en dichas unidades de datos.

3. El método (700, 725) de la reivindicación 1 ó 2, según la cual la información acerca de qué partes de una unidad de datos parcialmente recibida no fueron recibidas está incluida en dichas unidades de datos, como información que indica una primera y una última partes de la unidad de datos no recibida.

4. El método (700, 730) de cualquiera de las reivindicaciones 1-3, según la cual, si una unidad de datos del eNB ha sido segmentado y un último segmento de una unidad de datos parcialmente recibida, no ha alcanzado la UE, esto se puede indicar por la UE (110, 120) al eNB (110, 120).

5. El método (700, 730) de la reivindicación 3 ó 4, según la cual, dicha información qué partes no se recibieron, comprende un valor predefinido para indicar la última parte de la unidad de datos parcialmente recibida.

6. El método (700, 735) de la reivindicación 1, según la cual la información acerca de qué partes de una unidad de datos parcialmente recibida no fueron recibidas, está incluida en dichas unidades de datos, como información que indique el número de secuencia de dicha unidad de datos, así como información acerca del comienzo de los datos no recibidos en dicha unidad de datos, y la cantidad de datos no recibidos.

7. El método (700, 740) de cualquiera de las reivindicaciones anteriores, en donde el sistema de comunicaciones celulares es un sistema (100) de E-UTRAN.

8. El método de la reivindicación 7, según la cual dicha unidad de datos es una PDU de RLC, y dichos segmentos son segmentos de PDU de RLC.

9. El método (700) de cualquiera de las reivindicaciones anteriores, según la cual la información de estado se envía como un mensaje (300) que comprende uno o más de los siguientes:

• Información (D/C) acerca de la naturaleza del mensaje, p. ej., un mensaje de datos o de control,

• Datos (ACK) de reconocimiento de unidades de datos recibidas apropiadamente, en forma de un determinado número de secuencia,

10. El método (700) de la reivindicación 1, según la cual dicho segundo bit indicador de extensión (F) indica la ausencia o la presencia de información acerca del comienzo (SO11, SO21) y del final (SO12, SO22) de datos no recibidos.

11. Un equipo de usuario, UE (120, 800) para un sistema de comunicaciones celulares (100), estando configurado el UE para:

- enviar unidades de datos a y recibir unidades de datos desde un eNodeB, eNB (110) en el sistema, en donde a cada una de dichas unidades de datos se le asigna un identificador en forma de un número de secuencia, y en donde dichas unidades de datos están divididas en segmentos, y

- enviar información de estado en unidades de datos (200, 300) acerca de unidades de datos recibidas parcialmente recibidas o no recibidas, a dicho eNB, caracterizado por que en el caso de una o más unidades de datos no recibidas o parcialmente recibidas, la información de estado se envía a modo de un mensaje (300) que comprende:

-un primer bit indicador de extensión (E),

-datos (NACK) relativos a una unidad de datos no recibida o parcialmente recibida, en forma de un número de secuencia para la unidad de datos no recibida o parcialmente recibida,

- un segundo indicador de extensión (F, RF) que indica una ausencia o presencia de información que indica que partes de una unidad de datos parcialmente recibida no fue recibida, y

- en el caso de una o más unidades de datos parcialmente recibidas, información de que partes (715) de una unidad de datos parcialmente recibida no fue recibida,

en donde dicho primer bit indicador de extensión (E) indica la ausencia o la presencia de otro conjunto que comprende otros de dichos primer (E) y otro de dicho segundo bit indicadores de extensión (F, RF) y datos (NACK, SN) relativos a una unidad no recibida o parcialmente, en forma de un número de secuencia (SN) para la unidad de datos parcialmente recibida o no recibida.

12. El UE (120, 800) de la reivindicación 11, que está configurado para llevar a cabo un método de cualquiera de las reivindicaciones 2 a 10.

13. El UE (120, 800) de la reivindicación 11 o 12, configurado para enviar información de estado al eNB (110, 120) como un mensaje (300) que comprende uno o más de los siguientes:

• Información acerca del comienzo (SO11, SO12) y del final (SO12, SO22) de segmentos no recibidos.

14. El UE (800) de la reivindicación 13, en donde dicho segundo indicador de extensión (F) indica la ausencia o la presencia de información acerca del comienzo (SO11, SO21) y del final (SO12, SO22) de datos no recibidos.

15. El UE (120, 800) de cualquiera de las reivindicaciones 11 a 14, que comprende una antena (810), un transmisor (830), medios de control (840) y memoria (850).