ES2974523T3 - Método para transmitir informe de estado PDCP - Google Patents

Abstract

Un método para transmitir informes de estado de PDCP (Protocolo de convergencia de datos empaquetados) se realiza mediante un terminal móvil recibiendo, desde una capa superior, una solicitud de restablecimiento de PDCP (Protocolo de convergencia de datos empaquetados); detectar si hay PDCP SDU (unidades de datos de servicio) fuera de secuencia almacenadas; y si hay al menos una SDU de PDCP fuera de secuencia almacenada, asignar un campo de mapa de bits de longitud en bits igual al número de SN de PDCP desde (y sin incluir) la primera SDU de PDCP fuera de secuencia hasta (incluido) un último SDU PDCP fuera de secuencia. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Método para transmitir informe de estado PDCP

Campo técnico

La presente invención se refiere a informes de estado PDCP.

Técnica anterior

En la técnica asociada se realizaba la transmisión de informes de estado PDCP, pero los recursos de radio se desaprovechaban innecesariamente. Por sí mismas, las tecnologías de la técnica asociada no se ocupan suficientemente de dichos temas y, de este modo, no ofrecen soluciones apropiadas.

El documento LG Electronics Inc.: “Correction of status reporting coding”, R2-080969, 11 de febrero de 2008, páginas 1-3, XP002624626, divulga una propuesta de que en un informe de estado PDCP se indique el número de primera secuencia pendiente en lugar del número de última secuencia recibida en secuencia.

El documento Alcatel-Lucent: “PDCP status report carrying LIS only”, Borrador 3GPP, R2-080902, Proyecto de Asociación de 3a Generación (3GPP), Mobile Competence Centre, vol. RAN WG2, 4 de febrero de 2008, XP050138711, divulga una propuesta de que un informe de estado PDCP pueda contener solamente un parámetro LIS sin un mapa de bits que indique cuáles SDU están pendientes.

Divulgación de la invención

Solución técnica

Los presentes inventores han reconocido al menos los inconvenientes de la técnica asociada identificados anteriormente. Basándose en dicho reconocimiento, se han concebido las distintas características descritas de aquí en adelante de modo que se proporciona un método para transmitir informes de estado PDCP, lo que da como resultado un uso más eficiente de los recursos de radio. La invención está definida por la reivindicación independiente.

Breve descripción de los dibujos

La figura 1 muestra una arquitectura de red de ejemplo de un Sistema de Telecomunicaciones Móvil Universal (UMTS).

La figura 2 muestra una pila del protocolo de la interfaz de radio de ejemplo utilizada entre un terminal móvil y una UTRAN basándose en un estándar de red de acceso radio 3GPP.

La figura 3 muestra una entidad PDCP de ejemplo si la capa PDCP de la figura 2.

La figura 4 muestra una PDU de Estado PDCP generada por la Unidad de Control PDCP de la figura 3.

La figura 5 muestra un ejemplo de cómo se genera una PDU de Estado PDCP de acuerdo con la presente invención.

La figura 6 muestra otro ejemplo de cómo se genera la PDU de Estado PDCP.

La figura 7 muestra un diagrama de flujo de ejemplo útil para entender la presente invención.

La figura 8 muestra un ejemplo de cómo se genera una PDU de Estado PDCP.

La figura 9 muestra un ejemplo de cómo se genera una PDU de Estado PDCP.

Modo para la invención

Los conceptos y características en el presente documento asociados a un método para transmitir informes de estado PDCP se explican en términos de un sistema de la evolución a Largo Plazo (LTE) u otros de los denominados sistemas de comunicación 4G, los cuales son una mejora a las tecnologías 3GPP actuales. Sin embargo, dichos detalles no quieren limitar las distintas características descritas en el presente documento, las cuales son aplicables a otros tipos de sistemas y métodos de comunicación móvil y/o inalámbrica.

De aquí en adelante, el término “terminal móvil” se utilizará para referirse a diversos tipos de dispositivos de usuario como, por ejemplo, terminales de comunicaciones móviles, un equipo de usuario (UE), un equipo móvil (ME), y otros dispositivos que soportan diversos tipos de tecnologías de comunicación inalámbrica.

Las comunicaciones móviles de segunda generación (2G) están relacionadas con la transmisión y recepción de señales de voz de forma digital, e incluyen tecnologías como, por ejemplo, CDMA, GSM, etc. GPRS se desarrolló como una mejora de GSM para proporcionar servicios de datos de conmutación de paquetes basados en GSM. Las comunicaciones móviles de tercera generación (3G) están relacionadas con la transmisión y recepción no únicamente de señales de voz, sino también de vídeo y datos. El 3GPP (Proyecto de Colaboración de Tercera Generación) desarrolló el sistema de comunicación móvil IMT-2000 y seleccionó WCDMA como su tecnología de acceso radio (RAT). La combinación de IMT-2000 y WCDMA se puede denominar UMTS (Sistema de Telecomunicaciones Móvil Universal), el cual comprende una Red de Acceso Radio Terrestre UMTS (UTRAN). La figura 1 muestra la arquitectura de red de un Sistema de Telecomunicaciones Móvil Universal (UMTS). El sistema UMTS está compuesto básicamente por un equipo de usuario (UE) 10, una Red de Acceso Radio Terrestre UMTS (UTRAN) 50, y una red troncal (CN) 60. La UTRAN 50 tiene uno o más subsistemas de red radio (RNS) 30, 40 y cada R<n>S tiene un controlador de red radio (RNC) 33, 43, y uno o más Nodos B 31, 32, 41, 42 que son gestionados por el RNC 33, 43. Para un Nodo B existe una o más celdas.

