Sign In to Follow Application
View All Documents & Correspondence

Control Channel Signaling Using A Common Signaling Field For Transport Format And Redundancy Version

Abstract: The invention relates to a method for providing control signalling associated to a protocol data unit conveying user data in a mobile communication system and to the control channel signal itself. Furthermore, the invention also provides a mobile station and a base station and their respective operation in view of the newly defined control channel signals defined herein. In order to reduce the control channel overhead, the invention suggests defining a common field for the transport format and redundancy version in the control channel information format. According to one approach, the common field is used to jointly encode transport format and redundancy version therein. According to another aspect, one shared field is provided on the control channel signal that indicates either a transport format or a redundancy version depending of whether the control channel signal relates to an initial transmission or a retransmission. In another embodiment, further enhancements to a HARQ protocol are suggested for addressing certain error cases.

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
09 June 2010
Publication Number
41/2010
Publication Type
INA
Invention Field
COMMUNICATION
Status
Email
mail@lexorbis.com
Parent Application
Patent Number
Legal Status
Grant Date
2019-04-29
Renewal Date

Applicants

PANASONIC CORPORATION
1006, OAZA KADOMA, KADOMA-SHI, OSAKA 571-8501 JAPAN

Inventors

1. WENGERTER, CHRISTIAN
C/O PANASONIC R & D CENTER GERMANY GMBH, MONZASTRASSE 4C, 63225 LANGEN GERMANY
2. NISHIO, AKIHIKO
C/O MATSUSHITA ELECTRIC INDUSTRIAL CO., LTD., 7F TWIN 21 OBP PANASONIC TOWER, 2-1-61 SHIROMI, CHUO-KU, OSAKA 540-6207 JAPAN
3. SUZUKI, HIDETOSHI
7F TWIN 21 OBP PANASONIC TOWER, 2-1-61 SHIROMI, CHUO-KU, OSAKA 540-6207 JAPAN
4. LÖHR, JOACHIM
C/O PANASONIC R & D CENTER, MONZASTRASSE 4C, 63225 LANGEN GERMANY
5. HIRAMATSU, KATSUHIKO
7F TWIN 21 OBP PANASONIC TOWER, 2-1-61, SHIROMI, CHUO-KU, OSAKA 540-6207 JAPAN

Specification

