ES2518221T3 - Transmisión de datos de una red de comunicaciones - Google Patents

Abstract

Método para proporcionar a un elemento de red (5) de una red de comunicaciones unos parámetros de control disponibles en un controlador de red de radiocomunicaciones (4) de dicha red de comunicaciones, estando conectado dicho controlador de red de radiocomunicaciones (4) a dicho elemento de red (5) por medio de una interfaz, comprendiendo dicho método utilizar un protocolo de aplicación de interfaz que permite una inserción de parámetros de control en un mensaje de control asociado a un canal compartido de enlace descendente de alta velocidad y transmitido desde dicho controlador de red de radiocomunicaciones (4) a dicho elemento de red (5) a través de dicha interfaz, siendo dicho mensaje de control uno de entre un mensaje de SOLICITUD DE ESTABLECIMIENTO DE ENLACE DE RADIOCOMUNICACIONES y un mensaje de PREPARACIÓN DE RECONFIGURACIÓN DE ENLACE DE RADIOCOMUNICACIONES, y comprendiendo dichos parámetros de control para la inserción en dicho mensaje de control por lo menos los siguientes parámetros de control específicos del enlace de radiocomunicaciones: - la identidad de un canal compartido de enlace descendente de alta velocidad que va a ser usado en ese momento por dicho elemento de red (5) para una transmisión de enlace descendente; - una prioridad de asignación y/o retención que indica un nivel de prioridad en la asignación y/o retención de recursos internos de dicho elemento de red (5); - una prioridad de gestión de tramas que indica un nivel de prioridad que va a ser usado por dicho elemento de red (5) durante el tiempo de vida de un canal compartido de enlace descendente de alta velocidad para restricciones temporales de recursos asignados debido a un motivo de sobrecarga; y - uno o más parámetros que serán usados en ese momento por dicho elemento de red (5) para configurar una solicitud automática de repetición híbrida, implementada en dicho elemento de red (5).

Description

15

25

35

45

55

65 E01960691

20-10-2014

DESCRIPCIÓN

Transmisión de datos de una red de comunicaciones.

Campo de la invención

La presente invención se refiere a métodos para proporcionar a un elemento de red, por ejemplo, un Nodo B, de una red de comunicaciones, por ejemplo, una UTRAN (Red de acceso de radiocomunicaciones terrestre de servicios universales de telecomunicaciones móviles), datos, por ejemplo, datos relacionados con el HSDPA (Acceso por paquetes de enlace descendente de alta velocidad), requeridos en dicho elemento de red. La invención se refiere más específicamente a un método para proporcionar a un elemento de red, por ejemplo, un Nodo B, de una red de comunicaciones, por ejemplo, una UTRAN, parámetros de control, por ejemplo, parámetros de control relacionados con el HSDPA, disponibles en un controlador de dicha red de comunicaciones, por ejemplo, un RNC, estando conectado dicho controlador a dicho elemento de red por medio de una interfaz, por ejemplo, una interfaz Iub. La invención se refiere asimismo a redes de comunicaciones, elementos de red y controladores correspondientes.

Antecedentes de la invención

El HSDPA es un concepto que se introdujo para arquitecturas UTRAN como una mejora con respecto al concepto de canal compartido en el 3GPP (proyecto de asociación de 3ª generación).

En el UMTS, la UTRAN gestiona toda la funcionalidad relacionada con las radiocomunicaciones. Con este fin, una UTRAN comprende uno o más RNC, y, conectados a cada RNC, uno o más Nodos B. Los RNC de la UTRAN están conectados a una red central por medio de una interfaz Iu. Los RNC de una UTRAN se pueden interconectar adicionalmente mediante una interfaz Iur. En transmisiones de enlace descendente, un RNC recibe datos de usuario desde la red central, posiblemente por medio de otro RNC, y los reenvía, por medio de una interfaz Iub, a un Nodo

B. A continuación, el Nodo B transmite los datos al equipo de usuario UE direccionado, por medio de una interfaz Uu.

Los RNC de una UTRAN podrían adoptar diferentes roles. Se puede definir un RNC de control (CRNC), por ejemplo, con respecto a un conjunto específico de Nodos B. Existe solamente un CRNC para cualquier Nodo B. El CRNC tiene un control total sobre los recursos lógicos de sus Nodos B. Se puede definir un RNC de servicio (SRNC) con respecto a una conexión específica entre un UE y una UTRAN. Existe un SRNC para cada UE que dispone de una conexión con la UTRAN. El SRNC se encuentra a cargo de la conexión de control de recursos de radiocomunicaciones (RRC) entre un UE y la UTRAN. El RNC de Servicio también actúa como terminación de la Iu para este UE.

En el concepto de canal compartido en la UTRAN para el nodo FDD, un DSCH (canal compartido de enlace descendente) se define como un canal de transporte de enlace descendente que es compartido dinámicamente entre varios UE. El DSCH se ensambla en un CRNC y se transmite por medio de un Nodo B a un UE, tal como se describe por ejemplo en la especificación técnica 3GPP TS 25.301 V3.6.0 (2000-09) “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Radio Interface Protocol Architecture (Release 1999)”.

La idea básica del HSDPA es ofrecer, para transmisiones de enlace descendente, canales compartidos de alta velocidad con una velocidad de datos mayor y un mecanismo de retransmisión más rápido ya desde el Nodo B. Los canales compartidos de alta velocidad deben comprender un HS-DSCH (canal compartido de enlace descendente de alta velocidad) como canal de transporte y un DPCH (canal físico dedicado), combinado con un canal de control físico compartido independiente en combinación con un HS-PDSCH (canal físico compartido de enlace descendente de alta velocidad). El mecanismo de retransmisión rápida que se implementará en el Nodo B es la HARQ (solicitud automática de repetición híbrida).

El DSCH usado actualmente también puede prestar soporte a velocidades de datos altas, aunque la retransmisión la proporciona siempre una capa de RLC (control de enlace de radiocomunicaciones) en el RNC, lo cual ralentiza la transacción.

Con el fin de prestar soporte a las capacidades nuevas, especialmente la HARQ, se introdujo una nueva entidad MAC (control de acceso al medio) en el informe técnico 3GPP TR 25.855 V1.0.0 (2001-06): “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; High Speed Downlink Packet Access; Overall UTRAN Description (Release 5)”, que se incorpora a título de referencia a la presente. A la entidad MAC nueva se le denomina MAC -hs y está ubicada siempre en el Nodo B. En las ediciones anteriores del 3GPP, todas las entidades MAC UTRAN con capacidad de gestionar también datos del plano de usuario estaban ubicadas siempre exclusivamente en los RNC. La MAC -hs existe únicamente cuando la célula está configurada para prestar soporte al concepto de HSDPA, y está conectada a una MAC -c/hs ubicada en un RNC, a través de la interfaz Iub.

Una capa de MAC se usa para establecer correspondencias de canales lógicos con canales de transporte. Un canal lógico es un tipo de canal que se define entre el control de enlace de radiocomunicaciones (RLC) en un RNC y la

15

25

35

45

55

65 E01960691

20-10-2014

capa de MAC. Cada canal lógico define qué tipo de datos se va a transmitir a través del mismo. En el caso de HSDPA, los canales lógicos siempre se sitúan en el SRNC. Un canal de transporte es un tipo de canal que se define entre la capa de MAC y la L1 (capa 1). Describe cómo se van a transmitir datos a través de enlace de radiocomunicaciones. En el concepto de DSCH, el canal de transporte se ve en la interfaz Iub, mientras que, en el concepto de HSDPA, el canal de transporte es un canal interno en el Nodo B.

La conexión de diferentes MAC de una UTRAN para HSDPA se ilustra en la figura 1, la cual se tomó del informe técnico anteriormente citado TR 25.855.

La figura 1 representa un MAC -hs 1 ubicado en un Nodo B, y, adicionalmente, un MAC -c/sh 2 y un MAC -d 3 ubicados en uno o más RNC. El MAC -hs 1 está conectado al MAC -c/sh 2 por medio de la interfaz Iub, mientras que el MAC -c/sh 2 está conectado al MAC -d 3 por medio de una interfaz Iur en caso de que estén ubicados en RNC diferentes, si no, estos MAC 2, 3 están interconectados localmente. Un control de MAC tiene acceso a cada uno de los MAC 1 a 3. Se establecen correspondencias directamente de canales lógicos tales como el PCCH (canal de búsqueda) y el BCCH (canal de control de difusión general) con el MAC -c/sh 2 sin intervención del MAC -d 3. No obstante, canales lógicos tales como el DCCH (Canal de control dedicado) y el DTCH (canal de tráfico dedicado) están conectados siempre al MAC -d 3, el cual reenvía los paquetes de datos recibidos al MAC -c/sh 2, si el UE tiene derecho de acceso o bien al(a los) canal(es) común(es) o bien al(a los) canal(es) compartido(s). El MAC -c/sh 2 y el MAC -d 3 establecen correspondencias de tipos diferentes de canales lógicos sobre canales de transporte, como el PCH (canal de búsqueda), el FACH (canal de acceso directo), el DCH (canal dedicado), etcétera, para su transmisión a un UE por medio de un Nodo B. El MAC -d 3 proporciona datos recibidos relacionados con el HSDPA, por medio del MAC -c/sh 2, sin establecimiento de correspondencias al MAC -hs 1 del Nodo B para su transmisión en HS DSCH a un UE. Para los detalles de la figura 1 se hace referencia a informe técnico TR 25.855.

Alternativamente, el MAC -hs se podría conectar directamente a un MAC -d.

Puesto que las funcionalidades previamente implementadas solo en los RNC se van a proporcionar ahora también en los Nodos B, como la selección de TFC (combinación de formato de transporte), la división funcional entre Nodo B y RNC se ha reorganizado. La distribución nueva de funcionalidades se muestra en las figuras 2 y 3, las cuales se tomaron también del informe técnico TR 25.855, y que presentan de forma más detallada algunas de las funciones proporcionadas, respectivamente, por el MAC -c/sh 2 y el MAC -hs 1.

Tras la reorganización, las funciones de gestión de planificación/prioridades y de selección de TFC se han eliminado del MAC -c/sh 2 del RNC de la figura 2 para transmisiones de enlace descendente relacionadas con el HSDPA y se han añadido al MAC -hs 1 del Nodo B de la figura 3. Así, la planificación final y el control del tráfico de tiempo real ya no están bajo el control del RNC para el HSDPA. Por consiguiente, en el MAC -c/sh 2 de la figura 2, datos relacionados con el HSDPA recibidos desde un MAC -d se trasladan al MAC -hs 1 de la figura 3 sin que se realice ninguna planificación, gestión de prioridades o selección de TFC, etcétera, como para otros datos de enlace descendente. Previamente, siempre se atendía a estas funciones o bien en un SRNC cuando el Nodo B estaba conectado directamente a un SRNC, o bien en un CRNC cuando el Nodo B estaba conectado a un CRNC. Adicionalmente, se implementa la HARQ en el MAC -hs 1 nuevo de la figura 3. Para los detalles de las figuras 2 y 3, se hace referencia al informe técnico anteriormente citado TR 25.855.

La reorganización de funcionalidades implica que se deben adaptar las transmisiones conocidas de datos de usuario de enlace descendente y de información de control requerida desde un RNC a un Nodo B.