La figura 2 muestra la pila del protocolo de radio utilizada en UMTS. Las capas del protocolo de radio existen en paralelo en el terminal móvil y en la UTRAN, y gestionan la transmisión de datos sobre la interfaz de radio. La pila del protocolo de radio se divide groso modo en tres capas: L1 (Capa 1), L2 (Capa 2) y L3 (Capa 3).

La L1 (Capa 1) tiene la capa física (PHY) que utiliza varios tipos de técnicas de transmisión radio para transmitir datos con fiabilidad sobre la interfaz radio. La capa PHY está conectada a una capa superior (la capa MAC) mediante canales de transporte, los cuales se pueden dividir en canales de transporte dedicados y canales de transporte comunes.

La L2 (Capa 2) está compuesta de cuatro subcapas: MAC, RLC, PDCP y BMC, cada una de las cuales se describirá con más detalle a continuación.

La capa MAC (Control de Acceso al Medio) realiza un mapeo de varios canales lógicos a varios canales de transporte, y también realiza la multiplexación de canal lógico de múltiples canales lógicos para un único canal de transporte. La capa MAC está conectada con una capa superior (la capa RLC) a través de uno o más canales lógicos. En función del tipo de información que se transmite, estos canales lógicos se pueden dividir en canales de control utilizados para transmitir información del plano de control y canales de tráfico utilizados para transmitir información del plano de usuario. En función de los tipos de canales de transporte que se gestionan, la capa MAC se puede dividir en una subcapa MAC-b, una subcapa MAC-c/sh, una subcapa MAC-d, una subcapa MAC-hs y una subcapa MAC-e. La subcapa MAC-b controla la gestión de un BCH (Canal de Difusión) utilizado para difundir información del sistema. La subcapa MAC-c/sh gestiona canales compartidos de transporte como, por ejemplo, el FACH (Canal de Acceso Directo), el DSCH (Canal Compartido del Enlace Descendente), etc., los cuales se comparten con otros terminales móviles. La subcapa MAC-d controla la gestión de canales dedicados de transporte como, por ejemplo, el DCH (Canal Compartido del Enlace Descendente), con respecto a un terminal móvil concreto. Con el fin de soportar transmisiones de datos de alta velocidad sobre el enlace descendente y el enlace ascendente, la subcapa MAC-hs gestiona el HS-DSCH (Canal Compartido del Enlace Descendente de Alta Velocidad), el cual es un canal de transporte para transmitir datos del enlace descendente a alta velocidad. La subcapa MAC-e gestiona el E-DCH (Canal Dedicado Mejorado), el cual es un canal de transporte para las transmisiones de datos del enlace ascendente a alta velocidad.

La capa RLC (Control del Enlace Radio) controla la garantía de la calidad de servicio (QoS) de cada una de las portadoras radio (RB) y la transmisión de datos sobre ellas. Para que el RLC garantice una QoS individual de la RB, para cada RB existen una o dos entidades RLC independientes, y se proporcionan tres tipos de modos RLC (TM: Modo Transparente; UM: Modo Sin Confirmar; AM: Modo Confirmado) con el fin de soportar las distintas QoS. Además, el RLC ajusta el tamaño de los datos para que sea apropiado para la transmisión sobre la interfaz radio (aérea) por parte de una capa inferior, y realiza las funciones de segmentación y concatenación de los datos (Unidades de Datos de Servicio: SDU) recibidos desde una capa superior (esto es, la capa RLC).

La capa PDCP (Protocolo de Convergencia de Paquetes de Datos) se sitúa sobre la capa RLC y permite que los datos se transmitan de forma efectiva utilizando paquetes IP (como, por ejemplo, IPv4 o IPv6) sobre la interfaz radio (aérea) con un ancho de banda relativamente pequeño. Para hacerlo, la capa PDCP realiza una función de compresión de cabeceras, lo cual permite una transmisión de datos que es necesaria únicamente en la porción de cabecera de datos de modo que aumenta la eficiencia de transmisión sobre la interfaz radio (aérea). La capa PDCP únicamente existe en el dominio PS (Conmutación de Paquetes) debido a que la compresión de cabeceras es una función básica, y existe una entidad PDCP por cada RB con el fin de proporcionar de forma efectiva funciones de compresión de cabeceras con respecto a cada servicio PS.