Control Channel Signaling using a Common Signaling Field
for Transport Format and Redundancy Version
FIELD OF THE INVENTION
The invention relates to a method for providing control signalling associated to a protocol
data unit conveying user data in a mobile communication system and to the control
channel signal itself. Furthermore, the invention also provides a mobile station and a
base station and their respective operation in view of the newly defined control channel
signals defined herein.
TECHNICAL BACKGROUND
Packet-Scheduling and Shared Channel Transmission
In wireless communication systems employing packet-scheduling, at least part of the
air-interface resources are assigned dynamically to different users (mobile stations - MS
or user equipments - UE). Those dynamically allocated resources are typically mapped
to at least one Physical Uplink or Downlink Shared CHannel (PUSCH or PDSCH). A
PUSCH or PDSCH may for example have one of the following configurations:
- One or multiple codes in a CDMA (Code Division Multiple Access) system are
dynamically shared between multiple MS.
- One or multiple subcarriers (subbands) in an OFDMA (Orthogonal Frequency Division
Multiple Access) system are dynamically shared between multiple MS.
- Combinations of the above in an OFCDMA (Orthogonal Frequency Code Division
Multiplex Access) or a MC-CDMA (Multi Carrier-Code Division Multiple Access)
system are dynamically shared between multiple MS.
Fig. 1 shows a packet-scheduling system on a shared channel for systems with a single
shared data channel. A sub-frame (also referred to as a time slot) reflects the smallest
interval at which the scheduler (e.g. the Physical Layer or MAC Layer Scheduler)
performs the dynamic resource allocation (DRA). In Fig. 1, a TTI (transmission time
interval) equal to one sub-frame is assumed. It should be born noted that generally a TTI
may also span over multiple sub-frames.
Further, the smallest unit of radio resources (also referred to as a resource block or
resource unit), which can be allocated in OFDM systems, is typically defined by one sub-
frame in time domain and by one subcarrier/subband in the frequency domain. Similarly,
in a CDMA system this smallest unit of radio resources is defined by a sub-frame in the
time domain and a code in the code domain.
In OFCDMA or MC-CDMA systems, this smallest unit is defined by one sub-frame in
time domain, by one subcarrier/subband in the frequency domain and one code in the
code domain. Note that dynamic resource allocation may be performed in time domain
and in code/frequency domain.
The main benefits of packet-scheduling are the multi-user diversity gain by time domain
scheduling (TDS) and dynamic user rate adaptation.
Assuming that the channel conditions of the users change over time due to fast (and
slow) fading, at a given time instant the scheduler can assign available resources (codes
in case of CDMA, subcarriers/subbands in case of OFDMA) to users having good
channel conditions in time domain scheduling.
Specifics of DRA and Shared Channel Transmission in OFDMA
Additionally to exploiting multi-user diversity in time domain by Time Domain Scheduling
(TDS), in OFDMA multi-user diversity can also be exploited in frequency domain by
Frequency Domain Scheduling (FDS). This is because the OFDM signal is in frequency
domain constructed out of multiple narrowband subcarriers (typically grouped into
subbands), which can be assigned dynamically to different users. By this, the frequency
selective channel properties due to multi-path propagation can be exploited to schedule
users on frequencies (subcarriers/subbands) on which they have a good channel quality
(multi-user diversity in frequency domain).
For practical reasons in an OFDMA system the bandwidth is divided into multiple
subbands, which consist out of multiple subcarriers. I.e. the smallest unit on which a user
may be allocated would have a bandwidth of one subband and a duration of one slot or
one sub-frame (which may correspond to one or multiple OFDM symbols), which is
denoted as a resource block (RB). Typically, a subband consists of consecutive
subcarriers. However, in some case it is desired to form a subband out of distributed
non-consecutive subcarriers. A scheduler may also allocate a user over multiple
consecutive or non-consecutive subbands and/or sub-frames.
For the 3GPP Long Term Evolution (3GPP TR 25.814: "Physical Layer Aspects for
Evolved UTRA", Release 7, v. 7.1.0, October 2006 - available at http://www.3gpp.org
and incorporated herein by reference), a 10 MHz system (normal cyclic prefix) may
consist out of 600 subcarriers with a subcarrier spacing of 15 kHz. The 600 subcarriers
may then be grouped into 50 subbands (a 12 adjacent subcarriers), each subband
occupying a bandwidth of 180 kHz. Assuming, that a slot has a duration of 0.5 ms, a
resource block (RB) spans over 180 kHz and 0.5 ms according to this example.
In order to exploit multi-user diversity and to achieve scheduling gain in frequency
domain, the data for a given user should be allocated on resource blocks on which the
users have a good channel condition. Typically, those resource blocks are close to each
other and therefore, this transmission mode is in also denoted as localized mode (LM).
An example for a localized mode channel structure is shown in Fig. 2. In this example
neighboring resource blocks are assigned to four mobile stations (MS1 to MS4) in the
time domain and frequency domain. Each resource block consists of a portion for
carrying Layer 1 and/or Layer 2 control signaling (L1/I2 control signaling) and a portion
carrying the user data for the mobile stations.
Alternatively, the users may be allocated in a distributed mode (DM) as shown in Fig. 3.
In this configuration, a user (mobile station) is allocated on multiple resource blocks,
which are distributed over a range of resource blocks. In distributed mode a number of
different implementation options are possible. In the example shown in Fig. 3, a pair of
users (MSs 1/2 and MSs 3/4) shares the same resource blocks. Several further possible
exemplary implementation options may be found in 3GPP RAN WG#1 Tdoc R1-062089,
"Comparison between RB-level and Sub-carrier-level Distributed Transmission for
Shared Data Channel in E-UTRA Downlink", August 2006 (available at
http://www.3gpp.org and incorporated herein by reference).
It should be noted, that multiplexing of localized mode and distributed mode within a
sub-frame is possible, where the amount of resources (RBs) allocated to localized mode
and distributed mode may be fixed, semi-static (constant for tens/hundreds of
sub-frames) or even dynamic (different from sub-frame to sub-frame).
In localized mode as well as in distributed mode in - a given sub-frame - one or multiple
data blocks (which are inter alia referred to as transport-blocks) may be allocated
separately to the same user (mobile station) on different resource blocks, which may or
may not belong to the same service or Automatic Repeat reQuest (ARQ) process.
Logically, this can be understood as allocating different users.
L1/L2 Control signaling
In order to provide sufficient side information to correctly receive or transmit data in
systems employing packet scheduling, so-called L1/L2 control signaling (Physical
Downlink Control CHannel - PDCCH) needs to be transmitted. Typical operation
mechanisms for downlink and uplink data transmission are discussed below.
Downlink Data Transmission
Along with the downlink packet data transmission, in existing implementations using a
shared downlink channel, such as 3GPP-based High Speed Data Packet Access
(HSDPA), L1/L2 control signaling is typically transmitted on a separate physical (control)
channel.
This L1/L2 control signaling typically contains information on the physical resource(s) on
which the downlink data is transmitted (e.g. subcarriers or subcarrier blocks in case of
OFDM, codes in case of CDMA). This information allows the mobile station (receiver) to
identify the resources on which the data is transmitted. Another parameter in the control
signaling is the transport format used for the transmission of the downlink data.
Typically, there are several possibilities to indicate the transport format. For example, the
transport block size of the data (payload size, information bits size), the Modulation and
Coding Scheme (MCS) level, the Spectral Efficiency, the code rate, etc. may be signaled
to indicate the transport format (TF). This information (usually together with the resource
allocation) allows the mobile station (receiver) to identify the information bit size, the
modulation scheme and the code rate in order to start the demodulation, the
de-rate-matching and the decoding process. In some cases the modulation scheme
maybe signaled explicitly.
In addition, in systems employing Hybrid ARQ (HARQ), HARQ information may also form
part of the L1/L2 signaling. This HARQ information typically indicates the HARQ process
number, which allows the mobile station to identify the Hybrid ARQ process on which the
data is mapped, the sequence number or new data indicator, allowing the mobile station
to identify if the transmission is a new packet or a retransmitted packet and a redundancy
and/or constellation version. The redundancy version and/or constellation version tells
the mobile station, which Hybrid ARQ redundancy version is used (required for de-
rate-matching) and/or which modulation constellation version is used (required for
demodulation)
A further parameter in the HARQ information is typically the UE Identity (UE ID) for
identifying the mobile station to receive the L1/L2 control signaling. In typical
implementations this information is used to mask the CRC of the L1/L2 control signaling
in order to prevent other mobile stations to read this information.
The table below (Table 1) illustrates an example of a L1/L2 control channel signal
structure for downlink scheduling as known from 3GPP TR 25.814 (see section 7.1.1.2.3
- FFS = for further study):
Uplink Data Transmission
Similarly, also for uplink transmissions, L1/L2 signaling is provided on the downlink to the
transmitters in order to inform them on the parameters for the uplink transmission.
Essentially, the L1/L2 control channel signal is partly similar to the one for downlink
transmissions. It typically indicates the physical resource(s) on which the UE should
transmit the data (e.g. subcarriers or subcarrier blocks in case of OFDM, codes in case
of CDMA) and a transport format the mobile station should use for uplink transmission.
Further, the L1/L2 control information may also comprise Hybrid ARQ information,
indicating the HARQ process number, the sequence number or new data indicator, and
further the redundancy and/or constellation version. In addition, there may be a UE
Identity (UE ID) comprised in the control signaling.
Variants
There are several different flavors how to exactly transmit the information pieces
mentioned above. Moreover, the L1/L2 control information may also contain additional
information or may omit some of the information. For example, the HARQ process
number may not be needed in case of using no or a synchronous HARQ protocol.
Similarly, the redundancy and/or constellation version may not be needed, if for example
Chase Combining is used (i.e. always the same redundancy and/or constellation version
is transmitted) or if the sequence of redundancy and/or constellation versions is pre-
defined.
Another variant may be to additionally include power control information in the control
signaling or MIMO related control information, such as e.g. pre-coding information. In
case of multi-codeword MIMO transmission transport format and/or HARQ information
for multiple code words may be included.
In case of uplink data transmission, part or all of the information listed above may be
signaled on uplink, instead of on the downlink. For example, the base station may only
define the physical resource(s) on which a given mobile station shall transmit,.
Accordingly, the mobile station may select and signal the transport format, modulation
scheme and/or HARQ parameters on the uplink. Which parts of the L1/L2 control
information is signaled on the uplink and which proportion is signaled on the downlink is
typically a design issue and depends on the view how much control should be carried out
by the network and how much autonomy should be left to the mobile station.
The table below (Table 2) illustrates an example of a L1/L2 control channel signal
structure for uplink scheduling as known from 3GPP TR 25.814 (see section 7.1.1.2.3 -
FFS = for further study):
Another, more recent suggestion of a L1/L2 control signaling structure for uplink and
downlink transmission may be found in 3GPP TSG-RAN WG1 #50 Tdoc. R1-073870,
"Notes from offline discussions on PDCCH contents", August 2007, available at
http://www.3gpp.org and incorporated herein by reference.
As indicated above, L1/L2 control signaling has been defied for systems that are already
deployed to in different countries, such as for example, 3GPP HSDPA. For details on
3GPP HSDPA it is therefore referred to 3GPP TS 25.308, "High Speed Downlink Packet
Access (HSDPA); Overall description; Stage 2", version 7.4.0, September 2007
(available at http://www.3gpp.org) and Harri Holma and Antti Toskala, "WCDMA for
UMTS, Radio Access For Third Generation Mobile Communications", Third Edition, John
Wiley & Sons, Ltd., 2004, chapters 11.1 to 11.5, for further reading.
As described in section 4.6 of 3GPP TS 25.212, "Multiplexing and Channel Coding
(FDD"), version 7.6.0, September 2007 (available at http://www.3gpp.org) in HSDPA the
"Transport Format" (TF) (Transport-block size information (6 bits)), the "Redundancy and
constellation Version" (RV/CV) (2 bits) and the "New Data Indicator" (NDI) (1 bit) are
signaled separately by in total 9 bits. It should be noted that the NDI is actually serving
as a 1-bit HARQ Sequence Number (SN), i.e. the value is toggled with each new
transport-block to be transmitted.
SUMMARY OF THE INVENTION
One object of the invention is to reduce the amount of bits required for control channel
signaling, such as for example L1/L2 control signaling, in uplink or downlink. Further, it is
desirable that such solution does further not introduce additional problematic HARQ
protocol error cases.
The object is solved by the subject matter of the independent claims. Advantageous
embodiments of the invention are subject matters of the dependent claims.
One main aspect of the invention is to suggest a new format for the control channel
information. According to this aspect, the transport format/transport block size/payload
size/modulation and coding scheme and the redundancy version /constellation version
for the associated transmission of the user data (typically in form of a protocol data unit
or transport block) is provided in a single field of the control channel information. This
single field is referred to as the control information field herein, but may for example also
be denoted a transport format/redundancy version field or, in abbreviated form, a TF/RV
field. In addition, some embodiment of the invention foresee to combine the transport
format transport block size/payload size/modulation and coding scheme, the redundancy
version/constellation version and additionally HARQ related information (sequence
number or new data indicator) within a single field of the control channel information.
According to one embodiment, the invention provides a control channel signal (such as
for example a L1/L2 control channel signal) for use in a mobile communication system.
The control channel signal is associated to protocol data unit transporting user data and
comprises a control information field consisting of a number of bits jointly encoding a
transport format and a redundancy version used for transmitting the protocol data unit.
In one exemplary embodiment of the invention, the bits of the control information field
jointly encode the transport format, a redundancy version used for transmitting the
protocol data unit and a sequence number of the protocol data unit.
Further, in another exemplary embodiment, the bits of the control information field not
only jointly encode the transport format and a redundancy version used for transmitting
the protocol data unit, but further include a new data indicator for indicating whether the
transmission of the protocol data unit is an initial transmission of the user data. Hence, in
this example, a single field of the control channel signal is utilized to encode the three
before mentioned control information related to the associated transmission of the user
data.
According to another exemplary embodiment of the invention, the control information
field consists of a number of bits yielding a range of values that can be represented in
the control information field (e.g. if there are N bits provided in the field, 2N different
values may be represented in the field) and wherein a first subset of the values is
reserved for indicating a transport format of the protocol data unit and a second subset of
values are reserved for indicating a redundancy version for transmitting the user data. In
one exemplary implementation, the first subset of values contains more values than the
second subset of values.
Moreover, in another exemplary embodiment of the invention, the redundancy version of
the protocol data unit is implicit to its transport format that indicated by the corresponding
value of the first subset. In other words, each individual transport format that is
represented by a specific bit combination of the first subset is univocally linked to a
respective redundancy version so that no explicit signaling of the redundancy version of
the protocol data unit is necessary. Another possibility would be that the redundancy
version to be used for the initial transmission of the user data in the protocol data unit is
fixed or preconfigured.
In another embodiment, it may be assumed that the transmission of the before-
mentioned protocol data unit is an initial transmission of the user data. In this case, the
value of the encoded information bits in the control channel field is representing a value
of the first subset of values. Hence, in general, in case of an initial transmission, the
transport format and optionally the redundancy version of the protocol data unit is
indicated in the control channel signal. As indicated previously, the redundancy version
may also be implicit to the transport format.
In a similar fashion, in case the transmission of the protocol data unit is a retransmission
of the user data, the value of the encoded information bits in the control channel field is
representing a value of the second subset of values. This may be for example
advantageous in a system design, where the transport format (e.g. transport block size)
of a protocol data unit does not change between initial transmission and retransmission
or if the transport format can be determined from the transport format and the resource
allocation information for the initial transmission and the resource allocation information
for the retransmission. Accordingly, if a retransmission needs to be sent for the user
data, the control channel signal for this retransmission does not need to explicitly signal
the transport format for the retransmitted protocol data unit, but rather the bits of the
control information field indicate the redundancy version of the protocol data unit, while
assuming the transport format of the retransmission to be the same as for the initial
transmission or to be determined from the transport format and (optionally) the resource
allocation information of the initial transmission and, optionally further, the resource
allocation information in the retransmission.
However, in other exemplary designs, the transport format of the initial transmission of
the user data may not be known, e.g. in case the receiving terminal has missed the
transmission of the control channel signal, or the same transport format can no longer be
used for the retransmission, e.g. due to a reconfiguration of resources allocated to the
transmission of the protocol data unit. Accordingly, in another embodiment of the
invention, in case the transmission of the protocol data unit is a retransmission of the
user data, the value of the encoded information bits in the control channel field is
representing a value of the first subset or the second subset of values.
Hence, in this example, the control information field may either indicate the redundancy
version of the protocol data unit, while assuming the transport format of the
retransmission to be known from the initial transmission, or a transport format (and
implicitly or explicitly the redundancy version) for the retransmission may be indicated in
the retransmission, as appropriate.
Another exemplary embodiment, the transport format, a redundancy version used for
transmitting the protocol data unit and a new data indicator for indicating whether the
transmission of the protocol data unit is an initial transmission of the user data are
assumed to be jointly encoded in the control information field, while the values that can
be represented by the control information field bits are again split into a first and second
subset in a similar fashion as described above. In this example, use of one of the values
of a first subset set also indicates the transmission of the protocol data unit to be an
initial transmission. I.e. in this case the values of the first subset may be considered a
new data indicator being set, i.e. indicating an initial transmission, while the values of the
second subset may be considered a new data indicator not being set, i.e. indicating a
retransmission.
In case the sequence number/new data indicator is not jointly encoded together with the
transport format and the redundancy version, in an alternative embodiment of the
invention, a respective field may be realized in the control channel signal.
According to a further embodiment of the invention, the control channel signal comprises
a resource allocation field for indicating the physical radio resource or resources
allocated to a receiver for receiving the protocol data unit or the physical radio resource
or resources on which a transmitter is to transmit the protocol data unit.
In another embodiment, the control channel signal further comprises a mobile terminal
identifier field for indicating the mobile terminal or a group of mobile terminals that are to
receive the control channel signal.
In a further embodiment of the invention, the control channel signal or rather the bits of
the control information field include a flag indicating the type of information indicated by
the remaining bits of the control information field, in case the protocol data packet is a
retransmission for the user data.
In an alternative solution according to another embodiment of the invention, another
control channel signal is provided. Also this alternative control channel signal is
associated to protocol data unit transporting user data and comprises a control
information field consisting of a number of bits representing a transport format and
implicitly a redundancy version of the protocol data unit, if the transmission of the
protocol data unit is an initial transmission of the user data, or representing a redundancy
version of the protocol data unit, if the transmission of the protocol data unit is a
retransmission of the user data.
Further, in a variation of this embodiment, the bits of the control information field
represent a redundancy version and optionally a transport format of the protocol data
unit, if the transmission of the protocol data unit is a retransmission.
Another embodiment of the invention relates to a method for encoding control signaling
associated to a protocol data unit conveying user data in a mobile communication
system. In this method, the base station generates a control channel signal comprising a
control information field in which a transport format and a redundancy version of the
protocol data unit is jointly encoded, and subsequently transmits the control channel
signal to at least one mobile terminal.
In a further embodiment, the base station receives feedback from the at least one mobile
terminal. The feedback indicates whether the protocol data unit has been successfully
decoded at the mobile terminal. If no successful decoding has been possible, the base
station may retransmit the protocol data unit and may further transmit a second control
channel signal comprising a control information field in which a transport format and a
redundancy version of the protocol data unit is jointly encoded. Thereby, the second
control channel signal is associated to a retransmission of the protocol data unit to the
mobile terminal.
In one exemplary embodiment, the protocol data unit and the second protocol data unit
are transmitted or received using the same HARQ process.
Another embodiment of the invention relates to a method for providing control signaling
associated to a protocol data unit conveying user data in a mobile communication
system. According to this method, a base station of the mobile communication system
generates a control channel signal that comprises a control information field consisting of
a number of bits representing:
- a transport format and implicitly a redundancy version of the protocol data unit, if the
transmission of the protocol data unit is an initial transmission of the user data, or
- a redundancy version of the protocol data unit, if the transmission of the protocol data
unit is a retransmission of the user data.
Subsequently the base station transmits the control channel signal to at least one mobile
terminal.
In a further embodiment of the invention, in both methods mentioned above, the base
station may also transmit the protocol data unit to a mobile terminal or receiving the
protocol data unit from the mobile terminal utilizing a HARQ retransmission protocol. In
one example, the protocol data unit is transmitted or received using a HARQ process
indicated in the control channel signal. In another example, the protocol data unit is
transmitted or received using a HARQ process determined based on to the sub-frame
number of the sub-frame conveying the protocol data unit. The protocol data unit may be
transmitted or received using the physical radio resource or resources indicated in the
control channel signal.
In one exemplary embodiment of the invention the mobile communication system is a
multi-carrier system, such as for example an OFDM-based system, and the control
channel signal is transmitted within the physical radio resources of a sub-frame allocated
to the L1/L2 control channels of the multi-carrier system.
Furthermore, in another exemplary embodiment of the invention the protocol data unit is
transmitted in the same sub-frame as the associated control channel signal.
Though the exemplary embodiments described herein are mainly focusing on outlining
the relation between one base station and one mobile terminal, it is apparent that the
base station may be serving a plurality of mobile terminals, and a control channel signal
is generated and transmitted by the base station for each mobile terminal or group of
mobile terminals.
A further embodiment of the invention is related to the operation of the mobile terminal.
Accordingly, a method is provided in which a mobile terminal receive a sub-frame of
physical radio resources comprising a control channel signal destined to the mobile
terminal. The control channel signal comprises a control information field in which a
transport format and a redundancy version of a protocol data unit are jointly encoded.
The mobile terminal next determines the transport format and the redundancy version for
the protocol data packet conveying user data based on the received control channel
signal, and receives or transmits the protocol data packet on at least one physical radio
resource using the transport format and the redundancy version of the protocol data
packet indicated in the received control information field.
In one example, the transport format is transport block size information of the protocol
data unit, and the received control channel signal comprises a resource allocation field
indicating the physical radio resource or resources allocated to the mobile terminal.
Accordingly, the mobile terminal may determine the transport block size of the protocol
data unit depending on the information comprised in the resource allocation field and the
control information field.
In another example, the control channel signal indicates the protocol data packet to be a
retransmission (e.g. new data indicator not set) of user data and wherein the method
further comprises the step of transmitting a positive acknowledgment for the received
protocol data packet to the base station, if the control channel signaling associated to the
initial transmission for the user data has been missed. Hence, even though the mobile
terminal has not received the control channel signal and could not receive the associated
transmission of the user data, the mobile terminal may acknowledge "successful
reception" of the user data and may for example rely on upper layer protocols, such as
for example the Radio Link Control (RLC) protocol, to take care of handling
retransmission.
In case the protocol data unit is a retransmission, according to another example, the
mobile terminal may reuse the transport format information of the protocol data unit
indicated in a control channel signal for the initial transmission for the transmission or
reception of the retransmission of the protocol data unit. Accordingly, the control channel
signal may be "only" indicating the redundancy version of the retransmission (though one
may still consider the control channel signal to implicitly indicate the transport format).
In another exemplary embodiment of the invention, the information bits in the control
information field of the control channel signal are associated to a single reference
information indicating a transport format and a redundancy version used for transmitting
the protocol data unit associated to the respective value represented by the information
bits of the control information field for initial transmissions and retransmissions of the
protocol data packet.
In a further embodiment of the invention relates to the operation of the mobile terminal. In
this embodiment, the mobile terminal receives a sub-frame of physical radio resources
comprising a control channel signal. The control channel signal thereby comprises a
control information field consisting of a number of bits representing:
- a transport format and implicitly a redundancy version of the protocol data unit, if the
transmission of the protocol data unit is an initial transmission of the user data, or
- a redundancy version of the protocol data unit, if the transmission of the protocol data
unit is a retransmission of the user data.
Next, the mobile terminal determines (based on the received control channel signal) the
transport format of and the redundancy version for the protocol data packet conveying
user data, and further receive or transmits the protocol data packet on at least one
physical radio resource using the transport format and the redundancy version of the
protocol data packet indicated in the received control information field.
In this exemplary embodiment, the information bits of the control information are
associated to two different reference information (based on which the control information
field content is interpreted). If the transmission of the protocol data packets is an initial
transmission, the first reference information is utilized when determining the transport
format and the redundancy version of the protocol data packet. If the transmission of the
protocol data packets is a retransmission, the second reference is used when
determining the transport format and the redundancy version of the protocol data packet.
In one example, the first reference information indicates a transport format associated to
the respective value represented by the information bits of the control information field,
and the second reference information indicates a redundancy version associated to the
respective value represented by the information bits of the control information field.
Another embodiment of the invention provides a base station for providing control
signaling associated to a protocol data unit conveying user data in a mobile
communication system. The base station comprises a processing unit for generating a
control channel signal comprising a control information field in which a transport format
and a redundancy version of the protocol data unit is jointly encoded, and a transmitter
unit transmitting control signaling comprising the control channel signal to at least one
mobile terminal.
Further, another embodiment of the invention relates to a mobile terminal for use in a
mobile communication system, whereby the mobile terminal comprises a receiver unit for
receiving a sub-frame of physical radio resources comprising a control channel signal
destined to the mobile terminal. The control channel signal comprises a control
information field in which a transport format and a redundancy version of a protocol data
unit is jointly encoded, as mentioned previously herein. The mobile terminal also
comprises a processing unit for determining based on the received control channel signal
the transport format of and the redundancy version for the protocol data packet
conveying user data, and a transmitter unit for transmitting the protocol data packet on at
least one physical radio resource using the transport format and the redundancy version
of the protocol data packet indicated in the received control information field.
In an alternative embodiment, the mobile terminal comprises a receiver unit for receiving
a sub-frame of physical radio resources comprising a control channel signal destined to
the mobile terminal, and a processing unit for determining based on the received control
channel signal the transport format of and the redundancy version for the protocol data
packet conveying user data. Furthermore, the receiver unit is capable of receiving the
protocol data packet on at least one physical radio resource using the transport format
and the redundancy version of the protocol data packet indicated in the received control
information field.
Moreover, the invention according to other exemplary embodiments relates to the
implementation of the methods described herein in software and hardware. Accordingly,
another embodiment of the invention provides a computer readable medium storing
instructions that, when executed by a processor unit of a base station, cause the base
station to generate a control channel signal comprising a control information field in
which a transport format and a redundancy version of the protocol data unit is jointly
encoded, and to transmit the control channel signal to at least one mobile terminal.
A further embodiment relates to a computer readable medium storing instructions that,
when executed by a processor unit of a mobile terminal, cause the mobile terminal to
receive a sub-frame of physical radio resources comprising a control channel signal
destined to the mobile terminal, determine based on the received control channel signal
the transport format of and the redundancy version for the protocol data packet
conveying user data, and receive or transmit the protocol data packet on at least one
physical radio resource using the transport format and the redundancy version of the
protocol data packet indicated in the received control information field.
BRIEF DESCRIPTION OF THE FIGURES
In the following, the invention is described in more detail in reference to the attached
figures and drawings. Similar or corresponding details in the figures are marked with the
same reference numerals.
Fig. 1 shows an exemplary data transmission to users in an OFDMA system in localized
mode (LM) having a distributed mapping of L1/L2 control signaling,
Fig. 2 shows an exemplary data transmission to users in an OFDMA system in localized
mode (LM) having a distributed mapping of L1/L2 control signaling,
Fig. 3 shows an exemplary data transmission to users in an OFDMA system in
distributed mode (DM) having a distributed mapping of L1/L2 control
signaling,
Fig. 4 exemplarily highlights the interrelation between transport block/protocol data unit
and its different redundancy versions as well as the transport block
size/protocol data unit size,
Fig. 5 shows an example of a control channel signal with a common field for jointly
encoding transmission format and redundancy version of a protocol data
unit according to one embodiment of the invention,
Fig. 6 shows an example of a control channel signal with a common, shared field for
signaling the transmission format or the redundancy version of a protocol
data unit according to one embodiment of the invention,
Fig. 7 shows another example of a control channel signal with a common, shared field
for signaling the transmission format, the redundancy version or other
information for a protocol data unit according to one embodiment of the
invention,
Fig. 8 shows an exemplary, typical message flow between a transceiver and receiver of
a control channel signal according to an exemplary embodiment of the
invention,
Fig. 9 shows an exemplary message flow between a transceiver and receiver of a
control channel signal in which the retransmission protocol operation of the
receiver is optimized according to an exemplary embodiment of the
invention,
Fig. 10 shows a mobile communication system according to one embodiment of
the invention, in which the ideas of the invention may be implemented, and
Fig. 11 shows another example of a control channel signal with a common, shared
field for signaling the transmission format or the redundancy version of a
protocol data unit according to one embodiment of the invention,
DETAILED DESCRIPTION OF THE INVENTION
The following paragraphs will describe various embodiments of the invention. For
exemplary purposes only, most of the embodiments are outlined in relation to an
(evolved) UMTS communication system according to the SAE/LTE discussed in the
Technical Background section above. It should be noted that the invention may be
advantageously used for example in connection with a mobile communication system
such as the SAE/LTE communication system previously described or in connection with
multi-carrier systems such as OFDM-based systems, but the invention is not limited to its
use in this particular exemplary communication network.
Before discussing the various embodiments of the invention in further detail below, the
following paragraphs will give a brief overview on the meaning of several terms
frequently used herein and their interrelation and dependencies. Generally, a protocol
data unit may be considered a data packet of a specific protocol layer that is used to
convey one or more transport blocks. In one example, the protocol data unit is a MAC
Protocol Data Unit (MAC PDU), i.e. a protocol data unit of the MAC (Medium Access
Control) protocol layer. The MAC PDU conveys data provided by the MAC layer to the
PHY (Physical) layer. Typically, for a single user allocation (one L1/L2 control Ghannel -
PDCCH - per user), one MAC PDU is mapped onto one transport block (TB) on Layer 1.
A transport block defines the basic data unit exchanged between Layer 1 and MAC
(Layer 2). Typically, the when mapping a MAC PDU onto a transport block one or
multiple CRCs are added. The transport block size is defined as the size (number of bits)
of a transport block. Depending on the definition, the transport size may include or
exclude the CRC bits.
in general, the transport format defines the modulation and coding scheme (MCS) and/or
the transport block size, which is applied for the transmission of a transport block and is,
therefore, required for appropriate (de)modulation and (de)coding. In a 3GPP-based
system as for example discussed in 3GPP TR 25.814, the following relationship between
the modulation and coding scheme, the transport block size and the resource allocation
size is valid:

where NRE is the number of allocated resource elements (RE) - one RE being identical to
one modulation symbol -, CR is the code rate for encoding the transport block, and M is
the number of bits mapped onto one modulation symbol, e.g. M=4 for 16-QAM.
Due to this relationship described above, the L1/L2 control signaling may only need to
indicate either the transport block size or the modulation and coding scheme. In case the
modulation and coding scheme should be signaled, there are several options how to
implement this signaling. For example, separate fields for modulation and coding or a
joint field for signaling both, the modulation and coding parameters may be foreseen. In
case the transport block site should be signaled, the transport block size is typically not
explicitly signaled, but is rather signaled as a TBS index. The interpretation of the TBS
index to determine the actual transport block size may for example depend on the
resource allocation size.
In the following, the transport format field on the L1/L2 control signaling is assumed to be
indicating either the modulation and coding scheme or the transport block size. It should
be noted, that the transport block size for a given transport block typically does not
change during transmissions. However, even if the transport block size is not changed,
the modulation and coding scheme may change between transmissions, e.g. if the
resource allocation size is changed (as apparent for the described relationship above).
It should be also noted that in some embodiments of the invention, for retransmissions
the transport block size is typically known from the initial transmission. Therefore, the
transport format (MCS and/or TBS) information (even if the modulation and coding
scheme changes between transmissions) does not have to be signaled in
retransmissions, since the modulation and coding scheme can be determined from the
transport block size and the resource allocation size, which can be determined from the
resource allocation field.
A redundancy version denotes a set of encoded bits generated from a given transport
block, as shown in Fig. 4. In systems, where the code rate for the data transmission is
generated by a fixed rate encoder and a rate matching unit (e.g. in HSDPA of UMTS or
LTE systems), different redundancy versions are generated for a single transport block
(or protocol data unit) by selecting different sets of available encoded bits, where the set
size (number of selected bits) depends on the actual code rate (CR) for the data
transmission. In case the actual code rate for a transmission (or retransmission) is higher
than the encoder rate, a redundancy version is constructed out of a subset of encoded
bits. In case the actual code rate for a transmission (or retransmission) is lower than the
encoder rate, a redundancy version is typically constructed out of all encoded bits with
selected bits being repeated.
A constellation version denotes the constellation diagram being applied for the
modulation of the data transmission. In some cases, this may simply refer to a specific
bit-to-symbol mapping for a given modulation scheme. In other cases, this may refer to a
specific bit operations by interleaving and/or inversion of bit values in order to achieve a
similar effect as by applying a specific bit-to-symbol mapping (see for example
EP 1 293 059 B1 or EP 1 313 248 B1 or 3GPP TS 25.212, "Multiplexing and Channel
Coding (FDD"), version 7.6.0, September 2007 available at http://www.3gpp.org)
A New Data Indicator (NDI) denotes a flag (or field) indicating whether a transmission of
a transport block (or protocol data unit) is an initial transmission or a retransmission. If
the NDI is set, the transmission of a transport block (or protocol data unit) is an initial
transmission. In some implementations, the new data indicator is a 1-bit sequence
number (SN), which is incremented every other transport block (or protocol data unit). In
case of using a single bit for the NDI/SN the increment is identical to toggling the bit.
Generally, however, a sequence number may comprise more than one bit.
One main aspect of the invention is to suggest a new format for the control channel
information. According to this aspect, the transport format/transport block size/payload
size/modulation and coding scheme and the redundancy version/constellation version for
the associated transmission of the user data (typically in form of a protocol data unit) is
provided in a single field of the control channel information. The control channel
information may for example be L1/L2 control information/a L1/L2 control channel signal
that is transmitted on the PDCCH (Physical Downlink Control CHannel) of a 3GPP LTE
system.
It should be noted that for simplicity it is referred to transport format and redundancy
version in most of the examples herein. However, in all embodiments of this invention the
term "transport format" means either one of "transport format", "transport block size",
"payload size" or "modulation and coding scheme". Similarly, in all embodiments of this
invention the term "redundancy version" can be replaced by "redundancy version and/or
constellation version".
In addition, some embodiment of the invention foresee to combine the transport format,
the redundancy version and additionally HARQ related information
((Retransmission/HARQ) sequence number or new data indicator - NDI) within a single
field of the control channel information.
There are two basic approaches suggested herein. According to different embodiments
of the invention, a joint encoding of transport format and redundancy version is provided
or alternatively a shared signaling of transport format and redundancy version is used. In
both cases, only a single control channel information field is provided for the transport
format and the redundancy version, however the use of the filed is different.
When using joint encoding, there is one common field for the transport format and the
redundancy version defined in the control channel information/signal. The transport
format and redundancy version are jointly coded, e.g. a field of N bits is used yielding 2N
values, which can be signaled. Out of the 2N values M (<2N) values are used to indicate a
transport format which is for example associated to a given fixed or pre-configured
redundancy version (In this case one could speak of an explicit signaling of the transport
format and a simultaneous implicit signaling of the redundancy version). All or part of the
remaining values is used to indicate additional redundancy versions that may be for
example used for retransmissions of the protocol data unit.
The latter may for example be especially applicable in a system design, where the
transport format of a transport block/protocol data unit does not change between initial
and retransmission or can be derived from other information in the control channel signal
for the retransmission and/or the initial transmission (for example, in some systems it
may be possible to derive the transport format of a retransmission from the transport
format and optionally resource allocation information related to the initial transmission -
further also the information on the resource allocation for the retransmission may be
taken into account) . In this example, the control signaling for the retransmission may
explicitly indicate the redundancy version of the protocol data unit used for its
retransmission and implicitly yielding the transport format (i.e. the same transport format
as used for the initial transmission of the protocol data unit that has been indicated in a
previous control channel signal for the initial transmission or the transport format can be
derived from other control channel signaling information as mentioned above).
As mentioned previously, as an additional enhancement, the new data indicator or
sequence number may be additionally jointly coded with the transport format and
redundancy version.
Utilizing the second approach of having a shared field for the transport format and the
redundancy version defined in the control channel information structure, at one signaling
instant the shared field is used to signal the transport format and at another signaling
instant the shared field is used to signal the redundancy version.
Accordingly, when jointly encoding the transport format and the redundancy version only
on single set of reference information to map the bit value indicated by the bit
combination in the common control information field in the control channel signal to a
respective combination of transport format and redundancy version of the protocol data
unit providing the user data may be needed, irrespective of whether the transmission is
an initial transmission of the protocol data unit or a retransmission thereof.
In case of having a shared control information field in the control channel signal, there
may be two sets of reference information to map the bit value indicated by the bit
combination in the common control information field to a respective combination of
transport format and redundancy version, depending on whether the transmission is an
initial transmission of the protocol data unit or a retransmission thereof. For example, in
case there is a pre-configured or fixed redundancy version for the initial transmission, the
control channel signal for the initial transmission may explicitly indicate the transport
format of the initial transmission within the shared field. For some retransmissions, the
transport format of the initial transmission may be reused, so that the control channel
signal for the retransmission may "only" explicitly indicate the redundancy version of the
retransmission (while the transport format may be considered implicitly identified or
known from the control channel signal for the initial or any previous transmission).
One significant difference between the general concept of the invention and existing
systems, such as 3GPP HSDPA, from the viewpoint of an efficient system operation is
related to HARQ protocol errors. In HSDPA a lost transport block (MAC PDU), e.g. due
to an ACK/NACK misdetection or a lost L1/L2 downlink control signaling carrying the
scheduling information (TF, HARQ, etc.), comes at a high resource cost and high delay,
since the RLC protocol taking care of these errors is slow and heavy. In LTE systems
(which is one of the target systems for employing the this invention), the higher-layer
RLC protocol is lightweight and fast, which allows designing the L1/L2 downlink control
signaling to be less robust, which in turn allows for optimizations disclosed herein. As
indicated above, one approach suggested herein is the use of a single/common field in
the control channel information format to indicate the transport format and (at least
implicitly) the redundancy version of the transmission of a protocol data unit and to jointly
encode (at least) these two parameters using the bits of the common field. According to
one exemplary embodiment of the invention, the common field in the control channel
information may be assumed to consist of N bits so that 2N values can be represented
and signaled. Out of the 2N values M (<2N values may be for example used to indicate a
transport format associated with a given fixed or pre-configured redundancy version. All
or part of the remaining values is/are used to indicate additional redundancy versions.
Table 3 below illustrates an example, where the common field (Signaled Value) consists
of 4 bits. The first part (denoted TF range) of the total range of values representable by
the 4 bits is used to indicate different transport formats that are associated to a given
redundancy version (RV 0). The remaining values representable by the 4 bits form a
second part (denoted RV range) and indicate a redundancy version of the respective
transmission.
In Table 3 above, all values of the TF range are assigned to a single redundancy version
(RV 0) only. Of course, it may be also possible that the respective values/transport
formats are associated to different redundancy versions. This is exemplified in Fig. 4
below.
According to the example in Table 4, redundancy versions may be defined depending on
the actual signaling value. In one embodiment, for small transport block sizes or low
MCS levels, one specific redundancy version (RV 0) could be used and for larger
transport block sizes/high MCS levels, another redundancy version (RV 1 or RV 2) are
used. Furthermore, in another example, the same transport format may be associated to
different redundancy versions.
In operation, when initially transmitting a protocol data unit (or transport block), the base
station may send a control channel signal comprising a common TF/RV field having a
value selected from the "TF range". Accordingly, the signaled value does not only identify
a transport format of the protocol data unit but also indicates the respective redundancy
version. If a protocol data unit is retransmitted, a value from the "RV range" indicating a
specific redundancy version is signaled, as it may be assumed that the transport format
is constant or known for all transmissions of a respective protocol data unit (transport
block) to facilitate soft-combining by the HARQ protocol.
Alternatively, e.g. depending on the feedback of the receiver (e.g. the mobile station) of
the protocol data unit provided to the transmitter (e.g. the base station) of the protocol
data unit, the transmitter may decide to send the retransmission with the same transport
format and redundancy version as the initial transmission. Using a reference table as
shown in Table 3, the control channel signal for the retransmission may thus indicate the
same value in the TF/RV field of the control channel signal as the control channel signal
for the initial transmission (as the "RV range" does not allow to signal RV 0). If using a
reference table as shown in Table 4, it should be noted that the "RV range" yields three
the same three redundancy versions that are identified in the TF range", so that the TF/
RV field in the control channel signal may always a value of the "RV range" for the
retransmissions.
In case there should be the possibility to send retransmissions with the same
redundancy version as the initial transmission, e.g. due to using HARQ with Chase
combining as a retransmission protocol for the protocol data units the following
exemplary implementations may be foreseen.
In one exemplary implementation, any "TF range" value can be signaled in the control
channel signal for retransmissions, even if the signaled value does not matching the TF
(TBS) value of the transport block (or in other words the TF of the initial transmission of
the protocol data unit). In this case, the receiver (e.g. mobile station) simply ignores the
transport format that would be yielded by the signaled "TF range" value, and simply
applies the signaled redundancy version. Accordingly, in order to distinguish when to
ignore the signaled transport format, the receiver may evaluate the sequence number
(field) or new data indicator first, so as to recognize whether the associated transmission
of the protocol data unit is an initial transmission or a retransmission.
In another, second exemplary implementation, also for a retransmission the "TF range"
value can be signaled that is matching the transport format (TBS) of the first, initial
transmission. In this case, the receiver (e.g. mobile station) shall typically not ignore the
signaled transport format (TBS) value, as this might help to discover error cases. If for
example the receiver has missed the control signaling of the initial transmission (and
hence missed also the first transmission of the protocol data unit/transport block), the
receiver may try to decode the data based on the signaling for the retransmission, since
the control signaling contains the transport format.
In a third exemplary implementation, the interpretation of the transport format (TBS)
value in the common TF/RV field depends on the resource allocation field also
comprised in the control channel information. This means that for a given resource
allocation size, only a specific range of transport block sizes may be signaled (typically,
the transport block size TBS is related to the amount of allocated resources - measured
in resource blocks RBs - as follows: TBS = N • RB, where N = 1,2,3,...). In case the
resource allocation size changes between initial transmission and retransmissions, it
may happen that it is not possible to signal the correct transport block size. In this case, it
may be advantageous to include an "Out of Range" TF value in the reference table used
at the receiver of the control channel signal to interpret the content of the TF/RV field.
This latter case is exemplified in Table 5 below.
In another, fourth exemplary implementation, it may be ensured that the same
redundancy version as used for a initial transmission may be used for a retransmission
by having including in the "RV range" a value that yields the same redundancy version as
yielded by the values of the "TF range". This implementation is exemplified in Table 6
below, where the "RV range" also comprises a value ("1101") that is indicating use of
redundancy RV 0.
In another embodiment of the invention, the control channel signal also includes a new
data indicator (indicating whether the data is new data/a new protocol data unit) or a
sequence number of the protocol data unit, which allows the receiver to detect the
transmission of new data/ a new protocol data unit.
According to one example, the new data indicator or the sequence number may be
transmitted in a separate field or flag in the control channel signal. In one exemplary
implementation the sequence number field is one bit, i.e. incrementing is identical to
toggling the flag. Similarly, the new data indicator may be implemented as a 1-bit field. In
case, a new transport block is transmitted (initial transmission) the new data indicator
value is set (e.g. to value 1) and, if a transport block is retransmitted, the new data
indicator is not set (e.g. is set to value 0).
According to another exemplary implantation, the sequence number or new data
indicator is jointly encoded together with the transport format and the redundancy version
in a single, common field of the control channel signal. Hence, the NDI/SN field may be
no longer required, which allows to reduce signaling overhead.
The joint encoding of the new data indicator (NDI) with the transport format and the
redundancy version according to two exemplary embodiments of the invention is shown
in Table 7 and Table 8. In Table 8, the use of redundancy version RV 0 may be
considered to implicitly also indicate new data, i.e. could therefore also be interpreted as
a NDI flag being set (e.g. NDI=1), and all other redundancy versions RVs (RV 1-3)
indicate retransmissions, i.e. could be also interpreted as the NDI flag not being set (e.g.
NDI=0)
Essentially, Table 7 is similar to Table 6 (so is Table 8 to Table 3), except for adding
another column to the reference table indicating the identified NDI setting for a respective
signaled value. In general, independent from the specific example given in Table 7, it
should be recognized that the definition of two ranges of values ("TF range" and "RV
range") also defines two ranges of values indicating, whether new data is sent or whether
a retransmission is provided. Essentially, selecting a value from the "TF range" indicates
a new transmission, and is thus equivalent to a new data indicator being set (or a
sequence number being incremented). Similarly, selecting a value from the "RV range"
indicates no new data being transmitted and is thus equivalent to new data indicator not
being set (or a sequence number not being incremented). As the setting of a new data
indicator (incrementing the sequence number) typically coincides with the transmission of
an initial transmission of a protocol data unit or transport block respectively, for initial
transmissions a value from the "TF range" should be signaled and for retransmissions, a
value from the "RV range" should be signaled.
Another alternative approach to the joint encoding of transport format and redundancy
version is the use of a shared field (which could be also referred to as a shared TF/RV
field) in the control channel information format to be used for the signaling of transport
format and redundancy version. In this alternative approach, according to another
embodiment of the invention, it is assumed that the transport format is generally
associated to a specific redundancy version for the initial transmission (or the
redundancy version for the initial transmission is either fixed or pre-defined). Accordingly,
in case of an initial transmission, the shared field is interpreted as signaling a transport
format, as shown in Table 9, and so to say implicitly indicating a redundancy version of
the respective transmission in a similar fashion as discussed in some examples above
relating to the joint encoding approach.
Furthermore, it is also assumed, that the transport block size is not changing between
initial transmission and retransmission of a protocol data unit or transport block. Hence,
in case of a retransmission the shared field in the control channel signal is interpreted as
a redundancy version, as shown in Table 10.
Table 10
Comparing the joint encoding approach and the use of a shared field, the main difference
between the approaches is the interpretation of the bits of the respective fields. In the
joint encoding case, the same reference table is used for interpreting the bits of the
common field in the control channel signal to determine transport format and redundancy
version of a transmission, irrespective of whether the transmission is an initial
transmission or a retransmission. Furthermore, in case of additionally jointly encoding the
sequence number or a new data indicator, the value range that can be represented by
the bits in the common field should be separated into two ranges so as to be able to
differentiate between initial transmission and retransmission and to thereby recognize a
new data indicator being set or a sequence number being incremented. In contrast, the
shared field approach is using two different reference tables for the interpretation of the
bits contained in the common field for transport format and redundancy version (see
Tables 9 and 10 above), depending on whether an initial transmission or a
retransmission is sent. This allows more freedom and flexibility to indicate a larger variety
of transport formats and redundancy versions or may allow reducing the size of the
signaling field.
However, the receiver of the control channel signal must be aware of whether an initial
transmission or a retransmission is associated to the respective control channel signal. In
theory, the receiver of the control channel signal may derive the information from its own
feedback, which is however not necessarily very reliable as the feedback may be lost or
misinterpreted.
Therefore, in one further embodiment of the invention, it is suggested that the control
channel signal further comprises an additional sequence number field or new data
indicator. In case of using a new data indicator, the interpretation of the shared TF/RV
field depends on the value of the new data indicator field, i.e. returning to the example
above, the receiver (e.g. mobile station) of the control channel signal either chooses
Table 9 or table 10 for interpreting the shared TF/RV field depending on the setting of the
new data indicator. Similarly, in case of having a sequence number field, the receiver
selects the reference table for interpreting the content of the shared TF/RV field based
on the sequence number being incremented or not.
The differences between a joint encoding of transport format and redundancy version in
a common field and the use of a shared field will be exemplified with respect to Fig. 5
and Fig. 6. In Fig. 5 a control channel signal according to one exemplary embodiment is
shown. The control channel signal comprises a resource allocation field (RB allocation),
a TF/RV field for jointly encoding transport format and redundancy version ("Joint TF/RV
field"), a NDI/SN field and HARQ process field. The same configuration of the control
channel signal is provided on Fig. 6.
In Fig. 5, the transport format and redundancy version are jointly encoded in a common
field ("Joint TF/RV field") irrespective of whether the control channel information relate to
an initial transmission or a retransmission. The four bits of the common field for transport
format and redundancy version may for example represent the transport format and
redundancy versions as outlined above with respect to Tables 3 to 6.
In Fig. 6, the shared field approach according to one exemplary embodiment of the
invention is illustrated in further detail. The NDI/SN field may either comprise a new data
indicator or a sequence number and is used to determine, whether the control channel
information relates to an initial transmission and which reference information are to be
used for interpreting the content of the shared TF/RV field. If the control channel
information is related to an initial transmission of a protocol data unit or transport block,
the shared TF/RV field indicates the transport format thereof, as for example shown in
Table 9 above. If the control channel information is related to a retransmission, the
shared TF/RV field indicates the redundancy version of the protocol data unit, as for
example shown in Table 10 above.
Next, operation of the transmitter of the control channel signal according to one of the
various embodiments described herein and the receiver thereof will be described in
further detail, thereby exemplarily relating to the case of downlink data transmission. For
exemplary purposes a network as exemplified in Fig. 10 may be assumed. The mobile
communication system of Fig. 10 is considered to have a "two node architecture"
consisting of at least one Access and Core Gateway (ACGW) and Node Bs. The ACGW
may handle core network functions, such as routing calls and data connections to
external networks, and it may also implement some RAN functions. Thus, the ACGW
may be considered as to combine functions performed by GGSN and SGSN in today's
3G networks and RAN functions as for example radio resource control (RRC), header
compression, ciphering/integrity protection.
The base stations (also referred to as Node Bs or enhanced Node Bs = eNode Bs) may
handle functions as for example segmentation/concatenation, scheduling and allocation
of resources, multiplexing and physical layer functions, but also RRC functions, such as
outer ARQ. For exemplary purposes only, the eNodeBs are illustrated to control only one
radio cell. Obviously, using beam-forming antennas and/or other techniques the
eNodeBs may also control several radio cells or logical radio cells.
In this exemplary network architecture, a shared data channel may be used for
communication of user data (in form or protocol data units) on uplink and/or downlink on
the air interface between mobile stations (UEs) and base stations (eNodeBs). This
shared channel may be for example a Physical Uplink or Downlink Shared CHannel
(PUSCH or PDSCH) as know in LTE systems. However, it is also possible that the
shared data channel and the associated control channels are mapped to the physical
layer resources as shown in Fig. 2 or Fig. 3.
The control channel signals/information may be transmitted on separate (physical)
control channels that are mapped into the same subframe to which the associated user
data (protocol data units) are mapped or may be alternatively sent in a subframe
preceding the one containing the associated information. In one example, the mobile
communication system is a 3GPP LTE system, and the control channel signal is L1/L2
control channel information (e.g. information on the Physical Downlink Control CHannel -
PDCCH). Respective L1/L2 control channel information for the different users (or groups
of users) may be mapped into a specific part of the shared uplink or downlink channel, as
exemplarily shown in Fig. 2 and 3, where the control channel information of the different
users is mapped to the first part of a downlink subframe ("control").
Fig. 8 shows a message exchange and tasks performed by a transmitted and a receiver
of a control channel signal according to an exemplary embodiment of the invention. The
message exchange may be performed in the mobile communication network shown in
Fig. 10. Accordingly, as the example in Fig. 8 is relating to the downlink data
transmission, the transmitter shown in Fig. 8 may be assumed to correspond to base
station/Node B NB1 in Fig. 10 and the receiver shown in Fig. 8 may be assumed to
correspond to mobile station/UE MS1 in Fig. 10. Generally, it may be assumed in Fig. 8
that a retransmission protocol, such as Hybrid ARQ, is used between the transmitter
(here: base station NB1) and receiver (here: mobile station MS1) of the data (protocol
data unit) so as to ensure successful decoding of the data at the receiver.
Mobile station MS1 is first receiving 801 the PDCCH and obtains a L1/L2 control channel
signal. Subsequently, the mobile station MS1 interprets (or decodes) 802 the content of
L1/L2 control channel signal. The control channel signal may be assumed to have a
format as exemplified in Fig. 6. Next, the mobile station MS1 receives and tries to
decode 804 the protocol data unit transmitted 803 on the associated downlink data
channel with the parameters indicated by the L1/L2 control channel signal.
In case the mobile station MS1 can decode the protocol data unit successfully (known
due to correct CRC), it transmits an ACK on the uplink. Alternatively, the mobile
transmits 805 an NACK on the uplink, if it has not decoded the data correctly (known due
to false CRC). In case mobile station MS1 did not receive (decode correctly) the control
channel signal from the PDCCH, it does not transmit an ACK or NACK on the uplink
(DTX).
In case of receiving a NACK at the base station NB1, same will provide a retransmission
of the protocol data unit to the mobile station. As the retransmission of the protocol data
unit is exemplarily assumed to be another redundancy version of the same protocol data
unit, the base station NB1 generates 806 a control channel signal for the retransmission
and transmits 807, this control channel signal and the retransmission of the protocol data
unit 809 to mobile station MS1. Similar to steps 802 and 804, mobile station MS1
receives 808 the control channel signal for the retransmission and uses the parameters
indicated therein to receive and decode 810 the retransmission of the protocol data unit.
As it is assumed that the protocol data unit may be correctly decoded after having
received the retransmission, mobile station MS1 informs 811 the base station NB1 on the
successful (unsuccessful) decoding by means of an ACK (NACK).
In a further embodiment, some further improvement to the retransmission protocol is
suggested. This improvement will be outlined with the exemplary signaling flow and data
exchange as illustrated in Fig. 9. It may be assumed that the retransmission protocol is
provided on the Medium Access Layer (MAC) of the mobile communication system and
that another higher layer protocol in the protocol stack provides another retransmission
function to ensure successful data delivery. For example, this higher layer protocol may
be the Radio Link Control (RLC) protocol.
Generally, if a mobile station misses 901 the control signaling (e.g. on the PDCCH) for
the initial transmission of a protocol data unit (e.g. MAC PDU), it may also not receive
903 the initial transmission of the protocol data unit as well. Furthermore, the mobile
station is also not aware of the transport format that will be used for the transmission and
retransmissions of the protocol data unit and provides no feedback to the transmitting
base station.
In case the base station does not receive any feedback for the initial transmission, a
typical implementation of the scheduler unit of the base station considers 903 this
absence of feedback as a NACK (two-state ACK/NACK receiver) and the base station
generates 904 and transmits 905, another L1/L2 control signaling for the retransmission
of the protocol data unit.
If the mobile station subsequently receives 906 this L1/L2 control signaling for the
retransmission. Assuming now that there is a common field for the transport format and
the redundancy version within the control signaling, the bits in the common TF/RV field
do not yield the transport format (e.g. transport block sizes, MCS, etc.) of the protocol
data unit, but may only indicate the redundancy version (see for example Tables 3 to 8
and assuming that a value of the "RV range" is signaled for retransmission or see Table
9 for the shared TF/RV field approach). Even though the mobile station is not capable of
receiving the retransmission 907 of the protocol data unit, according to this embodiment
of the invention, the mobile station sends 908 a positive acknowledgement (ACK) in
order to abort the transmission of the current protocol data unit (MAC PDU), since
otherwise (transmitting NACK) the base station would continue with retransmissions
without the mobile terminal having a chance to correctly decode the transport block. The
transmission of an ACK causes the transport block being lost, however retransmission of
this transport block (protocol data unit) can be taken care of by higher layer (ARQ)
protocols, if available (e.g. RLC).
A similar behavior can for example also be implemented in case the base station (or
rather the scheduling unit) has the capability to not only detect ACK/NACKs from but also
a transmitted DTX (i.e. no transmission of ACK/NACK) - i.e. a three-state
ACK/NACK/DTX receiver - for situations where the mobile station missed the control
signaling on the PDCCH, but due to an error in receiving/decoding the feedback - the
base station wrongly detects a NACK instead of DTX. In this case the base station will
send a retransmission for the protocol data packet together with an associated control
channel signal indicating the transmission to be a retransmission, similar as for the 2-
state ACK/NACK receiver case described above. In this case, the mobile station may
detect a protocol error and sends a positive acknowledgement to abort the
retransmissions. In case the base station correctly detects the DTX signal, the base
station may transmit another initial transmission (indicating the transport format) of the
same transport block or of a newly constructed transport block.
The exemplary embodiments discussed above have been mainly focused on L1/L2
control signaling for downlink data transmission. Also in case of uplink data
transmissions, the L1/L2 control signaling may be transmitted in the downlink. As the
transmission of the (user) data is on another link (uplink), the transmissions of the data
may take place on different sub-frames numbers than the associated control signaling
(because uplink and downlink may not really be synchronized, i.e. the timing of the uplink
and downlink sub-frames are different). In any case there needs to be a well-defined
mapping of the sub-frame the control signaling takes place and the sub-frame the actual
data transmission takes place. Accordingly in TDD systems, the subframes may be
different for uplink and for downlink.
In the following further options and improvements to the L1/L2 control signaling
discussed previously herein will be discussed.
Another embodiment of the invention relates to a further improvement of the use of a
shared TF/RV field in the control channel signal. The number of signaling bits for the
transport format (e.g. 4-7 bits) is typically larger than the bits needed for the redundancy
(e.g. 1-3 bits). Therefore, in case of signaling the redundancy version for retransmissions
some bits (or values) of the shared TF/RV field may for example be used to transmit
other useful control information. For example, some or all bits not used for signaling the
redundancy version may be used to signal:
- the modulation scheme as shown in Fig. 11, e.g. in case the modulation scheme
should be controlled for each retransmission independently. In this case the code rate
for decoding can be determined from the transport block size known from a previous
transmission (typically initial transmission), the signaled resource allocation (from
which the resource allocation size can be determined) and the signaled modulation
scheme.
- additional restricted transport format related information, e.g. on modulation only, on
the MCS level, on the TBS, etc.
- MIMO HARQ sub-process information, as for example suggested in 3GPP TSG RAN
WG1 #47 Tdoc. R1-063548, "MIMO HS-SCCH structure", November 2006 (available
at http://www.3gpp.org and incorporated herein by reference). Assuming a MIMO
mode supporting a 2 code word transmission and 2 HARQ processes, typically, the
sub process number needs to be signaled in the L1/L2 control channel, which requires
an additional bit for the HARQ process. Assuming that this bit is not required in initial
transmissions, in retransmissions this bit can be signaled on the available space.
- additional power control information for uplink/downlink control and data channels.
- information on the resources used (by the base station) or to be used (by the UE) for
the ACK/NACK signaling. This information maybe e.g. an explicit indication of the
resources or maybe restricting the resources.
- a flag bit indicating that the remaining bits in the shared field are used for RV
information or e.g. for (restricted) TF information (see Fig. 7). This maybe especially
beneficial in case of self-decodable retransmissions, where the base station has the
flexibility to choose what to signal in the retransmissions.
It should be noted, that in a further embodiment of the invention, control channel
signaling is transmitted for initial transmissions and optionally in addition for selected
retransmissions of a protocol data unit. Thus, some or all retransmissions may be
transmitted without a control channel. In this case the control information for being able
to receive the transmission of the associated protocol data unit may be derived from the
control signaling for the initial transmission of the protocol data unit, from an earlier
(re)transmission of the protocol data unit or the transport format and redundancy version
for the retransmissions may be predefined. E.g. the resource allocation may be derived
from the resource allocation of an earlier transmission (e.g. identical resource allocation
or predefined hopping and resizing of the resource allocation). This implementation may
be for example used for uplink data transmission with a synchronous HARQ protocol.
In comparison to conventional schemes the use of a common field for transport format
and redundancy version (and optionally the NDI/SN) has the following advantages. The
reduction of the L1/L2 control signaling overhead compared to having separate field in
the control channel format for transport format, redundancy version and NDI/SN fields by
the disclosed concept is up to 3 bits depending on the actual embodiment. Assuming L1/
L2 control signaling formats as described in the co-pending PCT application no.
PCT/EP2007/010755, "Configuration of Control Channels in a Mobile Communication
System" (by the same applicant, filed December 10, 2007) yielding sizes between -25
and ~80 bits for the L1/L2 control channel signal, this results into an overhead reduction
of 4-12%. Especially, for the small L1/L2 control signaling formats the reduction is
beneficial (up to 12% reduction), since these are used for cell-edge mobile stations,
where the (power and time-frequency) resources per L1/L2 control channel (PDCCH) are
large due to power and MCS control of the L1/L2 control channel (PDCCH). Therefore,
the concept of having a common field for encoding transport format and redundancy
version (and optionally the NDI/SN) allows for an increased coverage and cell size.
Furthermore, the use of a common field for encoding transport format and redundancy
version (and optionally the NDI/SN) in the control signaling also allows signaling more
transport format sizes. Assuming that e.g. in total 8 bits for transport format, redundancy
version and NDI/SN (5 bits TF, 2 bits RV, 1 bit NDI/SN) are used in a conventional
system to code the respective fields individually, the joint encoding of transport format
and redundancy version and still having a separate NDI/SN field allows using 7 bits for a
common field. The prior art yields up to 25-1=31 transport format values (one value
reserved for "Out of Range"), whereas the joint encoding of transport format and
redundancy version in a TF/RC field yields 27-3=125 transport format values (assuming 3
values are to be reserved for signaling 3 RVs defined for retransmissions). This provides
a significantly finer granularity of transport block sizes allowing e.g. for a lower MAC PDU
padding overhead or a finer link adaptation by MCS selection. In case of additionally
jointly encoding the NDI, the number of transport formats values further increases to 28-
3=253.
Furthermore, as discussed in several examples above, in implementations where the
transport format (Transport Block Size) does not change for retransmissions, which
should be the case, since otherwise soft-combining is not feasible, no transport format
needs to be signaled for retransmissions. In a conventional design, the transport format
is also signaled in retransmissions. In certain cases, the signaling of the transport format
for retransmissions can help from recovering error cases (e.g. if the receiver missed the
transmission of the control signaling for the initial transmission). However, these error
cases are very unlikely for certain systems, and therefore, it is more efficient to avoid
signaling of the transport format for retransmissions, which saves control signaling
overhead.
The signaling of the transport format for retransmission typically causes additional
overhead in the control signaling so as to account for error cases in case the resource
allocation size is changing for retransmissions. In certain cases, it can happen that the
transport format (transport blocks size), which needs to be signaled for retransmissions
in conventional designs, is not within the range of the values that can be signaled after
the update of the resource allocation. In this case, conventional systems typically define
an "Out of Range" value to account for these situations. In some of the embodiments of
the invention discussed herein, this "Out of Range" value is not required since the
transport format (transport block size) is not signaled in retransmissions.
Another feature of the invention according to some embodiments of the invention is that
it does not allow for a dynamic selection of the redundancy version for the initial
transmission. This is not necessarily a drawback in comparison with conventional
solutions (which may allow for a free choice of the redundancy version for initial
transmissions), since dynamic redundancy version selection is typically not beneficial
and may only be applied in rare cases.
Examples of mobile communication systems in which the principles of the invention
outlined herein may be utilized are communication systems utilizing an OFDM scheme, a
MC-CDMA scheme or an OFDM scheme with pulse shaping (OFDM/OQAM).
Another embodiment of the invention relates to the implementation of the above
described various embodiments using hardware and software. It is recognized that the
various embodiments of the invention may be implemented or performed using
computing devices (processors). A computing device or processor may for example be
general purpose processors, digital signal processors (DSP), application specific
integrated circuits (ASIC), field programmable gate arrays (FPGA) or other
programmable logic devices, etc. The various embodiments of the invention may also be
performed or embodied by a combination of these devices.
Further, the various embodiments of the invention may also be implemented by means of
software modules, which are executed by a processor or directly in hardware. Also a
combination of software modules and a hardware implementation may be possible. The
software modules may be stored on any kind of computer readable storage media, for
example RAM, EPROM, EEPROM, flash memory, registers, hard disks, CD-ROM, DVD,
etc.
Furthermore, it should be noted that the terms mobile terminal and mobile station are
used as synonyms herein. A user equipment may be considered one example for a
mobile station and refers to a mobile terminal for use in 3GPP-based networks, such as
LTE.
In the previous paragraphs various embodiments of the invention and variations thereof
have been described. It would be appreciated by a person skilled in the art that
numerous variations and/or modifications may be made to the present invention as
shown in the specific embodiments without departing from the spirit or scope of the
invention as broadly described.
It should be further noted that most of the embodiments have been outlined in relation to
a 3GPP-based communication system and the terminology used in the previous sections
mainly relates to the 3GPP terminology. However, the terminology and the description of
the various embodiments with respect to 3GPP-based architectures is not intended to
limit the principles and ideas of the inventions to such systems.
Also the detailed explanations given in the Technical Background section above are
intended to better understand the mostly 3GPP specific exemplary embodiments
described herein and should not be understood as limiting the invention to the described
specific implementations of processes and functions in the mobile communication
network. Nevertheless, the improvements proposed herein may be readily applied in the
architectures described in the Technical Background section. Furthermore, the concept
of the invention may be also readily used in the LTE RAN currently discussed by the
3GPP.
CLAIMS
1. A control channel signal for use in a mobile communication system, wherein
the control channel signal is associated to protocol data unit transporting user
data and comprises a control information field consisting of a number of bits
jointly encoding a transport format and a redundancy version used for
transmitting the protocol data unit.
2. The control channel signal according to claim 1, wherein the bits of the control
information field jointly encode the transport format, a redundancy version
used for transmitting the protocol data unit and a sequence number of the
protocol data unit.
3. The control channel signal according to claim 1, wherein the bits of the control
information field jointly encode the transport format, a redundancy version
used for transmitting the protocol data unit and a new data indicator for
indicating whether the transmission of the protocol data unit is an initial
transmission of the user data.
4. The control channel signal according to one of claims 1 to 3, wherein the
control information field consists of a number of bits yielding a range of values
that can be represented in the control information field, and wherein a first
subset of the values is reserved for indicating a transport format of the
protocol data unit and a second subset of values are reserved for indicating a
redundancy version for transmitting the user data.
5. The control channel signal according to claim 4, wherein the first subset of
values contains more values than the second subset of values.
6. The control channel signal according to claim 4 or 5, wherein the redundancy
version of the protocol data unit is implicit to the transport format indicated by
the corresponding value of the first subset.
7. The control channel signal according to one of claims 4 to 6, wherein in case
the transmission of the protocol data unit is an initial transmission of the user
data, the value of the encoded information bits in the control channel field is
representing a value of the first subset of values.
8. The control channel signal according to one of claims 4 to 7, wherein in case
the transmission of the protocol data unit is a retransmission of the user data,
the value of the encoded information bits in the control channel field is
representing a value of the first subset or the second subset of values.
9. The control channel signal according to one of claims 4 to 8, wherein in case
the transmission of the protocol data unit is a retransmission of the user data,
the value of the encoded information bits in the control channel field is
representing a value of the second subset of values.
10. The control channel signal according to one of claims 4 to 9, wherein the bits
of the control information field jointly encode the transport format, a
redundancy version used for transmitting the protocol data unit and a new
data indicator for indicating whether the transmission of the protocol data unit
is an initial transmission of the user data, and
wherein use of one of the values of a first subset set also indicates the
transmission of the protocol data unit to be an initial transmission.
11. The control channel signal according to one of claims 1 to 10, wherein the
redundancy version to be used for the initial transmission of the user data in
the protocol data unit is fixed or preconfigured.
12. The control channel signal according to claim 1, further comprising a
sequence number field indicating the sequence number of the protocol data
unit.
13. The control channel signal according to claim 1, further comprising a new
data indicator field indicating whether the transmission of the protocol data
unit is an initial transmission or a retransmission of the user data.
14. The control channel signal according to one of claims 1 to 13, wherein the
control channel signal further comprises a resource allocation field for
indicating the physical radio resource or resources allocated to a receiver for
receiving the protocol data unit or the physical radio resource or resources on
which a transmitter is to transmit the protocol data unit.
15. The control channel signal according to one of claims 1 to 14, wherein the
control channel signal further comprises a mobile terminal identifier field for
indicating the mobile terminal or a group of mobile terminals that are to
receive the control channel signal.
16. The control channel signal according to one of claims 1 to 15, wherein the
control channel signal is a L1/L2 control channel signal.
17. The control channel signal according to one of claims 1 to 16, wherein in case
the protocol data packet is a retransmission for the user data, the bits of the
control information field include a flag indicating the type of information
indicated by the remaining bits of the control information field.
18. A control channel signal for use in a mobile communication system, wherein
the control channel signal is associated to protocol data unit transporting user
data and comprises a control information field consisting of a number of bits
representing:
- a transport format and implicitly a redundancy version of the protocol data
unit, if the transmission of the protocol data unit is an initial transmission of
the user data, or
- a redundancy version of the protocol data unit, if the transmission of the
protocol data unit is a retransmission of the user data.
19. The control channel signal according to claim 18, wherein the bits of the
control information field represent a redundancy version and optionally a
transport format of the protocol data unit, if the transmission of the protocol
data unit is a retransmission.
20. A method for providing a control signalling associated to a protocol data unit
conveying user data in a mobile communication system, comprising the
following steps performed by a base station of the mobile communication
system:
generating a control channel signal comprising a control information field in
which a transport format and a redundancy version of the protocol data unit is
jointly encoded, and
transmitting the control channel signal to at least one mobile terminal.
21. The method according to claim 20, further comprising the step of receiving
from the at least one mobile terminal a feedback indicating, whether the
protocol data unit has been successfully decoded at the mobile terminal, and
if not, retransmitting the protocol data unit and transmitting a second control
channel signal comprising a control information field in which a transport
format and a redundancy version of the protocol data unit is jointly encoded
and, wherein the second control channel signal is associated to the
retransmission of the protocol data unit to the mobile terminal.
22. The method according to claim 21, wherein the protocol data unit and the
second protocol data unit are transmitted or received using the same HARQ
process.
23. A method for providing control signalling associated to a protocol data unit
conveying user data in a mobile communication system, comprising the
following steps performed by a base station of the mobile communication
system:
generating a control channel signal according to claim 16, and
transmitting the control channel signal to at least one mobile terminal.
24. The method according to one of claims 20 to 23, further comprising the step
of transmitting the protocol data unit to a mobile terminal or receiving the
protocol data unit from the mobile terminal utilizing a HARQ retransmission
protocol.
25. The method according to claim 24, wherein the protocol data unit is
transmitted or received using a HARQ process indicated in the control
channel signal.
26. The method according to claim 25, wherein the protocol data unit is
transmitted or received using a HARQ process determined based on to the
sub-frame number of the sub-frame conveying the protocol data unit.
27. The method according to claim 20 to 26, wherein the protocol data unit is
transmitted or received using the physical radio resource or resources
indicated in the control channel signal.
28. The method according to one of claims 20 to 27, wherein the mobile
communication system is a multi-carrier system and the control channel
signal is transmitted within the physical radio resources of a sub-frame
allocated to the L1/L2 control channels of the multi-carrier system.
29. The method according to claim on of claims 20 to 28, wherein the protocol
data unit is transmitted in the same sub-frame as the associated control
channel signal.
30. The method according to one of claims 20 to 29, wherein the base station is
serving a plurality of mobile terminals, and wherein a control channel signal is
generated and transmitted by the base station for each mobile terminal or
group of mobile terminals.
31. A method for use in a mobile communication system, the method comprising
the following steps performed by a mobile terminal:
receiving a sub-frame of physical radio resources comprising a control
channel signal destined to the mobile terminal, wherein the control channel
signal comprises a control information field in which a transport format and a
redundancy version of a protocol data unit is jointly encoded,
determining based on the received control channel signal the transport format
of and the redundancy version for the protocol data packet conveying user
data, and
receiving or transmitting the protocol data packet on at least one physical
radio resource using the transport format and the redundancy version of the
protocol data packet indicated in the received control information field.
32. The method according to claim 31, wherein the transport format is a transport
block size information of the protocol data unit, and wherein the received
control channel signal further comprises a resource allocation field indicating
the physical radio resource or resources allocated to the mobile terminal,
and wherein the step of determining the transport block size of the protocol
data unit depends on the information comprised in the resource allocation
field and the control information field
33. The method according to claim 31 or 32, wherein the control channel signal
indicates the protocol data packet to be a retransmission of user data and
wherein the method further comprises the step of transmitting a positive
acknowledgement for the received protocol data packet to the base station, if
the control channel signaling associated to the initial transmission for the user
data has been missed.
34. The method according to claim 31 to 33, further comprising the step of, in
case the protocol data unit is retransmission, reusing the transport format of
the protocol data unit indicated in a control channel signal for the initial
transmission for the transmission or reception of the retransmission of the
protocol data unit.
35. The method according to one of claims 31 to 34, wherein the information bits
are associated to a single reference information indicating a transport format
and a redundancy version used for transmitting the protocol data unit
associated to the respective value represented by the information bits of the
control information field for initial transmissions and retransmissions of the
protocol data packet.
36. A method for use in a mobile communication system, the method comprising
the following steps performed by a mobile terminal:
receiving a sub-frame of physical radio resources comprising a control
channel signal according to claim 18 or 19,
determining based on the received control channel signal the transport format
of and the redundancy version for the protocol data packet conveying user
data, and
receiving or transmitting the protocol data packet on at least one physical
radio resource using the transport format and the redundancy version of the
protocol data packet indicated in the received control information field.
37. The method according to claim 36, wherein the information bits are
associated to two different reference information, and the method comprises
the steps of:
using the first reference information when determining the transport format
and the redundancy version of the protocol data packet, if the transmission of
the protocol data packets is an initial transmission, and
using the second reference when determining the transport format and the
redundancy version of the protocol data packet, if the transmission of the
protocol data packets is a retransmission.
38. The method according to claim 37, wherein the first reference information
indicates a transport format associated to the respective value represented by
the information bits of the control information field, and
the second reference information indicates a redundancy version associated
to the respective value represented by the information bits of the control
information field.
39. A base station for providing control signalling associated to a protocol data
unit conveying user data in a mobile communication system, the base station
comprising:
a processing unit for generating a control channel signal comprising a control
information field in which a transport format and a redundancy version of the
protocol data unit is jointly encoded, and
a transmitter unit transmitting control signalling comprising the control channel
signal to at least one mobile terminal.
40. A mobile terminal for use in a mobile communication system, the mobile
terminal comprising:
a receiver unit for receiving a sub-frame of physical radio resources
comprising a control channel signal destined to the mobile terminal, wherein
the control channel signal comprises a control information field in which a
transport format and a redundancy version of a protocol data unit is jointly
encoded,
a processing unit for determining based on the received control channel
signal the transport format of and the redundancy version for the protocol
data packet conveying user data, and
a transmitter unit for transmitting the protocol data packet on at least one
physical radio resource using the transport format and the redundancy
version of the protocol data packet indicated in the received control
information field.
41. A mobile terminal for use in a mobile communication system, the mobile
terminal comprising:
a receiver unit for receiving a sub-frame of physical radio resources
comprising a control channel signal destined to the mobile terminal, wherein
the control channel signal comprises a control information field in which a
transport format and a redundancy version of a protocol data unit is jointly
encoded, and
a processing unit for determining based on the received control channel
signal the transport format of and the redundancy version for the protocol
data packet conveying user data,
wherein the receiver unit is adapted to receive the protocol data packet on at
least one physical radio resource using the transport format and the
redundancy version of the protocol data packet indicated in the received
control information field.
42. A computer readable medium storing instructions that, when executed by a
processor unit of a base station, cause the base station to:
generate a control channel signal comprising a control information field in
which a transport format and a redundancy version of the protocol data unit is
jointly encoded, and
transmit the control channel signal to at least one mobile terminal.
43. A computer readable medium storing instructions that, when executed by a
processor unit of a mobile terminal, cause the mobile terminal to:
receive a sub-frame of physical radio resources comprising a control channel
signal destined to the mobile terminal, wherein the control channel signal
comprises a control information field in which a transport format and a
redundancy version of a protocol data unit is jointly encoded,
determine based on the received control channel signal the transport format
of and the redundancy version for the protocol data packet conveying user
data, and
receive or transmit the protocol data packet on at least one physical radio
resource using the transport format and the redundancy version of the
protocol data packet indicated in the received control information field.

The invention relates to a method for providing control signalling associated to a protocol
data unit conveying user data in a mobile communication system and to the control
channel signal itself. Furthermore, the invention also provides a mobile station and a
base station and their respective operation in view of the newly defined control channel
signals defined herein. In order to reduce the control channel overhead, the invention
suggests defining a common field for the transport format and redundancy version in the
control channel information format. According to one approach, the common field is used
to jointly encode transport format and redundancy version therein. According to another
aspect, one shared field is provided on the control channel signal that indicates either a
transport format or a redundancy version depending of whether the control channel
signal relates to an initial transmission or a retransmission. In another embodiment,
further enhancements to a HARQ protocol are suggested for addressing certain error
cases.

Documents

Application Documents

# Name Date
1 2119-KOLNP-2010-RELEVANT DOCUMENTS [16-09-2023(online)].pdf 2023-09-16
1 abstract-2119-kolnp-2010.jpg 2011-10-07
2 2119-KOLNP-2010-RELEVANT DOCUMENTS [03-09-2022(online)].pdf 2022-09-03
2 2119-kolnp-2010-specification.pdf 2011-10-07
3 2119-KOLNP-2010-RELEVANT DOCUMENTS [16-09-2021(online)].pdf 2021-09-16
3 2119-kolnp-2010-pct request form.pdf 2011-10-07
4 2119-KOLNP-2010-RELEVANT DOCUMENTS [31-03-2020(online)].pdf 2020-03-31
4 2119-kolnp-2010-pct priority document notification.pdf 2011-10-07
5 2119-KOLNP-2010-PA.pdf 2011-10-07
5 2119-KOLNP-2010-IntimationOfGrant29-04-2019.pdf 2019-04-29
6 2119-KOLNP-2010-PatentCertificate29-04-2019.pdf 2019-04-29
6 2119-kolnp-2010-international publication.pdf 2011-10-07
7 2119-kolnp-2010-form 5.pdf 2011-10-07
7 2119-KOLNP-2010-ABSTRACT [01-02-2019(online)].pdf 2019-02-01
8 2119-kolnp-2010-form 3.pdf 2011-10-07
8 2119-KOLNP-2010-CLAIMS [01-02-2019(online)].pdf 2019-02-01
9 2119-KOLNP-2010-COMPLETE SPECIFICATION [01-02-2019(online)].pdf 2019-02-01
9 2119-KOLNP-2010-FORM 3 1.1.pdf 2011-10-07
10 2119-KOLNP-2010-FER_SER_REPLY [01-02-2019(online)].pdf 2019-02-01
10 2119-kolnp-2010-form 2.pdf 2011-10-07
11 2119-KOLNP-2010-FORM 13.pdf 2011-10-07
11 2119-KOLNP-2010-OTHERS [01-02-2019(online)].pdf 2019-02-01
12 2119-kolnp-2010-form 1.pdf 2011-10-07
12 2119-KOLNP-2010-PETITION UNDER RULE 137 [01-02-2019(online)].pdf 2019-02-01
13 2119-KOLNP-2010-Certified Copy of Priority Document (MANDATORY) [11-10-2018(online)].pdf 2018-10-11
13 2119-kolnp-2010-drawings.pdf 2011-10-07
14 2119-kolnp-2010-description (complete).pdf 2011-10-07
14 2119-KOLNP-2010-FORM 3 [29-08-2018(online)].pdf 2018-08-29
15 2119-kolnp-2010-correspondence.pdf 2011-10-07
15 2119-KOLNP-2010-FER.pdf 2018-08-01
16 2119-KOLNP-2010-AMENDED DOCUMENTS [25-06-2018(online)].pdf 2018-06-25
16 2119-KOLNP-2010-CORRESPONDENCE 1.2.pdf 2011-10-07
17 2119-KOLNP-2010-CORRESPONDENCE 1.1.pdf 2011-10-07
17 2119-KOLNP-2010-Changing Name-Nationality-Address For Service [25-06-2018(online)].pdf 2018-06-25
18 2119-kolnp-2010-claims.pdf 2011-10-07
18 2119-KOLNP-2010-RELEVANT DOCUMENTS [25-06-2018(online)].pdf 2018-06-25
19 2119-KOLNP-2010-CLAIMS 1.1.pdf 2011-10-07
19 2119-KOLNP-2010-FORM 3 [02-06-2018(online)].pdf 2018-06-02
20 2119-KOLNP-2010-ASSIGNMENT.pdf 2011-10-07
20 2119-KOLNP-2010-FORM 3 [27-12-2017(online)].pdf 2017-12-27
21 2119-kolnp-2010-abstract.pdf 2011-10-07
21 Form 3 [17-04-2017(online)].pdf 2017-04-17
22 2119-KOLNP-2010-CORRESPONDENCE-(04-11-2016).pdf 2016-11-04
22 2119-KOLNP-2010-FORM-18.pdf 2011-11-25
22 Description(Complete) [24-10-2016(online)].pdf 2016-10-24
23 2119-KOLNP-2010-FORM-1-(04-11-2016).pdf 2016-11-04
23 Form 13 [24-10-2016(online)].pdf 2016-10-24
23 Power of Attorney [04-10-2016(online)].pdf 2016-10-04
24 2119-KOLNP-2010-PA ORIGINAL-(04-11-2016).pdf 2016-11-04
24 Form 6 [04-10-2016(online)].pdf 2016-10-04
24 Other Document [24-10-2016(online)].pdf 2016-10-24
25 Assignment [04-10-2016(online)].pdf 2016-10-04
25 Description(Complete) [24-10-2016(online)].pdf 2016-10-24
26 Form 13 [24-10-2016(online)].pdf 2016-10-24
26 Form 6 [04-10-2016(online)].pdf 2016-10-04
26 Other Document [24-10-2016(online)].pdf 2016-10-24
27 Form 13 [24-10-2016(online)].pdf 2016-10-24
27 Other Document [24-10-2016(online)].pdf 2016-10-24
27 Power of Attorney [04-10-2016(online)].pdf 2016-10-04
28 Description(Complete) [24-10-2016(online)].pdf 2016-10-24
28 Assignment [04-10-2016(online)].pdf 2016-10-04
28 2119-KOLNP-2010-FORM-18.pdf 2011-11-25
29 2119-kolnp-2010-abstract.pdf 2011-10-07
29 2119-KOLNP-2010-PA ORIGINAL-(04-11-2016).pdf 2016-11-04
29 Form 6 [04-10-2016(online)].pdf 2016-10-04
30 2119-KOLNP-2010-ASSIGNMENT.pdf 2011-10-07
30 2119-KOLNP-2010-FORM-1-(04-11-2016).pdf 2016-11-04
30 Power of Attorney [04-10-2016(online)].pdf 2016-10-04
31 2119-KOLNP-2010-CLAIMS 1.1.pdf 2011-10-07
31 2119-KOLNP-2010-CORRESPONDENCE-(04-11-2016).pdf 2016-11-04
31 2119-KOLNP-2010-FORM-18.pdf 2011-11-25
32 2119-kolnp-2010-abstract.pdf 2011-10-07
32 2119-kolnp-2010-claims.pdf 2011-10-07
32 Form 3 [17-04-2017(online)].pdf 2017-04-17
33 2119-KOLNP-2010-ASSIGNMENT.pdf 2011-10-07
33 2119-KOLNP-2010-CORRESPONDENCE 1.1.pdf 2011-10-07
33 2119-KOLNP-2010-FORM 3 [27-12-2017(online)].pdf 2017-12-27
34 2119-KOLNP-2010-CLAIMS 1.1.pdf 2011-10-07
34 2119-KOLNP-2010-CORRESPONDENCE 1.2.pdf 2011-10-07
34 2119-KOLNP-2010-FORM 3 [02-06-2018(online)].pdf 2018-06-02
35 2119-kolnp-2010-claims.pdf 2011-10-07
35 2119-kolnp-2010-correspondence.pdf 2011-10-07
35 2119-KOLNP-2010-RELEVANT DOCUMENTS [25-06-2018(online)].pdf 2018-06-25
36 2119-kolnp-2010-description (complete).pdf 2011-10-07
36 2119-KOLNP-2010-CORRESPONDENCE 1.1.pdf 2011-10-07
36 2119-KOLNP-2010-Changing Name-Nationality-Address For Service [25-06-2018(online)].pdf 2018-06-25
37 2119-KOLNP-2010-AMENDED DOCUMENTS [25-06-2018(online)].pdf 2018-06-25
37 2119-KOLNP-2010-CORRESPONDENCE 1.2.pdf 2011-10-07
37 2119-kolnp-2010-drawings.pdf 2011-10-07
38 2119-kolnp-2010-correspondence.pdf 2011-10-07
38 2119-KOLNP-2010-FER.pdf 2018-08-01
38 2119-kolnp-2010-form 1.pdf 2011-10-07
39 2119-kolnp-2010-description (complete).pdf 2011-10-07
39 2119-KOLNP-2010-FORM 13.pdf 2011-10-07
39 2119-KOLNP-2010-FORM 3 [29-08-2018(online)].pdf 2018-08-29
40 2119-KOLNP-2010-Certified Copy of Priority Document (MANDATORY) [11-10-2018(online)].pdf 2018-10-11
40 2119-kolnp-2010-drawings.pdf 2011-10-07
40 2119-kolnp-2010-form 2.pdf 2011-10-07
41 2119-kolnp-2010-form 1.pdf 2011-10-07
41 2119-KOLNP-2010-FORM 3 1.1.pdf 2011-10-07
41 2119-KOLNP-2010-PETITION UNDER RULE 137 [01-02-2019(online)].pdf 2019-02-01
42 2119-KOLNP-2010-FORM 13.pdf 2011-10-07
42 2119-kolnp-2010-form 3.pdf 2011-10-07
42 2119-KOLNP-2010-OTHERS [01-02-2019(online)].pdf 2019-02-01
43 2119-KOLNP-2010-FER_SER_REPLY [01-02-2019(online)].pdf 2019-02-01
43 2119-kolnp-2010-form 2.pdf 2011-10-07
43 2119-kolnp-2010-form 5.pdf 2011-10-07
44 2119-KOLNP-2010-COMPLETE SPECIFICATION [01-02-2019(online)].pdf 2019-02-01
44 2119-KOLNP-2010-FORM 3 1.1.pdf 2011-10-07
44 2119-kolnp-2010-international publication.pdf 2011-10-07
45 2119-KOLNP-2010-CLAIMS [01-02-2019(online)].pdf 2019-02-01
45 2119-kolnp-2010-form 3.pdf 2011-10-07
45 2119-KOLNP-2010-PA.pdf 2011-10-07
46 2119-KOLNP-2010-ABSTRACT [01-02-2019(online)].pdf 2019-02-01
46 2119-kolnp-2010-form 5.pdf 2011-10-07
46 2119-kolnp-2010-pct priority document notification.pdf 2011-10-07
47 2119-kolnp-2010-international publication.pdf 2011-10-07
47 2119-KOLNP-2010-PatentCertificate29-04-2019.pdf 2019-04-29
47 2119-kolnp-2010-pct request form.pdf 2011-10-07
48 2119-KOLNP-2010-IntimationOfGrant29-04-2019.pdf 2019-04-29
48 2119-KOLNP-2010-PA.pdf 2011-10-07
48 2119-kolnp-2010-specification.pdf 2011-10-07
49 2119-kolnp-2010-pct priority document notification.pdf 2011-10-07
49 2119-KOLNP-2010-RELEVANT DOCUMENTS [31-03-2020(online)].pdf 2020-03-31
49 abstract-2119-kolnp-2010.jpg 2011-10-07
50 2119-KOLNP-2010-RELEVANT DOCUMENTS [16-09-2021(online)].pdf 2021-09-16
50 2119-kolnp-2010-pct request form.pdf 2011-10-07
51 2119-kolnp-2010-specification.pdf 2011-10-07
51 2119-KOLNP-2010-RELEVANT DOCUMENTS [03-09-2022(online)].pdf 2022-09-03
52 abstract-2119-kolnp-2010.jpg 2011-10-07
52 2119-KOLNP-2010-RELEVANT DOCUMENTS [16-09-2023(online)].pdf 2023-09-16
53 2119-KOLNP-2010-CERTIFIED COPIES-CERTIFICATE U-S 72 147 & UR 133-2 [08-08-2025(online)].pdf 2025-08-08
54 2119-KOLNP-2010-CERTIFIED COPIES-CERTIFICATE U-S 72 147 & UR 133-2 [08-08-2025(online)]-6.pdf 2025-08-08
55 2119-KOLNP-2010-CERTIFIED COPIES-CERTIFICATE U-S 72 147 & UR 133-2 [08-08-2025(online)]-5.pdf 2025-08-08
56 2119-KOLNP-2010-CERTIFIED COPIES-CERTIFICATE U-S 72 147 & UR 133-2 [08-08-2025(online)]-4.pdf 2025-08-08
57 2119-KOLNP-2010-CERTIFIED COPIES-CERTIFICATE U-S 72 147 & UR 133-2 [08-08-2025(online)]-3.pdf 2025-08-08
58 2119-KOLNP-2010-CERTIFIED COPIES-CERTIFICATE U-S 72 147 & UR 133-2 [08-08-2025(online)]-2.pdf 2025-08-08
59 2119-KOLNP-2010-CERTIFIED COPIES-CERTIFICATE U-S 72 147 & UR 133-2 [08-08-2025(online)]-1.pdf 2025-08-08

Search Strategy

1 search_06-07-2018.pdf

ERegister / Renewals

3rd: 03 Jun 2019

From 18/12/2010 - To 18/12/2011

4th: 03 Jun 2019

From 18/12/2011 - To 18/12/2012

5th: 03 Jun 2019

From 18/12/2012 - To 18/12/2013

6th: 03 Jun 2019

From 18/12/2013 - To 18/12/2014

7th: 03 Jun 2019

From 18/12/2014 - To 18/12/2015

8th: 03 Jun 2019

From 18/12/2015 - To 18/12/2016

9th: 03 Jun 2019

From 18/12/2016 - To 18/12/2017

10th: 03 Jun 2019

From 18/12/2017 - To 18/12/2018

11th: 03 Jun 2019

From 18/12/2018 - To 18/12/2019

12th: 09 Dec 2019

From 18/12/2019 - To 18/12/2020

13th: 15 Dec 2020

From 18/12/2020 - To 18/12/2021

14th: 08 Dec 2021

From 18/12/2021 - To 18/12/2022

15th: 08 Dec 2022

From 18/12/2022 - To 18/12/2023

16th: 06 Dec 2023

From 18/12/2023 - To 18/12/2024

17th: 10 Dec 2024

From 18/12/2024 - To 18/12/2025