Para la transmisión de datos de usuario de enlace descendente, se propuso que la capa de RLC no se cambiase. Esto significa que el RLC almacena temporalmente, igual que antes, PDU (unidades de datos de protocolo) de RLC en memorias intermedias del RNC, y que el RLC envía datos a la capa inferior únicamente tras una solicitud de la capa de MAC que se sitúa en el RNC, es decir, el MAC -d 3. Por lo tanto, las transacciones para prestar soporte a la transmisión de datos entre una entidad MAC en un RNC y un MAC -hs 1 en un Nodo B están definidas actualmente solo en un alto nivel, pero todavía faltan detalles. Por medio de estas definiciones de alto nivel, se define una funcionalidad de control de flujo entre el MAC -c/sh 2 y el MAC -hs 1 como característica nueva, según se indica en la figura 3, con el fin de control el flujo de datos desde el RNC al Nodo B.

Para prestar soporte a las transmisiones de datos reales en la interfaz Iub, se incluyó además una capa de Protocolo de trama de HS-DSCH (FP de HS-DSCH) por debajo del MAC -c/sh y por encima del MAC -hs. Esta capa se indica en la figura 4, la cual se tomó nuevamente el informe técnico TR 25.855. La figura 4 muestra una arquitectura de protocolos de interfaz de radiocomunicaciones del HSDPA, y más específicamente capas de elementos de red, siendo estos elementos de red, de izquierda a derecha, un equipo de usuario UE conectado por medio de una interfaz Uu a un Nodo B, el cual está conectado además por medio de una interfaz Iub a un primer RNC, el cual está conectado finalmente por medio de una interfaz Iur a un segundo RNC. Cada uno del Nodo B, el primer y el segundo RNC comprende, además de la entidad MAC respectiva, un FP de HS-DSCH. Este FP de HS-DSCH está destinado a transmitir no solamente paquetes de datos desde el RNC al Nodo B, sino también información de control relacionada. Se propone un protocolo FP sin ningún detalle para transmisiones de datos en el enlace descendente en las interfaces tanto Iub como Iur, usando dichas transmisiones el servicio de L2 (capa 2) del MAC y el RLC. Para

15

25

35

45

55

65 E01960691

20-10-2014

los detalles de la figura 4, se hace referencia al informe técnico antes citado TR 25.855.

No obstante, ninguna de las estructuras actuales de tramas FP definidas para la interfaz Iub es aplicable para el HSDPA. En particular, la estructura de tramas FP usada para la DSCH, de los cuales procede la propuesta para el HSDPA, no es adecuada para transmisiones de datos HSDPA, puesto que una trama FP DSCH contiene campos cuyos valores solamente se pueden definir cuando ya se ha realizado la planificación o la selección de TFC. Tal como se ha mencionado anteriormente, estas funciones se dejaron para transmisiones relacionadas con el HSDPA hacia el Nodo B. Por otra parte, una trama FP DSCH no contiene toda la información que se requiere para que el HSDPA preste soporte al control del flujo entre un RNC y un Nodo B.

Además de datos de usuario relacionados con el HSDPA, en el Nodo B también tiene que haber disponible información de control de manera que el Nodo B pueda establecer y re-configurar canales HS-DSCH para transmisiones.

Debido a la reorganización funcional, los procedimientos actuales de protocolos de aplicación en la Iub para el establecimiento y la reconfiguración del DSCH, descritos, por ejemplo, en la especificación técnica 3GPP TS 25.433 V3.4.1 (2000-12): “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iub Interface NBAP Signalling (Release 1999)”, no se pueden usar para el HS-DSCH. Por ejemplo, en el caso del HSDPA, no es necesario proporcionar parámetros de codificación de canal durante un establecimiento de enlace de radiocomunicaciones (RL) igual que para el DSCH, puesto que estos parámetros de codificación de canal se resuelven en el Nodo B. Por otro lado, algunos parámetros que no son requeridos por un Nodo B para el DSCH se deberían proporcionar a un Nodo B para el HSDPA durante un procedimiento de establecimiento de célula de modo que el Nodo B pueda configurar los atributos de HS-DSCH en una célula. Por otra parte, debería resultar posible modificar estos parámetros sobre la base de cada célula, preferentemente de una manera semi-estática.

Sumario de la invención

Es un objetivo de la invención posibilitar la transmisión de datos dentro de una red de comunicaciones, siendo requeridos dichos datos en un elemento de red de dicha red de comunicaciones.

Es también un objetivo de la invención posibilitar el uso del HSDPA por parte de una UTRAN, y, más específicamente, posibilitar que el RNC de una UTRAN proporcione a un Nodo B de la UTRAN datos relacionados con el HSDPA.

Es en particular un objetivo de la invención posibilitar que un RNC proporcione a un Nodo B, de una manera adecuada, parámetros de control relevantes para el HSDPA en la NBAP (Parte de Aplicación del Nodo B).

La invención se define en las reivindicaciones independientes adjuntas.

Un primer aspecto de la descripción va dirigido a la transmisión de datos de usuario, mientras que un segundo aspecto de la descripción va dirigido a la transmisión de parámetros de control.

Para el primer aspecto, se propone un método para transmitir datos de usuario dentro de una red de comunicaciones desde un controlador a un elemento de red a través de una interfaz. La red de comunicaciones puede ser, en particular, una UTRAN, el controlador un RNC, el elemento de red un Nodo B y la interfaz una interfaz Iub. El controlador usa por lo menos una estructura de tramas dedicada, en particular una estructura de tramas FP HSDPA dedicada, para ensamblar tramas de datos con los datos de usuario. A continuación, las tramas de datos se transmiten, por medio de la interfaz, al elemento de red. La estructura de tramas incluye por lo menos una sección de encabezamiento para recibir información requerida en dicho elemento de red con el fin de procesar los datos de usuario.

Para el primer aspecto, se proponen además una red de comunicaciones, en particular una UTRAN, un controlador, en particular un RNC, y un elemento de red, en particular un Nodo B, que comprenden medios para materializar el método propuesto.

El primer aspecto proviene de la idea de que la transmisión de información requerida para el procesado de datos de usuario relacionados con el HSDPA debería ser similar a las soluciones usadas para otros canales compartidos, aunque se debería seguir optimizando para los requisitos del HSDPA. La estructura de tramas dedicada propuesta permite eliminar todos los campos utilizados en las estructuras para DSCH que ya no son necesarios para el HSDPA, e insertar campos para la información requerida adicionalmente para el HSDPA. De este modo, se posibilita una transmisión optimizada de información requerida para datos de usuario relacionados con el HSDPA, por medio de la interfaz Iub. Se aplican las mismas consideraciones para otras redes de comunicaciones, otros elementos de red y otras situaciones.

Para el segundo aspecto, se propone un método para proporcionar a un elemento de red de una red de comunicaciones parámetros de control disponibles en un controlador de la red de comunicaciones, estando

15

25

35

45

55

65 E01960691

20-10-2014

conectado dicho controlador a dicho elemento de red por medio de una interfaz. La red de comunicaciones puede ser en particular una UTRAN, el controlador un RNC, el elemento de red un Nodo B y la interfaz una interfaz Iub. El método comprende utilizar un protocolo de aplicación de interfaz que posibilita una inserción de por lo menos un parámetro de control, en particular un parámetro de control relacionado con el HSDPA, en por lo menos un tipo de mensaje de control transmitido desde dicho controlador a dicho elemento de red a través de dicha interfaz.

También para el segundo aspecto, se propone además una red de comunicaciones, en particular una UTRAN, un controlador, en particular un RNC, y un elemento de red, en particular un Nodo B, que comprenden medios para materializar el método propuesto.

El segundo aspecto proviene de la idea de que la forma más eficiente de proporcionar a un Nodo B parámetros de control requeridos para establecer y re-configurar canales DSCH HS es incluir los parámetros en mensajes de control transmitidos desde un RNC al Nodo B. Puesto que el RNC y el Nodo B están conectados entre sí por medio de una interfaz Iub, se propone por lo tanto la modificación, de manera correspondiente, del protocolo de aplicación de la Iub. Como consecuencia, el Nodo B puede, por ejemplo, establecer y re-configurar canales HS-DSCH basándose en parámetros de control recibidos. Por lo tanto, el Nodo B puede ser configurado por el RNC para prestar soporte a datos relacionados con el HSDPA para equipos de usuario en la célula. Se aplican las mismas consideraciones para otras redes de comunicaciones, otros elementos de red y otras situaciones.

Los dos aspectos de la descripción tienen en común que comprenden una implementación, específica del HSDPA, de especificaciones generales usadas para transmitir datos desde el RNC al Nodo B por medio de la interfaz Iub, es decir, por un lado, una implementación de estructuras de tramas dedicadas y, por otro lado, una implementación de un protocolo de aplicación de la Iub con procedimientos específicos del HSDPA.

A partir de las reivindicaciones secundarias se pondrán de manifiesto formas de realización preferidas de la invención.

En una forma de realización preferida del primer aspecto de la descripción, la estructura de tramas incluye además una sección de carga útil para recibir por lo menos una SDU en la cual dicho controlador distribuyó datos de usuario relacionados con el HSDPA, recibiendo la sección de encabezamiento información requerida en el elemento de red para procesar datos de usuario relacionados con el HSDPA. Así, información requerida en el Nodo B para procesar datos de usuario relacionados con el HSDPA se puede transmitir de una manera ventajosa en una única trama junto con dichos datos de usuario. Las SDU son, en particular, SDU MAC -d, y/o SDU MAC -c/sh.

Para el primer aspecto, debe indicarse que la estructura propuesta de tramas FP HSDPA se puede diseñar para recibir cualquier cantidad de información, pudiéndose predeterminar arbitrariamente dicha información de acuerdo con los requisitos.

Además, no debería ser obligatorio que la sección de carga útil contenga ningún dato en una trama ensamblada de acuerdo con la estructura de tramas dedicada, de manera que se puede usar la misma estructura para transmitir información únicamente en la sección de encabezamiento, por ejemplo, información para un control de flujo HSDPA.

En particular, se pueden proporcionar diferentes estructuras de tramas FP para los casos en los que, en el RNC, se permita o no el multiplexado de ID de UE en MAC/FP. El multiplexado de ID de UE es un tipo de multiplexado en el cual diferentes UE se multiplexan sobre el mismo canal de transporte y el mismo se puede llevar a cabo o bien en la capa MAC o bien en la capa FP de un RNC. En el caso del multiplexado de ID de UE en FP, el encabezamiento de la trama FP debería contener siempre la identificación ID del UE. Esta identificación puede ser, por ejemplo, RNTI, o puede ser una identificación nueva definida únicamente para esta finalidad, y, por lo tanto, puede ser más corta que la RNTI actual. En un caso de multiplexado por ID de UE en MAC, el campo de ID de UE se usa en el encabezamiento MAC, es decir, la RNTI se añade al encabezamiento MAC, no requiriéndose necesariamente ninguna identificación en la trama FP. El Nodo B puede recuperar la información de ID de UE leyendo el encabezamiento MAC. A continuación, de nuevo si se desea que la trama FP contenga el campo de ID de UE a pesar de la adición de la RNTI en el encabezamiento MAC, el ID de UE usado puede ser, por ejemplo, la RNTI, o puede ser una identificación nueva definida únicamente para esta finalidad y, por lo tanto, más corta que la RNTI actual.