La capa BMC (Control de Difusión/Multidifusión) existe sobre la capa RLC y realiza las funciones asociadas a la planificación de mensajes de difusión de celda y la difusión a terminales móviles situados en una celda concreta. La L3 (Capa 3) tiene la capa RRC (Control de Recursos Radio), situada en su parte inferior, que está definida únicamente en el plano de control, para controlar parámetros de L1 y L2 con respecto al establecimiento, restablecimiento y liberación de portadoras radio, así como para controlar los canales lógicos, canales de transporte y canales físicos. Aquí, una portadora radio se refiere a una ruta lógica que es proporcionada por las L1 y L2 del protocolo radio para transferir datos entre el terminal móvil y laUTRa N.En general, el establecimiento de la portadora radio se refiere a un procedimiento de configuración de las características de las capas del protocolo de radio y los canales necesarios para proporcionar un servicio concreto y, a continuación, configurar cada parámetro concreto y sus métodos de funcionamiento.

A continuación, se hará referencia a la figura 3 para describir la capa PDCP con más detalle. Se muestra una entidad PDCP de ejemplo de la capa PDCP de la figura 2. La entidad PDCP de la figura 3 está conectada a la capa RRC o a una aplicación de usuario situada por encima de ella y conectada a la capa RLC por debajo de ella. Esta entidad PDCP comprende un lado transmisor y un lado receptor.

En la figura 3, el lado izquierdo representa el lado transmisor con una memoria intermedia de transmisión, una unidad de compresión de cabeceras, una unidad de control de seguridad, y una unidad para adjuntar una cabecera PDCP, mientras que el lado derecho representa el lado receptor con una unidad de eliminación de la cabecera PDCP, una unida de control de seguridad, una unidad de cancelación de compresión de cabeceras y una memoria intermedia de recepción. Dichos lados transmisor y receptor comparten una unidad de control PDCP.

La entidad PDCP del lado transmisor construye las PDU (Unidades de Datos de Protocolo) utilizando SDU (Unidades de Datos de Servicio) recibidas desde la capa superior o utilizando información de control que ha sido generada por la propia entidad PDCP y, a continuación, transmite dichas PDU a una entidad PDCP homóloga (esto es, una entidad PDCP dentro del RNS) en el lado receptor. Esta entidad PDCP en el lado receptor convierte las PDU de PDCP recibidas en SDU de PDCP o extrae la información de control desde las PDU de PDCP recibidas.

Se debería observar que los bloques funcionales que se muestran en la figura 3 se pueden implementar de muchas formas diferentes tal como pueden comprender aquellos experimentados en la técnica.

Tal como se ha mencionado previamente, las PDU generadas por la entidad PDCP en el lado transmisor pueden ser PDU de Datos y PDU de Control.

La PDU de Datos PDCP es un bloque de datos construido en la entidad PDCP procesando la SDU recibida desde una capa superior. La PDU de Control PDCP es un bloque de datos que genera la propia entidad PDCP con el fin de transferir información de control a una entidad PDCP homóloga.

La PDU de Datos PDCP es generada para la portadora radio (RB) tanto del plano de usuario (plano-U) como del plano de control (plano-C), y algunas de las funciones PDCP se aplican de forma selectiva al plano de usuario. Específicamente, la función de compresión de cabecera se aplica únicamente para los datos del plano U, y la función de protección de integridad dentro de las funciones de la unidad de control de seguridad se aplica únicamente para los datos del plano C. Además de la función de protección de integridad, la unidad de control de seguridad también dispone de una función de cifrado que mantiene la seguridad de los datos, y dicha función de cifrado se aplica tanto a los datos del plano U como a los datos del plano C.

La PDU de Control PDCP es generada únicamente por la portadora radio (RB) del plano U, y existen dos tipos: (1) un mensaje de informe de estado PDCP (esto es, “PCDP Status Report”) utilizado para informar al lado transmisor sobre el estado de la memoria intermedia de recepción de la entidad PDCP y (2) un Paquete de Realimentación de Compresión de Cabecera (“Header Compression Feedback”) utilizado para informar sobre el estado de descompresión de cabecera a la compresión de cabecera del lado transmisor.

El mensaje de informe de estado PDCP (mensaje “PDCP Status Report”) se transmite desde el PDCP receptor al PDCP transmisor con el fin de informar al PDCP transmisor sobre las PDU de PDCP que han sido recibidas o no por parte del PDCP receptor, de modo que se puedan retransmitir las SDU de PDCP que no se han recibido y las SDU de PDCP no recibidas no necesitan ser retransmitidas. Este mensaje de informe de estado PDCP se puede enviar en forma de una PDU de Estado PDCP y en la figura 4 se muestra un ejemplo de su estructura.

La figura 4 muestra un ejemplo de PDU de Estado PDCP generada por la Unidad de Control PDCP de la figura 3. Tal como se puede observar, la PDU de Estado PDCP está formada por uno o más octetos (1 octeto = 8 bits) que incluyen un campo D/C (Datos/Control), un campo de Tipo de PDU, un campo de número de Primera Secuencia Pendiente (FMS), y un campo de mapa de bits (Bitmap).

El campo D/C está formado por 1 bit que se utiliza para informar si la PDU correspondiente es una PDU de Datos o una PDU de Control.

El campo Tipo de PDU está formado por 3 bits utilizados para informar sobre el tipo de PDU de Control. Por ejemplo, el valor '000' significa Informe de Estado PDCP (“PDCP Status Report”), el valor '001' significa Información de Realimentación de Compresión de Cabecera (“Header Compression Feedback Information”), y se reservan otros tipos de valores para un uso futuro.

