ES2463095T3 - Método de comunicación inalámbrica para transmitir una secuencia de unidades de datos entre un dispositivo inalámbrico y una red - Google Patents
Método de comunicación inalámbrica para transmitir una secuencia de unidades de datos entre un dispositivo inalámbrico y una red Download PDFInfo
- Publication number
- ES2463095T3 ES2463095T3 ES10194238.1T ES10194238T ES2463095T3 ES 2463095 T3 ES2463095 T3 ES 2463095T3 ES 10194238 T ES10194238 T ES 10194238T ES 2463095 T3 ES2463095 T3 ES 2463095T3
- Authority
- ES
- Spain
- Prior art keywords
- pdcp
- received
- sdu
- bitmap
- status report
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000004891 communication Methods 0.000 title claims abstract description 51
- 238000000034 method Methods 0.000 title claims abstract description 25
- 238000012546 transfer Methods 0.000 claims description 31
- 230000005540 biological transmission Effects 0.000 claims description 21
- 230000006870 function Effects 0.000 description 16
- 238000005259 measurement Methods 0.000 description 11
- 230000011664 signaling Effects 0.000 description 8
- 238000010586 diagram Methods 0.000 description 7
- 238000007726 management method Methods 0.000 description 6
- 230000006837 decompression Effects 0.000 description 3
- 102100035591 POU domain, class 2, transcription factor 2 Human genes 0.000 description 2
- 101710084411 POU domain, class 2, transcription factor 2 Proteins 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 2
- 230000006835 compression Effects 0.000 description 2
- 238000007906 compression Methods 0.000 description 2
- 238000012790 confirmation Methods 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000010295 mobile communication Methods 0.000 description 2
- 241000760358 Enodes Species 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1614—Details of the supervisory signal using bitmaps
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
- H04L1/0023—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the signalling
- H04L1/0028—Formatting
- H04L1/0031—Multiple signaling transmission
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1635—Cumulative acknowledgement, i.e. the acknowledgement message applying to all previous messages
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W48/00—Access restriction; Network selection; Access point selection
- H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Quality & Reliability (AREA)
- Mobile Radio Communication Systems (AREA)
- Small-Scale Networks (AREA)
- Communication Control (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
Abstract
Un dispositivo de comunicación configurado para transferir un informe de estado en un sistema de comunicación inalámbrica, el dispositivo de comunicación que comprende: -una unidad de configuración para configurar un informe de estado de PDCP, Protocolo de Convergencia de Datos por Paquetes, de aquí en adelante abreviado como un informe de estado de PDCP, en el que el informe de estado de PDCP pertenece a una capa de PDCP situada por encima de una capa de RLC, Control de Enlace de Radio, el informe de estado de PDCP que incluye un indicador que indica un número de secuencia de una primera SDU de PDCP no recibida y un mapa de bits que proporciona información de estado acerca de la recepción de al menos una SDU de PDCP que sigue a dicha primera SDU de PDCP no recibida; y -una unidad de transmisión para transferir el informe de estado de PDCP configurado a la capa de RLC, en el que el indicador es un campo de primer número de secuencia ausente de PDCP, de aquí en adelante abreviado como FMS, que contiene el número de secuencia de la primera SDU de PDCP no recibida, y en el que dicha al menos una SDU de PDCP comienza a partir de una SDU de PDCP después de la 15 primera SDU de PDCP no recibida.
Description
Método de comunicación inalámbrica para transmitir una secuencia de unidades de datos entre un dispositivo inalámbrico y una red
Antecedentes de la invención
Campo de la invención
La presente invención se refiere a comunicación inalámbrica.
Más concretamente se refiere a retransmisión selectiva de unidades de datos entre un dispositivo inalámbrico y una red, dependiendo de si se han recibido o no.
Aunque se describe a continuación en el contexto de un tipo de red celular LTE (Evolución a Largo Plazo) con fines ilustrativos y debido a que parece adaptarse bien a ese contexto, los expertos en la técnica de las comunicaciones reconocerán que la invención descrita en la presente memoria también se puede aplicar a otros diversos tipos de redes celulares.
Discusión de la técnica relacionada
El sistema universal de telecomunicaciones móviles (UMTS) es un sistema de comunicación móvil asíncrono de tercera generación (3G) que funciona en acceso múltiple por división de código de banda amplia (WCDMA) basado en sistemas europeos, sistema global para comunicaciones móviles (GSM) y servicios generales de radio por paquetes (GPRS). La evolución a largo plazo (LTE) de UMTS, también conocida como sistema de universal telecomunicación móvil evolucionado (E-UMTS), está bajo discusión por el proyecto de cooperación de 3ª generación (3GPP) que estandarizó UMTS.
LTE es una tecnología para permitir comunicaciones por paquetes de alta velocidad. Se han propuesto muchos esquemas para el objetivo de LTE que incluyen aquéllos dirigidos a reducir los costes del usuario y del proveedor, mejorar la calidad de servicio, y expandir y mejorar la cobertura y la capacidad del sistema. LTE requiere un coste reducido por bit, una mayor disponibilidad de servicio, uso flexible de una banda de frecuencia, una estructura sencilla, una interfaz abierta, y un consumo de potencia adecuado de un terminal como requisito de nivel superior.
La figura 1 es un diagrama de bloques que ilustra la estructura de red de un sistema LTE. La red de comunicación está ampliamente desplegada para proporcionar una variedad de servicios de comunicación tales como voz y datos por paquetes.
Tal como se ilustra en la figura 1, la red E-UMTS incluye una red de acceso radio terrestre UMTS evolucionado (E-UTRAN) y un Núcleo de Paquetes Evolucionado (EPC) y uno o más equipos de usuario. La E-UTRAN puede incluir uno o más NodosB evolucionados (eNodoB) 20, y una pluralidad de equipos de usuario (UE) 10 se pueden situar en una celda. Una o más pasarelas 30 de entidad de gestión de movilidad (MME)/evolución de arquitectura de sistema (SAE) de E-UTRAN se pueden colocar en el extremo de la red y conectar a una red externa.
Tal como se usa en la presente memoria, “enlace descendente” se refiere a la comunicación desde el eNodoB 20 hasta el UE 10, y “enlace ascendente” se refiere a comunicación desde el UE hasta un eNodoB. El UE 10 se refiere a un equipo de comunicación que un usuario lleva y también se puede denominar estación móvil (MS), terminal de usuario (UT), estación de abonado (SS) o dispositivo inalámbrico.
Un eNodoB 20 proporciona puntos finales de un plano de usuario y un plano de control al UE 10. La pasarela 30 de MME/SAE proporciona un punto final de una función de gestión de movilidad y sesión para el UE 10. El eNodoB y la pasarela de MME/SAE se pueden conectar a través de una interfaz S1.
El eNodoB 20 es generalmente una estación fija que comunica con un UE 10, y también se puede denominar estación base (BS) o punto de acceso. Por cada celda se puede desplegar un eNodoB 20. Se puede usar una interfaz para transmitir tráfico de usuario o tráfico de control entre eNodosB 20.
La MME proporciona diversas funciones que incluyen distribución de mensajes de radiomensajería a eNodosB 20, control de seguridad, control de movilidad de estado inactivo, control de portador de SAE, y señalización de cifrado y protección de la integridad de estrato de no acceso (NAS). El ordenador central de pasarela de SAE proporciona funciones ordenadas que incluyen terminación de paquetes de plano U (plano de usuario) por motivos de radiomensajería, y conmutación del plano U para soportar movilidad de UE. Por claridad la pasarela 30 de MME/SAE se conocerá en la presente memoria simplemente como “pasarela”, pero se entiende que esta entidad incluye tanto una pasarela de MME como una de SAE.
Se pueden conectar una pluralidad de nodos entre un eNodoB 20 y una pasarela 30 a través de la interfaz S1. Los eNodosB 20 se pueden conectar entre sí a través de una interfaz X2 y los eNodosB colindantes pueden tener una estructura de red mallada que tiene la interfaz X2.
La figura 2(a) es un diagrama de bloques que representa la arquitectura de una E-UTRAN típica y de un EPC típico. Tal como se ilustra, un eNodoB 20 puede realizar funciones de selección para la pasarela 30, encaminamiento hacia la pasarela durante una activación de Control de Recursos de Radio (RRC), planificación y transmisión de mensajes de radiomensajería, planificación y transmisión de información de Canal de Difusión (BCCH), asignación dinámica de recursos a los UE 10 tanto en el enlace ascendente como en el enlace descendente, configuración y suministro de mediciones de eNodoB, control de portador de radio, control de admisión de radio (RAC), y control de movilidad de conexión en estado LTE_ACTIVO. En el EPC, y tal como se indicó anteriormente, la pasarela 30 puede realizar funciones de creación de radio mensajería, gestión de estado LTE-INACTIVO, cifrado del plano de usuario, control de portador de Evolución de Arquitectura de Sistema (SAE), y señalización de cifrado y protección de integridad de estrato de no acceso (NAS).
Las figuras 2(b) y 2(c) son diagramas de bloques que representan la pila de protocolo de plano de usuario y de protocolo de plano de control para el E-UMTS. Tal como se ilustra, las capas de protocolo se pueden dividir en una primera capa (L1), una segunda capa (L2) y una tercera capa (L3) en base a las tres capas inferiores de un modelo estándar de interconexión de sistemas abiertos (OSI) que es bien conocido en la técnica de sistemas de comunicación.
La capa física, la primera capa (L1), proporciona un servicio de transmisión de información a una capa superior usando un canal físico. La capa física se conecta con una capa de control de acceso al medio (MAC) situada en un nivel superior a través de un canal de transporte, y los datos entre la capa MAC y la capa física se transfieren a través del canal de transporte. Entre diferentes capas físicas, esto es, entre capas físicas de un lado de transmisión y un lado de recepción, los datos se transfieren a través del canal físico.
La capa MAC de Capa 2 (L2) proporciona servicios a una capa de control de enlace de radio (RLC) (que es una capa superior) a través de un canal lógico. La capa de RLC de Capa 2 (L2) soporta la transmisión de datos con fiabilidad. Se debería señalar que la capa de RLC ilustrada en las figuras 2(b) y 2(c) se representa porque si las funciones de RLC se implementan en y se realizan mediante la capa MAC, la propia capa de RLC no se requiere. La capa de PDCP de Capa 2 (L2) realiza una función de compresión de cabecera que reduce la información de control innecesaria de modo que los datos que se transmiten empleando paquetes de protocolo de Internet (IP), tales como IPv4 o IPv6, se pueden enviar eficazmente a través de una interfaz radio (inalámbrica) que tiene un ancho de banda relativamente pequeño. La capa de PDCP recibe SDU (Unidades de Datos de Servicio) como entrada y entrega PDU (Unidades de Datos por Paquetes) comprimidas como salida a las capas inferiores.
Una capa de control de recursos de radio (RRC) situada en la parte más inferior de la tercera capa (L3) se define solamente en el plano de control y controla los canales lógicos, canales de transporte y los canales físicos en relación con la configuración, reconfiguración, y liberación de los portadores de radio (RB). Aquí, el RB significa un servicio proporcionado por la segunda capa (L2) para transmisión de datos entre el terminal y la E-UTRAN.
Tal como se ilustra en la figura 2(b), las capas RLC y MAC (terminadas en un eNodoB 20 en el lado de red) pueden realizar funciones tales como planificación, solicitud de repetición automática (ARQ), y solicitud de repetición automática híbrida (HARQ). La capa de PDCP (terminada en un eNodoB 20 en el lado de red) puede realizar las funciones de plano de usuario tales como compresión de cabecera, protección de integridad, y cifrado.
Tal como se ilustra en la figura 2(c), las capas RLC y MAC (terminadas en un eNodoB 20 en el lado de red) realizan las mismas funciones que para el plano de control. Tal como se ilustra, la capa de RRC (terminada en un eNodoB 20 en el lado de red) puede realizar funciones tales como difusión, radio mensajería, gestión de conexión de RRC, control de Portador de Radio (RB), funciones de movilidad, y control e informe de medición del UE. El protocolo de control de NAS (terminado en la MME de la pasarela 30 en el lado de red) puede realizar funciones tales como una gestión de portador de SAE, autentificación, manejo de movilidad LTE_INACTIVO, creación de radiomensajería en LTE_INACTIVO, y control de seguridad para la señalización entre la pasarela y el UE 10.
El protocolo de control de NAS puede usar tres estados diferentes; el primero, un estado LTE_SEPARADO si no hay ninguna entidad de RRC; el segundo, un estado LTE_INACTIVO si no hay ninguna conexión de RRC mientras se almacena información de UE mínima; y el tercero, un estado LTE_ACTIVO si se establece la conexión de RRC. También, el estado de RRC se puede dividir en dos estados diferentes tales como un RRC_INACTIVO y un RRC_CONECTADO.
En el estado RRC_INACTIVO, el UE 10 puede recibir difusiones de información de sistema e información de radiomensajería mientras que el UE especifica una Recepción Discontinua (DRX) configurada por NAS, y se ha asignado al UE una identificación (ID) que identifica de manera única al UE en un área de seguimiento. También, en el estado RRC_INACTIVO, no se almacena ningún contexto de RRC en el eNodoB.
En el estado RRC_CONECTADO, el UE 10 tiene una conexión de RRC de E-UTRAN y un contexto en la E-UTRAN, de modo que llega a ser posible la transmisión y/o la recepción de datos a/desde la red (eNodoB). También, el UE 10 puede notificar información de calidad de canal e información de realimentación al eNodoB.
En el estado RRC_CONECTADO, la E-UTRAN conoce la celda a la que pertenece el UE 10. Por lo tanto, la red puede transmitir y/o recibir datos a/desde el UE 10, la red puede controlar la movilidad (traspaso) del UE, y la red puede realizar mediciones de celda para una celda colindante.
En el modo RRC_INACTIVO, el UE 10 especifica el ciclo de DRX (Recepción Discontinua) de radio mensajería. Específicamente, el UE 10 monitoriza una señal de radiomensajería en una ocasión específica de radio mensajería de cada ciclo de DRX de radio mensajería específica de UE.
Un enlace de comunicación inalámbrica es un enlace entre un dispositivo inalámbrico (por ejemplo, un UE en el contexto de LTE) y una red que tiene una pluralidad de estaciones base (por ejemplo, eNodosB en el contexto de LTE). Ya que es direccional, tal enlace de comunicación inalámbrica tiene un lado de transmisión de unidad de datos y un lado de recepción de unidad de datos. Dependiendo de la dirección del enlace, el dispositivo inalámbrico puede estar en el lado de transmisión de unidad de datos mientras que la red está en el lado de recepción de unidad de datos, o el dispositivo inalámbrico puede estar en el lado de recepción de unidad de datos mientras que la red está en el lado de transmisión de unidad de datos.
En algunas circunstancias, se puede iniciar un traspaso de tal enlace de comunicación inalámbrica con un dispositivo inalámbrico desde una estación base de origen a una estación base de destino.
Se recuerda que el procedimiento de traspaso se realiza para transferir, o traspasar, una comunicación pendiente desde una celda de origen, a la que da servicio un eNodoB de origen, a una celda de destino, a la que da servicio un eNodoB de destino. Consideramos aquí el caso no limitativo en el que las celdas de origen y de destino no son servidas por el mismo eNodoB.
La figura 3 muestra esquemáticamente transmisiones en relación con un enlace de comunicación inalámbrica en el que el dispositivo inalámbrico está en el lado de recepción de unidad de datos y la red está en el lado de transmisión de unidad de datos del enlace de comunicación inalámbrica, un traspaso del enlace de comunicación inalámbrica con el UE que se inicia desde un eNodoB de origen a un eNodoB de destino.
Se pueden encontrar detalles adicionales sobre los mensajes transmitidos en las especificaciones técnicas de LTE pertinentes, en particular en la TS 36.423 V8.0.0 del 3GPP “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 application protocol (X2AP) (Release 8)” y en TS 36.300 V8.3.0 del 3GPP “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 8)”, ambas publicadas en diciembre de 2007.
Antes de iniciarse el procedimiento de traspaso, una secuencia de unidades de datos (de enlace descendente) se transmite a lo largo del enlace de comunicación inalámbrica desde el eNodoB de origen hasta el UE.
Las unidades de datos consideradas aquí son unidades de datos de la capa de PDCP (Protocolo de Convergencia de Datos de Protocolo), también denominada SDU (Unidades de Datos de Servicio) de PDCP. PDCP en el contexto de LTE se describe de manera completa en la especificación técnica TS 36.323 V8.0.0 del 3GPP “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification (Release 8)”, publicada en diciembre de 2007.
Sin embargo, también se pueden considerar otros tipos de unidades de datos, como será evidente para un experto en la técnica. En particular, se pueden considerar unidades de datos de una capa diferente de PDCP.
El eNodoB de origen configura los procedimientos de medición de UE, que forman parte del protocolo de RRC representado en la figura 2(a), según la información de restricción de área suministrada en cada eNodoB. Esto sepuede hacer enviando uno o más mensajes de CONTROL DE MEDICIÓN al UE en el estado RRC_CONECTADO. Las mediciones solicitadas por el eNodoB de origen pueden ayudar a la función que controla la movilidad de conexión del UE. El UE se desencadena entonces para enviar mensajes de INFORME DE MEDICIÓN (referencia 1) según las reglas establecidas por ejemplo por la información de sistema difundida por el eNodoB de origen y/o especificadas en el mensaje de CONTROL DE MEDICIÓN o señalización de enlace descendente adicional.
Para cada UE en el estado RRC_CONECTADO, el eNodoB de origen ejecuta uno o más algoritmos de control de traspaso cuyas entradas incluyen las mediciones notificadas por el UE y posiblemente otras mediciones hechas por el eNodoB de origen. Dependiendo de las mediciones, el eNodoB de origen puede decidir traspasar el UE a un eNodoB de destino. Cuando ocurre esto, el eNodoB de origen emite un mensaje de SOLICUTUD DE TRASPASO al eNodoB de destino (referencia 2), que pasa la información necesaria para preparar el traspaso al lado de destino. Tal información incluye una referencia de contexto de señalización UE X2 en el eNodoB de origen, una referencia de contexto de señalización de EPC UE S1, un identificador de celda de destino, un contexto de RRC y un contexto de portador de SAE. Las referencias de contexto de señalización UE X2 y UE S1 permiten al eNodoB de destino dirigir
el eNodoB de origen y el EPC. El contexto de portador de SAE incluye la información de direccionamiento necesaria de capa de red de radio (RNL) y de capa de red de transporte (TNL).
Se puede realizar una función de control de admisión por el eNodoB de destino dependiendo de la información de calidad de servicio (QoS) de portador de SAE recibida para aumentar la probabilidad de un traspaso con éxito, si están disponibles los recursos necesarios en el eNodoB de destino. Si se admite el traspaso, el eNodoB de destino configura los recursos según la información de QoS de portador de SAE recibida y reserva un nuevo identificador temporal de red celda-radio (C-RNTI) en aras de identificar el UE en la celda de destino. El eNodoB de destino prepara el traspaso en las capas 1 y 2 y envía un mensaje de ACUSE DE RECIBO DE SOLICITUD DE TRASPASO al eNodoB de origen (referencia 3). El mensaje de ACUSE DE RECIBO DE SOLICITUD DE TRASPASO incluye un contenedor transparente que va a ser pasado al UE 10. El contenedor puede incluir el nuevo C-RNTI asignado por el eNodoB de destino, y posiblemente algunos otros parámetros tales como parámetros de acceso, bloques de información de sistema (SIB), etc. El mensaje de ACUSE DE RECIBO DE SOLICITUD DE TRASPASO también puede incluir información de RNL/TNL para los túneles de retransmisión, si es necesario.
En respuesta, el eNodoB de origen genera el mensaje de COMANDO DE TRASPASO del protocolo de RRC y lo envía hacia el UE (referencia 4). En paralelo, el eNodoB de origen transfiere al eNodoB de destino parte o todas las unidades de datos que están almacenadas temporalmente para su transmisión al UE y actualmente en tránsito hacia el UE, así como información con respecto al estado de acuse de recibo de las unidades de datos por el UE.
El mensaje de COMANDO DE TRASPASO incluye el contenedor transparente, que se ha recibido desde el eNodoB de destino. El eNodoB de origen aplica las funciones necesarias de protección de integridad y cifrado al mensaje. El UE recibe el mensaje de COMANDO DE TRASPASO con los parámetros necesarios (nuevo C-RNTI, posible tiempo de inicio, SIB de eNodoB de destino, etc.) y por ello se dan instrucciones por el eNodoB de origen para realizar el traspaso. El UE cumple el comando de traspaso separándose de la celda de origen, obteniendo sincronización y accediendo a la celda de destino.
Cuando el UE ha accedido con éxito a la celda de destino, envía un mensaje de CONFIRMACIÓN DE TRASPASO al eNodoB de destino usando el C-RNTI (referencia 9) recién asignado para indicar que el procedimiento de traspaso se ha completado en el lado del UE. El eNodoB de destino verifica el C-RNTI enviado en el mensaje de CONFIRMACIÓN DE TRASPASO. Si la verificación es positiva, se informa al EPC mediante el mensaje de TRASPASO COMPLETO desde el eNodoB de destino que el UE ha cambiado de celda. El EPC conmuta el trayecto de datos de enlace descendente al lado de destino y libera cualquier recurso de plano U/TNL hacia el eNodoB de origen. El EPC confirma devolviendo un mensaje de ACUSE DE RECIBO DE TRASPASO COMPLETO.
El eNodoB de destino informa entonces al eNodoB de origen que el traspaso se realizó con éxito enviando unmensaje de LIBERACIÓN DE RECURSOS (referencia 13), que desencadena la liberación de recursos, es decir recursos de radio y relacionados con el plano C asociados con el contexto de UE, por el eNodoB de origen.
Tal como se muestra en la figura 3, después de que fue iniciado el traspaso desde el eNodoB de origen hasta el eNodoB de destino (referencias 1-4), el eNodoB de origen reenvía al eNodoB de destino SDU de PDCP de enlace descendente de las que no se ha acusado recibo de recepción en el UE al eNodoB de origen (referencia 6), de modo que el eNodoB de destino puede retransmitirlas al UE.
Se configura un informe de estado de PDCP en el UE, que lo transfiere a una capa inferior. Una unidad de transmisión en el UE puede transmitir además el informe de estado de PDCP (referencia 10) al eNodoB de destino. Se indica mediante la señalización de RRC si se enviará o no este informe de estado de PDCP. El formato y contenido del informe de estado de PDCP aparecen en la sección 6.2.6 de la TS 36.323 mencionada anteriormente y se reproduce en la figura 5.
Tal como se muestra en la figura 5, el informe de estado de PDCP contiene un campo LIS de 12 bits que incluye el último número de secuencia de PDCP recibido en secuencia, es decir, el número de secuencia de la última SDU de PDCP recibida en secuencia por el UE.
“SDU de PDCP recibidas en secuencia” se pueden definir como SDU de PDCP recibidas de la secuencia de SDU de PDCP transmitida que precede a la primera SDU de PDCP no recibida en la secuencia. Así, el campo LIS es un puntero que designa la SDU de PDCP de la secuencia que precede inmediatamente a la primera SDU de PDCP no recibida.
El informe de estado de PDCP también contiene un mapa de bits que proporciona información de estado sobre las SDU de PDCP de la secuencia, que se puede almacenar en una unidad de almacenamiento del UE y que indica, para cada SDU de PDCP que tenga un número de secuencia (SN) mayor que LIS (es decir, para cada SDU de PDCP de la secuencia siguiente a la última SDU de PDCP recibida en secuencia), si se ha recibido o no dicha SDU de PDCP por el UE.
Más específicamente, este mapa de bits tiene un tamaño variable y se crea de modo que el MSB (Bit Más Significativo) de su primer octeto (Oct 3, en la figura 5) indica si se ha recibido o no la PDU de PDCP con el SN (LIS
+ 1) módulo 4096 y, opcionalmente si la PDU (Unidad de Datos de Protocolo) de PDCP correspondiente se ha descomprimido correctamente o no, mientras que el LSB (Bit Menos Significativo) del primer octeto (Oct 3, en la figura 5) indica si se ha recibido correctamente o no la PDU de PDCP con el SN (LIS + 8) módulo 4096. Lo mismo se aplica en cuanto al octeto de orden N del mapa de bits (Oct 2+N, en la figura 5), de modo que el mapa de bits puede cubrir cada SDU de PDCP desde la SDU de PDCP inmediatamente siguiente a la última SDU de PDCP recibida en secuencia hasta la última SDU de PDCP recibida.
Cada bit del mapa de bits se ajusta a:
- -
- 0 cuando la PDU de PDCP con Número de Secuencia de PDCP = (LIS + posición de bit) módulo 4096 no se ha recibido u opcionalmente se ha recibido pero no se ha descomprimido correctamente; o
- -
- 1 cuando la PDU de PDCP con Número de Secuencia de PDCP = (LIS + posición de bit) módulo 4096 se ha recibido correctamente y puede o puede no haber sido descomprimida correctamente.
En otras palabras, todas las posiciones en el mapa de bits correspondiente a las SDU de PDCP que no se han recibido como se indica por el RLC y opcionalmente, las PDU de PDCP para las que ha fallado la descompresión se ajustan a 0, mientras que todas las otras posiciones en el mapa de bits se ajustan a 1.
Cuando el eNodoB de origen recibe el informe de estado de PDCP, puede descartar todas las SDU de PDCP que se indican con el valor binario 1 en el mapa de bits, así como las SDU de PDCP con un SN de PDCP igual o menor que el SN de PDCP indicado por el campo LIS (referencia 11 en la figura 3).
Las otras SDU de PDCP, es decir, aquéllas indicadas con el valor binario 0 en el mapa de bits, se pueden retransmitir al UE por el eNodoB de destino que las ha recibido previamente desde el eNodoB de origen (referencia 12).
De este modo, en caso de que el eNodoB de origen no haya recibido hasta ahora la información de estado de RLC desde el UE anterior al traspaso, se evita la retransmisión innecesaria por el eNodoB de destino de las SDU de PDCP ya recibidas por el UE.
La figura 4 muestra esquemáticamente transmisiones en relación con un enlace de comunicación inalámbrica en el que el dispositivo inalámbrico está en el lado de transmisión de unidad de datos y la red está en el lado de recepción de unidad de datos del enlace de comunicación inalámbrica, un traspaso del enlace de comunicación inalámbrica con el UE que se inicia desde un eNodoB de origen hasta un eNodoB de destino.
Así, antes de que se inicie el procedimiento de traspaso, se transmite una secuencia de unidades de datos (de enlace ascendente) a lo largo del enlace de comunicación inalámbrica desde el UE hasta el eNodoB de origen.
La mayoría de las transmisiones mostradas en la figura 4 son idénticas o similares a las de la figura 3.
El mensaje de transferencia de estado de SN (referencia 5’) enviado por el eNodoB de origen hasta el eNodoB de destino incluye una indicación del último número de secuencia de PDCP recibido en secuencia así como de si se han recibido correctamente o no las siguientes SDU de PDCP de enlace ascendente en el eNodoB de origen en forma de un mapa de bits.
En base a la información contenida en el mensaje de transferencia de estado de SN, el eNodoB de destino entonces puede crear y transmitir al UE un informe de estado de PDCP (referencia 10’), que como en el caso ilustrado en la figura 3, puede incluir un campo LIS que identifica el último número de secuencia de PDCP recibido en secuencia y un mapa de bits que indica si se han recibido o no las SDU de PDCP que tienen los números de secuencia (SN) mayores que LIS por el eNodoB de origen.
Cuando el UE recibe el informe de estado de PDCP, puede descartar todas las SDU de PDCP que se indican con el valor binario 1 en el mapa de bits, así como las SDU de PDCP con un SN de PDCP igual o menor que el SN de PDCP indicado por el campo LIS (referencia 11’ en la figura 4).
Las otras SDU de PDCP, es decir, aquéllas indicadas con el valor binario 0 en el mapa de bits, se pueden retransmitir al eNodoB de destino por el UE (referencia 12’).
Por supuesto, pueden existir dos enlaces de comunicación inalámbrica que tienen direcciones opuestas simultáneamente entre un UE y la red, uno para transmitir las SDU de PDCP de enlace descendente y el otro para transmitir las SDU de PDCP de enlace ascendente. En este caso, los mecanismos descritos anteriormente tal como se ilustra en las figuras 3 y 4 ambos se pueden llevar a cabo en paralelo y puede darse una retransmisión selectiva en ambas direcciones.
El campo LIS del informe de estado, en la dirección de enlace ascendente o enlace descendente, tal como se explicó anteriormente, contiene el número de secuencia SN de la última SDU de PDCP recibida “en secuencia”. Esto implica que al menos una SDU de PDCP se ha recibido en secuencia.
Sin embargo en el caso de que la primera SDU de PDCP transmitida, es decir, la SDU de PDCP que tiene el número de secuencia 0, no se haya recibido, pero se hayan recibido otras SDU de PDCP, no hay ninguna SDU de PDCP recibida en secuencia. En otras palabras, no hay ninguna SDU de PDCP recibida antes de la primera SDU de PDCP no recibida.
Tal situación se ilustra en la figura 6, en la que los recuadros con aspas representan las SDU de PDCP recibidas, mientras que los recuadros vacíos representan las SDU de PDCP no recibidas (o posiblemente las PDU de PDCP no descomprimidas correctamente). Tal como se muestra en la figura 6, la SDU de PDCP con el SN 0 no se ha recibido en el lado de recepción de unidad de datos (por el eNodo B de origen o el UE). De modo que la primera SDU de PDCP transmitida también es la primera SDU de PDCP no recibida. Sin embargo, se han recibido otras SDU de PDCP, tales como las que tienen SN 1, 2, 4 y M. En este caso, no hay ninguna SDU de PDCP recibida en secuencia.
Ya que no se puede determinar ningún valor de LIS en este caso, el UE y el eNodoB de destino no serán capaces de rellenar un informe de estado, y no será posible indicar qué SDU de PDCP se han recibido y qué SDU de PDCP no se han recibido. En ausencia de tal información, esto puede provocar una retransmisión extensiva o, por el contrario, una caída de cualquier retransmisión, lo que tendría en ambos casos efectos negativos (ocupación de ancho de banda o pérdida significativa de información útil en la comunicación).
De hecho, el valor -1 tendría que ser indicado en el campo LIS del informe de estado de modo que el mapa de bits pueda comenzar con la SDU de PDCP con el SN 0. Pero esto no es posible ya que hay un número limitado de valores disponibles para el campo LIS (4096 valores para el formato de 12 bits en LTE) que ya se han usado todos. Añadir el valor -1 requeriría de esta manera extender el tamaño del campo LIS, por ejemplo, con al menos un bit adicional, lo que no cumpliría las especificaciones existentes.
Los documentos WO 2006/118418 A o US 2007/277074 A1 describen métodos y dispositivos existentes con desventajas similares.
Un objeto de la presente invención es superar esta desventaja.
Compendio de la invención
La invención propone un dispositivo de comunicación configurado para transferir un informe de estado en un sistema de comunicación inalámbrica, el dispositivo de comunicación que es como se define en la reivindicación 1.
La invención también propone un método para transferir un informe de estado en un sistema de comunicación inalámbrica, el método que es como se define en la reivindicación 9.
Se definen realizaciones ventajosas en las reivindicaciones dependientes.
Breve descripción de las figuras
Otros objetos, características y ventajas de la invención llegarán a ser evidentes cuando se lea la siguiente descripción sobre realizaciones ejemplares no limitantes con referencia a los dibujos anexos.
- -
- La figura 1, ya comentada, es un diagrama de bloques que ilustra la estructura de red de un sistema E-UMTS (o LTE).
- -
- Las figuras 2(a), 2(b) y 2(c), ya comentadas, son diagramas de bloques que representan la arquitectura lógica de entidades de red típicas del sistema LTE (figura 2(a)), una pila de protocolo de plano de usuario (plano U) (figura 2(b)) y una pila de protocolo de plano de control (plano C) (figura 2(c)).
- -
- La figura 3, ya comentada, es un diagrama que ilustra un procedimiento de traspaso típico en un sistema LTE en relación con una comunicación que incluye la transmisión en secuencia de unidades de datos desde el eNodoB de origen hasta el UE.
- -
- La figura 4, ya comentada, es un diagrama que ilustra un procedimiento de traspaso típico en un sistema LTE en relación con una comunicación que incluye la transmisión en secuencia de unidades de datos desde el UE hasta el eNodoB de origen.
- -
- La figura 5, ya comentada, muestra el formato de un informe de estado de PDCP enviado desde el UE hasta el eNodoB de destino durante un procedimiento de traspaso.
- -
- La figura 6 muestra esquemáticamente un estado de recepción en el que no se puede identificar ninguna SDU de PDCP recibida última en secuencia.
- -
- La figura 7 muestra un ejemplo no limitante de formato para un informe de estado para o bien la dirección de enlace descendente o bien la de enlace ascendente según la invención.
Descripción de las realizaciones preferidas
Al igual que en la introducción, la invención se describirá ahora más particularmente en su aplicación a la capa de PDCP de una red LTE o E-UMTS. Sin embargo, la invención también podría aplicarse a unidades de datos de otras capas de protocolo y/o a otros tipos de redes (por ejemplo, UMTS), tal como será evidente para un experto en la técnica. En este caso, el dispositivo inalámbrico, estaciones base, unidades de datos, etc. apropiados sustituirán al UE, los eNodosB, las SDU de PDCP, etc. mencionados en el contexto de LTE.
Los mecanismos descritos anteriormente todavía pueden aplicarse. Sin embargo, según la invención, el formato del informe de estado de PDCP se modifica tal como se muestra en la figura 7.
En lugar del campo LIS mencionado anteriormente, el informe de estado de PDCP incluye un puntero que designa la primera SDU de PDCP no recibida en la secuencia. En el ejemplo mostrado en la figura 7, este puntero adopta la forma de un campo que contiene el número de secuencia SN de la primera SDU de PDCP no recibida. En adelante, este campo se denomina FMS por First Missing Sequence Number (primer número de secuencia ausente) de PDCP. El valor de FMS se puede ver como el valor que el campo LIS contendría si fuera usado, más uno.
El campo FMS es ventajosamente del mismo tamaño que el campo LIS, es decir 12 bits, aunque también pueden ser adecuados otros tamaños.
En el ejemplo no limitante de la figura 6, el FMS contendría el valor de SN 0. Como resultado, incluso cuando no hay ninguna SDU de PDCP recibida en secuencia, siempre se puede determinar un valor de FMS y siempre se puede crear un informe de estado.
Se observará que cuando se puede identificar una última SDU de PDCP en secuencia, siempre va seguida inmediatamente por la primera SDU de PDCP no recibida. Esto provocaba tener el primer bit en el mapa de bits siempre ajustado a 0 en el informe de estado de PDCP de la técnica anterior tal como se muestra en la figura 5. Dicho primer bit no proporcionaba ninguna información adicional además del campo LIS.
Con el informe de estado de PDCP tal como se muestra en la figura 7, no hay necesidad de tener un bit relativo a la primera SDU de PDCP no recibida en el mapa de bits, ya que está implícito a partir de la presencia en el campo FMS del número de secuencia de la primera SDU de PDCP no recibida, que esta SDU de PDCP no se ha recibido.
De esta manera, el tamaño del mapa de bits en comparación con el caso en el que se notifica el LIS sería un bit más pequeño.
De esta manera se puede crear el mapa de bits de manera que el MSB (Bit Más Significativo) de su primer octeto (Oct 3, en la figura 7) indica si se ha recibido o no la PDU de PDCP con el SN (FMS + 1) módulo 4096 y, opcionalmente si se ha descomprimido correctamente o no la PDU (Unidad de Datos de Protocolo) de PDCP correspondiente, mientras que el LSB (Bit Menos Significativo) del primer octeto (Oct 3, en la figura 7) indica si se ha recibido correctamente o no la PDU de PDCP con el SN (FMS + 8) módulo 4096. Lo mismo se aplica en cuanto al octeto de orden N del mapa de bits (Oct 2+N, en la figura 7), de modo que el mapa de bits puede cubrir cada SDU de PDCP desde la SDU de PDCP inmediatamente siguiente a la primera SDU de PDCP no recibida hasta la última SDU de PDCP recibida.
El UE llena el mapa de bits indicando qué SDU están ausentes (bit no ajustado – ‘0’), es decir, si una SDU no se ha recibido u opcionalmente se ha recibido pero no se ha descomprimido correctamente, y qué SDU no necesitan retransmisión (bit ajustado - ’1’), es decir, si una SDU se ha recibido correctamente y puede o puede no haber sido descomprimida correctamente.
Esto se ilustra en la tabla siguiente.
- Bit
- Descripción
- 0
- PDU de PDCP con Número de Secuencia de PDCP = (FMS + posición de bit) módulo 4096 está ausente en el receptor.
- 1
- PDU de PDCP con Número de Secuencia de PDCP = (FMS + posición de bit) módulo 4096 no necesita ser retransmitida.
De modo más general, el mapa de bits contenido en el informe de estado proporciona la información de estado para un conjunto de SDU de PDCP que sigue a la primera SDU de PDCP no recibida en la secuencia.
Este conjunto de SDU de PDCP puede comenzar una SDU de PDCP después de la primera SDU de PDCP no recibida, como en el ejemplo descrito anteriormente. Pero se puede usar alternativamente una distancia más grande entre la primera SDU de PDCP del conjunto y la primera SDU de PDCP no recibida en la secuencia.
Del mismo modo, el conjunto de las SDU de PDCP de cuyo estado se informa en el mapa de bits puede constar de SDU de PDCP consecutivas de la secuencia, es decir, las SDU de PDCP que tienen números de secuencia consecutivos mayores que el valor de FMS. Sin embargo, también pueden ser adecuadas otras posibilidades (por ejemplo, solamente SN impares, solamente SN pares, series específicas de SN, etc.).
Ventajosamente, al menos una SDU de PDCP que sigue a la primera SDU de PDCP no recibida puede estar por debajo de la última SDU de PDCP recibida fuera de secuencia.
Si el conjunto de las SDU de PDCP incluye solamente un número limitado de SDU de PDCP de la secuencia que sigue a la primera SDU de PDCP no recibida, el bit ahorrado del mapa de bits en comparación con la técnica anterior se puede usar para proporcionar la información de estado para una SDU de PDCP adicional, o cualquier otra información adicional.
Cuando el informe de estado de PDCP se envía desde el UE hasta el eNodoB de destino, tal como se muestra en la figura 3, el eNodoB de destino entonces puede analizarlo para obtener el SN de la primera SDU de PDCP no recibida a partir del campo FMS y comprobar a partir del mapa de bits si se han recibido o no las siguientes SDU de PDCP.
De este modo, se puede realizar una retransmisión selectiva por el eNodoB de destino dependiendo del mapa de bits contenido en el informe de estado de PDCP. De hecho, el eNodoB de destino puede descartar al menos algunas de las SDU de PDCP recibidas, y retransmitir al UE al menos algunas de las SDU de PDCP que no se reciben por el UE y opcionalmente al menos algunas de las PDU de PDCP para las que ha fallado la descompresión en el UE.
Aunque no hay ningún bit relacionado con la primera SDU de PDCP no recibida en el mapa de bits del informe de estado de PDCP, el eNodoB de destino puede retransmitir la primera SDU de PDCP no recibida ya que conoce a partir del campo FMS que esta SDU de PDCP no se ha recibido.
De manera similar, cuando el informe de estado de PDCP se envía desde el eNodoB de destino al UE, tal como se muestra en la figura 4, el UE entonces puede analizarlo para obtener el SN de la primera SDU de PDCP no recibida a partir del campo FMS y comprobar a partir del mapa de bits si se han recibido o no las siguientes SDU de PDCP.
De este modo, se puede realizar una retransmisión selectiva por el UE dependiendo del mapa de bits contenido en el informe de estado de PDCP. De hecho, el UE puede descartar al menos algunas de las SDU de PDCP recibidas, y retransmitir al eNodoB de destino al menos algunas de las SDU de PDCP que no se han recibido por el eNodoB y opcionalmente al menos algunas de las PDU de PDCP para las que ha fallado la descompresión en el eNodoB.
Aunque no hay ningún bit relativo a la primera SDU de PDCP no recibida en el mapa de bits del informe de estado de PDCP, el UE puede retransmitir la primera SDU de PDCP no recibida ya que conoce a partir del campo FMS que esta SDU de PDCP no se ha recibido.
En este caso, el eNodoB de destino ha sido informado previamente por el eNodoB de origen, en el mensaje de transferencia de estado de SN (referencia 5’ en la figura 4), de la primera SDU de PDCP no recibida y de si se han recibido o no las SDU de PDCP que siguen a dicha primera SDU de PDCP no recibida. Esta información puede usar ventajosamente el mismo tipo de formato que el informe de estado de PDCP mostrado en la figura 7.
La presente invención se ha descrito anteriormente en el caso en que se transmite un informe de estado de PDCP entre un UE y un eNodoB de destino, después de que se haya iniciado un traspaso del enlace de comunicación inalámbrica con el UE desde un eNodoB de origen hasta un eNodoB de destino. Por ejemplo, en el caso del enlace descendente, el UE puede configurar el informe de estado de PDCP después de haber recibido una indicación de que ha ocurrido un traspaso desde una capa superior.
Sin embargo, la transmisión de tal informe de estado y posiblemente la realización de una retransmisión selectiva en base al informe de estado según la invención también pueden aplicarse a un enlace de comunicación inalámbrica entre un UE y un eNodoB, aunque no ocurra ningún traspaso del enlace de comunicación inalámbrica. Como ejemplo no limitante, se puede transmitir un informe de estado de PDCP a lo largo del enlace de comunicación inalámbrica cuando haya algunas razones para pensar que hasta ahora no se ha recibido o no se recibirá información de estado RLC en el lado de transmisión de unidad de datos del enlace de comunicación inalámbrica.
Claims (15)
- REIVINDICACIONES1. Un dispositivo de comunicación configurado para transferir un informe de estado en un sistema de comunicación inalámbrica, el dispositivo de comunicación que comprende:
- -
- una unidad de configuración para configurar un informe de estado de PDCP, Protocolo de
5 Convergencia de Datos por Paquetes, de aquí en adelante abreviado como un informe de estado de PDCP, en el que el informe de estado de PDCP pertenece a una capa de PDCP situada por encima de una capa de RLC, Control de Enlace de Radio, el informe de estado de PDCP que incluye un indicador que indica un número de secuencia de una primera SDU de PDCP no recibida y un mapa de bits que proporciona información de estado acerca de la recepción de al menos una SDU de PDCP que sigue a10 dicha primera SDU de PDCP no recibida; y- -
- una unidad de transmisión para transferir el informe de estado de PDCP configurado a la capa de RLC,
en el que el indicador es un campo de primer número de secuencia ausente de PDCP, de aquí en adelante abreviado como FMS, que contiene el número de secuencia de la primera SDU de PDCP no recibida, yen el que dicha al menos una SDU de PDCP comienza a partir de una SDU de PDCP después de la 15 primera SDU de PDCP no recibida. -
- 2.
- El dispositivo de comunicación de la reivindicación 1, en el que el mapa de bits se rellena para indicar qué SDU de PDCP están ausentes e indicar qué SDU de PDCP no necesitan retransmisión.
-
- 3.
- El dispositivo de comunicación de la reivindicación 2, en el que en el mapa de bits, las SDU de PDCP
indicadas como que están ausentes indica si no se ha recibido o si se ha recibido pero no se ha 20 descomprimido correctamente una SDU de PDCP. - 4. El dispositivo de comunicación de la reivindicación 2, en el que, en el mapa de bits, las SDU de PDCP indicadas como que no necesitan retransmisión indica si una SDU de PDCP se ha recibido correctamente y se ha descomprimido correctamente o no se ha descomprimido correctamente.
- 5. El dispositivo de comunicación de la reivindicación 3, en el que un bit ‘0’ en el mapa de bits indica que está25 ausente la SDU de PDCP con Número de Secuencia de PDCP = (FMS + posición de bit) módulo 4096.
-
- 6.
- El dispositivo de comunicación de la reivindicación 4, en el que un bit ‘1’ en el mapa de bits indica que no necesita ser retransmitida la SDU de PDCP con Número de Secuencia de PDCP = (FMS + posición de bit) módulo 4096.
-
- 7.
- El dispositivo de comunicación de la reivindicación 1, en el que el campo FMS tiene un tamaño de 12 bits
30 situado entre un campo de tipo Unidad de Datos de Protocolo, PDU, y el mapa de bits en el informe de estado de PDCP. - 8. El dispositivo de comunicación de la reivindicación 1, en el que el mapa de bits no contiene un bit relacionado con la primera SDU de PDCP no recibida debido a la presencia del campo FMS que contiene el número de secuencia de la primera SDU de PDCP no recibida para indicar que no se ha recibido tal SDU35 de PDCP.
- 9. Un método para transferir un informe de estado en un sistema de comunicación inalámbrica, el método que comprende:
- -
- configurar un informe de estado de PDCP, Protocolo de Convergencia de Datos por Paquetes, que pertenece a una capa de PDCP situada por encima de una capa de RLC, Control de Enlace de Radio,
40 el informe de estado de PDCP que incluye un indicador que indica un número de secuencia de una primera SDU de PDCP no recibida y un mapa de bits que proporciona información de estado acerca de la recepción de al menos una SDU de PDCP que sigue a dicha primera SDU de PDCP no recibida; y- -
- transferir el informe de estado de PDCP configurado a la capa de RLC,
en el que el indicador es un campo de primer número de secuencia ausente de PDCP, de aquí en adelante 45 abreviado como FMS, que contiene el número de secuencia de la primera SDU de PDCP no recibida, yen el que dicha al menos una SDU de PDCP comienza a partir de una SDU de PDCP después de la primera SDU de PDCP no recibida -
- 10.
- El método de la reivindicación 9, en el que el mapa de bits se rellena para indicar qué SDU de PDCP están ausentes e indicar qué SDU de PDCP no necesitan retransmisión.
-
- 11.
- El método de la reivindicación 10, en el que en el mapa de bits, las SDU de PDCP indicadas como que están ausentes indica si no se ha recibido o si se ha recibido pero no se ha descomprimido correctamente una SDU de PDCP.
-
- 12.
- El método de la reivindicación 10, en el que, en el mapa de bits, las SDU de PDCP indicadas como que no
5 necesitan retransmisión indica si una SDU de PDCP se ha recibido correctamente y se ha descomprimido correctamente o no se ha descomprimido correctamente. - 13. El método de la reivindicación 11, en el que un bit ‘0’ en el mapa de bits indica que está ausente la SDU de PDCP con Número de Secuencia de PDCP = (FMS + posición de bit) módulo 4096.
- 14. El método de la reivindicación 12, en el que un bit ‘1’ en el mapa de bits indica que no necesita ser 10 retransmitida la SDU de PDCP con Número de Secuencia de PDCP = (FMS + posición de bit) módulo 4096.
- 15. El método de la reivindicación 9, en el que el campo FMS tiene un tamaño de 12 bits situado entre un campo de tipo Unidad de Datos de Protocolo, PDU, y el mapa de bits en el informe de estado de PDCP.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US2611708P | 2008-02-04 | 2008-02-04 | |
US26117P | 2008-02-04 |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2463095T3 true ES2463095T3 (es) | 2014-05-27 |
Family
ID=40225580
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES08159388T Active ES2362173T3 (es) | 2008-02-04 | 2008-07-01 | Método de comunicación inalámbrica para transmitir una secuencia de unidades de datos entre un dispositivo inalámbrico y una red. |
ES10194238.1T Active ES2463095T3 (es) | 2008-02-04 | 2008-07-01 | Método de comunicación inalámbrica para transmitir una secuencia de unidades de datos entre un dispositivo inalámbrico y una red |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES08159388T Active ES2362173T3 (es) | 2008-02-04 | 2008-07-01 | Método de comunicación inalámbrica para transmitir una secuencia de unidades de datos entre un dispositivo inalámbrico y una red. |
Country Status (11)
Country | Link |
---|---|
US (2) | US7911969B2 (es) |
EP (4) | EP2086149B1 (es) |
JP (3) | JP4991011B2 (es) |
CN (2) | CN101933254B (es) |
AT (1) | ATE500663T1 (es) |
BR (1) | BRPI0822186A2 (es) |
DE (1) | DE602008005252D1 (es) |
ES (2) | ES2362173T3 (es) |
MX (1) | MX2010007947A (es) |
TW (2) | TWI466484B (es) |
WO (2) | WO2009099265A1 (es) |
Families Citing this family (51)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101237672B (zh) | 2007-01-29 | 2012-05-23 | 华为技术有限公司 | 一种演进网络中建立s1信令连接的方法、装置及系统 |
US8818375B2 (en) * | 2007-04-25 | 2014-08-26 | Telefonaktiebolaget L M Ericsson (Publ) | Method and apparatus for seamless handover in a wireless communication network |
KR101454021B1 (ko) * | 2007-08-07 | 2014-10-27 | 삼성전자주식회사 | 이동통신시스템에서 홈셀/개인네트워크셀의 메저먼트 장치및 방법 |
KR100907978B1 (ko) * | 2007-09-11 | 2009-07-15 | 엘지전자 주식회사 | 이동통신 시스템에서 pdcp 계층의 상태보고 전송 방법 및 수신장치 |
EP2086149B1 (en) * | 2008-02-04 | 2011-03-02 | LG Electronics Inc. | Wireless communication method for transmitting a sequence of data units between a wireless device and a network |
KR101531513B1 (ko) * | 2008-02-04 | 2015-07-06 | 엘지전자 주식회사 | 랜덤 접속의 접속 지연 재개 방법 |
ATE536674T1 (de) | 2008-02-08 | 2011-12-15 | Ericsson Telefon Ab L M | Verfahren und anordnung in einem telekommunikationssystem |
KR101402801B1 (ko) * | 2008-06-27 | 2014-06-02 | 삼성전자주식회사 | 이동통신 시스템에서 서빙 셀 전환 지연시간 감소 방법 및장치 |
US9537613B2 (en) | 2008-10-24 | 2017-01-03 | Qualcomm Incorporated | Acknowledgment based on short cell radio network temporary identifier |
US8837395B2 (en) * | 2008-12-19 | 2014-09-16 | Optis Cellular Technology, Llc | Method and entity for conveying data units |
US8228871B2 (en) | 2009-03-19 | 2012-07-24 | Telefonaktiebolaget Lm Ericsson (Publ) | Wireless handover optimization |
CN102461257A (zh) * | 2009-06-19 | 2012-05-16 | 捷讯研究有限公司 | 在演进通用陆地无线接入网接入节点处具有s1端接的中继切换期间的数据处理机制 |
EP2443904A1 (en) * | 2009-06-19 | 2012-04-25 | Research In Motion Limited | Mechanisms for data handling during a relay handover with s1 termination at relay |
US20120140704A1 (en) * | 2009-08-17 | 2012-06-07 | Qun Zhao | Method and apparatus for controlling downlink data transmission in a multi-hop relay communication system |
US8804596B2 (en) * | 2009-10-02 | 2014-08-12 | Blackberry Limited | Architecture for termination at access device |
US8687590B2 (en) * | 2009-10-02 | 2014-04-01 | Blackberry Limited | System and method for handover between relays |
US8406192B2 (en) * | 2009-10-02 | 2013-03-26 | Research In Motion Limited | Handover mechanisms with synchronous PDCP protocol under various relay architectures |
CN102056226B (zh) | 2009-11-10 | 2016-03-02 | 中兴通讯股份有限公司 | Pdcp状态报告的获取方法和pdcp实体 |
US8891356B2 (en) | 2010-06-28 | 2014-11-18 | Qualcomm Incorporated | System and method for multi-point HSDPA communication utilizing a multi-link RLC sublayer |
US8989140B2 (en) | 2010-06-28 | 2015-03-24 | Qualcomm Incorporated | System and method for mobility in a multi-point HSDPA communication network |
US8571582B2 (en) * | 2010-11-04 | 2013-10-29 | Verizon Patent And Licensing Inc. | LTE smart paging list |
US8989004B2 (en) * | 2010-11-08 | 2015-03-24 | Qualcomm Incorporated | System and method for multi-point HSDPA communication utilizing a multi-link PDCP sublayer |
US8737211B2 (en) | 2011-08-03 | 2014-05-27 | Qualcomm Incorporated | Methods and apparatuses for network configuration of user equipment communication modes in multiflow systems |
US9125098B2 (en) | 2011-08-03 | 2015-09-01 | Qualcomm Incorporated | Method and apparatus for flow congestion control in multiflow networks |
KR20130093774A (ko) * | 2011-12-29 | 2013-08-23 | 엘지전자 주식회사 | Pdcp 패킷 전송 방법 |
JP6186355B2 (ja) | 2012-10-17 | 2017-08-23 | サターン ライセンシング エルエルシーSaturn Licensing LLC | データ処理装置、データ処理方法、及び、プログラム |
EP3247128B1 (en) * | 2012-10-17 | 2019-07-24 | Sony Corporation | Data processing device, data processing method, and program |
KR102104493B1 (ko) * | 2013-05-10 | 2020-05-04 | 주식회사 팬택 | 이중 연결성을 지원하는 무선 통신 시스템에서 데이터 전송 방법 및 장치 |
CN105210438A (zh) * | 2013-05-10 | 2015-12-30 | 富士通株式会社 | 无线通信系统、移动台、基站和无线通信方法 |
KR101853868B1 (ko) | 2014-03-20 | 2018-06-20 | 후지쯔 가부시끼가이샤 | 무선 통신 장치 및 무선 통신 방법 |
US9838282B2 (en) * | 2014-05-09 | 2017-12-05 | Telefonaktiebolaget Lm Ericsson (Publ) | PDCP and flow control for split bearer |
EP3326408B1 (en) * | 2015-07-22 | 2020-04-01 | Intel IP Corporation | Convergence layer for 5g communication systems |
US9999049B2 (en) | 2015-08-31 | 2018-06-12 | Qualcomm Incorporated | Avoiding unnecessary protocol data unit (PDU) transmissions |
JP6041964B1 (ja) * | 2015-09-24 | 2016-12-14 | 株式会社Nttドコモ | 無線通信装置及び無線通信方法 |
CN114079955B (zh) * | 2016-02-05 | 2024-12-10 | 瑞典爱立信有限公司 | 用于接收状态报告的方法和设备 |
CN107426776B (zh) * | 2016-05-24 | 2024-06-04 | 华为技术有限公司 | QoS控制方法及设备 |
CN109155951B (zh) * | 2016-05-27 | 2021-01-29 | 华为技术有限公司 | 传输方法、基站和终端 |
US9999016B2 (en) * | 2016-09-04 | 2018-06-12 | Lg Electronics Inc. | Status report polling to avoid HFN de-synchronization |
EP3580873B8 (en) * | 2017-02-13 | 2021-12-01 | Telefonaktiebolaget LM Ericsson (publ) | Technique for monitoring a radio communication |
EP3611859A4 (en) * | 2017-05-05 | 2020-04-29 | Huawei Technologies Co., Ltd. | Data receiving state reporting method and apparatus |
WO2019095110A1 (zh) * | 2017-11-14 | 2019-05-23 | Oppo广东移动通信有限公司 | 一种切换处理方法、网络设备及计算机存储介质 |
CN116761279A (zh) | 2018-04-05 | 2023-09-15 | 三星电子株式会社 | 在移动通信系统中操作终端的协议层的方法和装置 |
KR102503003B1 (ko) * | 2018-04-05 | 2023-02-24 | 삼성전자 주식회사 | 차세대 이동 통신 시스템에서 비활성화 모드에 있는 단말의 셀 선택 및 재선택 수행 방법 및 장치 |
GB2574876A (en) * | 2018-06-21 | 2019-12-25 | Tcl Communication Ltd | Transmission techniques in a cellular network |
US11818615B2 (en) | 2018-11-01 | 2023-11-14 | Telefonaktiebolaget Lm Ericsson (Publ) | User equipment, source access node, target access node, and methods in a wireless communications network for handling data packets in a handover |
CN111918335B (zh) * | 2019-05-08 | 2022-07-22 | 华为技术有限公司 | 处理数据包的方法和装置 |
JP7050721B2 (ja) * | 2019-06-05 | 2022-04-08 | 富士通株式会社 | 無線通信装置及び制御方法 |
US11937122B2 (en) | 2020-01-30 | 2024-03-19 | Qualcomm Incorporated | Self-reportable radio link control status protocol data units |
CN113556792B (zh) * | 2020-04-24 | 2025-03-25 | Oppo广东移动通信有限公司 | 状态报告传输方法、终端设备和网络设备 |
CN114339614B (zh) * | 2020-09-29 | 2023-07-28 | 上海朗帛通信技术有限公司 | 一种被用于无线通信的方法和设备 |
WO2023121513A1 (ru) * | 2021-12-21 | 2023-06-29 | федеральное государственное автономное образовательное учреждение высшего образования "Национальный исследовательский университет "Высшая школа экономики" | Способ отправки данных с помощью двух базовых станций 5g new radio |
Family Cites Families (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6163861A (en) * | 1996-08-23 | 2000-12-19 | Nippon Telegraph And Telephone Corporation | Error compensating method and apparatus and medium storing an error compensation program |
US7184426B2 (en) * | 2002-12-12 | 2007-02-27 | Qualcomm, Incorporated | Method and apparatus for burst pilot for a time division multiplex system |
FI107364B (fi) * | 1998-05-11 | 2001-07-13 | Nokia Networks Oy | Ei-transparentti datasiirto matkaviestinverkossa |
US6697331B1 (en) | 1999-11-17 | 2004-02-24 | Telefonaktiebolaget Lm Ericsson (Publ) | Link layer acknowledgement and retransmission for cellular telecommunications |
US6801512B1 (en) * | 2000-03-23 | 2004-10-05 | Motorola, Inc. | Method and apparatus for providing a distributed architecture digital wireless communication system |
AU2002362869A1 (en) * | 2001-10-17 | 2003-04-28 | Nokia Corporation | A handover method |
EP1343267A3 (en) * | 2002-02-08 | 2005-08-03 | ASUSTeK Computer Inc. | Data transmission confirmation in a wireless communication system |
KR100765123B1 (ko) * | 2002-02-16 | 2007-10-11 | 엘지전자 주식회사 | Srns 재할당 방법 |
EP1700414B1 (en) * | 2003-12-29 | 2009-05-06 | Electronics and Telecommunications Research Institute | Method for creating feedback messages for arq in a mobile communication system |
KR100595646B1 (ko) * | 2004-01-09 | 2006-07-03 | 엘지전자 주식회사 | Mbms서비스를 제공하는 무선통신 시스템 |
US7599363B2 (en) * | 2004-08-13 | 2009-10-06 | Samsung Electronics Co. Ltd | Method for reporting reception result of packets in mobile communication system |
US20060251105A1 (en) * | 2005-02-07 | 2006-11-09 | Samsung Electronics Co., Ltd. | Method and apparatus for requesting/transmitting status report of a mobile communication system |
KR101084135B1 (ko) * | 2005-05-04 | 2011-11-17 | 엘지전자 주식회사 | 무선 통신 시스템의 송수신 단에서의 상태 pdu송수신방법 |
EP1878155B1 (en) * | 2005-05-04 | 2013-12-04 | LG Electronics Inc. | Method of transmitting control information in wireless communication system and transmission window updating method using the same |
KR100912784B1 (ko) * | 2006-01-05 | 2009-08-18 | 엘지전자 주식회사 | 데이터 송신 방법 및 데이터 재전송 방법 |
US8879500B2 (en) * | 2006-03-21 | 2014-11-04 | Qualcomm Incorporated | Handover procedures in a wireless communications system |
KR101387475B1 (ko) * | 2006-03-22 | 2014-04-22 | 엘지전자 주식회사 | 복수의 네트워크 엔터티를 포함하는 이동 통신시스템에서의 데이터 처리 방법 |
EP1871137A2 (en) * | 2006-06-22 | 2007-12-26 | Innovative Sonic Limited | Method and apparatus for handling status report after handover in a wireless communications system |
KR100907978B1 (ko) * | 2007-09-11 | 2009-07-15 | 엘지전자 주식회사 | 이동통신 시스템에서 pdcp 계층의 상태보고 전송 방법 및 수신장치 |
KR20090084756A (ko) * | 2008-02-01 | 2009-08-05 | 엘지전자 주식회사 | 이동통신 시스템 및 그의 상태보고 전송 방법 |
EP2086149B1 (en) * | 2008-02-04 | 2011-03-02 | LG Electronics Inc. | Wireless communication method for transmitting a sequence of data units between a wireless device and a network |
-
2008
- 2008-07-01 EP EP08159388A patent/EP2086149B1/en active Active
- 2008-07-01 EP EP10194237.3A patent/EP2290863B1/en active Active
- 2008-07-01 EP EP10194238.1A patent/EP2290864B1/en active Active
- 2008-07-01 ES ES08159388T patent/ES2362173T3/es active Active
- 2008-07-01 DE DE602008005252T patent/DE602008005252D1/de active Active
- 2008-07-01 ES ES10194238.1T patent/ES2463095T3/es active Active
- 2008-07-01 AT AT08159388T patent/ATE500663T1/de not_active IP Right Cessation
- 2008-07-01 EP EP08159395A patent/EP2086142A3/en not_active Withdrawn
- 2008-07-16 BR BRPI0822186-3A patent/BRPI0822186A2/pt not_active IP Right Cessation
- 2008-07-16 WO PCT/KR2008/004173 patent/WO2009099265A1/en active Application Filing
- 2008-07-16 CN CN2008801261730A patent/CN101933254B/zh active Active
- 2008-07-16 WO PCT/KR2008/004174 patent/WO2009099266A1/en active Application Filing
- 2008-07-16 MX MX2010007947A patent/MX2010007947A/es active IP Right Grant
- 2008-07-16 JP JP2010544212A patent/JP4991011B2/ja active Active
- 2008-07-16 JP JP2010544213A patent/JP5135444B2/ja not_active Expired - Fee Related
- 2008-07-16 CN CN2008801259938A patent/CN101933253B/zh not_active Expired - Fee Related
- 2008-07-18 TW TW101105675A patent/TWI466484B/zh active
- 2008-07-18 TW TW097127447A patent/TWI387285B/zh active
- 2008-08-20 US US12/195,253 patent/US7911969B2/en active Active
- 2008-08-20 US US12/195,267 patent/US7903578B2/en not_active Expired - Fee Related
-
2012
- 2012-01-31 JP JP2012017558A patent/JP5281700B2/ja active Active
Also Published As
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2463095T3 (es) | Método de comunicación inalámbrica para transmitir una secuencia de unidades de datos entre un dispositivo inalámbrico y una red | |
US11323929B2 (en) | Method and apparatus for transmitting data in CU-DU split scenario | |
ES2337633T3 (es) | Metodo para transmitir informes de estatus de memoria intermedia y datos de enlace ascendente en un sistema de comunicaciones inalambricas, dispositivo inalambrico para implementar dicho metodo. | |
ES2604981T3 (es) | Procedimiento para desplazar una ventana de recepción en una red de acceso de radio | |
US10869353B2 (en) | Method and apparatus for modifying radio bearer in CU-DU split scenario | |
US20190349803A1 (en) | Method and apparatus for establishing drb | |
KR100907978B1 (ko) | 이동통신 시스템에서 pdcp 계층의 상태보고 전송 방법 및 수신장치 | |
ES2648153T3 (es) | Método para procesamiento de protocolo de radio en sistema de telecomunicaciones móviles y transmisor de telecomunicaciones móviles | |
ES2581847T3 (es) | Almacenamiento temporal de paquetes para una transferencia sin pérdidas | |
EP3104632B1 (en) | Communication methods executed by auxiliary base station and main base station and corresponding base stations | |
US8437291B2 (en) | Method for configuring different data block formats for downlink and uplink | |
US11317401B2 (en) | Method and apparatus for selecting carrier |