Por otra parte, existen diferentes alternativas sobre cómo puede llevarse a cabo el multiplexado, y puede que se deba tener en consideración el método de multiplexado usado cuando se determine la estructura más adecuada de la trama FP. El tipo de multiplexado usado puede tener, en particular, un impacto sobre el número de campos del mismo tipo proporcionados en una trama FP. Una alternativa para el multiplexado es el multiplexado basado en la división de tiempo, lo cual significa que una trama de datos FP puede transportar datos que pertenecen solamente a un UE. En otra alternativa es posible transportar datos pertenecientes a UE diferentes en una trama FP. Además, el multiplexado se podría abordar permitiendo que una entidad de FP envíe solamente una trama FP dentro de un TTI, y esta trama se podría destinar a solamente un UE o la misma podría transmitir datos para una serie de UE. Multiplexado podría significar también que una entidad de FP pudiera enviar más de una trama FP dentro de un TTI, estando asignadas todas ellas a un UE, o cada trama FP podría transportar datos que están destinados a diferentes

15

25

35

45

55

65 E01960691

20-10-2014

UE.

Asimismo, se pueden proporcionar diferentes estructuras de tramas FP para los casos en los que se debe transmitir

o no una identificación de equipo de usuario desde el RNC al Nodo B.

Se puede hacer que el tamaño de tramas basado en una estructura de tramas predeterminada sea variable, permitiendo para cierta información de la sección de encabezamiento un campo dedicado para cada equipo de usuario o para cada memoria intermedia de RNC desde la cual se tomaron datos, etcétera. Por otra parte, una estructura de campos se puede generalizar haciendo que la inserción de parte de la información sea opcional.

Cierta información que es tenida en cuenta por una estructura de tramas específica puede estar relacionada con memorias intermedias del RNC o el almacenamiento temporal utilizado en la transmisión de datos HSDPA para almacenar de manera temporal datos de usuario en un RNC. Debe indicarse que la expresión almacenamiento temporal de RNC o memorias intermedias de RNC se usa para indicar la capacidad de almacenamiento temporal en el RNC sin identificar la ubicación exacta de la memoria intermedia. Por lo tanto, el almacenamiento temporal se puede proporcionar, por ejemplo, en la capa de RLC y/o en la capa de MAC.

Por otra parte, en el primer aspecto, cierta información específica de cada equipo de usuario o bien se puede incluir en la sección de encabezamiento de la estructura de tramas propuesta, o bien en una sección de encabezamiento de una SDU respectiva insertada en la sección de carga útil de la estructura de tramas propuesta.

En el segundo aspecto, también el protocolo de aplicación de la Iub puede permitir la inclusión de cualquier tipo y número adecuados de parámetros en cualesquiera tipos adecuados de mensaje de acuerdo con los requisitos.

Existen dos clases de parámetros de control que se podrían tener que proporcionar desde un RNC a un Nodo B de acuerdo con el segundo aspecto. O bien el RNC elige un valor exacto de un parámetro y el Nodo B debe seguir esta decisión o bien el RNC proporciona un acotamiento de posibles elecciones. En este último caso, el Nodo B puede elegir el valor de acuerdo con sus propias condiciones dentro del acotamiento proporcionado. Así, el contenido de cada parámetro de control es o bien un valor fijo, o bien una indicación de un intervalo para el valor, o bien un conjunto de valores permitidos para ser usados por dicho Nodo B.

Los parámetros de control del segundo aspecto pueden ser, en particular, parámetros específicos de cada célula requeridos en el Nodo B, por ejemplo, para el establecimiento y/o la reconfiguración de una célula, o un parámetro específico de cada enlace de radiocomunicaciones, requerido en el Nodo B, por ejemplo, para el establecimiento y/o la reconfiguración de un enlace de radiocomunicaciones. A continuación, el protocolo de aplicación de la Iub puede determinar que los parámetros se deben incluir en mensajes de control referentes a un establecimiento o reconfiguración de célula o en un mensaje de control referente a un establecimiento o reconfiguración de RL, respectivamente.

Ambos, parámetros específicos de cada célula y parámetros específicos de cada RL, se pueden proporcionar o bien como valor específico o bien como acotamiento de elecciones.

Con el fin de incluir los parámetros de control del segundo aspecto en un mensaje de control, se definen preferentemente uno o más elementos de información (IE) o grupo de IE. A continuación, cada IE puede comprender un campo para cada parámetro requerido para una situación específica. Los IE se pueden añadir a un mensaje de control que debe ser transmitido en esta situación específica. Adicionalmente, se podrían usar IE definidos para el DSCH o IE correspondientes, en la medida en la que los parámetros requeridos sean los mismos para algunas situaciones. También es posible definir conjuntos de IE y/o grupos de IE para situaciones específicas, los cuales deben añadirse a algún mensaje de control para la situación respectiva.

Breve descripción de las figuras

A continuación, se explica la invención de forma más detallada haciendo referencia a dibujos, en los cuales

la figura 1 muestra una arquitectura MAC total conocida, del lado de la UTRAN, definida para el HSDPA;

la figura 2 muestra detalles de un MAC -c/sh conocido de un RNC;

la figura 3 muestra detalles de un MAC -hs conocido de un Nodo B;

la figura 4 muestra una arquitectura conocida de protocolos de interfaz de radiocomunicaciones definida para el HSDPA;

la figura 5 muestra un modelo para la Iub, cuando, en el RNC, no se permite un multiplexado de nivel MAC;

la figura 6 muestra un modelo para la Iub, cuando, en el RNC, se permite un multiplexado de nivel MAC;

15

25

35

45

55

65 E01960691

20-10-2014

la figura 7 muestra una estructura de tramas FP DSCH conocida;

la figura 8 muestra una primera forma de realización de una estructura de tramas FP HSDPA;

la figura 9 muestra una segunda forma de realización de una estructura de tramas FP HDSPA;

la figura 10 muestra una tercera forma de realización de una estructura de tramas FP HDSPA;

la figura 11 ilustra una estructura de PDU MAC;

la figura 12 muestra un primer ejemplo de posibles valores de campos del encabezamiento de las tramas FP para la forma de realización de la figura 10;

la figura 13 muestra un segundo ejemplo de posibles valores de campos del encabezamiento de tramas FP para la forma de realización de la figura 10;

la figura 14 es una tabla que presenta un conjunto de IE específicos de cada célula para una forma de realización del segundo aspecto;

la figura 15 es una tabla que presenta un IE específico de cada célula de RL para una forma de realización del segundo aspecto;

la figura 16 es una tabla que presenta un primer conjunto de IE específicos de cada célula de RL para una forma de realización del segundo aspecto;

la figura 17 es una tabla que presenta un segundo conjunto de IE específicos de cada célula de RL para una forma de realización del segundo aspecto; y

la figura 18 es una tabla que ilustra una modificación de un TFS conocido para una forma de realización del segundo aspecto.

Descripción detallada de la invención

En primer lugar, se presentarán tres formas de realización de una estructura de tramas FP HSDPA de acuerdo con el primer aspecto.

Las estructuras de tramas respectivas se van a usar para transmitir datos de usuario relacionados con el HSDPA dentro de una UTRAN, desde un MAC -c/sh de un RNC, por medio de una interfaz Iub, a un MAC -hs de un Nodo B. Un UE al cual van dirigidos los datos de usuario está conectado a este Nodo B.

Cuando se determina una estructura de tramas adecuada, deberían considerarse los requisitos y capacidades de los elementos de red, es decir, el RNC y el Nodo B. Uno de los puntos importantes que debería considerarse, por ejemplo, es el multiplexado de ID de UE en MAC/FP el cual puede estar permitido o no en el RNC, tal como se explicará en lo sucesivo.

En un primer modelo, que se ilustra en la figura 5, al RNC no se le permite llevar a cabo un multiplexado al nivel de ID de UE en MAC/FP.

La figura 5 muestra esquemáticamente un RNC 4 y un Nodo B 5 interconectados por medio de una interfaz Iub. El RNC 4 comprende un RLC 6, un MAC -d y MAC -c/sh 2, 3 y una entidad de FP 7. Asimismo, el Nodo B 5 comprende una entidad de FP 8, y un MAC -hs 1. En una situación actual, se asignan tres portadores de radiocomunicaciones RB w, z, y v a un primer equipo de usuario UEx, mientras que se asignan dos portadores de radiocomunicaciones RB adicionales m y n a un segundo equipo de usuario UEy. Los RB de UEy y asimismo el RB v de UEx se trasladan sin multiplexado desde el RLC 6 en canales lógicos, por medio del MAC -d y el MAC -c/sh 2, 3 y la entidad de FP 7, la interfaz Iub y la entidad de FP 8 del Nodo B 5 al MAC -hs 1. Los RB w y z de UEx se multiplexan por C/T en la capa MAC del RNC 4, y se transmiten sobre una única conexión de transporte, por medio de las mismas entidades, al Nodo B 5. Multiplexado por C/T significa el multiplexado de diferentes RB, es decir, que están usando canales lógicos diferentes, los cuales están asignados todos para el mismo UE sobre el mismo canal de transporte. A continuación, el MAC -hs 1 establece correspondencias de los canales lógicos recibidos sobre canales de transporte.

Si se permite llevar a cabo el multiplexado por C/T entre portadores de radiocomunicaciones (RB), que están todos asignados al mismo UE, el número mínimo de conexiones requeridas de transmisión de la Iub es igual al número de UE que tienen acceso al HS-DSCH. El multiplexado por C/T puede ser usado por un RNC, por ejemplo, solamente para algunos RB de algunos UE, como en la figura 5, o para todos los RB de todos los UE.

10

15

20

25

30

35

40

45

50

55

60

65 E01960691

20-10-2014

Alternativamente, en el RNC 4 de la figura 5 podría no permitirse un multiplexado por C/T de diferentes portadores de radiocomunicaciones RB en la misma conexión de transmisión de la Iub. Incluso podría no permitirse la provisión del multiplexado por C/T, por ejemplo, debido a diferentes niveles de prioridad, si todos los portadores de radiocomunicaciones están asignados para el mismo UE. En este caso, el número de conexiones de transporte sobre la interfaz Iub es igual al número de portadores de radiocomunicaciones que están usando el método de transporte de tipo HSDPA.

En un segundo modelo, que se ilustra en la figura 6, al RNC 4 se le permite, por el contrario, llevar a cabo el multiplexado de ID de UE al nivel MAC.

La figura 6 muestra esquemáticamente la misma estructura que la figura 5, de un RNC 4 y un Nodo B 5 interconectados mediante una interfaz Iub. Solamente en este caso se representan un MAC -d 3 y un MAC -c/sh 2 independientes. Por otra parte, se asignan los mismos portadores de radiocomunicaciones RB w, z, v, m y n a los mismos equipos de usuario UEx, UEy que en la figura 5. Los portadores de radiocomunicaciones RB w y RB z se multiplexan por C/T nuevamente en la capa MAC, más específicamente por medio del MAC -d 3. Adicionalmente, la salida del multiplexado por C/T y los otros tres portadores de radiocomunicaciones RB v, m y n se multiplexan por ID de UE por medio del MAC -c/sh 2 en una única conexión de transporte para su transmisión al MAC -hs 1 por medio de la capa de FP 7 del RNC 4, la interfaz Iub y la capa de FP 8 del Nodo B 5. El MAC -hs 1 en primer lugar lleva a cabo un demultiplexado, y a continuación un establecimiento de correspondencias de los canales lógicos sobre canales de transporte.

En el Nodo B 5, la capa MAC demultiplexa de manera correspondiente la información recibida, antes de establecer una correspondencia de la misma con los HS-DSCH y adicionalmente con el HS-PDSCH como en la figura 5.