El campo FMS está formado por 12 bits y se utiliza para indicar el número de secuencia (SN) de la primera SDU de PDCP que no fue recibida por el receptor (esto es, una primera SDU de PDCP fuera de secuencia, una primera SDU de PDCP no recibida, una primera SDU de PDCP pendiente, etc.).

El campo Bitmap es de longitud variable y un valor de bit 0 indica que el dato de dicha posición no se ha recibido apropiadamente, mientras que un bit 1 indica que el dato de dicha posición se ha recibido satisfactoriamente. Dicho Informe de Estado PDCP (“PDCP Status Report”) se puede utilizar para varios tipos de situaciones que requerirían un restablecimiento PDCP como, por ejemplo, situaciones de traspaso (HO).

La entidad PDCP del lado transmisor (por ejemplo, el terminal móvil o el Nodo B) recibe las SDU de PDCP de la capa superior y las almacena en una memoria de almacenamiento intermedio de transmisión después de la transmisión en caso de que posteriormente sea necesaria su retransmisión. A partir de ahí, cuando se produce un traspaso (u otra situación de restablecimiento PDCP), a través de un Informe de Estado PDCP (“PDCP Status Report”) se proporciona un informe sobre las SDU de PDCP que se han recibido y las SDU de PDCP que no se han recibido, y después del traspaso se retransmiten las SDU de PDCP que no se habían recibido.

Por ejemplo, la entidad PDCP en el terminal móvil recibe las SDU de PDCP de la capa superior, las transmite a la estación base y las almacena en una memoria de almacenamiento intermedio de transmisión incluso después de la transmisión. A continuación, cuando se produce un traspaso (o cualquier otra situación que requiera un restablecimiento PDCP), el terminal móvil recibe información (mediante un Informe de Estado PDCP (“PDCP Status Report”) que se devuelve) sobre las SDU de PDCP que no han sido recibidas por la estación base, y dichas SDU de PDCP se retransmiten.

Tal como se ha descrito anteriormente, cuando se produce un traspaso (o cualquier otra situación que requiera un restablecimiento PDCP), el Nodo B cambia de la fuente al destino y, como también cambia la entidad PDCP, se deben utilizar las retransmisiones.

A continuación, se describe un ejemplo de generación de PDU de Estado PDCP.

En primer lugar, después de que la capa superior haya configurado una portadora radio (RB) al decidir que se debería transmitir un mensaje de Informe de Estado PDCP (mensaje “PDCP Status Report”), se compila un informe de estado (tal como se indica más abajo), construido en formato PDU para su transmisión, y es enviado a la capa inferior

- establecer el valor FMS para indicar el Número de Secuencia PDCP de la primera SDU de PDCP pendiente (o fuera de secuencia);

- asignar, como longitud del campo Bitmap, la longitud del valor (esto es el número de números de secuencia PDCP) desde (y sin incluir) la primera SDU de PDCP no recibida (fuera de secuencia) hasta (e incluida) la última SDU de PDCP fuera de secuencia recibida. Aquí, la longitud del campo Bitmap es de un máximo de 8 bits. Si es menos de 8 bits, se realiza un redondeo hasta el siguiente múltiplo de 8 bits, mientras que si es más de 8 bits, se utiliza el siguiente campo Bitmap;

- fijar con el valor 0 las posiciones de bit correspondientes del campo Bitmap. Aquí, 0 indica las SDU de PDCP no recibidas desde el transmisor en la capa inferior o indica las SDU de PDCP que se han recibido pero cuya descompresión de cabeceras no fue satisfactoria. (Esto es, se fija con el valor '0' la posición correspondiente del campo de mapa de bits todas las SDU de PDCP que no se han recibido tal como han indicado las capas inferiores y, opcionalmente, las PDU de PDCP para las que ha fallado la descompresión);

- fijar con el valor 1 las posiciones de bit correspondientes del campo Bitmap. Aquí, 1 indica las otras SDU de PDCP (no definidas anteriormente), esto es, las SDU de PDCP que se han recibido correctamente en la capa inferior. (Esto es, indicar en el campo de mapa de bits como '1' todas las demás SDU de PDCP).

Sin embargo, el procedimiento anterior de generación de la PDU de Estado PDCP no sólo hace que existan situaciones en las que se transmita dos veces información innecesaria, sino que también provoca que existan situaciones en las que no se puede transmitir en absoluto la información necesaria.

Haciendo referencia a las figuras 5 y 6, a continuación se explicará un procedimiento de ejemplo de generación de la PDU de Estado PDCP de acuerdo con la presente invención:

La figura 5 muestra un ejemplo de generación de PDU de Estado PDCP.

Tal como se muestra en (a) en la figura 5, dentro de una secuencia de SDU con números de secuencia de 3 a 12, se supone que la capa inferior del receptor ha recibido las SDU 3, 4, 7, 8 y 12, mientras que no se han recibido las SDU 5, 6, 9, 10 y 11.

En dicho caso, tal como se muestra en (b) de la figura 5, de acuerdo con este procedimiento de generación de PDU de Estado PDCP, el terminal móvil le asigna al campo FMS el valor 5, que es el número de secuencia de la primera SDU no recibida.

