ES2316874T3 - Planificacion de transmision de datos a traves de capa de control de acceso al medio (mac) en una red de telefonia celular. - Google Patents
Planificacion de transmision de datos a traves de capa de control de acceso al medio (mac) en una red de telefonia celular. Download PDFInfo
- Publication number
- ES2316874T3 ES2316874T3 ES03814239T ES03814239T ES2316874T3 ES 2316874 T3 ES2316874 T3 ES 2316874T3 ES 03814239 T ES03814239 T ES 03814239T ES 03814239 T ES03814239 T ES 03814239T ES 2316874 T3 ES2316874 T3 ES 2316874T3
- Authority
- ES
- Spain
- Prior art keywords
- tfc
- mac
- power
- transmission
- time interval
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 230000005540 biological transmission Effects 0.000 title claims abstract description 76
- 238000000034 method Methods 0.000 claims abstract description 41
- 238000004891 communication Methods 0.000 claims abstract description 9
- 239000002131 composite material Substances 0.000 claims abstract description 8
- 230000002457 bidirectional effect Effects 0.000 claims description 5
- 230000015572 biosynthetic process Effects 0.000 claims 1
- 238000001514 detection method Methods 0.000 claims 1
- 230000000903 blocking effect Effects 0.000 description 10
- 238000011282 treatment Methods 0.000 description 9
- 238000010187 selection method Methods 0.000 description 7
- ZIIRLFNUZROIBX-UHFFFAOYSA-N 2,3,5-trichlorobenzene-1,4-diol Chemical compound OC1=CC(Cl)=C(O)C(Cl)=C1Cl ZIIRLFNUZROIBX-UHFFFAOYSA-N 0.000 description 6
- 238000012545 processing Methods 0.000 description 6
- 230000011218 segmentation Effects 0.000 description 6
- 238000010586 diagram Methods 0.000 description 4
- 238000011369 optimal treatment Methods 0.000 description 4
- 238000013459 approach Methods 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 108700026140 MAC combination Proteins 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 150000001875 compounds Chemical class 0.000 description 1
- 239000000945 filler Substances 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- UOJMTSCORVQOHS-UHFFFAOYSA-N pachypodol Natural products COc1cc(ccc1O)C2=C(C)C(=O)c3c(O)cc(C)cc3O2 UOJMTSCORVQOHS-UHFFFAOYSA-N 0.000 description 1
- 230000035515 penetration Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 125000002306 tributylsilyl group Chemical group C(CCC)[Si](CCCC)(CCCC)* 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/12—Wireless traffic scheduling
- H04W72/1263—Mapping of traffic onto schedule, e.g. scheduled allocation or multiplexing of flows
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
- H04L47/2433—Allocation of priorities to traffic types
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L5/00—Arrangements affording multiple use of the transmission path
- H04L5/14—Two-way operation using the same type of signal, i.e. duplex
- H04L5/1469—Two-way operation using the same type of signal, i.e. duplex using time-sharing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
- H04W28/065—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information using assembly or disassembly of packets
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W52/00—Power management, e.g. Transmission Power Control [TPC] or power classes
- H04W52/04—Transmission power control [TPC]
- H04W52/30—Transmission power control [TPC] using constraints in the total amount of available transmission power
- H04W52/36—Transmission power control [TPC] using constraints in the total amount of available transmission power with a discrete range or set of values, e.g. step size, ramping or offsets
- H04W52/367—Power values between minimum and maximum limits, e.g. dynamic range
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/04—Wireless resource allocation
- H04W72/044—Wireless resource allocation based on the type of the allocated resource
- H04W72/0446—Resources in time domain, e.g. slots or frames
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/12—Wireless traffic scheduling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/50—Allocation or scheduling criteria for wireless resources
- H04W72/56—Allocation or scheduling criteria for wireless resources based on priority criteria
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/10—Flow control between communication endpoints
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
- H04W84/04—Large scale networks; Deep hierarchical networks
- H04W84/042—Public Land Mobile systems, e.g. cellular systems
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Mobile Radio Communication Systems (AREA)
- Small-Scale Networks (AREA)
- Communication Control (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
Abstract
Un método para planificar la transmisión de datos en una red de comunicación por radio que elimina una necesidad de determinar los requisitos de potencia para cada combinación de formato de transporte (TFC) en cada intervalo de tiempo, incluyendo la citada red al menos una capa física y una capa de Medium Access Control (MAC) (Control de Acceso Medio), que comprende: la citada capa física: que monitoriza la potencia de transmisión en un intervalo de tiempo; y que envía una notificación a la capa de MAC de que se ha alcanzado la máxima potencia, junto con el número de intervalo de tiempo; la citada capa de MAC: que determina qué Coded Composite Transport Channels (CCTrCHs) (Canales de Transporte Compuesto Codificados) han asignado códigos en el intervalo de tiempo que alcanza la máxima potencia; que marca que tales CCTrCHs han alcanzado la máxima potencia; y que limita un conjunto de Transport Format Combination (TFC) (Combinación de Formato de Transporte) a un conjunto de TFC mínimo en el límite del siguiente Common Transmit Time Interval (TTI) (Intervalo de Tiempo de Transmisión Común).
Description
Planificación de transmisión de datos a través
de capa de control de acceso al medio (MAC) en una red de telefonía
celular.
Esta invención se refiere generalmente a los
procedimientos utilizados por la Capa de MAC para planificar la
transmisión de datos. Más particularmente, la invención se refiere a
un método y algoritmo para la transmisión de datos en una red de
UMTS.
En un Third Generation Partnership Project
Universal Mobile Telecommunications System (3GPP UMTS) (Sistema de
Telecomunicaciones Móviles Universal mediante el Proyecto de
Asociación de Tercera Generación), la capa de MAC en el User
Equipment (UE) (Equipo de Usuario) y en el Radio Network Controller
(RNC) (Controlador de Red de Radio) es responsable de la
planificación de la transmisión de datos en el enlace ascendente y
en el enlace descendente respectivamente. Los canales de transporte
forman la interfaz entre la capa de MAC y la capa física. En la
capa física, un conjunto de canales de transporte es combinado para
formar un Coded Composite Transport Channel (CCTrCH) (Canal de
Transporte Compuesto Codificado).
La solicitud de patente europea con número de
publicación EP 1 349 332 describe un método para minimizar el
tiempo de búsqueda para la selección de un formato de transporte en
un sistema de comunicación CDMA que incluye una capa de RLC y una
capa de MAC. La entidad de la capa de RLC contiene una pluralidad de
canales lógicos y transmite datos de entrada a la capa de MAC a
través de un canal lógico específico de entre los canales lógicos.
La capa de MAC contiene una pluralidad de canales de transporte y
transmite los datos de entrada a una capa física a través de un
canal de transporte específico de entre los canales de transporte.
Los formatos de transporte son generados para los canales de
transporte, y clasificados de acuerdo con los tamaños de datos que
pueden ser transmitidos por canales de transporte correspondientes.
Se proporciona un indicador a cada uno de los formatos de
transporte clasificados de acuerdo con el tamaño de los datos, y se
generan una pluralidad de tablas de subconjunto. Cuando los datos
son introducidos en la capa de MAC, después de que las tablas de
subconjunto son generadas, se detecta una tabla de subconjunto que
tiene el mismo tamaño que los datos introducidos en la capa de MAC,
y se selecciona un formato de transporte que corresponde a un
indicador específico.
Un Transport Format Combination Set (TFCS)
(Conjunto de Combinación de Formato de Transporte) es definido para
cada CCTrCH. Cada Transport Format Combination (TFC) (Combinación de
Formato de Transporte) define un Transport Format (TF) (Formato de
Transporte) para cada canal de transporte del CCTrCH. El TF define
la tasa de datos de un canal de transporte estableciendo el
Transmission Time Interval (TTI) (Intervalo de Tiempo de
Transmisión) (en ms), tamaño del Transport Block (TB) (Bloque de
Transporte) (en bits) y el tamaño del Transport Block Set (TBS)
(Conjunto de Bloques de Transporte) (en número de bloques).
Un TB es la unidad básica intercambiada entre
las capas de MAC y física. Un TBS se define como un conjunto de
TBs, que son intercambiados entre las capas física y de MAC al mismo
tiempo y que usan el mismo canal de transporte. El TTI se define
como el tiempo entre llegadas de TBSs. Un TTI es igual a la
periodicidad a la cual un TBS es transferido desde la capa de MAC a
la capa física y a continuación a través de la capa física al
interfaz de radio.
El MAC obtiene datos de la capa de Radio Link
Control (RLC) (Control de Enlace de Radio). El interfaz entre la
capa de MAC y la capa de RLC está formado por canales lógicos, Radio
Bearers (RB) (Portadores de Radio). Cada canal de transporte puede
transportar más de un RB. El RLC mantiene una memoria temporal para
cada RB; cada memoria temporal contiene un conjunto de Service Data
Units (SDUs) (Unidades de Datos de Servicio) de RLC. Algunas
configuraciones de RLC (pero no todas) permiten la segmentación de
SDUs en Protocol Data Units (PDUs) (Unidades de Datos de
Protocolo), algunas permiten la concatenación de SDUs para construir
PDUs y algunas permiten el uso de PDUs de relleno. En la capa de
MAC, puede añadirse una cabecera de MAC a la PDU para formar un
TB.
La capa de MAC selecciona los tamaños de PDU
para un TTI dado y solicita estas PDUs de la capa de RLC. El RLC
entonces segmenta y/o concatena las SDUs con el fin de satisfacer la
solicitud del MAC. El MAC construye a continuación los TBs y envía
los TBs a la capa física para ser enviados por el aire en el
siguiente TTI.
En el lado del UE, con el fin de llevar a cabo
la selección de la TFC, existen algunos requisitos estándar que
pueden ser cumplidos por el UE. Estos requisitos se resumen a
continuación.
Es deseable proporcionar un método para la
selección de la TFC, que obvia la necesidad de que el MAC tenga que
determinar la potencia que necesita cada TFC en cada intervalo de
tiempo.
\newpage
Esta invención proporciona un método y un
algoritmo para la selección de la TFC en el cual la necesidad de
que el MAC determine la potencia necesitada por cada TFC en cada
intervalo de tiempo es obviada. La siguiente descripción expone el
procedimiento del MAC para planificar la transmisión de datos en el
que la planificación puede implicar la selección de una TFC para
usarse y la selección de RBs a los que se va a dar servicio.
Se explican tanto los lados del UE como del
Serving-RNC (S-RNC) (Controlador de
Red de Radio - de Servicio) de una red Time Division Duplex (TDD)
(Bidireccional por División de Tiempo) de Universal Mobile
Telecommunication Service (UMTS) (Servicio de Telecomunicación
Móvil Universal). En particular, se presentan las estrategias para
la selección de la TFC y los algoritmos correspondientes.
Antes de seleccionar una TFC, debe establecerse
un conjunto de TFCs válidas. Este conjunto se denomina el conjunto
candidato. Todas las TFCs del conjunto candidato deben satisfacer
generalmente las siguientes seis (6) reglas: 1) pertenecer al TFCS;
2) no transportar más bits de los que pueden ser transmitidos en un
TTI; 3) respetar la compatibilidad de TTI (es decir, el TF de un
TrCH no puede cambiar en medio del TTI del TrCH; 4) no estar en el
estado bloqueado, como se define a continuación; 5) ser compatibles
con la configuración del RLC; y 6) no requerir un RLC para producir
PDUs de relleno. Si todas las TFCs en el TFCS requieren PDUs de
relleno, este último requisito puede ser ignorado. La presente
invención proporciona soluciones para los últimos tres (3)
requisitos.
El criterio bloqueante se define como sigue:
En el caso de un único CCTrCH o múltiples
CCTrCHs que tienen mutuamente asignaciones de intervalo de tiempo
exclusivo, el UE considera el criterio bloqueante para una TFC dada
de un CCTrCH que debe cumplirse si, para tres (3) tramas sucesivas,
la potencia de transmisión del UE estimada es mayor que la potencia
transmisora del UE máxima para al menos un intervalo de tiempo
asociado con el CCTrCH en cada trama.
En el caso de CCTrCH múltiples que no tienen
asignaciones de intervalo de tiempo exclusivas mutuamente, si, para
un CCTrCH dado para tres (3) tramas sucesivas, la potencia de
transmisión del UE estimada es mayor que la potencia transmisora
del UE máxima para al menos un intervalo de tiempo asociado con el
CCTrCH en cada trama, el UE considera el criterio bloqueante que
debe cumplirse para una TFC dada si el uso de esta TFC provoca que
la potencia transmitida del UE estimada continúe siendo mayor que la
potencia transmisora del UE máxima en al menos un intervalo de
tiempo asociado con el CCTrCH.
Por lo que respecta al criterio no bloqueante,
el UE no debe considerar el criterio no bloqueante que debe cumplir
una TFC dada (que ha sido bloqueada) hasta que el uso de esta TFC
haga que la potencia transmitida del UE estimada sea mayor que la
potencia transmisora del UE máxima para todos los intervalo de
tiempo de Uplink (UL) (Enlace Ascendente) asociados con la TFC para
un mínimo de tres (3) tramas sucesivas. El número de las citadas
tramas sucesivas puede ser mayor o menor de tres (3) sin separarse
del ámbito de la invención. Por ejemplo, el número de tramas
sucesivas podría ser tan pequeño como dos (2) o cuatro (4) o más,
prefiriéndose tres (3) tramas consecutivas. Este es también el caso
para todos los criterios subsiguientes para disposiciones de
intervalo de tiempo exclusivo mutuamente para UEs y
S-RNCs.
El MAC está dividido en MAC-c y
MAC-d. El MAC-c es responsable de
canales comunes y el MAC-d es responsable de
canales dedicados. En el lado del UE, hay una única TFC definida
para el canal común, y por consiguiente la selección de TFC no
aplica en el MAC-c del UE. En el lado del RNC, la
selección de la TFC se realiza en MAC-c y
MAC-d.
La configuración del RLC juega un importante
papel durante la selección de la TFC. Dependiendo de la cantidad de
datos disponibles para transmisión, algunas TFCs en el TFCS pueden
no estar conformes con la configuración del RLC.
La compatibilidad de relleno (es decir, la
necesidad de PDUs de relleno) es un problema de la configuración
del RLC. Para comprobar la compatibilidad de relleno se necesita
comprobar si una TFC requiere PDUs de relleno para un canal de
transporte que lleva sólo canales lógicos que no puede proporcionar
PDUs de relleno, (es decir, canales lógicos en
RLC-TM (modo transparente)). Si es así, entonces la
TFC es incompatible con la configuración del RLC y se considera no
válida.
Obsérvese que existen otros requisitos relativos
a la configuración del RLC. Sin embargo, estos requisitos son
comprobados durante el propio procedimiento de selección de TFC.
Debido a que el procedimiento de selección de TFC maximiza la
capacidad de tratamiento de los datos de alta prioridad, el
procedimiento de selección de TFC se lleva a cabo en orden de
prioridad de canal lógico, y no por canal de transporte. De este
modo, si el requisito de compatibilidad de relleno no fuese
satisfecho, todo el procedimiento necesitaría repetirse (sin la TFC
seleccionada) con el fin de obtener una TFC válida. Es por lo que la
compatibilidad de relleno es comprobada antes de llevar a cabo la
selección de TFC, por lo que se reduce el conjunto candidato de
TFC.
La comprobación para la compatibilidad de PDU de
relleno debe realizarse preferiblemente para cada TFC basándose en
la ocupación de memoria temporal de los canales lógicos mapeados a
ese canal de transporte y el TF para ese canal de transporte. La
comprobación de la compatibilidad de PDU de relleno se lleva a cabo
sólo en canales lógicos configurados para modo transparente
(RLC-TM).
El TF determina el número de TBs y el tamaño del
TB que se necesita. La primera etapa es determinar cuántas PDUs
pueden ser generadas por todos los canales lógicos en ese canal de
transporte. Esta determinación debe considerar el tamaño del TB y
si la segmentación está permitida o no en cada canal lógico, y
comprende las siguientes etapas:
a) Si la segmentación está permitida en el canal
lógico, entonces calcular n:
donde n=SDUsize/TBsize,
y comprobar si n es un número entero (que
significa que el número de PDUs multiplicado por el tamaño de la PDU
es igual al tamaño de la SDU).
- i.
- si es sí, entonces el número de PDUs para ese canal lógico es igual a n
- ii.
- si es no, entonces el número de PDUs para ese canal lógico es igual a cero.
\vskip1.000000\baselineskip
b) Si la segmentación no está permitida,
comprobar si el tamaño de la SDU es igual al tamaño del TB.
- i.
- si es sí, el número de PDUs para ese canal lógico es igual al número total de SDUs en ese canal lógico disponibles para su transmisión.
- ii.
- si es no, el número de PDUs para ese canal lógico es igual a cero.
\vskip1.000000\baselineskip
El número de PDUs para ese canal de transporte
es determinado sumando el número de PDUs para cada canal lógico
mapeado a ese canal de transporte.
La TFC puede ser soportada en términos de PDUs
de relleno si el número de PDUs para ese canal de transporte es
mayor o igual que el número de TBs en el TF.
La idea de un conjunto de TFC mínimo propuesto
en los estándares y usado en esta invención se explica a
continuación. El conjunto de TFC mínimo es el conjunto que permite
la transmisión de un TB del canal de transporte de prioridad más
alta que tiene datos para ser enviados. El conjunto de TFC mínimo
incluye todas las TFCs que tienen un "TF compatible de menor
tamaño" para un canal de transporte y TFs vacíos para todos los
demás canales de transporte, donde el "TF compatible de menor
tamaño" se define como:
Para canales lógicos de RLC
(AM-RLC) en modo de reconocimiento, el "TF
compatible de menor tamaño" es el TF con un TB con "Tamaño de
RLC" igual al tamaño de la PDU del RLC.
Para canales lógicos (TM-RLC) en
Modo Transparente no segmentado. El "TF compatible de menor
tamaño" es el TF con un bloque de transporte con "Tamaño de
RLC" igual al tamaño de SDU del RLC considerado.
Para TM-RLC en modo segmentado,
el "TF compatible de menor tamaño" es el TF tal que el número
de bloques de transporte multiplicado por el "Tamaño de RLC"
es igual al tamaño de SDU del RLC considerada.
Para (UM-RLC) en Modo de No
Reconocimiento, el "TF compatible de menor tamaño" es el TF con
un único bloque de transporte (de cualquier tamaño puesto que no
hay restricción en el tamaño de la PDU para UM). Si hay más de un
TFs con un único bloque de transporte definido, el "TF compatible
de menor tamaño" es el uno con tamaño de bloque de transporte
mínimo.
En la presente invención, cada vez que se
alcanza la potencia de transmisión máxima en un intervalo de tiempo,
la capa física envía una notificación junto con el número del
intervalo de tiempo a la capa de MAC que ha alcanzado la máxima
potencia.
Cada vez que el MAC recibe una notificación
desde la capa física de que se ha alcanzado la máxima potencia de
transmisión en un intervalo de tiempo, el MAC determina qué CCTrCHs
han asignado códigos en el intervalo de tiempo que alcanzó la
máxima potencia y marca tales CCTrCHs como que han alcanzado la
máxima potencia. Cuando un CCTrCH alcanza la máxima potencia, el
MAC comprobará si debe o no "descender":
Descender: Cada vez que un CCTrCH alcanza la
máxima potencia de transmisión para tres (3) tramas consecutivas, el
MAC limitará el conjunto de TFC candidato al mínimo conjunto de TFC
en el siguiente límite de TTI común (TTI común a todos los canales
de transporte en el CCTrCH).
Después de que el MAC "desciende",
considerará los criterios de recuperación para "ascender".
Para ascender, tras cada trama de operación de
un CCTrCH en el conjunto de TFC mínimo, el MAC predecirá la
potencia que necesitará el conjunto de TFC completo de ese CCTrCH en
la siguiente trama. Si la potencia de transmisión predicha en todos
los intervalos de tiempo del CCTrCH es menor que la máxima potencia
de transmisión del UE permitida para tres (3) tramas consecutivas,
entonces el conjunto de TFC completo puede ser incluido en el
conjunto de TFC candidato. De otra forma, se usará el conjunto de
TFC mínimo.
Es decir, el MAC permitirá bien el conjunto
completo (en términos de potencia) o bien el conjunto mínimo. Esta
es una solución de bajo coste que evita la necesidad de que el MAC
determine la potencia que necesita cada TFC en cada intervalo de
tiempo.
Por lo que se refiere a la predicción de
potencia, con el fin de comprobar si el conjunto completo puede ser
soportado, es suficiente comprobar si la TFC que requiere la máxima
potencia de transmisión puede ser soportada. Sin embargo, debido a
la adaptación de la tasa y la penetración usada en el sistema de
TDD, la TFC que requiere potencia máxima de transmisión puede ser
diferente para cada intervalo de tiempo (es decir, cada intervalo
de tiempo tiene asociado con él una TFC que requiere potencia de
transmisión máxima). Una solución para este problema es para el MAC
conocer el procedimiento usado por la capa física para "llenar"
intervalos de tiempo y códigos. La potencia necesitada por cada
intervalo de tiempo dependerá de la TFC que se use, puesto que la
potencia de transmisión es una función de los factores beta
(\beta) y del número de códigos usados por la TFC en el intervalo
de tiempo, y cada TFC puede tener un factor beta diferente y tasa de
datos diferente (y así, diferente número de códigos
usados).
usados).
Se ha propuesto aquí una solución donde el MAC
predice la potencia de transmisión en cada intervalo de tiempo del
CCTrCH considerando el escenario del caso peor, asumiendo que: todos
los códigos asignados se están usando en ese intervalo de tiempo
(todos los códigos incluso si son de diferentes CCTrCHs); y se está
usando el factor beta más alto de entre todas las TFCs del TFCS.
Si hay códigos de diferentes CCTrCHs en el
intervalo de tiempo, entonces se usarán diferentes factores beta
para cada código (cada código usará el factor beta más alto del
CCTrCH asociado).
La técnica anterior proporciona una solución de
bajo coste que evita la necesidad de que el MAC determine qué TFC
requiere la mayor potencia en cada intervalo de tiempo.
Por lo que se refiere a las PDUs, como se ha
establecido antes, el requisito para las PDUs de relleno necesita
ser cumplido sólo si no hay TFCs disponibles entre las TFCs que no
requieren PDUs de relleno. En otras palabras, si hay TFCs
disponibles en el conjunto de TFC candidato que no requieren PDUs de
relleno, entonces uno de ellos debería ser seleccionado, en lugar
de seleccionar una TFC que requiere relleno. Se ha de observar que,
para todas las TFCs que requieren relleno, las PDUs de los canales
lógicos que no pueden producir PDUs de relleno (es decir, canales
lógicos de RLC-TM) son eliminados del conjunto de
TFC candidato cuando los requisitos de configuración de TLC
analizados para comprobar la compatibilidad de relleno. Las TFCs que
requieren PDUs de relleno y están en el conjunto de TFC candidato,
requieren PDUs de relleno de canales lógicos que pueden producir
relleno. Si se necesitan o no PDUs de relleno para un TFC dado,
depende de la ocupación de la memoria temporal del RLC (cantidad de
datos que necesita ser enviada). Con el fin de crear un conjunto
sólo con TFCs que no requieren PDUs de relleno, todas las TFCs
deben ser probados en cada TTI. No obstante, esta es una solución
cara.
Se ha propuesto aquí determinar si hay TFCs que
no requieren PDUs de relleno mientras se lleva a cabo el algoritmo
de selección de TFC, como se expone más adelante. Por consiguiente,
todas las TFCs que satisfacen los cinco requisitos establecidos
anteriormente formarán parte del conjunto de TFC candidato, y el
requisito que se refiere a las PDUs de relleno se cumplirá, cuando
sea posible, en cada iteración de selección de TFC.
Debe seleccionarse una TFC elegida del conjunto
candidato y debe satisfacer los siguientes criterios (y en el orden
en el cual se listan):
a) ninguna otra TFC permite la transmisión de
datos de prioridad más alta que la TFC elegida;
b) ninguna otra TFC permite la transmisión de
más datos desde los siguientes canales de prioridad menor, y
c) ninguna otra TFC tiene una tasa de bits menor
que la TFC elegida.
Las Figuras 1a a 1d comprenden un diagrama de
flujo para la implementación del algoritmo de selección de TFC del
MAC-c;
la Figura 1 muestra la manera en la cual las
Figuras 1A a 1D están dispuestas para formar el diagrama de
flujo;
las Figuras 2A a 2D comprenden un diagrama de
flujo para la implementación del algoritmo de selección del TFC del
MAC-d; y
la Figura 2 muestra la manera en la cual las
Figuras 2A a 2D están dispuestas para formar el diagrama de
flujo.
La Figura 3 es un diagrama de flujo para el
procedimiento de selección del tamaño de la SDU del
MAD-d.
En la descripción de las realizaciones de
ejemplo que siguen, cada canal lógico tiene una MLP (MAC Logical
Channel Priority) (Prioridad de Canal Lógico de MAC) asociada. La
MLP determina la prioridad del canal lógico. Las reglas descritas en
el párrafo siguiente están basadas en MLPs:
Por consiguiente, el primer punto importante es
que el algoritmo itera por prioridad de canal lógico (trata de
servir primero a los canales lógicos de prioridad más alta), por
contraposición a iterar por canal de transporte.
Una solución cuando se lleva a cabo la selección
de TFC es determinar cuántos datos de cada prioridad puede llevar
cada TFC (empezando con el de prioridad más alta), y a continuación
seleccionar uno basándose en los requisitos (maximizando la
capacidad de tratamiento de los datos de prioridad más alta). No
obstante, esto requiere revisar todas las TFCs del conjunto
candidato.
La solución propuesta aquí es identificar la
cantidad de datos de la máxima prioridad que cada TFC puede
transportar, y a continuación eliminar aquéllos que proporcionan
una menor capacidad de tratamiento desde el conjunto candidato. En
la siguiente iteración (para los siguientes datos de prioridad
máxima), sólo se considera el nuevo conjunto.
No obstante, existe todavía la necesidad de
satisfacer el requisito del "conjunto candidato" listado
anteriormente en las PDUs de relleno. Cuando se eliminan las TFCs
del conjunto antes de completar todo el procedimiento, la TFC final
seleccionada puede requerir PDUs de relleno, y debería repetirse
todo el procedimiento sin la TFC dada, hasta que se encuentre la
TFC que no requiere relleno (y si no se encuentra tal TFC, debería
usarse la primera TFC seleccionada).
La solución propuesta aquí es asegurar que al
menos una TFC que no requiere relleno permanece en el conjunto
candidato. Como se ha explicado anteriormente, ciertos conjuntos
candidatos pueden no tener tal TFC, en cuyo caso, el requisito del
"conjunto candidato" establecido anteriormente no necesita ser
satisfecho.
Así, si tras eliminar las TFCs que no maximizan
la capacidad de tratamiento del conjunto candidato, el conjunto
candidato no contiene al menos una TFC que es "llenada" (es
decir, todos los bloques de transportes se están usando), entonces
una TFC que no requiere PDUs de relleno (pero no maximiza la
capacidad de tratamiento) es añadida de nuevo al conjunto candidato
(debe observarse que el requisito de relleno es más fuerte que el
requisito de la capacidad de tratamiento). Si hay muchas TFCs que
podrían ser añadidas al conjunto candidato, se elige la que
maximiza la capacidad de tratamiento de los datos de prioridad más
alta. Esta regla debería ser aplicada recursivamente para todos los
niveles de prioridad.
Lo siguiente es un ejemplo de una implementación
del procedimiento de selección de la TFC del
MAC-d.
Lo siguiente se usa en el algoritmo que
sigue:
Las SDUs de canales lógicos con la prioridad
p son consideradas datos con prioridad p.
El conjunto de TFC candidato se denomina
TFC_Can.
Sólo canales lógicos que tienen una ocupación de
memoria temporal mayor que cero serán considerados para la selección
de la TFC.
El algoritmo debería correr sólo si el conjunto
de TFC tiene TFCs válidos (TFCs con tasa de datos mayor que
cero).
El siguiente algoritmo (mostrado en la Figura 2)
es llevado a cabo para la selección de la TFC del
MAC-d:
Tras llevar a cabo las etapas S1 a S3 para
obtener los conjuntos candidatos (siendo la etapa S1 llevada a cabo
sólo por los UEs), la rutina continúa como sigue:
S4: Inicializar p=1.
S5: Comprobar si hay al menos una TFC con al
menos un TB disponible en el TFC_Can (conjunto de TFC
candidato).
- a.
- Si es sí, S5a, ir a la etapa S6.
- b.
- Si es no, S5b, ir a la etapa S25 (todas las TFCs llenas, seleccionar una).
S6: Seleccionar la primera TFC con al menos un
TB disponible del TFC_Can (conjunto de TFC candidato).
S7: Comprobar si hay un canal lógico con
prioridad p tal que:
El canal lógico tiene PDUs disponibles para ser
enviadas; el canal lógico no está bloqueado para esta TFC; y el
canal de transporte que está mapeado a ese canal lógico tiene TBs
disponibles.
- a.
- Si es sí, S7a, para ir a S9 y seleccionar ese canal lógico. Si hay más de un canal lógico tal, seleccionar uno al azar. A continuación ir a la etapa 10.
- b.
- Si es no, S7b, ir a la etapa S16 (no más datos con prioridad p).
S10: Comprobar si hay restricción en los tamaños
de PDU para el canal lógico seleccionado.
- a.
- Si es sí, S10a, ir a la etapa S11 y comprobar si el tamaño de TB del canal de transporte es del mismo tamaño que el tamaño de PDU + la cabecera del MAC.
- i.
- Si es sí, S11a:
- 1.
- Ir a S13 y seleccionar PDUs de este canal lógico para llenar tantos TBs disponibles como sea posible en el canal de transporte.
- 2.
- Actualizar la información del canal lógico como sigue:
- a.
- Este canal lógico está bloqueado para esta selección de TFC (canal lógico ya servido).
- 3.
- Ir a S14, actualizar la información del TB como sigue:
- a.
- Los TBs usados no están ya disponibles para esta selección de TFC.
- 4.
- Ir a la etapa S14.
- ii.
- Si es no, S11b,
- 1.
- Ir a S8 donde el canal lógico se considera bloqueado para esta TFC (las PDUs no encajan con la TFC).
- 2.
- A continuación volver a la etapa S7.
- b.
- Si es no, S10b,
- i.
- ir a S12 y llenar tantos TBs como sea posible en ese canal de transporte con bits de este canal lógico.
- ii.
- En S14, actualizar la información del TB como sigue:
- 1.
- Los TBs usados ya no están disponibles para esta selección de TFC
- iii.
- Este canal lógico se considera bloqueado para esta selección de TFC (canal lógico ya servido).
- iv.
- Ir a la etapa S15.
En S15, comprobar si todos lo TBs en este TFC
están llenos.
- a.
- Si es sí, S15a, ir a la etapa S16 (no hay más espacio en este TFC).
- b.
- Si es no, S15b, volver a la etapa S7.
En S16, computarizar la capacidad de tratamiento
óptima total de los datos de prioridad p para esta TFC, como
sigue:
Sea Num_Bits(p,i,j) el número de
bits de los datos de prioridad p que puede ser transmitido en
el DCH i cuando se usa la TFC j (es decir, el tamaño de TB veces el
número de TBs que se están enviando, incluyendo cualquier TLC y/o
cabecera de MAC que es aplicable y/o bits de relleno).
\newpage
La capacidad de tratamiento de DCH i normalizada
es computarizada como:
donde TTI Length(i,j)
es la longitud de TTI del TF para el TrCH i dado
TFCj.
\vskip1.000000\baselineskip
La capacidad de tratamiento óptima total de los
datos de prioridad p para el CCTrCH es la suma de todas las
capacidades de tratamiento normalizadas de DCH's de estos datos de
prioridad.
En S17, comprobar si hay más TFCs en la
TFC_Can
- a.
- Si es sí, S17a, seleccionar la siguiente TFC y volver a la etapa S7.
- b.
- Si es no, S17b, (todas las TFCs fueron comprobadas), ir a la etapa S18.
En S18, entre todas las TFCs de la TFC_Can, hay
al menos una TFC, llamada TFC k, que proporciona la
"capacidad de tratamiento óptima total" más alta para la
prioridad p, de manera que:
Borrar (es decir "eliminar") todas las TFCs
que proporcionan capacidad de tratamiento menor que la de la TFC
k del TFC_Can. A continuación ir a la etapa S19.
En S19, comprobar si hay al menos una TFC en la
TFC_Can que tenga todos los TBs llenos.
- a.
- Si es no, S19a, ir a S20 y comprobar si hay al menos una TFC que no pertenece al TFC_Can y que tiene todos los TBs llenos.
- i.
- Si es sí, S20a:
- 1.
- Ir a S21 y crear un conjunto con todas aquellas TFCs, llamado TFC_NoPad (TFCs que no requieren relleno).
- 2.
- Entre todas las TFCs en la TFC_NoPad, seleccionar la TFC que proporciona la "capacidad de tratamiento óptima total" más alta para los datos de prioridad p.
- 3.
- Añadir esa TFC al TFC_Can (conjunto candidato).
- ii.
- Si es no, S20b, continuar hacia la etapa S22.
- b.
- Si es sí, S19b, continuar a la etapa S22 (ya hay una TFC en la TFC_Can que no requiere relleno).
En S22, comprobar si todas las TFCs en el
TFC_Can tienen todos los TBs llenos.
- a.
- Si es sí, S22a, ir a la etapa S25 (la selección de TFC está hecha).
- b.
- Si es no, S22b, ir a la etapa S23.
En S23, actualizar p=p+1.
\newpage
En S24, comprobar si p\leq8
- a.
- Si es sí, S24a, volver a la etapa S5
- b.
- Si es no, S24b, ir a la etapa S25 (todas las prioridades comprobadas, seleccionará un TFC).
En S25, comprobar si hay al menos una TFC en el
TFC_Can que no requiera PDUs de relleno.
- a.
- Si es sí, S25a, ir a la etapa S26.
- b.
- Si es no, S25b, ir a la etapa S27.
En S26, seleccionar la TFC del TFC_Can que no
requiere de relleno. Si hay más de un TFC disponible que no requiere
relleno, entre ellos, seleccionar la TFC que proporciona la tasa de
datos mínima.
En S27, seleccionar la TFC de la TFC_Can que
proporciona la tasa de datos mínima. Si hay más de una TFC
disponible con la misma tasa de datos, seleccionar una al azar.
Llenar las PDUs no llenas de la TFC con PDUs de relleno del RLC.
En el lado del RLC, la selección de TFC en la
capa de MAC se ha hecho tanto en las entidades MAC-c
como MAC-d. El MAC-c está situado en
la Controlling-RNC (C-RNC) (RNC de
Control) y hay un MAC-c por celda; el
MAC-d está situado en el S-RNC y hay
un MAC-d para cada UE.
Con el fin de transferir datos entre el
S-RNC y el C-RNC, se usa el control
de flujo de Forward Access Channel (FACH) (Canal de Acceso
Posterior). El Control de flujo permite que el MAC-c
(C-RNC) controle el número de SDUs (créditos) que
cada MAC-d (S-RNC) puede enviar para
una prioridad asociada (FACH Priority Indicator) (Indicador de
Prioridad FACH). El MAD-d selecciona un tamaño de
SDU para cada prioridad, y envía los datos al MAC-c.
El MAC-c almacena temporalmente estos datos, antes
de ser transmitidos.
Si credits=0 (por ejemplo debido a
congestión en el C-RNC), el S-RNC
inmediatamente detiene la transmisión de SDUs del
MAC-c. Si credits = "unlimited", indica
que el SRNC puede transmitir un número ilimitado de SDUs de
MAC-c.
Las siguientes secciones describen el algoritmo
de selección de TFC para el RNC del MAC-c (Figura 1)
y el algoritmo de selección de tamaño de SDU para canales de
transporte común en el RNC del MAC-d.
El algoritmo de selección del RNC del
MAC-d TFC es similar al de UE MAC-d,
con la excepción de que del lado del RNC no hay restricción en la
potencia de transmisión, y por ello no será presentado aquí. El
procedimiento explicado en la sección previa aplica al
MAC-d tanto en los lados del UE y del RNC.
Las especificaciones de MAC no especifican
ningún requisito para la selección de TFC en el RNC. Sin embargo,
para que el UE descodifique los datos correctamente, hay algunos
requisitos que deben cumplirse. Estos requisitos se resumen a
continuación.
Antes de seleccionar una TFC para el caso de
MAC-c, el conjunto de TFCs válidas debe ser
establecido. Este conjunto se llama el "conjunto candidato".
Todas las TFCs en el conjunto candidato deben:
1. pertenecer al TFCS;
2. respetar la compatibilidad de TTI - el
formato de transporte (TF) de un TrCH no puede cambiar en el medio
del TTI del TrCH; y
3. Ser compatible con la configuración del
RLC.
\vskip1.000000\baselineskip
La TFC elegida debe ser seleccionada desde el
conjunto candidato y debe satisfacer los siguientes criterios en el
orden en el que se listan a continuación:
1. Ninguna otra TFC permite la transmisión de
datos de prioridad más alta que la TFC elegida.
2. Ninguna otra TFC permite la transmisión de
más datos desde los siguientes canales lógicos de prioridad menor.
Este criterio es aplicado recursivamente para los niveles de
prioridad restante.
3. Ninguna otra TFC tiene una tasa de bit menor
que la TFC elegidos.
4. Debe respetar "primero en entrar primero en
salir" dentro de cada prioridad para los datos recibidos desde el
MAC-d.
Para el procedimiento del MAC-c,
los datos que son recibidos desde el MAC-d son
almacenados temporalmente en el MAC-c. Esto puede
hacerse bien teniendo una cola por UE, o una cola para todos los
UEs, o una cola para cada prioridad. Se ha propuesto tener una cola
por prioridad, puesto que hacer esto hará más fácil mantener el
orden de primero que entra primero que sale. El primer planteamiento
requeriría que la memoria temporal fuese de tiempo estampado con el
fin de mantener el orden, mientras que el segundo planteamiento
requeriría la coordinación de las prioridades.
Para propósito de bloqueo, el
MAC-c puede planificar datos en cualesquiera FACHs
mapeados en el canal lógico compuesto codificado. Si los datos de
un canal lógico son enviados en un canal de transporte con TTI de
longitud "t", los datos del mismo canal lógico no deberían ser
enviados en otros canales de lógico, para la duración de "t"
puesto que esto puede llevar a un problema de dejar de funcionar en
el RLC del lado de recepción (es decir, el lado del UE).
Para un CCCH (Common Control Channel) (Canal de
Control Común) este problema puede ser resuelto mediante bloqueo del
canal para transmisión para una duración igual al TTI del último
canal de transporte transmitido (es decir, no serán enviados datos
desde el canal lógico durante ese TTI).
Para los datos almacenados temporalmente (datos
recibidos desde el MAC-d), este problema puede ser
resuelto mediante el bloqueo de los datos de una prioridad dada.
Sin embargo, este planteamiento llevaría a la
infra-utilización de los recursos del sistema
puesto que una mayor cantidad de datos es bloqueada incluso si no es
necesario, y lleva a un retardo en la transmisión de datos desde
otros UEs de la misma prioridad. Para evitar esto, los datos de una
prioridad desde un UE son bloqueados durante un periodo "t", si
los datos desde este UE de esa prioridad son enviados en un canal
de transporte con periodo de TTI "t". Esto aumenta la cantidad
de datos que pueden ser enviados desde todos los UEs y también
soluciona el problema de dejar de funcionar.
En lo que se refiere al de relleno, el
MAC-c puede solicitar PDUs de relleno sólo desde la
entidad RLC del CCCH. Si el DDDH está bloqueado y si se necesitan
PDUs de relleno, el MAC-c solicita sólo PDUs de
relleno del RLC.
El siguiente es un ejemplo de una implementación
del procedimiento de Selección de TFC del RNC del
MAC-c.
En este algoritmo de MAC-c,
algoritmo:
- Una memoria temporal con PDUs transferidas se
denomina "canal lógico".
- El conjunto de TFC candidato se denomina
TFC_Can
- Sólo los canales lógicos que tienen ocupación
de memoria temporal mayor que cero serán considerados para la
selección de la TFC.
- El algoritmo debería correr sólo si el
conjunto de TFC tiene TFCs válidos (TFCs con tasa de datos mayor que
cero)
- Haciendo referencia a las Figuras 1A a 1D, las
siguientes etapas son llevadas a cabo por el algoritmo de selección
de TFC del MAC-c:
S1. Inicializar p=1.
S2. Comprobar si hay al menos una TFC con al
menos un TB disponible en la TFC_Can (conjunto de TFC
candidato).
- a.
- Si es sí, S2a, ir a la etapa S3.
- b.
- Si es no, ir a la etapa S26 (todas las TFCs llenas, seleccionará una).
S3: Seleccionar la primera TFC con al menos un
TB disponible de la TFC_Can (conjunto de TFC candidato)
S4: Comprobar si hay un canal lógico con
prioridad p tal que:
el canal lógico tiene PDUs disponibles para ser
enviadas; si el canal lógico seleccionado es un CCCH, el canal
lógico no está bloqueado por la TFC seleccionada; si el canal lógico
seleccionado es de PDUs transferidas, entonces comprobarlo; si hay
al menos una PDU que no está bloqueada para la TFC seleccionada; y
el canal lógico seleccionado no está bloqueado para esta TFC.
- a.
- Si es sí, S4a, ir a S5 y seleccionar ese canal lógico. Si hay más de un canal lógico tal, seleccionar uno al azar. Ir a la etapa S6.
- b.
- Si es no, S4b, ir a S17 (no hay más datos con prioridad p).
\newpage
\global\parskip0.950000\baselineskip
S6: Comprobar si hay una restricción en los
tamaños de PDU para el canal lógico seleccionado.
- a.
- Si es sí, S6a, ir a S7 y comprobar si hay un TB disponible con el mismo tamaño que el tamaño de PDU + cabecera de MAC.
- i.
- Si es sí, S7, ir a S8 y:
- 1.
- seleccionar el canal de transporte con ese tamaño de TB.
Si más de uno está disponible, seleccionar un
canal de transporte que proporcione la máxima tasa de datos
disponible, como sigue:
MAX {(número de TBs
disponibles)/tamaño de TTI};
y
- 2.
- seleccionar PDUs que no están bloqueadas desde este canal lógico para llenar tantos TBs como sea posible en el canal de transporte. La selección de PDU debe respetar FIFO; las PDUs bloqueadas deben saltarse.
- 3.
- Actualizar la información de memoria temporal como sigue:
- a.
- las PDUs seleccionados no están disponibles para esta selección de TFC, entonces ir a S11 y:
- b.
- los TBs usados ya no están disponibles para esta selección de TFC.
A continuación ir a la etapa S14.
- ii.
- Si es no, S7b, ir a S9 y realizar:
- 1.
- Este canal lógico es considerado bloqueado para este TFC (puesto que las PDUs no encajan con la TFC).
- 2.
- A continuación volver a la etapa S4.
- b.
- Si es no, S6b, ir a S10 y:
- i.
- seleccionar un canal de transporte que proporcione la máxima tasa de datos disponible, como sigue:
MAX {(número de TBs disponible *
tamaño de TB)/tamaño de
TTI}.
- ii.
- Llenar tantos TBs como sea posible en ese canal de transporte con bits de este canal lógico.
- iii.
- Actualizar la información de la memoria temporal como sigue:
- 1.
- Los bits usados ya no están disponibles para esta selección de TFC y no deberían ser contados en la ocupación de la memoria temporal.
- iv.
- A continuación ir a la etapa S11 para actualizar la información del TB como sigue:
- 1.
- Los TBs usados ya no están disponibles para esta selección de TFC.
- v.
- A continuación ir a la etapa S12.
- 2.
- Si el canal lógico seleccionado es un DDDH, S12a, ir a S14 y:
Considerar el CCCH que va a ser bloqueado por
esta TFC durante esta selección de TFC (para las siguientes etapas
de la selección de TFC para este TTI).
- 3.
- Si el canal lógico seleccionado no es un CCCH, S12b, ir a S13 para determinar:
Si el canal lógico seleccionado es de PDUs
transferidas, S13a, entonces ir a S15, para asegurar:
- todas las demás PDUs que:
- están en la misma memoria temporal (es decir,
la misma prioridad); y
- tienen la misma UE ID que la UE ID de la PDU o
las PDUs seleccionadas están consideradas bloqueadas por esta TFC
durante esta selección de TFC (para las siguientes etapas de la
selección de TFC para este TTI).
- 5.
- Si el canal lógico seleccionado no es de PDUs transferidas, S13b, ir directamente a S16.
\global\parskip1.000000\baselineskip
En S16, comprobar si todos los TBs de esta TFC
están llenos.
- a.
- Si es sí, S16a, ir a la etapa S17 (ya no hay más espacio en este TFC).
- b.
- Si es no, S16b, volver a la etapa S4.
En S17, computarizar la capacidad de tratamiento
óptima total de datos de prioridad p para este TFC, como
sigue:
Sea Num_Bits(p,i,j) el número de
bits de datos de prioridad p que puede ser transmitido en el
FACH i cuando se usa TFC j (es decir, el tamaño de TB veces
el número de TBs que están siendo enviados, incluyendo cualquier RLC
y/o la cabecera del MAC que es aplicable y/o bits de relleno).
La capacidad de tratamiento normalizada de PACH
i es computarizada como
\vskip1.000000\baselineskip
donde TTI Length(i,j)
es la longitud de TTI de TF para un TrCH i dado
TFCj.
La capacidad de tratamiento de MAC óptima total
de los datos de prioridad p para el CCTrCH
(S-CCPCH) es la suma de todas las capacidades de
tratamiento normalizadas de FACHs de los datos de esta
prioridad.
\vskip1.000000\baselineskip
En S18, comprobar si hay más TFCs en la
TFC_Can.
- a.
- Si es sí, S18a, seleccionar la siguiente TFC y volver a la etapa S4.
- b.
- Si es no, S18b, (todas las TFCs han sido comprobadas), ir a la etapa S19.
En S19, entre todas las TFCs de la TFC_Can, hay
al menos una TFC, sea TFC k, que proporciona la "capacidad
de tratamiento óptima total" más alta para la prioridad p,
de manera que:
\vskip1.000000\baselineskip
Borrar todas las TFCs que proporcionan capacidad
de tratamiento menor que la TFC k seleccionada de la
TFC_Can.
En S20, comprobar si hay al menos un TFC en la
TFC_Can que tiene todos los TBs llenos (no requiere relleno).
- a.
- Si es no, S20a, ir a S21 y comprobar si hay al menos una TFC que no pertenece al TFC_Can y que tiene todos los TBs llenos.
- i.
- Si es sí, S21a, ir a S22 para:
- 1.
- Crear un conjunto con todas esas TFCs, llamado TFC_NoPad (TFCs que no requieren relleno);
- 2.
- entre todas las TFCs de la TFC_NoPad, seleccionar la TFC que proporciona la "capacidad de tratamiento óptima total" más alta para los datos de prioridad p; y
- 3.
- añadir esa TFC al TFC_Can.
- ii.
- Si es no, S21b, continuar hacia la etapa S23.
- b.
- Si es sí, S20b, continuar hacia la etapa S23 (ya hay una TFC en el TFC_Can que no requiere relleno).
En S23, comprobar si todas las TFCs del TFC_Can
tienen todos los TBs llenos.
- a.
- Si es sí, S23a, ir a la etapa S26 (la selección de la TFC está hecha).
- b.
- Si es no, S23b, ir a la etapa S24.
En S24, actualizar p = p+1, y a continuación ir
a S25 para comprobar si p<=8.
Si es sí, S25a, ir a la etapa S26 (comprobadas
todas las prioridades, seleccionar una TFC).
En S26, comprobar si hay al menos una TFC en el
TFC_Can que no requiere PDUs de relleno.
- a.
- Si es sí, S26a, ir a la etapa S27.
- b.
- Si es no, S26b, ir a la etapa S28.
En S27, seleccionar la TFC del TFC_Can que no
requiere relleno. Si hay más de una TFC disponible que no requiere
relleno, entre aquéllos, seleccionar la TFC que proporciona la tasa
de datos mínima.
En S28, seleccionar la TFC del TFC_Can que
proporciona la tasa de datos mínima, Si hay más de una TFC
disponible con el mismo número de bits, seleccionar una al azar.
Llenar las PDUs no llenas de la TFC con PDUs de relleno del TLC
(CCCH).
Después de S27 o S28, ir a S29.
En S29, si el CCCH se usa en esta TFC,
considerar que el CCCH va a ser bloqueado por todas las TFCs durante
un periodo de tiempo igual al TTI del canal de transporte
seleccionado.
En S30, para cada canal lógico con PDUs
transferidas (es decir, para cada memoria temporal con una prioridad
específica) usado en la TFC seleccionada, cada PDU que está en esa
memoria temporal y tiene el UE ID igual al UE ID de una PDU
seleccionada para esta TFC se considera que está bloqueado por todas
las TFCs durante un periodo de tiempo igual al TTI del canal de
memoria temporal seleccionado para ese canal lógico.
La Figura 1, que muestra el diagrama de flujo
para la implementación del algoritmo de selección de TFC del
MAC-c, incluye más etapas que el algoritmo de la
Figura 2.
El MAC-d puede ser configurado
con un conjunto de tamaños de SDU permitidos (el tamaño permitido
depende de las TFCs del S-CCPCH (Secondary Common
Control Channel) (Canal de Control Común Secundario) para cada
indicador de prioridad de canal de transporte común (prioridad de
FACH). Una trama de control de flujo de FACH es usada por el
C-RNC para controlar el flujo de datos del usuario.
Puede ser generada en respuesta a la Petición de Capacidad del FACH
o en cualquier otro momento. La trama de control de Flujo del FACH
contendrá el número de créditos que a la entidad
S-RNC MAC-d se le permite
transmitir.
Para cada canal lógico, hay una prioridad de FAC
asociada. El MAC-d selecciona un tamaño de SDU (del
conjunto configurado) para cada canal lógico, dependiendo de la
ocupación de la memoria temporal del canal lógico (BO) y del número
de créditos disponibles para la prioridad de ese FACH. Las SDUs del
MAC-d del mismo tamaño y de la misma prioridad de
FACH pueden ser transmitidas en la misma trama de datos del
FACH.
La selección de tamaño de la SDU para un canal
lógico depende de la configuración del RLC correspondiente, del
canal lógico BO, y del número de créditos disponibles para la
prioridad de ese FACH.
Para un BO dado, puede haber un número variable
de créditos disponible necesarios para cada tamaño de SDU. Si el
número de créditos requerido multiplicado por el tamaño de la SDU no
coincide exactamente con el BO, entonces requerirá algún
encabezamiento (relleno de RLC). Un tamaño de SDU que minimiza este
encabezamiento es seleccionado, para maximizar la capacidad de
tratamiento. Sin embargo, eso puede requerir seleccionar un tamaño
que requiere un mayor número de créditos. Se ha de observar que
cuanto mayor es el número de créditos que se pide, más veces se
añade la cabecera del MAC, lo que provoca más encabezamiento.
Puesto que no existe ninguna ecuación de forma
cerrada para determinar qué opción es mejor (minimizar el
encabezamiento de relleno de RLC o minimizar el número de créditos
para un BO dado), el último (minimizar el número de créditos que se
están usando para un BO dado) es seleccionado, porque, seleccionando
un tamaño que requiere un menor número de créditos, más créditos
están disponibles para un futuro uso, lo que resulta ser
extremadamente útil en un sistema completamente cargado. También,
si el BO es muy grande comparado con los tamaños de SDU, entonces la
solución minimiza tanto el encabezamiento cono el número de
créditos.
Lo siguiente es un ejemplo de una implementación
del procedimiento de selección de tamaño de la SDU del
MAC-d del RNC.
Con el fin de enviar SDUs al
MAC-c, el MAC-d sigue el siguiente
procedimiento (véase la Figura 3):
S1: Seleccionar la mayor prioridad (es decir, la
mayor MLP).
S2: Seleccionar un canal lógico con esa
prioridad. Si hay más de un canal lógico con esa prioridad,
seleccionar una al azar.
S3: Basándose en la ocupación de memoria
temporal del lógico canal, seleccionar el tamaño de SDU que va a ser
usado por ese canal lógico, como sigue:
Basándose en el número de "créditos"
disponibles en el MAC-d, determinar la cantidad de
bits de información que pueden ser transmitidos usando cada tamaño
de PDU (no incluyendo bits de relleno). Para cada tamaño de PDU, la
cantidad de bits de información está dada por:
MIN (BO, créditos x tamaño de
PDU).
Seleccionar el tamaño de PDU que proporciona la
máxima cantidad de bits de información. Si más de un tamaño de PDU
proporciona la misma cantidad máxima de bits de información,
seleccionar el tamaño de PDU que proporciona el mínimo número de
créditos requerido para enviar la cantidad máxima de bits de
información dada. Si más de un tamaño de PDU proporciona el mismo
número de créditos mínimo, seleccionar el tamaño de PDU menor.
Seleccionar las SDUs que van a ser enviadas
desde ese canal lógico. Muchas PDUs pueden ser enviadas pero sólo
un único tamaño de SDU está permitido para ese canal lógico. Los
créditos permitidos deben ser respetados cuando se selecciona el
número de SDUs que se va a enviar.
Comprobar si hay más canales lógicos con la
misma prioridad y si hay todavía créditos disponibles para esa
prioridad
Si es sí, S5a, volver a S2.
Si es no, S5b, ir a S6.
En S6, construir una trama de datos del FACH
"Iur" para cada tamaño de PDU (para una prioridad dada). Se ha
de observar que el tamaño de la SDU es el mismo para un canal lógico
dado, pero puede ser diferente para distintos canales lógicos de la
misma prioridad. Así, si hay n canales lógicos con esa prioridad,
habrá al menos una (1) y como mucho n tramas de datos del FACH (una
para cada tamaño). Debería observarse también que el orden de las
SDUs para cada canal lógico debe ser mantenido dentro de la trama de
datos.
En S7, comprobar si hay más canales lógicos
disponibles.
Si es sí, S7a, ir a S8 para seleccionar la
siguiente prioridad más alta disponible y volver a S2.
Si es no, S7b, el procedimiento está
terminado.
En las secciones previas, se ha descrito la
información que se necesita con el fin de llevar a cabo la selección
de la TFC. Para la interacción entre el MAC y el RLC, se necesitan
tanto la información de la configuración basada en modo de canal
lógico (estática) como la información de los datos almacenados
temporalmente (dinámica).
Por lo que respecta a la Especificación del
Protocolo del MAC (3GPP TS 25.321) y a la Especificación del
Protocolo del RLC (3GPP TS 25.322), el RLC proporciona el MAC con
la ocupación de la memoria temporal (BO), que es la cantidad total
de datos almacenados temporalmente en el RLC. No obstante, puesto
que el MAC necesita más información del RLC con el fin de llevar a
cabo la selección de la TFC, la especificación del protocolo de RLC
(3GPP TS 25.322) establece también que el RLC necesita proporcionar
la "RLC Entity Info" (Información de la Entidad RLC) al MAC.
La especificación del protocolo del RLC (3GPP TS 25.322) no
especifica qué debe contener la "RLC Entity Info".
En esta sección se describirán los contenidos de
la "RLC Entity Info". Puesto que esta información es usada para
"restringir" la selección de la TFC, a esta información se la
denomina TFC Restriction Variables (Variables de Restricción de la
TFC).
Las variables de restricción de la TFC
proporcionan información sobre las PDUs y/o las SDUs almacenadas
temporalmente en el RLC que están disponibles para transmisión en el
siguiente TTI.
Para modos no reconocidos y transparentes, el
MAC especifica el tamaño de la PDU con respecto al TTI. Por lo
tanto, el RLC no puede crear PDUs por delante del TTI, y sólo
información basada en las SDUs almacenadas temporalmente puede ser
proporcionada por el RLC antes de la transmisión. Para un modo
reconocido, el tamaño de la PDU está fijado, y por lo tanto
información basada en las PDUs almacenadas temporalmente puede ser
proporcionada por el RLC.
Debe observarse que las variables de restricción
de la TFC pueden contener el propio modo de RLC. No obstante,
puesto que proporcionar el modo de RLC requiere que el MAC haga
asunciones sobre las características de los datos almacenados
temporalmente en el RLC basándose en el modo de RLC, entonces las
propias características de los datos son proporcionadas en su
lugar.
Puesto que la selección de la TFC depende de la
cantidad de datos que está disponible para su transmisión en un TTI
dado, las variables de restricción de la TFC incluyen el tamaño de
la SDU/PDU y el número de SDUs/PDUs almacenadas temporalmente en el
RLC.
Dependiendo del modo de RLC, y también con el
fin de evitar conflictos en la transmisión de datos, sólo algunos
de los datos almacenados temporalmente en el RLC pueden estar
disponibles para la transmisión.
Para todos los modos de RLC, los tamaños y los
tipos de UE Id de todas las PDUs transmitidas al MAC en un TTI
deben ser los mismos. La información reportada al MAC debe
garantizar que la TFC está seleccionada de manera que estas dos
restricciones no son violadas. Por lo tanto, sólo se proporciona
información para SDUs y PDUs que tienen el mismo tamaño y tipo de
UE Id. Puesto que los datos deben ser transmitidos en el orden en
el que fueron recibidos, el RLC informa sólo sobre el número de
SDUs/PDUs consecutivas en la memoria temporal de transmisión del
RLC (empezando desde la SDU/PDU más antigua) que tienen el mismo
tamaño y el mismo tipo de UE Id.
Para modo transparente con segmentación
configurada, sólo puede ser transmitida una SDU por TTI, y por lo
tanto el RLC informará de que sólo una SDU está disponible para su
transmisión.
Para modo reconocido, dependiendo de la
configuración del RLC, un canal lógico puede transportar datos de
la SDU del RLC (recibida desde la capa superior) y/o datos de
control de igual a igual del RLC. La cantidad de datos de PDU
disponibles para un canal lógico de modo reconocido está por lo
tanto restringida por el tipo de datos del RLC sobre los que puede
informar. Para canales en modo reconocido que soportan la
transmisión de RLC SDUs (recibido desde la capa superior), la
cantidad de datos de PDUs disponibles está también restringida por
el tamaño de la ventana de transmisión del RLC del canal lógico.
Debe observarse que el tamaño de la ventana de transmisión del RLC
está estáticamente configurado en el RLC.
Para la selección de la TFC, el MAC necesita
saber cuánto del TB es recogido por la cabecera del MAC. Puesto que
el tamaño de la cabecera del TB depende del tipo de la UE ID,
entonces las variables de restricción de la TFC contienen también
el tipo de UE ID. Debe observarse que la especificación del
protocolo del MAC (3GPP TS 25.321) establece que el tipo del UE Id
es proporcionado por el RLC al MAC para cada transmisión de
datos.
Puesto que la TFC contiene información sobre el
número de PDUs que el MAC debe solicitar del RLC entonces el MAC
necesita saber si las SDUs almacenadas temporalmente en el RLC
pueden ser segmentadas o no. Por lo tanto las variables de
restricción de la TFC incluyen un indicador de segmentación. Debe
observarse que este indicador está estáticamente configurado en el
RLC.
Como se ha mencionado en las secciones previas,
la información de relleno necesita ser conocida por el MAC con el
fin de que sea capaz de llevar a cabo la selección de la TFC. Puesto
que el relleno sólo está soportado en ciertos modos de RLC (sólo
modos UM y AM), se incluye también un indicador de PDU de relleno en
las variables de restricción de la TFC.
Lo anterior es una descripción de un método y
algoritmos de ejemplo para procedimientos usados por la capa de MAC
para la selección de la TFC con el fin de planificar la transmisión
de datos. El 3GPP UMTS establecido anteriormente como el contexto
para la invención es sólo a modo de ejemplo, y, la invención puede
ser modificada para servir a otros estándares relacionados y modos
de transmisión de datos. Se considera que todas las modificaciones
tales están dentro del ámbito de la presente invención.
Las técnicas bloqueantes y no bloqueantes
descritas anteriormente son extremadamente ventajosas para su uso
en una red de radio que emplea Time Division Duplex (TDD)
(Transmisión Bidireccional por División de Tiempo) para
comunicaciones. No obstante, las técnicas anteriores pueden ser
empleadas en una red del tipo de Frequency Division Duplex (FDD)
(Transmisión Bidireccional por División de Frecuencia).
Todos los demás aspectos de la invención son
aplicables a todos los demás modos de UMTS.
Claims (30)
1. Un método para planificar la transmisión de
datos en una red de comunicación por radio que elimina una necesidad
de determinar los requisitos de potencia para cada combinación de
formato de transporte (TFC) en cada intervalo de tiempo, incluyendo
la citada red al menos una capa física y una capa de Medium Access
Control (MAC) (Control de Acceso Medio), que comprende:
la citada capa física:
que monitoriza la potencia de transmisión en un
intervalo de tiempo; y
que envía una notificación a la capa de MAC de
que se ha alcanzado la máxima potencia, junto con el número de
intervalo de tiempo;
la citada capa de MAC:
que determina qué Coded Composite Transport
Channels (CCTrCHs) (Canales de Transporte Compuesto Codificados) han
asignado códigos en el intervalo de tiempo que alcanza la máxima
potencia;
que marca que tales CCTrCHs han alcanzado la
máxima potencia; y
que limita un conjunto de Transport Format
Combination (TFC) (Combinación de Formato de Transporte) a un
conjunto de TFC mínimo en el límite del siguiente Common Transmit
Time Interval (TTI) (Intervalo de Tiempo de Transmisión Común).
2. El método de la Reivindicación 1, en el que
la etapa limitadora incluye también:
Detectar que la máxima potencia de transmisión
ha tenido lugar para un número dado de tramas consecutivas antes de
limitar al citado conjunto de TFC candidato.
3. El método de la Reivindicación 1, en el que
el número de tramas consecutivas es preferiblemente tres (3).
4. El método de la Reivindicación 2 que
comprende también:
la citada capa de MAC:
que predice una potencia que necesita el
conjunto de TFC lleno de un CCTrCH que será requerida en la
siguiente trama responsable de la operación de un CCTrCH en el
conjunto de TFC mínimo:
que compara la potencia de transmisión predicha
en todos los intervalos de tiempo del CCTrCH; y que incluye el
conjunto de TFC completo en el conjunto de TFC candidato cuando la
potencia de transmisión predicha en todos los intervalos de tiempo
del CCTrCH es menor que la máxima potencia de transmisión del UE
permitida.
5. El método de la Reivindicación 4, en el que
la etapa comparadora incluye:
llevar a cabo la etapa comparadora para un
número dado de tramas consecutivas con el fin de incluir el conjunto
de TFC completo en el conjunto de TFC candidato.
6. El método de la Reivindicación 5, en el que
el número dado de tramas consecutivas es tres (3).
7. El método de la Reivindicación 1, en el que
predecir la potencia de transmisión en cada intervalo de tiempo
comprende considerar un escenario de caso peor asumiendo que todos
los códigos asignados están siendo usados en ese intervalo de tiempo
y si son de diferentes CCTrCHs.
8. El método de la Reivindicación 7, en el que
un factor beta usado para cada código es un factor beta más alto del
CCTrCH entre todas las TFCs en el conjunto de TFC que se está
usando.
9. El método de la reivindicación 1, en el que
una TFC es seleccionada del el conjunto candidato de manera que:
ninguna otra TFC permite la transmisión de datos
de mayor prioridad en una TFC elegida;
ninguna otra TFC permite la transmisión de más
datos desde los siguientes canales de prioridad menor, y
ninguna otra TFC tiene una tasa de bits menor
que la TFC elegida.
10. El método de la Reivindicación 1, en el que
la citada capa de MAC es un canal del tipo
MAC-dedicated (MAC-d) (Canal
dedicado a MAC).
11. El método de la Reivindicación 1, en el que
la etapa de aprovisionamiento incluye también:
proporcionar el conjunto de TFC completo sólo si
el conjunto de TFC completo puede ser soportado.
12. El método de la Reivindicación 1, en el que
la citada red emplea una técnica de Time Division Duplex (TDD)
(Transmisión Bidireccional por División de Tiempo) para
comunicación.
13. Un método para planificar la transmisión de
datos en una red de comunicación por radio que elimina una necesidad
de determinar los requisitos de potencia para cada Transport Format
Combination (TFC) en cada intervalo de tiempo, incluyendo la citada
red al menos una capa física y una capa de Medium Access Control
(MAC) (Control de Acceso Medio), que comprende:
la citada capa física:
que monitoriza la potencia de transmisión en un
intervalo de tiempo; y
que envía una notificación a la capa de MAC de
que se ha alcanzado la máxima potencia, junto con el número del
intervalo de tiempo; y
la citada capa de MAC:
que selecciona una TFC bien sea de un conjunto
de TFC completo o de un conjunto de TFC mínimo basándose en la
notificación de potencia desde la capa física.
14. El método de la Reivindicación 13, en el que
la citada capa de MAC es un tipo de canal
MAC-dedicated (MAC-d) (Dedicado a
MAC).
15. Aparato para planificar la transmisión de
datos en una red de comunicación por radio que elimina una necesidad
de determinar los requisitos de potencia, incluyendo la citada red
al menos una capa física y una capa de Medium Access Control (MAC)
(Control de Acceso Medio), que comprende:
la citada capa física que comprende:
un medio para monitorizar la potencia de
transmisión en un intervalo de tiempo; y
un medio para enviar una notificación a la capa
de MAC de que se ha alcanzado la máxima potencia, junto con el
número del intervalo de tiempo;
la citada capa de MAC que comprende:
un medio para determinar qué Coded Composite
Transport Channels (CCTrCHs) (Canales de Transporte Compuesto
Codificado) han asignado códigos en el intervalo de tiempo que
alcanza la máxima potencia;
un medio para marcar que tales CCTrCHs han
alcanzado la máxima potencia; y
un medio para limitar un conjunto de Transport
Format Combination (TFC) (Combinación de Formato de Transporte)
candidato a un conjunto de TFC mínimo en el límite de un Common
Transmit Time Interval (TTI) (Intervalo de Tiempo de Transmisión
Común) siguiente.
16. El aparato de la Reivindicación 15 en el que
el medio para limitar comprende también:
un medio para detectar que la potencia de
transmisión máxima ha tenido lugar para un número dado de tramas
consecutivas; y
un medio responsable de que el citado medio de
detección limite el citado conjunto de TFC candidato.
17. El aparato de la Reivindicación 16 en el que
el medio para detectar el número de tramas consecutivas determina
que la potencia de transmisión máxima ha tenido lugar para tres (3)
tramas consecutivas.
18. El aparato de la Reivindicación 15 en el que
la citada capa de MAC es un canal del tipo de
MAD-dedicated (Dedicado a MAC).
19. El aparato de la Reivindicación 15, en el
que la citada red emplea una técnica de Time Division Duplex (TDD)
(Transmisión Bidireccional por Division de Tiempo para
comunicaciones.
20. El aparato de la Reivindicación 15, que
comprende también:
la citada capa de MAC que comprende:
un medio para predecir una potencia necesitada
por el conjunto de TFC completo de un CCTrCH en la siguiente trama
responsable de todas las tramas de operación de un CCTrCH en el
conjunto de TFC mínimo;
un medio para comparar la potencia de
transmisión predicha en todos los intervalos de tiempo del CCTrCH;
y
un medio para incluir el conjunto de TFC
completo en el conjunto de TFC candidato cuando la potencia de
transmisión predicha en todos los intervalos de tiempo del CCTrCH es
menor que la potencia de transmisión máxima permitida de un User
Equipment (UE) (Equipo de Usuario).
21. El aparato de la Reivindicación 20, en el
que el medio de comparación comprende:
un medio para llevar a cabo la etapa de
comparación para un número dado de tramas consecutivas con el fin de
incluir el conjunto de TFC completo en el conjunto de TFC
candidato.
22. El aparato de la Reivindicación 21, en el
que, el medio para incluir incluye el conjunto de TFC llenos en el
conjunto de TFC candidato responsable de que el citado medio de
comparación detecte que la potencia de transmisión predicha es menor
que la potencia permitida máxima para tres (3) tramas
consecutivas.
23. El aparato de la Reivindicación 15, en el
que el medio para predecir la potencia de transmisión en cada
intervalo de tiempo comprende:
un medio para considerar un escenario de caso
peor asumiendo que todos los códigos asignados están siendo
utilizados en ese intervalo de tiempo incluso si son de diferentes
CCTrCHs.
24. El aparato de la Reivindicación 23, en el
que un factor beta usado para cada código es un factor beta más alto
del CCTrCH entre todas las TFCs del conjunto de TFC que se está
usando.
25. El aparato de la Reivindicación 15, que
comprende también:
un medio para seleccionar una TFC del conjunto
de TFC candidato empleando los criterios de que:
ninguna otra TFC permite la transmisión de datos
de prioridad más alta que una TFC elegida;
ninguna otra TFC permite la transmisión de más
datos desde los siguientes canales de prioridad más baja, y
ninguna otra TFC tiene una tasa de bits más baja
que la TFC elegida.
26. El aparato de la Reivindicación 15, en el
que el medio para proporcionar comprende también:
un medio para proporcionar el conjunto de TFC
completo sólo si el conjunto de TFC completo puede ser
soportado.
27. Aparato para planificar la transmisión de
datos en una red de comunicación por radio que elimina una necesidad
de determinar los requisitos de potencia para cada Transport Format
Combination (TFC) (Combinación de Formatos de Transporte) en cada
intervalo de tiempo, comprendiendo la citada red:
al menos una capa física y una capa de Medium
Access Control (MAC) (Control de Acceso Medio);
comprendiendo la citada capa física:
un medio para monitorizar la potencia de
transmisión en un intervalo de tiempo; y
un medio para enviar una notificación a la capa
de MAC de que la potencia máxima ha sido alcanzada, junto con el
número del intervalo de tiempo;
comprendiendo la citada capa de MAC:
un medio para proporcionar una de un conjunto de
TFC completo y un conjunto de TFC mínimo basándose en una
notificación de potencia desde la capa física.
28. El método de la Reivindicación 13, en el que
el citado MAC:
estableciendo un conjunto de TFC mínimo:
prediciendo, después de cada trama de operación
de un Coded Composite Transport Channel (CCTrCH) (Canal de
Transporte Compuesto Codificado), una potencia necesitada por un
conjunto de TFC completo para el citado CCTrCH en una trama
siguiente;
\newpage
incluyendo el conjunto de TFC completo en un
conjunto de TFC candidato cuando la potencia de transmisión predicha
es menor que la potencia de transmisión del User Equipment (UE)
(Equipo de Usuario) permitida máxima para tres (3) tramas
consecutivas.
29. El método de la Reivindicación 28 en el que
la citada capa de MAC es un canal MAD-dedicado del
tipo (MAC-d).
30. El método de la Reivindicación 28 en el que
el conjunto de TFC mínimo es empleado por el citado MAC cuando la
citada potencia de transmisión predicha no es menor que la citada
potencia de UE permitida máxima para las citadas tres (3) tramas
consecutivas.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US43584202P | 2002-12-20 | 2002-12-20 | |
| US435842P | 2002-12-20 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2316874T3 true ES2316874T3 (es) | 2009-04-16 |
Family
ID=32682284
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES03814239T Expired - Lifetime ES2316874T3 (es) | 2002-12-20 | 2003-12-19 | Planificacion de transmision de datos a traves de capa de control de acceso al medio (mac) en una red de telefonia celular. |
Country Status (16)
| Country | Link |
|---|---|
| US (5) | US7058032B2 (es) |
| EP (4) | EP2785121B1 (es) |
| JP (2) | JP4271659B2 (es) |
| KR (6) | KR100979161B1 (es) |
| CN (2) | CN1729630B (es) |
| AT (1) | ATE417418T1 (es) |
| AU (3) | AU2003301161B2 (es) |
| CA (1) | CA2511324C (es) |
| DE (1) | DE60325272D1 (es) |
| DK (1) | DK1573935T3 (es) |
| ES (1) | ES2316874T3 (es) |
| MX (1) | MXPA05006600A (es) |
| NO (3) | NO337783B1 (es) |
| SG (1) | SG159386A1 (es) |
| TW (3) | TWI337470B (es) |
| WO (1) | WO2004059869A1 (es) |
Families Citing this family (62)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GEP20094593B (en) * | 2003-03-26 | 2009-01-26 | Interdigital Tech Corp | Wireless multi-cell communication system for managing resource power to provide high speed downlink packet access services |
| TWI240204B (en) * | 2003-08-04 | 2005-09-21 | Via Tech Inc | Network apparatus and method capable of wake on LAN after abnormal shutdown |
| FI20031414L (fi) * | 2003-09-30 | 2005-03-31 | Nokia Corp | Datan siirtäminen langattoman pakettivälitteisen datajärjestelmän matkaviestimessä |
| SE0302685D0 (sv) * | 2003-10-07 | 2003-10-07 | Ericsson Telefon Ab L M | Method and arrangement in a telecommunication system |
| JP4115928B2 (ja) * | 2003-12-17 | 2008-07-09 | 富士通株式会社 | トランスポートチャネル選択装置及び選択方法 |
| US7525925B2 (en) * | 2003-12-31 | 2009-04-28 | Stmicroelectronics Asia Pacific Pte. Ltd. | System and method for selecting an optimal transport format combination using progressive set reduction |
| KR100595645B1 (ko) * | 2004-01-09 | 2006-07-03 | 엘지전자 주식회사 | 이동통신 시스템에서의 제어정보 전송방법 |
| WO2005112296A2 (en) | 2004-04-29 | 2005-11-24 | Interdigital Technology Corporation | Wireless communication method and system for configuring radio access bearers for enhanced uplink services |
| WO2005115025A2 (en) * | 2004-05-07 | 2005-12-01 | Interdigital Technology Corporation | Wireless communication system and method for configuring cells with enhanced uplink services |
| KR101153598B1 (ko) | 2004-06-11 | 2012-06-11 | 닛본 덴끼 가부시끼가이샤 | 트랜스포트 포맷 콤비네이션 선택 방법, 무선 통신 시스템 및 이동국 |
| KR101059876B1 (ko) * | 2004-06-16 | 2011-08-29 | 엘지전자 주식회사 | 이동통신 시스템의 서비스 품질 보장을 위한 데이터전송량 선택 방법 |
| US7885245B2 (en) | 2004-07-19 | 2011-02-08 | Interdigital Technology Corporation | Method and apparatus for enhanced uplink multiplexing |
| CN100353686C (zh) * | 2004-08-11 | 2007-12-05 | 华为技术有限公司 | 高速上行分组接入中传输信道格式指示状态的转换方法 |
| DE102004044957B4 (de) * | 2004-09-16 | 2007-04-19 | Infineon Technologies Ag | Medium-Zugriffs-Steuerungs-Einheit, Mobilfunkeinrichtung und Verfahren zum Abbilden mittels einer Mobilfunkeinrichtung zu übertragender Daten |
| WO2006036049A1 (en) * | 2004-09-30 | 2006-04-06 | Samsung Electronics Co., Ltd. | Method and apparatus for transmitting uplink non-scheduled data in a mobile communication system |
| CN1798420A (zh) * | 2004-12-22 | 2006-07-05 | 上海贝尔阿尔卡特股份有限公司 | 用于在基站中进行快速资源调度的方法与基站 |
| CN1798446B (zh) * | 2004-12-29 | 2010-09-29 | 北京三星通信技术研究有限公司 | 在Mac-ePDU 中传输短信令的方法 |
| US20090122703A1 (en) * | 2005-04-13 | 2009-05-14 | Koninklijke Philips Electronics, N.V. | Electronic Device and Method for Flow Control |
| TWI544769B (zh) * | 2005-04-20 | 2016-08-01 | 內數位科技公司 | 經強化專用頻道排程傳輸方法及裝置 |
| US7408895B2 (en) * | 2005-04-20 | 2008-08-05 | Interdigital Technology Corporation | Method and apparatus for scheduling transmissions via an enhanced dedicated channel |
| US8179836B2 (en) * | 2005-04-20 | 2012-05-15 | Interdigital Technology Corporation | Method and apparatus for controlling transmissions via an enhanced dedicated channel |
| US8116292B2 (en) * | 2005-04-29 | 2012-02-14 | Interdigital Technology Corporation | MAC multiplexing and TFC selection procedure for enhanced uplink |
| TWI380651B (en) | 2005-04-29 | 2012-12-21 | Interdigital Tech Corp | Mac multiplexing and tfc selection procedure for enhanced uplink |
| EP1890400A4 (en) | 2005-05-02 | 2012-12-05 | Ntt Docomo Inc | TRANSMISSION CONTROL SYSTEM, MOBILE STATION, RADIO BASE STATION AND RADIO NETWORK CONTROL STATION |
| US20070036112A1 (en) * | 2005-08-15 | 2007-02-15 | Chien-Yi Chen | Method of determining next Transport Format Combination for being utilized in next Transmission Time Interval |
| US7839828B2 (en) | 2005-12-15 | 2010-11-23 | Interdigital Technology Corporation | Method and apparatus for selecting a transport format combination |
| JP4724755B2 (ja) * | 2005-12-15 | 2011-07-13 | インターデイジタル テクノロジー コーポレーション | トランスポート・フォーマット・コンビネーションを選択するための方法および装置 |
| KR100918743B1 (ko) * | 2006-01-18 | 2009-09-24 | 삼성전자주식회사 | 무선통신 시스템에서 전송포맷 조합의 선택 방법 및 장치 |
| EP2262341B1 (en) * | 2006-03-07 | 2016-11-02 | Panasonic Corporation | Overhead reduction of uplink control signaling in a mobile communication system |
| JP2007259031A (ja) * | 2006-03-23 | 2007-10-04 | Fujitsu Ltd | 移動通信システム及びフロー制御方法 |
| KR100752360B1 (ko) * | 2006-04-25 | 2007-08-27 | 광주과학기술원 | 무선 네트워크에서 가용 무선 자원량을 모니터링하는 방법,이를 이용한 데이터의 전송 방법, 무선 송신 단말기 및네트워크 |
| ATE502447T1 (de) * | 2006-11-02 | 2011-04-15 | Interdigital Tech Corp | Verfahren und vorrichtung zur optimierung von e- tfc-beschränkung für hsupa-kanäle |
| WO2008078907A1 (en) * | 2006-12-22 | 2008-07-03 | Samsung Electronics Co., Ltd. | A method of coupon based uplink scheduling and tfc selection |
| CN101232493B (zh) * | 2007-01-26 | 2011-04-20 | 中兴通讯股份有限公司 | 无线链路控制层确认模式下pdu尺寸确定方法和装置 |
| TW201503650A (zh) * | 2007-02-02 | 2015-01-16 | Interdigital Tech Corp | 可辯ｒｌｃ ｐｄｕ大小之增強ｒｌｃ方法及裝置 |
| ES2734122T3 (es) * | 2007-05-01 | 2019-12-04 | Nokia Technologies Oy | Selección de formato de transporte de enlace ascendente |
| KR100911304B1 (ko) * | 2007-06-18 | 2009-08-11 | 엘지전자 주식회사 | 무선통신 시스템에서 우선순위를 갖는 무선베어러의 데이터전송 방법 |
| CN101179595B (zh) * | 2007-12-10 | 2011-05-04 | 中国科学院计算技术研究所 | 一种无线通信数据收发设备和系统及数据处理方法 |
| WO2009075624A1 (en) * | 2007-12-13 | 2009-06-18 | Telefonaktiebolaget Lm Ericsson (Publ) | Transport format selection in enhanced ul |
| ES2436651T3 (es) | 2008-02-01 | 2014-01-03 | Interdigital Patent Holdings, Inc. | Método y aparato para priorizar canales lógicos |
| TWI357754B (en) * | 2008-03-25 | 2012-02-01 | Inventec Appliances Corp | Apparatus and method of 3g mobile communication ca |
| EP3229521A1 (en) * | 2008-04-30 | 2017-10-11 | Samsung Electronics Co., Ltd | System and method for data size adaptation in a ue |
| KR100968020B1 (ko) * | 2008-06-18 | 2010-07-08 | 엘지전자 주식회사 | 랜덤 액세스 절차를 수행하는 방법 및 그 단말 |
| GB2461780B (en) | 2008-06-18 | 2011-01-05 | Lg Electronics Inc | Method for detecting failures of random access procedures |
| US9125164B2 (en) * | 2008-06-18 | 2015-09-01 | Lg Electronics Inc. | Method of transmitting power headroom reporting in wireless communication system |
| GB2461158B (en) | 2008-06-18 | 2011-03-02 | Lg Electronics Inc | Method for performing random access procedures and terminal therof |
| GB2461159B (en) | 2008-06-18 | 2012-01-04 | Lg Electronics Inc | Method for transmitting Mac PDUs |
| US11272449B2 (en) | 2008-06-18 | 2022-03-08 | Optis Cellular Technology, Llc | Method and mobile terminal for performing random access |
| US7957298B2 (en) * | 2008-06-18 | 2011-06-07 | Lg Electronics Inc. | Method for detecting failures of random access procedures |
| US8358614B2 (en) | 2008-10-31 | 2013-01-22 | Interdigital Patent Holdings, Inc. | Method and apparatus for handling uplink transmissions using multiple uplink carriers |
| US8306059B2 (en) * | 2008-11-05 | 2012-11-06 | Htc Corporation | Method of constructing and transmitting packets with MIMO configuration in a wireless communication system and related communication device |
| KR101122095B1 (ko) | 2009-01-05 | 2012-03-19 | 엘지전자 주식회사 | 불필요한 재전송 방지를 위한 임의접속 기법 및 이를 위한 단말 |
| US20100281486A1 (en) * | 2009-05-04 | 2010-11-04 | HT mMobile Inc. | Enhanced scheduling, priority handling and multiplexing method and system |
| CN101631386B (zh) * | 2009-08-18 | 2011-09-21 | 中兴通讯股份有限公司 | 传输格式组合的选择方法及装置 |
| US8937956B2 (en) * | 2011-05-31 | 2015-01-20 | Broadcom Corporation | Interleaving audio and video packets |
| US9008047B2 (en) * | 2012-01-18 | 2015-04-14 | Qualcomm Incorporated | Methods and apparatuses for implementing a multi-RAB minimum TFC determination algorithm based on transmit power |
| US9398490B2 (en) * | 2013-03-15 | 2016-07-19 | Trane International Inc. | Method of fragmenting a message in a network |
| US9474067B2 (en) * | 2013-03-26 | 2016-10-18 | Qualcomm Incorporated | WLAN uplink scheduler for LTE-WLAN aggregation |
| US10348466B2 (en) * | 2015-11-03 | 2019-07-09 | Qualcomm Incorporated | Transport block segmentation and signaling |
| US20190150176A1 (en) * | 2016-05-12 | 2019-05-16 | Idac Holdings, Inc. | Flow-based processing in wireless systems |
| CN109076096B (zh) * | 2016-05-13 | 2021-09-07 | 苹果公司 | 无线设备的装置 |
| EP3777311B1 (en) * | 2018-04-03 | 2023-06-28 | LG Electronics Inc. | Method and apparatus for transmitting signals by tm rlc entity of transmission end in wireless communication system |
Family Cites Families (66)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5265261A (en) | 1989-08-14 | 1993-11-23 | Microsoft Corporation | Method and system for network communications using raw mode protocols |
| JPH08329612A (ja) * | 1995-06-02 | 1996-12-13 | Sony Corp | データ記録ディスク |
| US5742592A (en) | 1995-09-01 | 1998-04-21 | Motorola, Inc. | Method for communicating data in a wireless communication system |
| EP2242321B1 (en) | 1995-09-20 | 2015-07-22 | Ntt Docomo, Inc. | Access method, mobile station and base station for CDMA mobile communication system |
| US5732087A (en) * | 1996-05-10 | 1998-03-24 | Mitsubishi Electric Information Technology Center America, Inc. | ATM local area network switch with dual queues |
| CA2220900C (en) | 1996-11-14 | 2002-02-12 | Ntt Mobile Communications Network Inc. | Paging scheme for mobile communication system using increased paging channel data transmission rate |
| TW391009B (en) | 1997-02-14 | 2000-05-21 | Powerchip Semiconductor Corp | Charge recycling net structure in dynamic random access memory |
| US5914950A (en) | 1997-04-08 | 1999-06-22 | Qualcomm Incorporated | Method and apparatus for reverse link rate scheduling |
| US6273622B1 (en) | 1997-04-15 | 2001-08-14 | Flash Networks, Ltd. | Data communication protocol for maximizing the performance of IP communication links |
| US5956368A (en) | 1997-08-29 | 1999-09-21 | Telefonaktiebolaget Lm Ericsson | Downlink channel handling within a spread spectrum communications system |
| US6206624B1 (en) * | 1998-01-04 | 2001-03-27 | Rachel B. Brandenburg | Cargo space divider |
| US6594238B1 (en) | 1998-06-19 | 2003-07-15 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for dynamically adapting a connection state in a mobile communications system |
| KR100429540B1 (ko) * | 1998-08-26 | 2004-08-09 | 삼성전자주식회사 | 이동통신시스템의패킷데이터통신장치및방법 |
| TW421950B (en) | 1998-09-25 | 2001-02-11 | Ind Tech Res Inst | An efficient traffic scheduling algorithm in central-control shared-media networks |
| KR100619598B1 (ko) * | 1998-10-01 | 2006-12-01 | 엘지전자 주식회사 | 이동통신시스템에서의 신호 포맷방법 |
| KR100317261B1 (ko) * | 1999-07-02 | 2001-12-22 | 서평원 | 능동적 무선 접속 베어러 제어 방법 |
| US6493541B1 (en) * | 1999-07-02 | 2002-12-10 | Telefonaktiebolaget Lm Ericsson (Publ) | Transmit power control time delay compensation in a wireless communications system |
| EP1192831B1 (en) * | 1999-07-05 | 2004-01-02 | Nokia Corporation | Method for selection of coding method |
| FR2797736B1 (fr) * | 1999-08-19 | 2001-10-12 | Mitsubishi Electric France | Procede de configuration d'un systeme de telecommunications |
| WO2001020625A1 (en) * | 1999-09-10 | 2001-03-22 | Matsushita Electric Industrial Co., Ltd. | Solid electrolytic capacitor and production method thereof, and conductive polymer polymerizing oxidizing agent solution |
| FR2799320B1 (fr) * | 1999-10-04 | 2002-05-17 | Mitsubishi Electric France | Procede d'equilibrage de debit entre des canaux de transport de donnees, dispositif, station de base et station mobile correspondants |
| US6519461B1 (en) * | 1999-10-29 | 2003-02-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Channel-type switching from a common channel to a dedicated channel based on common channel load |
| EP1104216A1 (en) * | 1999-11-23 | 2001-05-30 | Lucent Technologies Inc. | Mobile telecommunications systems |
| US6760596B1 (en) * | 1999-12-03 | 2004-07-06 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and system for bit-rate adaptation to improve coverage |
| CN101364837B (zh) * | 2000-01-14 | 2016-02-03 | 交互数字技术公司 | 用于码分多址通信的设备和方法 |
| EP1127613A1 (de) * | 2000-02-18 | 2001-08-29 | Degussa AG | Geformter Festbettraney-Kupferkatalysator zur Verwendung bei der Dehydrierung von Alkoholen |
| CN1312885C (zh) * | 2000-02-25 | 2007-04-25 | 艾利森电话股份有限公司 | 通信系统中发射机和接收机实体之间的流控制 |
| FR2806576B1 (fr) * | 2000-03-15 | 2004-04-23 | Nortel Matra Cellular | Procede d'emission de signaux radio, reseau d'acces et terminal de radiocommunication appliquant le procede |
| BR0107546A (pt) * | 2000-04-07 | 2004-01-06 | Nokia Corp | Método e aparelho de transmissão de unidades de dados de protocolo de tamanho fixo através da camada de controle de enlace de rádio transparente |
| AU2001261848A1 (en) * | 2000-05-18 | 2001-11-26 | Brix Networks, Inc. | Method and system for transmit time stamp insertion in a hardware time stamp system for packetized data networks |
| FR2809577B1 (fr) * | 2000-05-25 | 2002-10-18 | Mitsubishi Electric Inf Tech | Methode de transmission de donnees combattant la degradation de la qualite de service |
| WO2001097411A1 (en) * | 2000-06-12 | 2001-12-20 | Samsung Electronics Co., Ltd | Method of assigning an uplink random access channel in a cdma mobile communication system |
| EP1170919A1 (en) * | 2000-07-04 | 2002-01-09 | TELEFONAKTIEBOLAGET LM ERICSSON (publ) | Method and device for improving the transmission efficiency in a communication system with a layered protocol stack |
| TW484283B (en) | 2000-08-11 | 2002-04-21 | Ind Tech Res Inst | Dynamic scheduling scheduler framework and method for mobile communication |
| AU2001293783A1 (en) | 2000-09-29 | 2002-04-08 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and system for transmitting data |
| JP3949584B2 (ja) * | 2000-10-09 | 2007-07-25 | シーメンス アクチエンゲゼルシヤフト | 移動無線システムの無線インターフェースを介するデータパケットの伝送のための方法 |
| KR100352895B1 (ko) * | 2000-11-14 | 2002-09-16 | 에스케이 텔레콤주식회사 | 비동기 이동 통신 시스템에서의 하이브리드 에이알큐의적용을 위한 부가 정보 전송 방법 |
| CN1265654C (zh) * | 2000-11-14 | 2006-07-19 | 皇家菲利浦电子有限公司 | 具有选择传输格式组合的无线网络 |
| US6847623B1 (en) * | 2000-11-15 | 2005-01-25 | Qualcomm Incorporated | Method and apparatus for allocating data streams onto a single channel |
| EP1209940A1 (en) * | 2000-11-22 | 2002-05-29 | Lucent Technologies Inc. | Method and system for UMTS packet transmission scheduling on uplink channels |
| US6425905B1 (en) * | 2000-11-29 | 2002-07-30 | Med-Logics, Inc. | Method and apparatus for facilitating removal of a corneal graft |
| KR100365185B1 (ko) * | 2000-12-07 | 2002-12-18 | 에스케이 텔레콤주식회사 | 비동기 이동 통신 시스템에서의 물리 계층 재코딩을이용한 소프트 콤바인 적용 방법 및 장치 |
| US7042883B2 (en) * | 2001-01-03 | 2006-05-09 | Juniper Networks, Inc. | Pipeline scheduler with fairness and minimum bandwidth guarantee |
| FR2819365B1 (fr) * | 2001-01-11 | 2003-03-28 | Mitsubishi Electric Telecom Eu | Procede de selection d'une combinaison de formats de transport pour canaux de transport dans une station mobile et station correspondante |
| DE10101703A1 (de) * | 2001-01-15 | 2002-07-18 | Philips Corp Intellectual Pty | Drahtloses Netzwerk mit einer Auswahl von Transport-Format-Kombinationen |
| US6813284B2 (en) * | 2001-01-17 | 2004-11-02 | Qualcomm Incorporated | Method and apparatus for allocating data streams given transmission time interval (TTI) constraints |
| DE10107700A1 (de) * | 2001-02-19 | 2002-08-29 | Siemens Ag | Verfahren und Vorrichtung zum Multiplexen und/oder Demultiplexen sowie entsprechende Computerprogramme und ein entsprechendes Computerprogramm-Erzeugnis |
| KR100830494B1 (ko) * | 2001-02-20 | 2008-05-20 | 엘지전자 주식회사 | 이동통신 시스템에서의 트래픽 볼륨 측정방법 |
| CA2376962A1 (en) * | 2001-04-02 | 2002-10-02 | Lucent Technologies Inc. | Method and system for umts packet transmission scheduling on uplink channels |
| CN1439206A (zh) * | 2001-04-25 | 2003-08-27 | 三菱电机株式会社 | 数据解码方法 |
| DE10124940A1 (de) * | 2001-05-21 | 2002-11-28 | Philips Corp Intellectual Pty | Netzwerk mit logischen Kanälen und Transportkanälen |
| EP1283650A1 (de) * | 2001-08-07 | 2003-02-12 | Siemens Aktiengesellschaft | Verfahren, Sende-/Empfangseinheit und Kommunikationssystem zur Übertragung von Daten von einem Versender an mehrere Empfänger |
| CN1140077C (zh) * | 2001-08-15 | 2004-02-25 | 信息产业部电信传输研究所 | 无线多媒体cdma通信系统有效闭环功率控制方法 |
| KR100825413B1 (ko) * | 2001-08-21 | 2008-04-29 | 노키아 코포레이션 | 통신 네트워크내에서의 데이터 전송 |
| US6845088B2 (en) * | 2001-10-19 | 2005-01-18 | Interdigital Technology Corporation | System and method for fast dynamic link adaptation |
| KR100493079B1 (ko) * | 2001-11-02 | 2005-06-02 | 삼성전자주식회사 | 고속 순방향 패킷 접속 방식을 사용하는 광대역 부호 분할다중 접속 통신 시스템에서 순방향 채널 품질을 보고하는장치 및 방법 |
| US6747958B2 (en) * | 2001-11-13 | 2004-06-08 | Qualcomm, Incorporated | Transport format combination selection for compressed mode in a W-CDMA system |
| US6904016B2 (en) * | 2001-11-16 | 2005-06-07 | Asustek Computer Inc. | Processing unexpected transmission interruptions in a wireless communications system |
| US7254143B2 (en) * | 2001-11-19 | 2007-08-07 | Innovative Sonic Limited | Local suspend scheme for wireless communication systems |
| KR100810281B1 (ko) * | 2002-03-30 | 2008-03-07 | 삼성전자주식회사 | 부호분할다중접속 이동통신시스템에서 전송 포맷 선택을위한 검색시간 최소화 방법 |
| JP4005400B2 (ja) * | 2002-04-10 | 2007-11-07 | 富士通株式会社 | 送信フォーマット組み合わせ情報選択方法及び移動端末装置 |
| US7539165B2 (en) * | 2002-05-24 | 2009-05-26 | Antti Toskala | Method and apparatus for distributed signaling for uplink rate control |
| US6888257B2 (en) * | 2002-06-28 | 2005-05-03 | Lord Corporation | Interface adhesive |
| US20040017771A1 (en) * | 2002-07-29 | 2004-01-29 | Brocade Communications Systems, Inc. | Cascade credit sharing for fibre channel links |
| US6882857B2 (en) * | 2002-11-26 | 2005-04-19 | Qualcomm, Incorporated | Method and apparatus for efficient processing of data for transmission in a communication system |
| US7339988B1 (en) * | 2003-07-03 | 2008-03-04 | Scintera Networks, Inc. | Channel monitoring and identification and performance monitoring in a flexible high speed signal processor engine |
-
2003
- 2003-12-19 CN CN2003801067511A patent/CN1729630B/zh not_active Expired - Fee Related
- 2003-12-19 WO PCT/US2003/040702 patent/WO2004059869A1/en not_active Ceased
- 2003-12-19 ES ES03814239T patent/ES2316874T3/es not_active Expired - Lifetime
- 2003-12-19 KR KR1020087030844A patent/KR100979161B1/ko not_active Expired - Fee Related
- 2003-12-19 AU AU2003301161A patent/AU2003301161B2/en not_active Ceased
- 2003-12-19 DE DE60325272T patent/DE60325272D1/de not_active Expired - Lifetime
- 2003-12-19 CN CN2008101868228A patent/CN101483454B/zh not_active Expired - Fee Related
- 2003-12-19 EP EP14165482.2A patent/EP2785121B1/en not_active Expired - Lifetime
- 2003-12-19 KR KR1020097014451A patent/KR101010983B1/ko not_active Expired - Fee Related
- 2003-12-19 TW TW093120827A patent/TWI337470B/zh not_active IP Right Cessation
- 2003-12-19 KR KR1020107013083A patent/KR20100087219A/ko not_active Withdrawn
- 2003-12-19 EP EP03814239A patent/EP1573935B1/en not_active Expired - Lifetime
- 2003-12-19 KR KR1020107000353A patent/KR20100018053A/ko not_active Withdrawn
- 2003-12-19 MX MXPA05006600A patent/MXPA05006600A/es active IP Right Grant
- 2003-12-19 DK DK03814239T patent/DK1573935T3/da active
- 2003-12-19 TW TW095146539A patent/TWI333754B/zh not_active IP Right Cessation
- 2003-12-19 AT AT03814239T patent/ATE417418T1/de not_active IP Right Cessation
- 2003-12-19 CA CA2511324A patent/CA2511324C/en not_active Expired - Fee Related
- 2003-12-19 TW TW092136328A patent/TWI257796B/zh not_active IP Right Cessation
- 2003-12-19 KR KR1020057017371A patent/KR100947914B1/ko not_active Expired - Fee Related
- 2003-12-19 KR KR1020057011674A patent/KR100772470B1/ko not_active Expired - Fee Related
- 2003-12-19 US US10/742,539 patent/US7058032B2/en not_active Expired - Lifetime
- 2003-12-19 EP EP14165479.8A patent/EP2797376B1/en not_active Expired - Lifetime
- 2003-12-19 SG SG200703389-7A patent/SG159386A1/en unknown
- 2003-12-19 EP EP08168313.8A patent/EP2017972B1/en not_active Expired - Lifetime
- 2003-12-19 JP JP2004563853A patent/JP4271659B2/ja not_active Expired - Fee Related
-
2005
- 2005-07-14 NO NO20053421A patent/NO337783B1/no not_active IP Right Cessation
-
2006
- 2006-05-04 US US11/417,593 patent/US7596117B2/en not_active Expired - Lifetime
-
2007
- 2007-08-07 JP JP2007205947A patent/JP4570646B2/ja not_active Expired - Fee Related
- 2007-08-31 AU AU2007214355A patent/AU2007214355B2/en not_active Ceased
-
2009
- 2009-09-28 US US12/568,029 patent/US8644229B2/en not_active Expired - Fee Related
-
2010
- 2010-03-10 AU AU2010200900A patent/AU2010200900B2/en not_active Expired
-
2014
- 2014-01-14 US US14/154,830 patent/US9392490B2/en not_active Expired - Fee Related
- 2014-10-23 NO NO20141262A patent/NO341774B1/no not_active IP Right Cessation
-
2016
- 2016-07-11 US US15/207,084 patent/US9867208B2/en not_active Expired - Fee Related
-
2017
- 2017-07-19 NO NO20171210A patent/NO20171210A1/no not_active Application Discontinuation
Also Published As
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2316874T3 (es) | Planificacion de transmision de datos a traves de capa de control de acceso al medio (mac) en una red de telefonia celular. | |
| HK1203735B (en) | Scheduling data transmission by medium access control (mac) layer in a mobile network | |
| HK1081017B (en) | Scheduling data transmission by medium access control (mac) layer in a mobile network |