Podría haber más de una conexión de transporte usada en el multiplexado. La idea general en el multiplexado es que resulta posible que todos los UE que cumplen los mismos criterios puedan usar los mismos recursos de transporte. El multiplexado se puede basar, por ejemplo, en el número de células en el Nodo B. Esto significa, si el Nodo B presta soporte a más de una célula, que se proporciona una conexión de transporte por cada célula. Alternativamente, el multiplexado se podría basar en niveles de prioridad asignados a los canales lógicos, es decir, se proporciona una conexión de transporte por prioridad. Además, se podría proporcionar solamente una única conexión de transporte para un Nodo B. El multiplexado también se podría basar en el número de canales físicos relacionados con el HSDPA sobre la Interfaz de Radiocomunicaciones.

En el segundo modelo, el multiplexado por ID de UE en MAC/FP no está limitado en modo alguno, lo cual significa que es posible que se permita a todos los UE usar la misma conexión de transporte sobre la interfaz Iub.

El segundo modelo se puede proporcionar también situando el multiplexado por ID del UE en la capa de FP. En los dos casos, si se usa la RNTI en el encabezamiento MAC, no es obligatorio ninguna ID de UE en la trama de FP, y si no se incluye ninguna identificación en el encabezamiento MAC pero se permite el multiplexado, entonces el encabezamiento de FP debería contener también el(los) campo(s) de ID de UE.

Cuando se permite el multiplexado por ID de UE en MAC/FP, la estructura de trama se debería definir de tal manera que el receptor pueda extraer la información perteneciente a diferentes UE correctamente a partir de una trama HSDPA recibida.

Las figuras 7 a 10 muestran a continuación una estructura convencional de tramas FP DSCH definida para la interfaz Iub, presentada con fines comparativos, una primera forma de realización de una estructura de tramas FP HSDPA para el caso en el que no se permite ningún multiplexado por ID de UE y una segunda y tercera formas de realización de una estructura de tramas FP HSDPA para el caso en el que se permite el multiplexado por ID de UE.

La estructura de tramas FP DSCH de la figura 7 se tomó de la especificación técnica 3GPP TS 25.435, V3.5.0 (2000-12) : “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iub Interface User Plane Protocols for Common Transport Channel Data Streams (Release 1999)”. La misma está compuesta por una sección de carga útil y una sección de encabezamiento, cada una de ellas dividida en filas de 8 bits 0 a 7. La sección de carga útil comprende de un primer a un último TB (bloques de transporte), una “Extensión de Reserva” (“Spare Extension”), y una “CRC de Carga útil” (“Payload CRC”) (comprobación de redundancia cíclica). La sección de encabezamiento comprende los campos “CRC de Encabezamiento” (“Header CRC”), “FT”, “CFN”, “TFI”, “Compensación de Potencia” (“Power Offset”), “Número de Código” (“Code Number”), “SF”, y “Info de MC” (“MC Info”).

El campo “CFN” se usa para indicar el número de trama de conexión (CFN) en el cual se deberían transmitir los datos de una trama a través de la interfaz de radiocomunicaciones. En el concepto HSDPA, el valor de este campo es únicamente conocido por el Nodo B después de una planificación de los datos correspondientes para la interfaz de radiocomunicaciones, y, por lo tanto, el RNC no puede proporcionar este campo al Nodo B.

15

25

35

45

55

65 E01960691

20-10-2014

El campo “TFI” se usa para indicar el formato de transporte válido (TF) para los datos en la trama. En el concepto HSDPA, la selección de TFC se lleva a cabo en el Nodo B, y, por lo tanto, el RNC no puede enviar dicha información al Nodo B.

El campo “Compensación de Potencia” se usa para indicar el nivel de potencia solicitado para la transmisión de los datos de la trama FP correspondiente. Este campo es necesario en el caso del DSCH, ya que, para el DSCH, se proporciona un control de potencia de bucle cerrado. En el caso del HSDPA, no se proporciona ningún control de potencia de bucle cerrado, y, por lo tanto, no se requiere del RNC ninguna información de control de potencia.

El campo “Número de código” indica el código usado para el DSCH. En el caso del HSDPA, la selección del código se realiza en el Nodo B, y, por lo tanto, no se requiere del RNC ninguna información de este tipo.

El campo “SF” identifica el factor de ensanchamiento (SF) que va a ser usado en un PDSCH para los paquetes de datos correspondientes de la trama. En el concepto HSDPA el SF se define en el Nodo B, y, por lo tanto, no se requiere del RNC ninguna información de este tipo.

El campo “Info de MC” se usa para indicar el número de códigos de PDSCH paralelos sobre los cuales se transportarán los datos de DSCH. En el concepto HSDPA, este tipo de información se define en el Nodo B, y, por lo tanto, no se requiere del RNC ninguna información de este tipo.

Así, para el HSDPA no se requiere ninguno de los campos de la sección de encabezamiento excepto el campo “CRC de Encabezamiento” y el campo “FT” (tipo de trama), y estos campos se pueden eliminar cuando se diseña una estructura de tramas FP HSDPA. Sin embargo, por otro lado, si los campos simplemente se eliminan, el Nodo B no recibe información suficiente para extraer la trama FP recibida. Por lo tanto, se requieren campos nuevos con el fin de garantizar que los mecanismos de control de flujo funcionan cuando la entidad MAC nueva MAC -hs está ubicada en el Nodo B.

La figura 8 presenta una estructura de tramas HSDPA que comprende dichos campos nuevos para el caso en el que no se permite ningún multiplexado por ID de UE en MAC/FP. La misma está compuesta nuevamente por una sección de carga útil y una sección de encabezamiento, cada una de ellas dividida en filas de 8 bits. De manera similar a la estructura de las tramas de DSCH, la sección de carga útil comprende de una primera a una última SDU (unidades de datos de servicio) MAC -c/sh, una “Extensión de Reserva”, y una “CRC de Carga Útil”. La estructura de una SDU MAC con un encabezamiento variable se conoce a partir del estado de la técnica como PDU MAC, y se describirá posteriormente en referencia a la figura 11. La sección de encabezamiento comprende ahora campos a los que se hace referencia con “CRC de Encabezamiento”, “FT”, “NumOfSDUs", “Tamaño de Memoria Intermedia de Usuario” (“User Buffer Size”), “Tipo de ID de UE” (“UE-ID type”), y “CMCH-PI”. En particular, la introducción de los dos últimos campos es opcional.

El campo “NumOfSDUs" se usa para indicar el número de las SDU MAC -c/hs en la trama. La longitud del campo se puede seleccionar de manera adecuada.

El campo “Tamaño de Memoria Intermedia de Usuario” se usa para indicar el estado de la memoria intermedia asignada al UE respectivo en las memorias intermedias de RNC (por ejemplo, en bytes). Este campo informa al Nodo B sobre cuántos datos pertenecientes al mismo flujo de datos siguen quedando en el RNC. Una cantidad de datos transportada en la trama de datos FP correspondiente o bien se puede excluir o bien se puede incluir en el campo de información del tamaño de memoria intermedia de usuario. El Nodo B puede usar esta información, por ejemplo, en la planificación de manera que un flujo de datos que presente la prioridad más alta y la mayor de datos en las memorias intermedias de RNC obtenga acceso al canal HSDPA antes que un flujo de datos que presente una prioridad inferior y una cantidad de datos en las memorias intermedias de RNC. Posteriormente se explicarán, en referencia a las figuras 12 y 13, diferentes significados posibles de la expresión memorias intermedias de RNC. La longitud del campo se puede seleccionar de manera adecuada.

El campo “Tipo de Id de UE” se usa para indicar qué tipo de RNTI, es decir, c-RNTI o U-RNTI, debería añadir el MAC -hs al Nodo B al encabezamiento MAC. El tipo U-RNTI (identidad temporal de red de radiocomunicaciones UTRAN) se puede usar en un encabezamiento MAC de la PDU MAC, cuya parte de carga útil contiene mensajes de señalización de L3 (RRC) específicos cuando el uso de la U-RNTI es obligatorio. Sobre este tipo de situación informa el RRC enviando una orden a la L2 (capa MAC por medio de la capa RLC) para usar la U-RNTI en lugar de la C-RNTI en un encabezamiento MAC. El tipo C-RNTI (Identidad temporal de red de radiocomunicaciones celular) se usa sobre el DTCH y el DSCH en el modo FDD (dúplex por división de frecuencia), y se puede usar en un encabezamiento MAC, cuando, desde capas superiores (RRC), no se recibe ninguna solicitud para usar la U-RNTI. El campo de tipo de ID de UE se requiere únicamente si se especifica que la RNTI se añada en el Nodo B. Si se especifica que la RNTI se añada en un SRNC o si no se usa en absoluto ninguna RNTI para transmisiones de datos HSDPA, dicho campo no se requiere en la trama de datos FP HSDPA. La longitud del campo es un bit.

El campo de indicador de prioridad de canal de transporte común (“CMCH-PI”) se usa para indicar la prioridad relativa de la trama de datos y/o de las SDU incluidas. Para transmisiones de datos HSDPA se puede introducir el

15

25

35

45

55

65 E01960691

20-10-2014

uso de este campo, aunque la prioridad del RB cuando no se proporciona ningún multiplexado se podría introducir en el momento en el que se configura la conexión de transporte correspondiente a través de la Iub.

En esta primera forma de realización de una estructura de tramas FP HSDPA, no es necesario que se incluya un campo para una información de tamaño de SDU MAC, ya que, para el HSDPA, se ha definido que se usarán tamaños de TB semi-estáticos, siendo la SDU MAC de un tamaño fijo en caso de que no se permita el multiplexado.

La figura 9 presenta una estructura de tramas HSDPA que comprende campos nuevos para el caso en el que se permite el multiplexado por ID de UE en MAC/FP. La misma está compuesta nuevamente por una sección de carga útil y una sección de encabezamiento, cada una de ellas dividida en filas de 8 bits. De manera similar a la estructura de tramas FP DSCH y a la primera forma de realización de una estructura de tramas FP HSDPA, la sección de carga útil comprende de una primera a una última SDU (unidades de datos de servicio) MAC -c/sh, una “Extensión de Reserva”, y una “CRC de Carga Útil”. La sección de encabezamiento comprende entonces campos a los que se hace referencia con “CRC de Encabezamiento”, “FT”, “NumOfSDUs", “NumOfBuff”, “Tamaño de SDU MAC” (“Size of MAC SDUs"), “Tamaño de Memoria Intermedia de Usuario” (“User Buffer Size”) 1-N, “Tipo de ID de UE” (“UE-ID type”), y “CMCH-PI”. Además, para “NumOfSDUs", “NumOfBuff2”, “Tamaño de SDU MAC”, y “CMCH-PI” puede haber varios campos, aun cuando, en la figura, se indica solamente un campo para cada parámetro.

El campo “NumOfSDUs" se usa para identificar el número de las SDU MAC -c/sh que se han tomado de una memoria intermedia de RNC. La longitud del campo se puede ajustar de manera adecuada. El número de este tipo de campos es igual al número de campos “NumOfBuff”.

El campo “NumOfBuff” indica desde cuántas memorias intermedias de RNC se han suministrado datos a esta trama FP. Debe indicarse que este campo no describe el número de memorias intermedias de RNC desde las cuales se podrían suministrar datos. La longitud del campo se puede ajustar adecuadamente.