Además, como el número de secuencia de la última SDU recibida fuera de secuencia es 12 (porque se han recibido las SDU 7 y 8 y se ha recibido la SDU 12), son necesarios un total de 8 bits para expresar las SDU con los números de secuencia de 5 a 12 (= un total de 8 SDU) y, de este modo, se fija una longitud de 8 para el campo Bitmap.

Adicionalmente, con respecto a las SDU con números de secuencia de 5 a 12, el terminal móvil utiliza cada bit del campo Bitmap para expresar si ha sido satisfactoria o no la recepción de cada SDU. Esto es, para la situación anterior el campo Bitmap sería 00110001.

Tal como se ha explicado hasta ahora, de acuerdo con el procedimiento de generación de la PDU de Estado PDCP, la información para la SDU correspondiente al número de secuencia 5 se incluye dos veces en la PDU de Estado PDCP, lo que provoca un desaprovechamiento de recursos de radio.

Además, la última SDU recibida fuera de secuencia (esto es, la SDU con SN=12) siempre tiene el valor 1 en el campo Bitmap y, de este modo, dicha inclusión provoca un desaprovechamiento de recursos de radio.

Adicionalmente, con respecto a la SDU 12 de PDCP, que es la última SDU en el procedimiento anterior, de acuerdo con su definición, como es una SDU recibida satisfactoriamente en la entidad PDCP receptora, siempre tendrá el valor 1. De este modo, no sería necesario transmitir información sobre esta SDU.

La figura 6 muestra otro procedimiento de ejemplo para generar una PDU de Estado PDCP.

Tal como se muestra en (a) en la figura 6, dentro de las SDU con números de secuencia de 3 a 13, se supone que la capa inferior del receptor ha recibido las SDU 3~12, mientras que no se ha recibido la SDU 13.

En dicho caso, tal como se muestra en (b) en la figura 6, de acuerdo con dicho método de generación de la PDU de Estado PDCP, el terminal móvil le asigna el valor 13 al campo FMS, que es el número de secuencia de la primera SDU que no se ha recibido.

Además, como la última SDU fuera de secuencia tiene un número de secuencia de 12, la representación de las SDU 12 y 13 requiere un tamaño de 2 bits, pero, al redondear (al múltiplo de 8 más cercano), la longitud del campo Bitmap es 8 bits, de este modo, se fija a 1 byte.

Adicionalmente, el terminal móvil tiene que representar si se han recibido o no las SDU 12 y 13 utilizando los respectivos bits en el campo Bitmap. Sin embargo, como la última SDU fuera de secuencia recibida tiene el número de secuencia 12, que es menor que el número de secuencia 13 de la primera SDU no recibida, se produce un error cuando se establece cada uno de los bits del campo Bitmap. Además, como el campo Bitmap tiene una longitud de 8 bits (=1 byte), mientras que únicamente es necesario rellenar 2 bits, no está claro cómo se debe rellenar el resto de bits.

Además, como el receptor ha recibido correctamente todas las SDU, únicamente es necesario enviar informe sobre la primera SDU 13 no recibida. Esto es, en este caso no es necesario el campo Bitmap. Pese a ello, tal como se ha descrito más arriba, se ha establecido una longitud de 1 byte para el campo Bitmap de la PDU de Estado PDCP y se ha transmitido, lo cual provoca un desaprovechamiento de recursos de radio.

En consecuencia, basándose en dicho reconocimiento del problema, la presente invención se ha concebido de modo que el mensaje de Informe de Estado PDCP (“PDCP Status Report”) se genera de forma más efectiva, lo que hace que se minimice el desaprovechamiento de recursos de radio.

Además, la presente invención permite proporcionar una información más eficiente asociada a las SDU recibidas y no recibidas en el receptor.

Con el fin de abordar los problemas anteriores, se proporciona un método de transmisión de informe de estado PDCP que comprende los siguientes pasos: recibir una petición de restablecimiento PDCP desde una capa superior; determinar si se ha almacenado alguna SDU de PDCP fuera de secuencia; y si se ha almacenado una SDU de PDCP fuera de secuencia, entonces asignar como longitud de un campo Bitmap de un mensaje de Informe de Estado PDCP (“PDCP Status Report”) el número de bits igual al número de SDU desde la SDU posterior a la primera SDU de PDCP pendiente hasta una última SDU de PDCP fuera de secuencia recibida. Si no se ha almacenado ninguna SDU de PDCP fuera de secuencia, en el mensaje de Informe de Estado PDCP (“PDCP Status Report”) no se incluye el campo Bitmap.

La SDU de PDCP se puede almacenar en una memoria de almacenamiento intermedia.

Los pasos anteriores se ejecutan para un modo AM (Modo Confirmado) del RLC (Control de Enlace Radio). La petición de restablecimiento PDCP se puede producir en una situación de traspaso.

El mensaje de Informe de Estado PDCP (“PDCP Status Report”) también puede incluir un campo FMS, en el que se configura un número de secuencia de la primera SDU de PDCP pendiente.

El valor 0 en el campo Bitmap puede indicar que no se ha recibido correctamente la SDU de PDCP correspondiente, mientras que el valor 1 del campo Bitmap puede indicar que se ha recibido correctamente la SDU de PDCP.