El campo “Tamaño de SDU MAC” se introduce ya que el multiplexado MAC no es una característica obligatoria, es decir, es posible que incluso si se permite el multiplexado por ID de UE en MAC/FP, algunos operadores no deseen usarlo. Por lo tanto, para poder trabajar con el caso correspondiente a múltiples proveedores cuando se permite el multiplexado por ID de UE en MAC/FP, el campo de tamaño de SDU MAC define el tamaño de las SDU en la trama respectiva. En principio, un TB tiene siempre un tamaño fijo en el HSDPA, pero, puesto que el encabezamiento MAC tiene una longitud variable en función de si se presta soporte o no al multiplexado por ID de UE en MAC/FP, el tamaño de la SDU MAC puede variar en función del contenido o la existencia del encabezamiento MAC. Esta información es necesaria en el lado del receptor con el fin de extraer SDU de la trama de datos HSDPA correctamente. La longitud del campo se puede ajustar adecuadamente.

El campo “Tamaño de Memoria Intermedia de Usuario” se usa para indicar el estado de la memoria intermedia asignada a un UE en las memorias intermedias de RNC, en bytes. La longitud del campo se puede ajustar adecuadamente. El número de campos de este tipo en una trama es igual al número de campos “NumOfBuff”.

El campo “CMCH-PI” se podría usar para proporcionar una información sobre la prioridad de los datos cuando se permite el multiplexado por ID de UE en MAC/FP. Si se permite multiplexar datos con diferentes niveles de prioridad, entonces el número de campos de este tipo debe ser igual al número de los campos “NumOfBuffer”, pero si no se permite dicho multiplexado, basta con proporcionar un campo “CMCH-PI” por trama.

Debe indicarse que incluso si se permite el multiplexado por ID de UE en MAC/FP, el número de los campos respectivos relacionados con el multiplexado “NumOfSDUs", “Tamaño de Memoria Intermedia de Usuario”, “Tamaño de SDU MAC” y “CMCH-PI” se puede reducir, si se identifica una restricción de que una trama FP HSDPA puede contener solamente datos que pertenecen a un UE o RB. En este caso, el multiplexado por ID de UE en MAC/FP se realiza basándose en un método de división de tiempo.

Otra modificación de la estructura de tramas FP HSDPA presentada como tercera forma de realización se refiere a una identificación de equipo de usuario en transmisiones de datos relacionadas con el HSDPA.

Si no se requiere ninguna identificación de UE en el Nodo B, y, por lo tanto, en el RNC no se permite ningún multiplexado por ID de UE en MAC/FP, ni en el RNC ni en el Nodo B se incluye una identificación del UE. Los datos se identifican, en su lugar, usando otros métodos.

No obstante, si se requiere una identificación de UE, los lugares en los que esta información se puede acoplar a los datos son o bien el MAC -c/sh en un CRNC o bien el MAC -hs en un Nodo B. En el primer caso, la identificación de UE usada podría ser o bien la RNTI usada en ese momento o bien puede ser una identificación de UE nueva que se define únicamente para la transmisión de datos a través de la interfaz Iub.

Si se usa la RNTI, la información de identificación de UE se puede incluir o bien en los encabezamientos de SDU MAC -c/sh, que ya tienen campos con este fin, o bien en la sección de encabezamiento de la Trama Respectiva de Datos FP HSDPA. Si la misma se incluye en el encabezamiento de la SDU MAC -c/sh, el Nodo B debe extraer esta

15

25

35

45

55

65 E01960691

20-10-2014

parte de encabezamiento con el fin de hallar la identidad del UE. Si la identidad del UE está incluida en la sección de encabezamiento de una trama de datos FP HSDPA, no se requiere ninguna extracción.

Para la estructura de tramas de la figura 9, se supuso que si se requiere la identificación del UE, la identificación es RNTI y se incluye en el encabezamiento de la SDU MAC o bien en el CRNC o bien en el Nodo B.

Para el caso en el que no se desea ninguna RNTI en la interfaz aérea, pero se sigue queriendo una identificación de UE en la Iub, se presenta una tercera forma de realización de una estructura de tramas, la cual se ilustra en la figura

10.

Nuevamente, la estructura de tramas de la figura 10 presta soporte al multiplexado por ID de UE en MAC/FP y comprende todos los campos presentes en la estructura de tramas de la figura 9. Comprende campos adicionales “id de UE 1” (“UE-id 1”) a “id de UE N” (“UE-id N”) para identificar UE para los cuales hay incluidos datos en SDU MAC c/sh en la sección de carga útil. En esta figura, hay también N campos diferentes “NumOfBuff”, “NumOfSDUs", “Tamaño de SDU MAC”, y “CMCH-PI”, respectivamente, indicados de manera explícita.

El contenido de los campos de identificación de UE “id de UE” puede ser la RNTI, aunque, con el fin de ahorrar capacidad de transmisión sobre la interfaz Iub, también se podría definir una identificación nueva más corta. Así, la longitud de este campo depende del tipo seleccionado de identificación. El número de los campos “id de UE” depende de si una trama HSDPA puede contener datos para diferentes UE. Si se permite esto, el número de los campos debe ser igual al número de los campos “NumOfBuff”. No obstante, si se permite el multiplexado por ID de UE en MAC/FP, es decir, más de un UE está usando la misma conexión de transporte sobre la interfaz Iub, pero una trama FP HSDPA puede contener datos solamente de una memoria intermedia de RNC, el número de campos de identificación de UE requeridos es 1.

La figura 11 presenta la estructura de la PDU MAC cuando se establecen correspondencias del DTCH o DCCH en el DSCH, y cuando DTCH o DCCH son los únicos canales lógicos, y se puede utilizar también para el HSDPA. La figura se tomó de la especificación técnica 3GPP TS 25.321 V3.6.0 (2000-12): “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; MAC protocol specification (Release 1999)”.

La PDU MAC de la figura 11 está compuesta por una SDU MAC y un encabezamiento MAC. El encabezamiento comprende un campo de “tipo de Id de UE”, un campo de “Id de UE” y un campo de “C/T”. Los campos de “Tipo de Id de UE” y de “Id de UE” se incluyen en el encabezamiento MAC para el FDD únicamente. El campo “Id de UE” proporciona un identificador del UE sobre canales de transporte común. El campo de “Tipo de Id de UE” es necesario para garantizar una decodificación correcta del campo de Id de UE en Encabezamientos MAC. El campo de “C/T” se incluye en el encabezamiento MAC si se aplica el multiplexado por C/T en el MAC. El campo de “C/T” proporciona una identificación de la instancia del canal lógico cuando se transportan múltiples canales lógicos sobre el mismo canal de transporte. El campo de “C/T” se usa también para proporcionar una identificación del tipo de canal lógico sobre canales de transporte dedicados y sobre FACH (canal de acceso directo) y RACH (canal de acceso aleatorio) cuando se usan para la transmisión de datos de usuario. El tamaño del campo de “C/T” se fija a 4 bits tanto para canales de transporte común como para canales de transporte dedicados.

Para el primer aspecto, se presenta finalmente un ejemplo de cómo se pueden ajustar los valores de campos del encabezamiento de la trama FP en una trama de acuerdo con la estructura de trama de la figura 10, para dos modelos diferentes correspondientes a las memorias intermedias de RNC.

El primer modelo de almacenamiento temporal se ilustra en la figura 12. En esta alternativa, las últimas memorias intermedias de RNC antes de las memorias intermedias del Nodo B están situadas en la capa de RLC en el RNC.

La figura 12 muestra cinco de estas memorias intermedias de RNC 9, la memoria intermedia de RLC z, h, k, y, y u. La memoria intermedia de RLC z se asigna a los datos para un equipo de usuario UEx, más específicamente a un portador de radiocomunicaciones RBz usado para este UE. Da salida a datos con un nivel de prioridad r para su uso en una PDU RLC. Las memorias intermedias de RLC h y k se asignan al portador de radiocomunicaciones RBh y RBk respectivamente, que se usan los dos para el equipo de usuario UEy. No obstante, solamente la memoria intermedia k da salida a datos para su distribución a PDU RLC. Más específicamente, se proporcionan dos canales lógicos desde la capa de RLC por medio de la memoria intermedia k. A los datos se les asigna un nivel de prioridad m, y los datos se distribuyen a dos PDU RLC. Las memorias intermedias de RLC y y u se asignan al portador de radiocomunicaciones RBy y RBu respectivamente, que se usan los dos para el equipo de usuario UEz. La memoria intermedia v da salida a datos con un nivel de prioridad r para su uso en una PDU RLC. La memoria intermedia u da salida a datos con un nivel de prioridad de m, distribuyéndose dichos datos a tres PDU RLC. Cada PDU RLC se usará en la capa MAC como base para una SDU MAC -c/sh en una trama FP HSDPA ensamblada.

En el modelo de la figura 12, el valor del campo “NumOfBuff” se puede definir sobre la base de los RB. Esto significa que el valor del campo “NumOfBuff” es igual al número de RB, y, por lo tanto, al número de memorias intermedias de RLC 9, que proporcionan datos para la trama FP HSDPA. Así, en el ejemplo presentado, el valor del campo “NumOfBuff” de una trama de datos sobre la base de la estructura de trama de la figura 10 se ajusta a 4, puesto que

15

25

35

45

55

65 E01960691

20-10-2014

los datos se extraen de cuatro de las memorias intermedias de RNC, es decir, memorias intermedias de RLC z, k, y y u.

El valor del campo “NumOfSDUs" para la memoria intermedia de RLC z se fija a 1, puesto que, de esta memoria intermedia, se extrajeron solamente datos para una PDU RLC para la trama actual. Para la memoria intermedia de RLC k, el valor del campo “NumOfSDUs" se ajusta a 2, puesto que, de esta memoria intermedia, se extrajeron datos para dos PDU RLC para la trama actual. Para la memoria intermedia de RLC v, el valor del campo “NumOfSDUs" se ajusta nuevamente a 1, puesto que, de esta memoria intermedia, se extrajeron solamente datos para una PDU RLC para la trama actual. Para la memoria intermedia de RLC u, el valor del campo “NumOfSDUs" se ajusta a 3, puesto que, de esta memoria intermedia, se extrajeron datos para tres PDU RLC para la trama actual.

El valor de los campos “SizeOfSDUs" y “Tamaño de Memoria Intermedia de Usuario” se fijan a los valores aplicables respectivamente. En el ejemplo representado, el equipo de usuario UEy tiene una entidad de RLC desde la cual se proporcionan dos canales lógicos diferentes a la capa MAC, según se indica en la figura. Una configuración de este tipo es posible en un modo RLC con acuse de recibo. Incluso si se han recibido datos desde dos canales lógicos, es necesario combinar la información de tamaño de las memorias intermedias, lo cual significa que el campo “Tamaño de Memoria Intermedia de Usuario” contiene información sobre el estado de la memoria intermedia de RLC k.

El valor del campo “id de UE” para la memoria intermedia de RLC z se ajusta a x, puesto que los datos de esta memoria intermedia están destinados al UE x. El valor del campo “id de UE” para la memoria intermedia de RLC k se ajusta a y, puesto que los datos de esta memoria intermedia están destinados al UE y. El valor del campo “id de UE” para las memorias intermedias de RLC y y u se ajusta a z, puesto que los datos de estas memorias intermedias están destinados al UE z.

El valor del campo “CMCH-PI” para la memoria intermedia de RLC z y la memoria intermedia de RLC v respectivamente se ajusta a r, puesto que el nivel de prioridad para los datos extraídos de estas dos memorias intermedias se ajustó a r. El valor del campo “CMCH-PI” para la memoria intermedia de RLC k y la memoria intermedia de RLC u respectivamente a m, puesto que el nivel de prioridad para los datos extraídos de estas dos memorias intermedias se ajustó a m.

Otra manera de materializar las memorias intermedias de RNC es localizar las últimas memorias intermedias antes de las memorias intermedias del Nodo B en la capa MAC del RNC, por ejemplo, en el MAC -c/sh, lo cual se ilustra en la figura 13.

La figura 13 muestra nuevamente cinco memorias intermedias de capa RLC 10 de un RNC, la memoria intermedia de RLC z, h, k, v y u. No obstante, en este caso, hay presentes además cuatro memorias intermedias de capa MAC 11, la memoria intermedia de MAC z, h, k, y uv.

La memoria intermedia de RLC z se asigna nuevamente a un portador de radiocomunicaciones RBz usado para el equipo de usuario UEx. La memoria intermedia de RLC z da salida a datos con un nivel de prioridad p hacia la memoria intermedia de MAC z, de manera que dicha memoria intermedia de MAC da salida a datos para su uso en una SDU MAC. Las memorias intermedias de RLC h y k se asignan nuevamente al portador de radiocomunicaciones RBh y RBk respectivamente, los cuales son usados los dos por el equipo de usuario UEy. La memoria intermedia de RLC h está conectada a la memoria intermedia de MAC h, y la memoria intermedia de RLC k a la memoria intermedia de MAC k, aunque solamente la memoria intermedia de RLC k reenvía datos a la memoria intermedia de MAC k con un nivel de prioridad asignado de m. La memoria intermedia de MAC k da salida a datos que se van a distribuir en dos SDU MAC. Las memorias intermedias de RLC v y u se asignan nuevamente al portador de radiocomunicaciones RBy y RBu respectivamente, los cuales son usados ambos para el equipo de usuario UEz. Tanto la memoria intermedia de RLC v como la memoria intermedia de RLC u reenvían datos recibidos con el mismo nivel de prioridad r a la memoria intermedia de MAC uv. La memoria intermedia de MAC uv da salida a datos que se van a distribuir en cuatro SDU MAC.

En el modelo de almacenamiento temporal de acuerdo con la figura 13, el valor del campo “NumOfBuff” define el número de memorias intermedias de nivel MAC 11 desde las cuales se suministran datos a la trama de datos correspondiente FP HSDPA. Así, en el ejemplo presentado, el valor del campo “NumOfBuff” de una trama de datos sobre la base de la estructura de trama de la figura 10 se ajusta a 3, puesto que los datos se extraen de tres memorias intermedias de MAC, es decir, las memorias intermedias de MAC z, k, y vu.

El valor del campo “NumOfSDUs" para la memoria intermedia de MAC z se ajusta a 1, puesto que, de esta memoria intermedia, se extrajeron solamente datos para una SDU MAC, para la trama actual. Para la memoria intermedia de MAC k, el valor del campo “NumOfSDUs" se ajusta a 2, puesto que, de esta memoria intermedia, se extrajeron datos para dos SDU MAC, para la trama actual. Para la memoria intermedia de MAC uv, el valor del campo “NumOfSDUs" se ajusta a 4, puesto que, de esta memoria intermedia, se extrajeron datos para cuatro SDU MAC, para la trama actual.

Los valores de los campos “SizeOfSDUs" y “Tamaño de Memoria Intermedia de Usuario” se ajustan a los valores

15

25

35

45

55

65 E01960691

20-10-2014

aplicables respectivamente.

El valor del campo “id de UE” para la memoria intermedia de MAC z se ajusta a x, puesto que los datos de esta memoria intermedia están destinados al UE x. El valor del campo “id de UE” para la memoria intermedia de MAC k se ajusta a y, puesto que los datos de esta memoria intermedia están destinados al UE y. El valor del campo “id de UE” para la memoria intermedia de MAC uv se ajusta a z, puesto que los datos de esta memoria intermedia están destinados al UE z.

El valor del campo “CMCH-PI” para la memoria intermedia de MAC z se ajusta a p, puesto que el nivel de prioridad para datos proporcionados a esta memoria intermedia se ajustó a p. El valor del campo “CMCH-PI” para la memoria intermedia de MAC k se ajusta a m, puesto que el nivel de prioridad para datos proporcionados a esta memoria intermedia se ajustó a m. El valor del campo “CMCH-PI” para la memoria intermedia de MAC uv se ajusta a r, puesto que el nivel de prioridad para datos proporcionados a esta memoria intermedia se ajustó a r.

En el ejemplo de la figura 13, varios RB asignados al mismo UE pueden usar una memoria intermedia de MAC común 11, en caso de que presenten, por ejemplo, un valor de prioridad común. También sería posible usar una memoria intermedia de MAC común 11 para todos los RB que tienen un valor de prioridad común para la información de UE transmitida, con independencia del UE al cual se asignen los RB. Sin embargo, esto haría que el control del flujo resultase muchos más complejo.

En conjunto, se presentaron diferentes estructuras de tramas FP HSDPA de acuerdo con el primer aspecto, las cuales se pueden utilizar de manera ventajosa para diferentes situaciones con el fin de transmitir datos de usuario relacionados con el HSDPA junto con información adicional requerida, desde un RNC a un Nodo B de una UTRAN. Las estructuras de tramas presentadas se pueden modificar de cualquier manera adecuada con el fin de proporcionar una adaptación óptima a requisitos específicos.

A continuación, se presentará una forma de realización del segundo aspecto para una UTRAN con capacidad HSDPA que comprende un RNC y un Nodo B interconectados por medio de una interfaz Iub. En esta forma de realización, se proporciona un protocolo de aplicación de Iub que define varios IE que pueden ser añadidos por el RNC a mensajes de control seleccionados transmitidos por medio de la interfaz Iub al Nodo B, con el fin de posibilitar que el Nodo B configure el HSDPA.

La figura 14 muestra una tabla con un conjunto de nuevos IE de “Información de HS_DSCH” (“HS_DSCH Information”) semi-estáticos que comprenden parámetros relacionados con células, con información relacionada con HS-DSCH que puede ser usada por un Nodo B para configurar el HSDPA en una célula y las características de la HARQ implementada. La tabla tiene el formato de tablas usadas por el 3GPP para definir IE, por ejemplo, en la antes citada especificación técnica TS 25.433. Estas tablas comprenden una columna respectiva para un IE/Nombre de Grupo, los requisitos sobre la presencia del IE, un intervalo, un tipo y una referencia de IE, una descripción semántica, una criticidad, y una criticidad asignada. En la figura 14, se usa solamente la columna “IE/Nombre de Grupo”. Las otras columnas se pueden completar de acuerdo con los requisitos respectivos.

A un primer IE en el conjunto de la tabla de la figura 14 se le denomina “Conjuntos de MCS” (“MCS Sets”). Comprende los conjuntos de esquemas de modulación y codificación (MCS) de entre los cuales el Nodo B puede escoger cada TTI para las transmisiones.

A un segundo IE en este conjunto se le denomina “Nivel de Potencia de HS_DSCH” (“HS_DSCH Power Level”). Este IE define la relación entre el nivel de potencia de código del HS-DSCH y del CPICH (canal piloto común) en el caso de una NQAM (modulación de amplitud en cuadratura de n símbolos).

A un tercer IE en este conjunto se le denomina “NumOfCodes” que define el número de canales de código que se asignará a los HS-DSCH. El RNC puede asignar el número de canales de código para que una célula habilite la configuración de características del HS-DSCH.

A un cuarto IE en este conjunto se le denomina “Selección de TTI” (“TTI Selection”). La “Selección de TTI” incluye una información sobre la longitud del TTI que usará el Nodo B.

En la tabla se incluye además la “Información de HARQ” (“HARQ Information”), que es un grupo de IE que podría incluir varios IE específicos de la HARQ, dependiendo dichos IE de la implementación seleccionada de la HARQ. El grupo de “Información de HARQ” define información para configurar la HARQ en el Nodo B. Los parámetros de este grupo permiten que el RNC restrinja la capacidad del Nodo B. En la figura 14, el grupo de IE “Información de HARQ” incluye los IE “NumOfChannel”, “MaxAttempt” y “RedundancyVer”. En caso de que se use una HARQ SAW de n canales, se puede incluir el IE “NumOfChannel” para permitir que el RNC configure el número de canales. Por otra parte, suponiendo que el Nodo B puede rechazar una solicitud de retransmisión del UE después de una cierta cantidad e intentos, la inclusión del IE “MaxAttempt” permite que el RNC proporcione al Nodo B un número máximo de intentos, y a continuación el Nodo B puede decidir si rechazar o no una solicitud bajo esta limitación de acuerdo con sus propias condiciones. Finalmente, en caso de que se use un método de redundancia incremental en lugar de

15

25

35

45

55

65 E01960691

20-10-2014

un método de combinación flexible/de Chase, el IE “RedundancyVer” puede definir la restricción de versiones de redundancia de entre las cuales puede elegir el Nodo B.

Especialmente, el IE “NumOfCodes” y los IE pertenecientes al grupo de IE “Información de HARQ” proporcionan límites al Nodo B, pudiendo seleccionar dicho Nodo B el valor apropiado de manera dinámica de dentro del acotamiento fijado. También sería posible clasificar estos parámetros alternativamente como valor fijo y/o como valores específicos de RL.

Los IE descritos específicos de cada célula se pueden añadir al procedimiento ESTABLECIMIENTO DE CÉLULA (CELL SETUP) y al procedimiento RECONFIGURACIÓN DE CÉLULA (CELL RECONFIGURATION) y pueden ser incluidos por el RNC en mensajes de SOLICITUD DE ESTABLECIMIENTO DE CÉLULA (CELL SETUP REQUEST) y mensajes SOLICITUD DE RECONFIGURACIÓN DE CÉLULA (CELL RECONFIGURATION REQUEST) relacionados con el HSDPA, transmitidos por el RNC al Nodo B.

Las figuras 15 a 17 muestran, cada una de ellas, una tabla con un conjunto de IE que comprenden parámetros relacionados con el RL que pueden ser usados por el Nodo B para establecer y reconfigurar canales HS-DSCH. Los IE se pueden añadir en el procedimiento ESTABLECIMIENTO DE ENLACE DE RADIOCOMUNICACIONES (RADIO LINK SETUP) y en el procedimiento PREPARACIÓN DE RECONFIGURACIÓN DE ENLACE DE RADIOCOMUNICACIONES SINCRONIZADO (SYNCHRONIZED RADIO LINK RECONFIGURATION PREPARATION). Las tablas tienen el mismo formato que la tabla de la figura 14.

La tabla de la figura 15 solamente contiene un IE “ID de HS_DSCH” (“HS_DSCH ID”). Este IE identifica de manera exclusiva un HS-DSCH dentro de un Contexto de Comunicación de Nodo B.

La tabla de la figura 16 comprende IE de “Respuesta de Información de HS_DSCH” (“HS_DSCH Information Response”), que proporcionan para HS-DSCH que han sido establecidos o modificados. El intervalo de entradas para cada IE va desde 1 a los números máximos de HS-DSCH para un UE.

Un primer IE de este conjunto es nuevamente el IE “ID de HS_DSCH” ya mencionado, el cual se debería incluir obligatoriamente.

Un segundo IE de este conjunto es el denominado “ID de Vinculación” (“Binding ID”), y el mismo se puede incluir opcionalmente. El “ID de Vinculación” es el identificador de un flujo continuo de datos de usuario. Se asigna en el Nodo B y es exclusivo para cada portador de transporte bajo establecimiento en o desde el Nodo B. Así, el significado es el mismo que para el DSCH.

Un tercer IE de este conjunto es el denominado “Dirección de Capa de Transporte” (“Transporte Layer Address”) y el mismo también se puede incluir opcionalmente. Este IE define la dirección de transporte del Nodo B. El significado es por lo tanto el mismo que para el DSCH.