Teniendo en cuenta los efectos de la presente invención, se puede reducir el tamaño del Informe de Estado PDCP (“PDCP Status Report”), se puede incluir únicamente la información necesaria, y se puede conseguir una utilización más efectiva de los recursos de radio.

Las características descritas en el presente documento se pueden aplicar a las tecnologías denominadas LTE (Evolución a Largo Plazo), que se han desarrollado después de las comunicaciones móviles 3G como anticipación al rápido aumento del tráfico de datos. Ese es un aspecto del desarrollo de una red evolucionada que puede soportar un ancho de banda mayor, y se utiliza el término E-UTRAN (UTRAN Evolucionada).

Sin embargo, las características descritas en el presente documento no se limitan a LTE, sino que también se pueden adaptar, aplicar e implementar en varios sistemas y métodos de comunicación distintos como, por ejemplo, GSM, GPRS, CDMA, CDMA2000, WCDMA, IEEE 802.xx, UMTS, etc.

De aquí en adelante se utiliza el término 'terminal móvil', pero también se puede denominar US (Equipo de Usuario), ME (Equipo Móvil), MS (Estación Móvil), etc. También, un terminal móvil puede incluir dispositivos altamente portátiles con funciones de comunicación como, por ejemplo, un teléfono portátil, una PDA, un Teléfono Inteligente, un ordenador portátil, etc., así como dispositivos menos portátiles como, por ejemplo, ordenadores personales (PC), dispositivos instalados en vehículos, etc.

Los términos y frases técnicos utilizados en el presente documento se utilizan para describir características en realizaciones concretas, y no pretenden limitar los conceptos de la presente invención. Además, si un término técnico en el presente documento no se ha definido específicamente de forma diferente, se interpretará que tiene el significado que una persona con un conocimiento normal en la técnica entendería, sin una interpretación excesivamente amplia o excesivamente limitada. Si cualquier término en el presente documento se ha utilizado erróneamente o no es completamente preciso técnicamente, entonces dichos términos se pueden clarificar o interpretar como aquellos experimentados en la técnica estimen oportuno. Además, ciertos términos generales utilizados en el presente documento se interpretarán de acuerdo con su significado del diccionario, o se interpretarán teniendo en cuenta el contexto sin interpretarlo demasiado restrictivamente.

Además, cualquier palabra o frase utilizada en singular en el presente documento se puede interpretar que abarca el plural, a menos que se especifique claramente lo contrario. No se debería interpretar que las expresiones “que incluye” o “que comprende” o similares quieren decir que es necesario que siempre se encuentren presentes los distintos elementos o pasos. Puede no ser necesario que se encuentren presentes algunos elementos o pasos, o también se pueden encontrar presentes elementos o pasos adicionales.

Las palabras “primero” o “segundo” u otros términos con una connotación de orden o secuencia pueden utilizarse para describir varios elementos o pasos diferentes para proporcionar un modo de diferenciarlos entre sí, a menos que se especifique que el orden numérico tiene algún significado. Por ejemplo, sin exceder el alcance de la presente invención, un primer elemento también se puede explicar como segundo elemento, mientras que un segundo elemento también se puede explicar como primer elemento.

Para cualquier descripción sobre un elemento que esté “conectado a” o “conectado con” o similares, con respecto a otro elemento, entre los dos elementos puede ser posible una conexión directa o puede existir un elemento intermedio. Por otro lado, si dos elementos se describen como conectados “directamente”, esto puede querer decir que entre ellos no existen otros elementos.

De aquí en adelante, con referencia a los dibujos adjuntos, se explicarán algunas realizaciones, y, con independencia de los números de referencia en los dibujos, algunos elementos se pueden etiquetar con los mismos números de referencia y se puede haber omitido cualquier explicación repetitiva únicamente en beneficio de ser breve. Además, algunos aspectos de la técnica asociada o convencional, que puede ser la base para la presente invención, pueden no haberse explicado, pero podrían ser entendidos por aquellos experimentados en la técnica. Las características que se muestran en los dibujos adjuntos se describen únicamente para mejorar la comprensión de la presente invención y no se debería interpretar que limitan las enseñanzas de la presente invención.

La figura 7 muestra un ejemplo de un diagrama de flujo que representa un procedimiento de Informe de Estado PDCP útil para entender la presente invención. Se puede entender que se cuenta el número total de SDU desde la SDU después de la primera SDU de PDCP pendiente y hasta la última SDU de PDCP recibida fuera de secuencia, y se asigna a la longitud del campo Bitmap un número de bits correspondiente. De este modo, en la presente divulgación, con respecto a la RB establecida para transmitir el mensaje de informe de estado PDCP, cuando se asigna la longitud del campo Bitmap de la PDU de Estado PDCP en el mensaje de informe de estado PDCP, no se considera la primera<s>D<u>de PDCP pendiente, sino la SDU posterior a la primera SDU de PDCP pendiente hasta la última SDU de PDCP recibida fuera de secuencia.

En primer lugar, la capa PDCP recibe, desde una capa superior, una petición de restablecimiento PDCP con respecto a una portadora radio (RB) (S110). Aquí la petición de restablecimiento PDCP se puede producir para una situación de traspaso de un terminal móvil.

A continuación, para la RB, se comprueba si existe alguna SDU de PDCP no secuencial (o fuera de secuencia) que se haya almacenado (S120).

Si es así, se utiliza el valor del número de secuencia (SN) de la primera SDU de PDCP no recibida para configurar el campo FMS de la PDU de Estado PDCP (S130).

Además, se determina el número total de SDU de PDCP no recibidas (esto es, las SDU de PDCP pendientes), y se comprueba si excede 1 (S140). Si el número total es 1 o menos, el campo Bitmap no se incluye en la PDU de Estado PDCP (S170). Sin embargo, como alternativa, el campo Bitmap se puede configurar e incluir de acuerdo con el procedimiento (S150).

Si el número total excede 1, entonces dentro de un rango definido desde la siguiente SDU justo después de la primera SDU de PDCP no recibida hasta la última SDU de PDCP recibida (en otras palabras, entre las SDU de PDCP recibidas de forma no secuencial, la SDU de PDCP con el mayor número de secuencia, esto es, la última SDU de PDCP fuera de secuencia), se obtiene el número total de SDU de PDCP dentro de dicho rango y se establece como su longitud el mismo número de bits en el campo Bitmap (S150).

En otras palabras, se asigna el campo Bitmap con una longitud en bits que es igual al número total de SDU de PDCP (Números de Secuencia) desde, y sin incluir, la primera SDU de PDCP pendiente hasta, e incluyendo, la última SDU de PDCP fuera de secuencia.

Aquí, el número de bits se redondea a múltiplos de 8, con el fin de determinar la longitud del campo Bitmap. Cuando se obtiene el número total, el conteo se puede basar en las SDU de PDCP o las PDU de PDCP. Cuando se van a utilizar las PDU de PDCP, entonces se excluye el número de PDU de Control PDCP, y únicamente se utiliza el número de PDU de Datos PDCP.

En el procedimiento (S150) anterior para establecer la longitud del campo Bitmap, se excluye de consideración la primera SDU de PDCP no recibida, pero se considera la última SDU de PDCP fuera de secuencia. Alternativamente, algunas veces se puede excluir la última SDU de PDCP fuera de secuencia, ya que se ha recibido correctamente y siempre tiene el valor 1. En dicho caso, se considera la SDU de PDCP inmediatamente anterior a la última SDU de PDCP fuera de secuencia.

A continuación, en función de la longitud del campo Bitmap, el campo Bitmap se completa y se transmite (S160). Aquí, el campo Bitmap tiene una primera posición de bit que contiene información para una SDU de PDCP con un número de secuencia igual al valor del campo FMS 1, cuyo valor es 1 si se ha recibido correctamente o su valor es 0 si no se ha recibido correctamente. Como tal, el campo Bitmap tiene un bit en la N-ésima posición que contiene información para una SDU de PDCP con un número de secuencia igual al valor del campo FMS+N, cuyo valor es 1 si se ha recibido correctamente o su valor es 0 si no se ha recibido correctamente.

Lo anterior se puede describir según la siguiente Tabla:

Tabla 1

Tal como se ha descrito hasta ahora, de acuerdo con la presente invención, se utiliza la primera posición de bit del campo Bitmap para informar si se ha recibido correctamente o no la SDU de PDCP (con un número de secuencia correspondiente al valor del campo FMS 1).

Además, de acuerdo con la presente invención, cuando existen 2 o más SDU de PDCP que no se han recibido correctamente, únicamente se pueden utilizar los recursos de radio de forma efectiva incluyendo el campo Bitmap en el mensaje de Informe de Estado PDCP (“PDCP Status Report”).

La figura 8 muestra otro ejemplo para generar una PDU de Estado PDCP.

Tal como se muestra en (a) en la figura 8, entre las SDU secuenciales con números de secuencia de 3 a 12, la capa inferior del receptor ha recibido las SDU 3, 4, 7, 8 y 12 mientras que las SDU 5, 6, 9, 10 y 11 no se han recibido.

En dicho caso, tal como se muestra en (b) en la figura 8, de acuerdo con el método de la presente invención, la capa PDCP del terminal móvil asigna el valor 5 al campo FMS, siendo 5 el número de secuencia de la primera pendiente (no recibida).

Además, para la SDU posterior a la primera SDU no recibida, comenzando desde dicha SDU con un número de secuencia de 6 hasta la última SDU recibida no secuencial (o fuera de secuencia) con un número de secuencia de 12 (porque las SDU 7, 8 se han recibido, y la SDU 12 se ha recibido), como los bits necesarios son 7 bits, al redondear hacia arriba al nivel de 8 bits, la longitud del campo Bitmap se configura con 8 bits.

Además, la capa PDCP del terminal móvil indica si se ha recibido correctamente cada SDU con los números de secuencia de 6 a 12, y se representa mediante los bits del campo Bitmap. Aquí, dicho campo Bitmap tendría el valor 01100010.

Aquí, el bit en la primera posición del campo Bitmap indica si se ha recibido correctamente o no la SDU de PDCP con SN=6.

La figura 9 muestra otro ejemplo sobre el procedimiento de generación de la PDU de Estado PDCP.