Los IE de la tabla de la figura 16 se pueden incluir en mensajes de RESPUESTA DE ESTABLECIMIENTO DE RADIOCOMUNICACIONES (RADIO SETUP RESPONSE) y en mensajes de RECONFIGURACIÓN DE ENLACE DE RADIOCOMUNICACIONES PREPARADA (RADIO LINK RECONFIGURATION READY).

La tabla de la figura 17 comprende IE “Información de FDD de HS_DSCH” (“HS_DSCH FDD Information”), que proporcionan información para HS-DSCH que van a ser establecidos. El intervalo de entradas para cada IE va nuevamente desde uno hasta los números máximos de HS-DSCH para un UE.

Un primer IE de este conjunto es nuevamente el IE antes mencionado “ID de HS_DSCH”.

Un segundo IE de este conjunto es el denominado “UE_ID” y el mismo se utiliza para permitir que el Nodo B distinga entre diferentes UE. Este IE se usará para rellenar el encabezamiento MAC. Puede ser la RNTI u otra cosa, por ejemplo, un tipo nuevo de indicación de identidad de equipo de usuario, que podría ser transparente para el UE.

Un tercer IE de este conjunto es el denominado “Conjunto de Formatos de Transporte” (“Transport Format Set”). El “Conjunto de Formatos de Transporte” se define como el conjunto de formatos de transporte asociados a un Canal de Transporte, por ejemplo, el HS-DSCH.

Un cuarto IE de este conjunto es el denominado “Prioridad de Asignación/Retención” (“Allocation/Retention Priority”). Este parámetro indica el nivel de prioridad en la asignación y retención de los recursos internos del Nodo B. El significado es por lo tanto el mismo que para el DSCH.

Un quinto IE de este conjunto es el denominado “Prioridad de Gestión de Tramas” (“Frame Handling Priority”). Este parámetro indica el nivel de prioridad que va a ser usado durante el tiempo de vida del HS-DSCH para restricciones temporales de los recursos asignados por motivos de sobrecarga. El significado es por lo tanto el mismo que para el DSCH.

10

15

20

25

30

35

40

45

50

55

60 E01960691

20-10-2014

Un sexto IE de este conjunto es el denominado “ToAWE”. El parámetro “ToAWE” es el tiempo de llegada del punto final de la ventana. Se espera que las tramas de datos de enlace descendente sean recibidas antes de este punto final de la ventana. El significado es por lo tanto el mismo que para el DSCH.

Un séptimo IE de este conjunto es el denominado “ToAWS”. El parámetro “ToAWS” es el tiempo de llegada de punto inicial de la ventana. Se espera que las tramas de datos de enlace descendente sean recibidas después de este punto inicial de la ventana. El significado es por lo tanto el mismo que para el DSCH.

Un octavo IE de este conjunto es el denominado “NumOfCodes” y ya se mencionó como posible parámetro basado en células. El RNC podría seleccionar el valor para este parámetro de acuerdo con la capacidad respectiva del UE.

Un noveno IE de este conjunto es el denominado “BufferStatus” y el mismo indica el estado actual de memorias intermedias de RNC. Este parámetro se puede usar en el comienzo de la conexión para el control del flujo.

Se incluye además en el conjunto la “Capacidad de HARQ” (“HARQ Capacity”), que es un grupo de IE que podría incluir varios IE específicos de la HARQ idénticos a los correspondientes del grupo “Información de HARQ” en la tabla de la figura 14. Sin embargo, aun cuando los nombres de IE son idénticos en el caso tanto específico de cada célula como específico del RL, los significados son ligeramente diferentes, puesto que, en el caso específico de cada célula, la “Información de HARQ” restringe la capacidad de la célula, mientras que en el caso específico del RL la “Capacidad de HARQ” refleja la QoS (Calidad de Servicio) del enlace de radiocomunicaciones o la capacidad del UE.

Los IE de esta tabla se pueden incluir en mensajes SOLICITUD DE ESTABLECIMIENTO DE ENLACE DE RADIOCOMUNICACIONES (RADIO LINK SETUP REQUEST) y en mensajes PREPARACIÓN DE RECONFIGURACIÓN DE ENLACE DE RADIOCOMUNICACIONES (RADIO LINK RECONFIGURATION PREPARE).

Se define otro conjunto de IE específico del HSDPA para Información de HS-DSCH que va a ser modificada. Este conjunto comprende un subconjunto del conjunto correspondiente a “Información de FDD de HS-DSCH”. Más específicamente, incluye los IE “ID de HS-DSCH”, “Conjunto de Formatos de Transporte”, “Prioridad de Asignación/Retención”, “Prioridad de Gestión de Tramas”, “ToAWS”, “ToAWE”, y “NumOfCodes”, y posiblemente los IE del grupo “Capacidad de HARQ”. Los IE de este conjunto se pueden incluir también en mensajes PREPARACIÓN DE RECONFIGURACIÓN DE ENLACE DE RADIOCOMUNICACIONES.

Muchos de los IE relacionados con el RL tienen un significado correspondiente igual que los IE relacionados con el DSCH presentados, por ejemplo, en la especificación técnica antes citada TS 25.433, que se incorpora a título de referencia a la presente y a la cual se hace remisión para obtener detalles adicionales.

El grupo de IE “Capacidad de HARQ” no es conocido para el DSCH, y el mismo indica características de HARQ de un RL, y también podría reflejar las capacidades del UE y/o la QoS del RL.

Por otra parte, el IE “UE_ID” se añadió como parámetro nuevo, con el fin de ayudar a completar el encabezamiento MAC en el Nodo B. Si en el encabezamiento MAC no se incluye o necesita ningún ID, este parámetro se puede usar alternativamente en la capa de FP con la misma finalidad.

El IE “Conjunto de Formatos de Transporte” es muy similar al IE correspondiente para el DSCH, aunque, para algunos IE, se definirán nuevos valores para prestar soportar al HS-DSCH. Esto se indica en la figura 18, que muestra una tabla para el conjunto de formatos de transporte del DSCH, tomada de la especificación antes citada TS 25.433 con algunas modificaciones subrayadas.

Más específicamente, se añaden algunos valores posibles más para el IE “Intervalo de tiempo de transmisión”, a saber “1slot”, “3slot”, “5slot”, y “15slot”. Estos valores se deben usar para el HS-DSCH únicamente y ningún otro valor será aplicable en el HD-DSCH. Adicionalmente, el valor “Convolucional” (“Convolutional”) no se debería usar en el IE “Tipo de codificación de canal” para HSDPA.

Así, en la forma de realización presentada del segundo aspecto, se definen IE básicos que se pueden proporcionar durante el establecimiento y la reconfiguración de las células y el establecimiento y la reconfiguración de RL con el fin de prestar soporte al HSDPA. Los conjuntos descritos de IE y los propios IE se pueden modificar de cualquier manera adecuada con el fin de adaptarse a requisitos específicos. Asimismo, se pueden definir otros conjuntos de IE en el protocolo de aplicación de la Iub con el fin de permitir cualquier transferencia requerida de información de control relacionada con el HSDPA.

Claims (20)

1. E01960691

   20-10-2014

   REIVINDICACIONES

   1. Método para proporcionar a un elemento de red (5) de una red de comunicaciones unos parámetros de control disponibles en un controlador de red de radiocomunicaciones (4) de dicha red de comunicaciones, estando

   5 conectado dicho controlador de red de radiocomunicaciones (4) a dicho elemento de red (5) por medio de una interfaz, comprendiendo dicho método utilizar un protocolo de aplicación de interfaz que permite una inserción de parámetros de control en un mensaje de control asociado a un canal compartido de enlace descendente de alta velocidad y transmitido desde dicho controlador de red de radiocomunicaciones (4) a dicho elemento de red (5) a través de dicha interfaz, siendo dicho mensaje de control uno de entre un mensaje de SOLICITUD DE ESTABLECIMIENTO DE ENLACE DE RADIOCOMUNICACIONES y un mensaje de PREPARACIÓN DE RECONFIGURACIÓN DE ENLACE DE RADIOCOMUNICACIONES, y comprendiendo dichos parámetros de control para la inserción en dicho mensaje de control por lo menos los siguientes parámetros de control específicos del enlace de radiocomunicaciones:

   15 -la identidad de un canal compartido de enlace descendente de alta velocidad que va a ser usado en ese momento por dicho elemento de red (5) para una transmisión de enlace descendente;

   -una prioridad de asignación y/o retención que indica un nivel de prioridad en la asignación y/o retención de recursos internos de dicho elemento de red (5);

   -una prioridad de gestión de tramas que indica un nivel de prioridad que va a ser usado por dicho elemento de red (5) durante el tiempo de vida de un canal compartido de enlace descendente de alta velocidad para restricciones temporales de recursos asignados debido a un motivo de sobrecarga; y

   25 -uno o más parámetros que serán usados en ese momento por dicho elemento de red (5) para configurar una solicitud automática de repetición híbrida, implementada en dicho elemento de red (5).

2. 2.

   Método según la reivindicación 1, en el que dicha red de comunicaciones es una red de acceso por radiocomunicaciones terrestre de servicios universales de telecomunicaciones móviles, siendo dicho elemento de red un Nodo B, y siendo dicha interfaz una interfaz Iub.

3. 3.

   Método según una de las reivindicaciones 1 y 2, en el que el contenido de por lo menos uno de entre dichos parámetros de control es un valor fijo, un valor limitativo o una secuencia de valores permitidos para ser usados por dicho elemento de red (5).

   35

4. 4.

   Método según una de las reivindicaciones 1 a 3, en el que dichos parámetros de control están comprendidos en unos elementos de información y están insertados en un mensaje de control añadiendo dichos elementos de información a un mensaje de control transmitido desde dicho controlador (4) a dicho elemento de red (5) a través de dicha interfaz.

5. 5.

   Método según una de las reivindicaciones anteriores, en el que dichos parámetros de control específicos del enlace de radiocomunicaciones comprenden además para su inserción en dicho mensaje de control por lo menos uno de los siguientes parámetros:

   45 -una identidad de vinculación que identifica el flujo continuo de datos de usuario que va a ser transmitido en ese momento por dicho elemento de red (5); y

   -una dirección de capa de transporte que define la dirección de transporte actual de dicho elemento de red (5).
6. 6. Método según una de las reivindicaciones anteriores, en el que dichos parámetros de control específicos del enlace de radiocomunicaciones comprenden además para su inserción en dicho mensaje de control por lo menos uno de los siguientes parámetros:

   -la identidad de un equipo de usuario al cual datos de usuario van a ser transmitidos por dicho elemento de 55 red (5);

   -un conjunto de formatos de transporte que serán usados en ese momento por dicho elemento de red (5);

   -un tiempo de llegada de un punto inicial de ventana después del cual se espera que se reciban tramas de datos de enlace descendente en dicho elemento de red (5);

   -un tiempo de llegada de un punto final de ventana antes del cual se espera que se reciban tramas de datos de enlace descendente en dicho elemento de red (5);

   65 -el número de canales de código que se asignan en ese momento a un canal usado por dicho elemento de red (5); y

   5

   15

   25

   35

   45

   55

   65 E01960691

   20-10-2014

   -un estado de memoria intermedia que indica un estado actual de memorias intermedias de dicho controlador (4).

7. 7.

   Método según una de las reivindicaciones anteriores, en el que dicho uno o más parámetros que van a ser usados por dicho elemento de red (5) para configurar una solicitud automática de repetición híbrida, incluye por lo menos uno de entre el número de canales que van a ser usados para una solicitud automática de repetición híbrida, un número permitido máximo de intentos para una solicitud automática de repetición híbrida, y restricciones de versiones de redundancia de entre las cuales dicho elemento de red (5) puede elegir.