Tal como se muestra en (2) de la figura 9, entre las SDU consecutivas que tienen números de secuencia de 3 a 13, se supone que la capa inferior del terminal móvil de recepción ha recibido las SDU 3~12, y no se ha recibido la SDU 13.

Como tal, como se muestra en (b) de la figura 9, la capa PDCP del terminal móvil asigna al campo FMS el número de secuencia 13 de la primera SDU no recibida (S130).

Además, como se comprueba que el número de las SDU de PDCP no recibidas no excede 1 (S140), el campo Bitmap no está incluido en la PDU de Estado PDCP (S170).

Volviendo a hacer referencia a la figura 7, se explicó que alternativamente, se podría incluir el campo Bitmap en la PDU de ESTADO PDCP. Si la recepción se realiza como en (a) de la figura 9, y la PDU de ESTADO p Dc P incluye el campo Bitmap, en el procedimiento para configurar el valor del campo Bitmap (S150), también se puede excluir de consideración la última PDU de PDCP recibida fuera de secuencia. Esto es porque la última PDU de PDCP recibida fuera de secuencia está siempre en secuencia con el número de secuencia de la SDU de PDCP con recepción correcta, dicha información se puede incluir e indicar de forma indirecta. En tal caso, el procedimiento de configuración de longitud del campo Bitmap (S150) se puede modificar del siguiente modo. Se obtiene el número total de SDU de PDCP con un número de secuencia dentro de un rango desde la SDU de PDCP con un número de secuencia que es inmediatamente posterior a la primera SDU de PDCP no recibida dentro de las SDU de PDCP recibidas fuera de secuencia, y hasta la SDU de PDCP con un número de secuencia inmediatamente anterior a la última SDU de PDCP fuera de secuencia con el número de secuencia mayor, y se configura el tamaño del campo Bitmap para que tenga el mismo número de bits que el número total de SDU de PDCP obtenido. Esto es, cuando se configura la longitud del Bitmap, se excluye de consideración la primera SDU de PDCP no recibida y también se excluye la última SDU de PDCP recibida fuera de secuencia. El método de la presente invención explicado hasta el momento se puede implementar mediante software, hardware o una combinación de los mismos. Por ejemplo, el método de la presente invención se puede implementar como códigos o instrucciones de un programa de software que se puede ejecutar mediante un procesador (CPU), y se puede almacenar en un medio de almacenamiento (por ejemplo, una memoria, un disco duro, etc.).

Determinados aspectos del método de la presente invención se implementan en un terminal móvil o entidad de red (por ejemplo, el RNC o el Nodo B de la figura 1). El terminal móvil o la entidad de red pueden incluir los protocolos de las figuras 2 y 3, tal como pueden comprender aquellos experimentados en la técnica.

Hasta el momento se han descrito algunas realizaciones a modo de ejemplo de la presente invención, pero dichas realizaciones no pretenden limitar las características descritas en el presente documento. Como tales, todas las distintas modificaciones, cambios, mejoras y variaciones razonables forman parte de la presente invención.

Aplicabilidad Industrial

Las características y conceptos en el presente documento son aplicables a, y se pueden implementar en, diversos tipos de dispositivos de usuario (por ejemplo, terminales móviles, teléfonos, dispositivos de comunicación inalámbrica, etc.) y/o entidades de red que se pueden configurar para soportar un método para transmitir informes de estado PDCP.

Como los distintos conceptos y características descritos en el presente documento se pueden llevar a cabo en varias formas sin apartarse de sus características, se debería entender que las realizaciones descritas anteriormente no se encuentran limitadas por ninguno de los detalles de la descripción anterior, a menos que se haya especificado lo contrario, sino que se deberían interpretar ampliamente dentro de su alcance tal como se define en la reivindicación adjunta.

Claims (1)

REIVINDICACIONES

1. Un informe de estado PDCP, Protocolo de Convergencia de Paquetes de Datos, transmitido por un dispositivo de comunicación inalámbrica y generado por una entidad PDCP situada entre una capa superior y una capa inferior del dispositivo de comunicación inalámbrica, después de pedir un restablecimiento PDCP desde la capa superior mediante la determinación de un número total de SDU, Unidades de Datos de Servicio, de PDCP pendientes, que comprende:

un campo de número de Primera Secuencia Pendiente (FMS) fijado con un número de secuencia PDCP de una primera SDU, Unidad de Datos de Servicio, de PDCP pendiente,

un campo de mapa de bits de longitud en bits igual al número de números de secuencia, SN, de PDCP desde, y que no incluye, la primera SDU de PDCP pendiente hasta, y que incluye, la última SDU de PDCP fuera de secuencia, redondeado hacia arriba hasta el siguiente múltiplo de 8, si el número total de SDU de PDCP pendientes excede de uno;

en el que posiciones del campo de mapa de bits para todas las SDU de PDCP que no se han recibido están indicadas por la capa inferior con un '0', y en el que posiciones del campo de mapa de bits para todas las demás SDU de PDCP están indicadas con un '1'; y

en el que, si el número total de SDU de PDCP pendientes es uno o menos, el informe de estado PDCP no incluye el campo de mapa de bits.