8. 8.

   Red de comunicaciones, que comprende por lo menos un controlador de red de radiocomunicaciones (4) y por lo menos un elemento de red (5), estando conectados dicho controlador de red de radiocomunicaciones (4) y dicho elemento de red (5) entre sí por medio de una interfaz, comprendiendo dicha red de comunicaciones además una implementación de un protocolo de aplicación de interfaz que permite que dicho controlador de red de radiocomunicaciones (4) proporcione a dicho elemento de red (5) unos parámetros de control insertando dichos parámetros de control en un mensaje de control asociado a un canal compartido de enlace descendente de alta velocidad y transmitido desde dicho controlador de red de radiocomunicaciones (4) a dicho elemento de red (5) a través de dicha interfaz, siendo dicho mensaje de control uno de entre un mensaje de SOLICITUD DE ESTABLECIMIENTO DE ENLACE DE RADIOCOMUNICACIONES y un mensaje de PREPARACIÓN DE RECONFIGURACIÓN DE ENLACE DE RADIOCOMUNICACIONES, y comprendiendo dichos parámetros de control para la inserción en dicho mensaje de control por lo menos los siguientes parámetros de control específicos del enlace de radiocomunicaciones:

   -la identidad de un canal compartido de enlace descendente de alta velocidad que va a ser usado en ese momento por dicho elemento de red (5) para una transmisión de enlace descendente;

   -una prioridad de asignación y/o retención que indica un nivel de prioridad en la asignación y/o retención de recursos internos de dicho elemento de red (5);

   -una prioridad de gestión de tramas que indica un nivel de prioridad que va a ser usado por dicho elemento de red (5) durante el tiempo de vida de un canal compartido de enlace descendente de alta velocidad para restricciones temporales de recursos asignados debido a un motivo de sobrecarga; y

   -uno o más parámetros que serán usados en ese momento por dicho elemento de red (5) para configurar una solicitud automática de repetición híbrida, implementada en dicho elemento de red (5).

9. 9.

   Red de comunicaciones según la reivindicación 8, en la que dicha red de comunicaciones es una red de acceso por radiocomunicaciones terrestre de servicios universales de telecomunicaciones móviles, siendo dicho elemento de red un Nodo B (5), siendo dicha interfaz una interfaz Iub.

10. 10.

    Controlador de red de radiocomunicaciones (4) para una red de comunicaciones, comprendiendo dicho controlador de red de radiocomunicaciones (4) unos medios para proporcionar a un elemento de red (5) de dicha red de comunicaciones, por medio de una interfaz, de acuerdo con un protocolo de aplicación de interfaz, unos parámetros de control insertando dichos parámetros de control en un mensaje de control asociado a un canal compartido de enlace descendente de alta velocidad y transmitido desde dicho controlador de red de radiocomunicaciones (4) a dicho elemento de red (5) a través de dicha interfaz, siendo dicho mensaje de control uno de entre un mensaje de SOLICITUD DE ESTABLECIMIENTO DE ENLACE DE RADIOCOMUNICACIONES y un mensaje de PREPARACIÓN DE RECONFIGURACIÓN DE ENLACE DE RADIOCOMUNICACIONES, y comprendiendo dichos parámetros de control para la inserción en dicho mensaje de control por lo menos los siguientes parámetros de control específicos del enlace de radiocomunicaciones:

    -la identidad de un canal compartido de enlace descendente de alta velocidad que va a ser usado en ese momento por dicho elemento de red (5) para una transmisión de enlace descendente;

    -una prioridad de asignación y/o retención que indica un nivel de prioridad en la asignación y/o retención de recursos internos de dicho elemento de red (5);

    -una prioridad de gestión de tramas que indica un nivel de prioridad que va a ser usado por dicho elemento de red (5) durante el tiempo de vida de un canal compartido de enlace descendente de alta velocidad para restricciones temporales de recursos asignados debido a un motivo de sobrecarga; y

    -uno o más parámetros que serán usados en ese momento por dicho elemento de red (5) para configurar una solicitud automática de repetición híbrida, implementada en dicho elemento de red (5).
11. 11. Controlador de red de radiocomunicaciones (4) según la reivindicación 10, en el que dicho controlador de red de radiocomunicaciones es un controlador de red de radiocomunicaciones de una red de acceso de

    5

    15

    25

    35

    45

    55

    65 E01960691

    20-10-2014

    radiocomunicaciones terrestre de servicios universales de telecomunicaciones móviles.

12. 12.

    Controlador de red de radiocomunicaciones (4) según una de las reivindicaciones 10 y 11, en el que el contenido de por lo menos uno de dichos parámetros de control es un valor fijo, un valor limitativo o una secuencia de valores permitidos para ser usados por dicho elemento de red (5).

13. 13.

    Controlador de red de radiocomunicaciones (4) según una de las reivindicaciones 10 a 12, en el que dichos parámetros de control están comprendidos en unos elementos de información y estando dichos medios configurados para insertar dichos parámetros de control en un mensaje de control añadiendo dichos elementos de información a dicho mensaje de control.

14. 14.

    Controlador de red de radiocomunicaciones (4) según una de las reivindicaciones 10 a 13, en el que dichos parámetros de control específicos del enlace de radiocomunicaciones comprenden además, para su inserción en dicho mensaje de control, por lo menos uno de los siguientes parámetros:

    -una identidad de vinculación que identifica el flujo continuo de datos de usuario que va a ser transmitido en ese momento por dicho elemento de red (5); y

    -una dirección de capa de transporte que define la dirección de transporte actual de dicho elemento de red (5).
15. 15. Controlador de red de radiocomunicaciones (4) según una de las reivindicaciones 10 a 14, en el que dichos parámetros de control específicos del enlace de radiocomunicaciones comprenden además para su inserción en dicho mensaje de control por lo menos uno de los siguientes parámetros:

    -la identidad de un equipo de usuario al cual dicho elemento de red (5) va a transmitir datos de usuario;

    -un conjunto de formatos de transporte que serán usados en ese momento por dicho elemento de red (5);

    -un tiempo de llegada de un punto inicial de ventana después del cual se espera que se reciban tramas de datos de enlace descendente en dicho elemento de red (5);

    -un tiempo de llegada de un punto final de ventana antes del cual se espera que se reciban tramas de datos de enlace descendente en dicho elemento de red (5);

    -el número de canales de código que se asignan en ese momento a un canal usado por dicho elemento de red (5); y

    -un estado de memoria intermedia que indica un estado actual de memorias intermedias de dicho controlador (4).

16. 16.

    Controlador de red de radiocomunicaciones (4) según una de las reivindicaciones 10 a 15, en el que dicho uno o más parámetros que van a ser usados por dicho elemento de red (5) para configurar una solicitud automática de repetición híbrida, incluye por lo menos uno de entre el número de canales que van a ser usados para una solicitud automática de repetición híbrida, un número permitido máximo de intentos para una solicitud automática de repetición híbrida, y restricciones de versiones de redundancia de entre las cuales dicho elemento de red (5) puede elegir.

17. 17.

    Elemento de red (5) para una red de comunicaciones, que comprende unos medios para recibir unos mensajes de control asociados a un canal compartido de enlace descendente de alta velocidad desde un controlador de red de radiocomunicaciones (4) de dicha red de comunicaciones por medio de una interfaz, y para extraer parámetros de control de un mensaje de control recibido, en el cual los parámetros de control fueron insertados por dicho controlador de red de radiocomunicaciones (4) de acuerdo con un protocolo de aplicación de interfaz, siendo dicho mensaje de control uno de entre un mensaje de SOLICITUD DE ESTABLECIMIENTO DE ENLACE DE RADIOCOMUNICACIONES y un mensaje de PREPARACIÓN DE RECONFIGURACIÓN DE ENLACE DE RADIOCOMUNICACIONES, y comprendiendo dichos parámetros de control insertados en dicho mensaje de control por lo menos los siguientes parámetros de control específicos del enlace de radiocomunicaciones:

    -la identidad de un canal compartido de enlace descendente de alta velocidad que va a ser usado en ese momento por dicho elemento de red (5) para una transmisión de enlace descendente;

    -una prioridad de asignación y/o retención que indica un nivel de prioridad en la asignación y/o retención de recursos internos de dicho elemento de red (5);

    -una prioridad de gestión de tramas que indica un nivel de prioridad que va a ser usado por dicho elemento de red (5) durante el tiempo de vida de un canal compartido de enlace descendente de alta velocidad para restricciones temporales de recursos asignados debido a un motivo de sobrecarga; y

    E01960691

    20-10-2014

    -uno o más parámetros que serán usados en ese momento por dicho elemento de red (5) para configurar una solicitud automática de repetición híbrida, implementada en dicho elemento de red (5).

    5 18. Elemento de red (5) según la reivindicación 17, en el que dicho elemento de red es un Nodo B de una red de acceso de radiocomunicaciones terrestre de servicios universales de telecomunicaciones móviles.
18. 19. Elemento de red (5) según una de las reivindicaciones 17 y 18, en el que el contenido de por lo menos uno de

    dichos parámetros de control es un valor fijo, un valor limitativo o una secuencia de valores permitidos para ser 10 usados por dicho elemento de red (5).
19. 20. Elemento de red (5) según una de las reivindicaciones 17 a 19, en el que dichos parámetros de control están comprendidos en por lo menos un elemento de información y han sido insertados en un mensaje de control añadiendo dicho por lo menos un elemento de información en un mensaje de control transmitido desde dicho

    15 controlador de red de radiocomunicaciones (4) a dicho elemento de red (5) a través de dicha interfaz.
20. 21. Elemento de red (5) según una de las reivindicaciones 17 a 20, en el que dichos parámetros de control comprenden además, insertados en dicho mensaje de control, por lo menos uno de los siguientes parámetros:

    20 -una identidad de vinculación que identifica el flujo continuo de datos de usuario que va a ser transmitido en ese momento por dicho elemento de red (5); y

    -una dirección de capa de transporte que define la dirección de transporte actual de dicho elemento de red (5).

    25 22. Elemento de red (5) según una de las reivindicaciones 17 a 21, en el que dichos parámetros de control comprenden además, insertados en dicho mensaje de control, por lo menos uno de los siguientes parámetros:

    -la identidad de un equipo de usuario al cual datos de usuario van a ser transmitidos por dicho elemento de red (5); 30 -un conjunto de formatos de transporte que serán usados en ese momento por dicho elemento de red (5);

    -un tiempo de llegada de un punto inicial de ventana después del cual se espera que se reciban tramas de datos de enlace descendente en dicho elemento de red (5); 35 -un tiempo de llegada de un punto final de ventana antes del cual se espera que se reciban tramas de datos de enlace descendente en dicho elemento de red (5);

    -el número de canales de código que se asignan en ese momento a un canal usado por dicho elemento de red 40 (5); y

    -un estado de memoria intermedia que indica un estado actual de memorias intermedias de dicho controlador (4).

    45 23. Elemento de red (5) según una de las reivindicaciones 17 a 22, en el que dicho uno o más parámetros que van a ser usados por dicho elemento de red (5) para configurar una solicitud automática de repetición híbrida incluye por lo menos uno de entre el número de canales que van a ser usados para una solicitud automática de repetición híbrida, un número permitido máximo de intentos para una solicitud automática de repetición híbrida, y restricciones de versiones de redundancia de entre las cuales dicho elemento de red (5) puede elegir.