Note: Descriptions are shown in the official language in which they were submitted.
CA 02715075 2014-03-14
1
Description
METHOD AND APPARATUS FOR PROCESSING
PADDING BUFFER STATUS REPORTS
Technical Field
[1] The present invention relates to a method and apparatus for processing
buffer
status reports (BSRs).
Background Art
[2] In the related art, buffer status reporting was performed, but radio
resources were
unnecessarily wasted. As such, the related art technologies do not
sufficiently address
such issues, and thus do not offer appropriate solutions.
Disclosure of Invention
Technical Solution
[3] The present inventors recognized at least the above-identified
drawbacks of the
related art. Based upon such recognition, the various features described
hereafter
have been conceived such that processing of buffer status reports (BSRs) is
improved, such that when protocol data units (PDUs) (or Transport Blocks (TB)
or
other types of data units) are constructed, the remaining available portions
therein are
used as a padding region for inserting buffer status information, which
results in more
efficient use of radio resources.
Summary of the Invention
[3a] In accordance with one aspect of the invention there is provided a
method of
constructing a medium access control protocol data unit (MAC PDU) to include a
buffer status report (BSR). The method involves determining whether any
padding
bits are available in the MAC PDU, and if a number of padding bits is equal to
or
larger than a size of Short BSR plus its sub-header but smaller than a size of
Long
BSR plus its sub-header and if more than one Logical Channel Group (LCG) has
buffered data, triggering the BSR. The method also involves including the
triggered
BSR into the MAC PDU. The MAC PDU contains a Logical Channel ID (LCID)
field and the triggered BSR. The triggered BSR is indicated explicitly in the
LCID field by using a specific value that is different from values of the LCID
CA 02715075 2014-03-14
la
field for a short BSR and a long BSR. The triggered BSR has a format that is
equivalent to the short BSR.
[3b] A format of the triggered BSR may have 2 bits of Logical Channel Group
ID
(LCG ID) field and 6 bits of buffer size field.
[3c] The LCID field may identify the logical channel instance of the
corresponding
MAC SDU or the type of the corresponding MAC control element or padding for
the
DL-SCH and UL-SCH respectively.
[3d] The value of the LCID field for the triggered BSR may be used to
indicate that
the BSR is included in the MAC PDU.
[3e] The logical channel identification (LCID) field may have 5 bits.
[3fl In accordance with another aspect of the invention there is provided
a protocol
entity of a mobile terminal. The protocol entity includes a checking unit that
checks
whether any padding bits are available in a medium access control protocol
data unit
(MAC PDU). The protocol entity also includes a processing unit that cooperates
with
the checking unit to perform steps of triggering a buffer status report (BSR)
if a
number of padding bits is equal to or larger than a size of Short BSR plus its
sub-
header but smaller than a size of Long BSR plus its sub-header and if more
than one
Logical Channel Group (LCG) has buffered data. The protocol entity also
includes
including the triggered BSR into the MAC PDU. The MAC PDU contains a
Logical Channel ID (LCID) field and the triggered BSR. The triggered BSR is
indicated explicitly in the LCID field by using a specific value that is
different
from values of the LCID field for a short BSR and a long BSR. The triggered
BSR has a format that is equivalent to the short BSR.
[3g] A format of the triggered BSR may have 2 bits of Logical Channel Group
ID
(LCG ID) field and 6 bits of buffer size field.
[3h] The LCID field may identify the logical channel instance of the
corresponding
MAC SDU or the type of the corresponding MAC control element or padding for
the
DL-SCH and UL-SCH respectively.
[3i] The value of the LCID field for the triggered BSR may be used to
indicate that
the BSR is included in the MAC PDU.
[3.i] The logical channel identification (LCID) field may have 5 bits.
CA 02715075 2014-03-14
lb
Brief Description of Drawings
[4] Figure 1 shows an exemplary network architecture for an E-UMTS (Evolved
Universal Mobile Telecommunications System).
[5] Figure 2 shows the control plane radio interface protocol between the
mobile
terminal and base station based on the 3GPP radio access network standard.
[6] Figure 3 shows the user plane radio interface protocol between the
mobile
terminal and base station based on the 3GPP radio access network standard.
[7] Figure 4 shows an exemplary MAC PDU format used by a MAC entity.
[8] Figure 5 shows exemplary MAC PDU sub-header formats used by a MAC
entity.
[9] Figure 6 shows an exemplary MAC PDU sub-header format used by a MAC
entity.
[10] Figure 7 shows an exemplary short BSR and truncated BSR MAC control
element.
[11] Figure 8 shows an exemplary long BSR MAC control element.
[12] Figure 9 shows an exemplary MAC PDU with data and padding, with and
without BSR.
[13] Figure 10 shows an example where the mobile terminal received
instructions to
construct a MAC PDU having a size of L+M+3 bytes.
[14] Figure 11 shows an example where a MAC PDU has 2 bytes in the
remaining
space,
2
WO 2009/104928 PCT/KR2009/000826
1 byte is used for the Padding BSR, and the MAC sub-header only has 1 byte for
ad-
ditional use.
[15] Figure 12 shows two exemplary implementations of constructing a MAC
PDU
having BSR included therein, with and without a BSR sub-header.
[16] Figure 13 shows three exemplary implementations of constructing a MAC
PDU
having BSR included therein.
[17] Figure 14 shows two more exemplary implementations of constructing a
MAC PDU
having BSR included therein.
[18] Figure 15 shows three more exemplary implementations of constructing a
MAC
PDU having BSR included therein.
[19] Figure 16 shows that the existence of padding LCID does not
discriminate whether
there is still a data in the UE's buffer, and to assist efficiency of the eNB
scheduler,
rather than wasting 2 bytes by Padding LCID, it would be more useful to use
those 2
bytes for short BSR.
[20] Figure 17 shows two possible implementations (a) and (b) on how to
indicate the
existence of Padding BSR.
[21] Figure 18 shows two possible implementations on the location of
Padding BSR in
case that explicit indication is used.
[22] Figure 19 shows the case where 2 bytes remain after short BSR is
already included
into a MAC PDU, thus long BSR should have been used instead of short BSR.
[23] Figure 20 shows the case where 2 bytes remain after Long BSR has been
included.
[24] Figure 21 shows the case where 2 remaining bytes after Long BSR is
included, in
case of implicit Padding BSR indication.
[25] Figure 22 shows that because 2 bytes are enough for the inclusion of
short BSR, the
format of (b) should be used instead of the format of (a).
[26] Figure 23 shows the case where 2 bytes remain for a MAC PDU which
already
included a short BSR.
[27] Figure 24 shows the case where 2 bytes remain for a MAC PDU which
already
included a long BSR.
[28] Figure 25 shows a use case of a 2 byte remaining space of TB (Padding
BSR is the
last one).
[29] Figure 26 shows that the remaining space is enough for the inclusion
of long BSR,
and different situations where multiple BSRs may be included in the MAC PDU.
[30] Figure 27 shows multiple BSRs being included in one MAC PDU.
[31] Figure 28 shows the case of combining the remaining space and the
already allocated
space for "Regular" and "Periodic" BSR to include a long BSR.
[32] Figure 29 shows an exemplary structure of a UE and an eNB with certain
protocol
layers including a MAC entity.
CA 02715075 2010-07-30
3
WO 2009/104928 PCT/KR2009/000826
Mode for the Invention
[33] The inventive concepts and features herein related to processing of
buffer status
reports (BSRs) are explained in terms of a Long Term evolution (LTE) system or
other
so-called 4G communication systems, which is an enhancement to current 3GPP
tech-
nologies. However, such details are not meant to limit the various features
described
herein, which are applicable to other types of mobile and/or wireless
communication
systems and methods.
[34] Hereafter, the term "mobile terminal" will be used to refer to various
types of user
devices, such as mobile communication terminals, user equipment (UE), mobile
equipment (ME), and other devices that support various types of wireless commu-
nication technologies.
[35] The present invention relates to exchanging data between a base
station and a mobile
terminal in a so-called Long Term Evolution (LTE) system. In particular, in a
MAC
entity that constructs a MAC PDU (or other type of data unit such as a
transport block)
upon receiving data from each logical channel, when padding space in a MAC PDU
is
available, the mobile terminal effectively sends buffer state information
using such
padding region of the MAC PDU such that unnecessary waste of radio resources
is
minimized.
[36] Figure 1 shows an exemplary network architecture for an E-UMTS
(Evolved
Universal Mobile Telecommunications System) 100, which is a type of mobile com-
munications system. The E-UMTS system is a system that has evolved from the
UMTS system and its basic standardization tasks are now being performed by the
3GPP organization. The E-UMTS system can be said to be a Long Term Evolution
(LTE) system, which is a type of so-called 4G or next generation system that
has
evolved from the current 3G mobile communication systems.
[37] The E-UMTS network 100 can be generally distinguished into the E-UTRAN
(Evolved Universal Terrestrial Radio Access Network) 110 and the CN (core
network).
The E-UTRAN is comprised of a mobile terminal 112 (e.g. user equipment (UE),
mobile station, handset, mobile phone, etc.), a base station 114, 116, 118
(e.g., an
eNode B, access point (AP), network node, etc.) a serving gateway (S-GW) 122,
124
located at an end of the network for connection with an external network, and
a
mobility management entity (MME) 122, 124 that manages various mobility
aspects of
the mobile terminal. For a single eNode B, one or more cells (or regions,
areas, etc.)
may exist.
[38] Figures 2 and 3 show the radio interface protocol between the mobile
terminal and
base station based on the 3GPP radio access network standard. This radio
interface
protocol is divided horizontally into a physical layer, a data link layer, and
a network
CA 02715075 2010-07-30
4
WO 2009/104928 PCT/KR2009/000826
layer, and is divided vertically into a user plane for transmitting data
information and a
control plane for transferring control signals (signaling). These protocol
layers can be
divided into Li (Layer 1), L2 (Layer 2), and L3 (Layer 3), which are the lower
three
layers of the OSI (Open System Interconnection) standard model, which is well
known
in communication systems.
[39] Hereafter, the control plane of the radio protocol in Figure 2 and the
user plane of the
radio protocol in Figure 3 will be described respectively.
[40] In Layer 1, the physical layer 225-245, 325-345 uses one or more
physical channels
to provide an information transfer service. The physical layer is connected to
the MAC
(Medium Access Control) layer 224-244, 324-344 located above via one or more
transport channels, and data is transferred between the MAC layer and the
physical
layer through these transport channels. Also, between respectively different
physical
layers, such as the physical layer in the transmitter (transmitting side) and
the physical
layer in the receiver (receiving side), data is transferred via one or more
physical
channels.
[41] In Layer 2, the MAC layer provides service to a RLC (Radio Link
Control) layer
223-243, 323-343, which is an upper layer, via one or more logical channels.
The RLC
layer supports the transmission of data with reliability. The PDCP (Packet
Data Con-
vergence Protocol) layer 322-342 in Layer 2 performs a header compression
function
to reduce the header size for Internet Protocol (IP) packets that contain
relatively large
and unnecessary control information such that IP packets (such as for IPv4,
IPv6, etc.)
may be effectively transmitted over the radio interface having relatively
small
bandwidth. Also, the PDCP layer is used for performing coding of control plane
(C-plane) data, such as RRC messages. The PDCP layer can also perform coding
of
user plane (U-plane) data.
[42] Located at the uppermost portion of Layer 3, the RRC (Radio Resource
Control)
layer 222-242 is only defined in the control plane and is responsible for the
control of
logical channels, transport channels and physical channels with relation to
the con-
figuration, re-configuration and release of radio bearers (RBs). Here, a radio
bearer is a
service provided by Layer 2 for transferring data between the mobile terminal
and E-
UTRAN.
[43] Hereafter, aspects of the RACH (Random Access CHannel) will be
explained. The
RACH channel is used for transmitting relatively short length data via the
uplink. In
particular, the RACH is used when there is a signaling message or user data to
be
transmitted via the uplink by a mobile terminal that did not receive
allocation of
dedicated radio resources, or may also be used when the base station should
instruct
the mobile terminal to perform a RACH procedure.
[44] As described above, the two main things that comprise the E-UTRAN are
the base
CA 02715075 2010-07-30
5
WO 2009/104928 PCT/KR2009/000826
station and the mobile terminal. The radio resources for a single cell are
comprised of
uplink radio resources and downlink radio resources. The base station is
responsible
for the allocation and control of uplink radio resources and downlink radio
resources of
a cell. Namely, the base station determines what radio resources are to be
used by what
mobile terminals at certain moments in time. For example, the base station can
determine that 3.2 seconds from now, the frequency from 100 Mhz to 101 Mhz
will be
allocated to user 1 for a duration of 0.2 seconds to allow downlink data
transmissions.
Also, after the base station makes such determination, these matters can be
informed to
the corresponding mobile terminal such that this mobile terminal receives
downlink
data. Likewise, the base station can determine when a certain mobile terminal
should
use what amount of which radio resources for data transmission via the uplink,
and the
base station informs the mobile terminal about its determination, to thus
allow the
mobile terminal to transmit data during the determined time period using the
de-
termined radio resources.
[45] If the base station manages radio resources in a dynamic manner,
efficient use of
radio resources would be possible. Typically, a single mobile terminal
continuously
uses a single radio resource during a call connection. This is not preferable
considering
that most recent services are IP packet-based. The reason is that most packet
services
do not continuously generate packets during the duration of a call connection,
and
there are many time periods in which nothing is transmitted during the call.
Despite
this, continued allocation of a radio resource to a single mobile terminal is
inefficient.
To solve this, the mobile terminal of a E-UTRAN system uses a method in which
radio
resources are allocated to the mobile terminal only while service data exists.
[46] In more detail, for efficient use of radio resources in an LTE system,
the base station
should know about the type and amount of data that each user wishes to
transmit. The
data for the downlink is transferred to the base station from the access
gateway. Thus,
the base station knows about how much data needs to be transferred via the
downlink
to each user. In contrast, for uplink data, if the mobile terminal itself does
not inform
the base station about the information related to the data to be transferred
via the
uplink, the base station cannot know how much radio resources are needed for
each
mobile terminal. Thus, for the base station to appropriately allocate uplink
radio
resources to the mobile terminal, each mobile terminal should provide to the
base
station, the necessary information that allows the base station to perform
scheduling of
radio resources.
[47] To do so, when the mobile terminal has data that it should transmit,
this is informed
to the base station, and the base station transfers a resource allocation
message (or uses
some other means of informing) to the mobile terminal based upon such
information.
[48] In the above procedure, namely, when the mobile terminal has data to
be transmitted,
CA 02715075 2010-07-30
6
WO 2009/104928 PCT/KR2009/000826
when such is informed to the base station, the mobile terminal informs the
base station
about the amount of data stored in its buffer. This is achieved by means of a
buffer
status report (BSR) or some other buffer status (or state) information.
[49] However, the buffer status report is generated in the form of a MAC
control element
(CE), which is included in a MAC PDU (protocol data unit) (or some other type
of
data unit or transport block) and transmitted from the mobile terminal to the
base
station. Namely, uplink radio resources are needed for transmitting the buffer
status
report (BSR). This would mean that uplink radio resource allocation request in-
formation, for transmitting the BSR, needs to be sent. When a BSR has been
generated,
if there are any uplink radio resources that have been allocated, the mobile
terminal
immediately uses the uplink radio resources to transmit the BSR. Such process
of
sending the BSR from the mobile terminal to the base station may be called a
BSR
procedure.
[50] Hereafter, the MAC PDU structure will be explained with reference to
Figures 4
through 8 that show various exemplary MAC PDU formats used by a MAC entity
(such as 224 and 244 in Fig. 2 or 324, 344 in Fig. 3).
[51] Figure 4 shows an exemplary format of a PDU used in the MAC entity.
The LCID
field indicates whether a MAC SDU or a MAC Control Element (CE) is related
thereto. If related to a MAC SDU, this indicates which logical channel the MAC
SDU
pertains to, and if related to a MAC CE, this indicates the kind or type of
MAC CE.
The L field informs about the size of the MAC SDU with respect to the MAC SDU.
The E field informs about whether any additional MAC sub-headers exist. In the
above
process, if the size of the corresponding MAC SDU or the MAC CE is 127 or
smaller,
a 7-bit L field is used, and otherwise a 15-bit L field is used (as shown in
Fig. 5). Also,
the MAC SDU included in the MAC PDU is the last among the data fields included
in
the MAC PDU, and the related MAC sub-header as shown in Figure 6 is used.
Alter-
natively, with respect to a MAC CE having a fixed size, the MAC sub-header as
shown
in Figure 6 is used. In other situations, the MAC sub-header shown in Figure 5
is used.
[52] Figures 7 and 8 show the exemplary formats of a BSR report. A short
BSR or a long
BSR may be used depending on the number of logical channel groups that have
data
and on the size of the available space in the MAC PDU. Here, the short BSR and
the
long BSR refer to the relative length of the BSR. As such, other similar terms
may be
used to express such types of BSR. For example, the short BSR may be called a
truncated or shortened BSR, while the long BSR may be called an expanded or
lengthened BSR.
[53] Referring back to Figures 4 through 6, each field used therein will be
explained.
[54] The MAC header is of variable size and consists of the following
fields:
[55] - LCID: The Logical Channel ID field identifies the logical channel
instance of the
CA 02715075 2010-07-30
7
WO 2009/104928 PCT/KR2009/000826
corresponding MAC SDU or the type of the corresponding MAC control element or
padding as described in Tables 1 and 2 (shown below) for the DL-SCH and UL-SCH
respectively. There is one LCID field for each MAC SDU, MAC control element or
padding included in the MAC PDU. In addition to that, one or two additional
LCID
fields are included in the MAC PDU, when single-byte or two-byte padding is
required
but cannot be achieved by padding at the end of the MAC PDU. The LCID field
size is
bits;
[56] - L: The Length field indicates the length of the corresponding MAC
SDU or MAC
control element in bytes. There is one L field per MAC PDU subheader except
for the
last subheader and sub-headers corresponding to fixed-sized MAC control
elements.
The size of the L field is indicated by the F field;
[57] - F: The Format field indicates the size of the Length field. There is
one F field per
MAC PDU subheader except for the last subheader and sub-headers corresponding
to
fixed-sized MAC control elements. The size of the F field is 1 bit. If the
size of the
MAC SDU or MAC control element is less than 128 bytes, the UE shall set the
value
of the F field to 0, otherwise the UE shall set it to 1;
[58] - E: The Extension field is a flag indicating if more fields are
present in the MAC
header or not. The E field is set to "1" to indicate another set of at least
R/R/E/LCID
fields. The E field is set to "0" to indicate that either a MAC SDU, a MAC
control
element or padding starts at the next byte;
[59] - R: Reserved bit, set to "0".
[60] The MAC header and sub-headers are octet aligned.
[61] Hereafter, information about the values used in the LCID is explained
in the
following tables for the downlink shared channel (DL-SCH) and the uplink
shared
channel (UL-SCH).
[62] Table 1
CA 02715075 2010-07-30
8
WO 2009/104928 PCT/KR2009/000826
[Table 1]
Values of LCID for DL-SCH
Index LCID values
00001- Identity of the logical
xxxxx channel
xxxxx- Reserved
11011
11100 UE Contention Resolution
Identity
11101 Timing Advance
11110 DRX Command
11111 Padding
[63] Table 2
[Table 2]
Values of LCID for UL-SCH
Index LCID values
00001- Identity of the logical
YYYYY channel
YYYYY- Reserved
11010
11011 Power Headroom Report
11100 C-RNTI
11101 Short Buffer Status Report
11110 Long Buffer Status Report
11111 Padding
[64] Hereafter, an exemplary method of how the MAC entity constructs a MAC
PDU will
be described.
[65] When multiple radio bearers (RBs) are multiplexed to a single
transport channel and
transmitted, the MAC layer in a mobile terminal (that can support LTE) uses
the
following rules with respect to the radio resources given for each
transmission time in
order to determine the amount of data to be transmitted.
[66] 1) First, with respect to the multiplexed transport channels, the
transmission data
amount is determined in sequentially decreasing order based on the Logical
Channel
Priority (LCP) of each logical channel, and according to the determined data
amount,
the MAC PDU is constructed using the data of the logical channels.
[67] 2) If any radio resources remain, the above step 1) can be repeated
such that, with
CA 02715075 2010-07-30
9
WO 2009/104928 PCT/KR2009/000826
respect to the multiplexed transport channels, the transmission data amount is
de-
termined in sequentially decreasing order based on the Logical Channel
Priority (LCP)
of each logical channel.
[68] Here, the LCP is currently being discussed as being defined from 1
through 8, with 1
being the highest and 8 being the lowest. However, the specific definitions
may change
in future discussions. Also, in the above procedure, if there is any MAC CE
(Control
Element) that needs to be sent, such MAC CE is firstly included into the MAC
PDU.
[69] The mobile terminal may perform triggering of the BSR procedure in at
least one of
the following situations:
[70] a) initially, all buffers do not contain any data, but when data newly
arrives at a
certain buffer (Regular B SR);
[71] b) when data arrives at an empty buffer, and the priority of the
logical channel related
to that buffer is higher than the priority of the logical channel having data
in the buffer
previously (Regular BSR);
[72] c) when a cell is changed (Regular BSR);
[73] d) upon lapse of a certain time after the last transmission of the BSR
(Periodic BSR);
and
[74] e) if there is any available space remaining in the constructed MAC
PDU (Padding
BSR).
[75] Among the above triggers, if the BSR is triggered due to the last
situation, such BSR
may be called a Padding BSR. The mobile terminal constructs the MAC PDU
according to the amount of radio resources allocated from the base station,
namely,
according to the size of the MAC PDU. Here, the MAC entity of the mobile
terminal
sequentially includes (or inserts) into the MAC PDU, the data that was stored
in the
buffer(s) of the logical channels, with respect to each logical channel
established for
the mobile terminal. If any available space remains in the MAC PDU even after
all
data stored with respect to each logical channel have been included
(inserted), the BSR
procedure is triggered and the padding BSR triggered as a result thereof is
included
into the MAC PDU for construction thereof, and such is transmitted to the base
station.
[76] However, in certain situations, the BSR occurring due to padding is
located at the
very last portion of the MAC PDU. Namely, after the MAC entity constructs a
MAC
PDU using the data of each logical channel, if any space remains in the MAC
PDU, the
BSR is additionally included (inserted) at the rear of the MAC PDU. This is
shown in
Figure 9.
[77] In Figure 9, it is assumed that the mobile terminal has received
allocation of radio
resources from the base station for constructing a MAC PDU having a size of
X+N
bytes. Here, based on the data stored with respect to each logical channel,
the MAC
entity begins to fill the MAC PDU for construction. In Figure 9, drawing (a)
shows
CA 02715075 2010-07-30
10
WO 2009/104928 PCT/KR2009/000826
that padding occurs when the MAC PDU in constructed by the MAC entity using
all
data stored in its buffer. If the size of padding is greater than the size of
the BSR, the
MAC entity adds the BSR into the padding region.
[78] Here, as can be seen in Figure 9, because it is not informed that the
Padding BSR is
included due to padding, the receiver that received the MAC PDU cannot
effectively
use the BSR information. Namely, the receiver cannot know which of the MAC PDU
formats of drawings (a) or (b) in Figure 9 has been received, thus even if the
MAC
PDU includes the BSR, the base station cannot perform proper allocation of
radio
resources using the BSR information.
[79] Also, in certain situations, in order to send Padding BSR, there may
be problems
related to a reduced amount of user data being included in the MAC PDU.
[80] Figure 10 shows an example where the mobile terminal received
instructions to
construct a MAC PDU having a size of L+M+3 bytes. In Figure 10, the portion
indicated as remaining space is a padding region, and is shown to have a
length of 2
bytes. Here, because the Short BSR size is 1 byte, the mobile terminal
determines that
the Short BSR can be inserted into the remaining space, and Padding BSR is
thus
triggered. However, problems may arise when the MAC entity attempts to insert
the
Short Padding BSR. For example, as can be seen in Figure 10, there is no L
field
included in the MAC sub-header of the RMC PDU N. But, if in the above
procedure,
when the Padding BSR is to be inserted, the RLC PDU N would no longer be the
last
element included in the MAC PDU. Thus, in certain situations, an L field must
be
included in the MAC sub-header of the MAC SDU, which is not the last element.
As
such, because the Padding BSR is forcibly inserted, the following error can
occur.
[81] Namely, as can be seen in Figure 11, of the 2 bytes in the remaining
space, 1 byte is
used for the Padding BSR, and the MAC sub-header only has 1 byte for
additional use.
However, if the RLC PDU N requires an L field of 2 bytes, an error will occur.
Thus,
in order to construct a proper MAC sub-header, a 1-byte portion of the RLC PDU
needs to be reduced.
[82] The present invention provides specific procedures and rules used by
the MAC entity
to include or insert a Padding BSR into the MAC PDU in an effective manner
when
Padding BSR has been triggered. Various exemplary embodiments of the present
invention will be described below.
[83] First embodiment
[84] The Padding BSR is included (or inserted) at a position that is not
the last portion of
the MAC PDU. When the Padding BSR procedure is triggered, the Padding BSR may
be inserted at a position that is just before the last position among the MAC
SDUs or
the MAC CEs of the MAC PDU. Accordingly, the MAC sub-headers related to the
MAC SDUs, the MAC CEs, and the Padding BSR may also be arranged in the same
CA 02715075 2010-07-30
11
WO 2009/104928 PCT/KR2009/000826
order. When the Padding BSR procedure is triggered, the Padding BSR may be
included (or inserted) in front of the other MAC SDUs of the MAC PDU.
Accordingly,
the MAC sub-headers related to the Padding BSR may also be arranged in the
same
order. When the Padding BSR procedure is triggered, the Padding BSR may be
included (or inserted) behind the other MAC SDUs of the MAC PDU. Accordingly,
the MAC sub-headers related to the Padding BSR may also be arranged in the
same
order.
[85] When constructing the MAC PDU, after the MAC PDU is filled with the
MAC
SDUs and MAC CEs and their related MAC sub-headers, if there is any remaining
space having a size that equals at least the total sum of the Short BSR, the
Long BSR,
and their MAC sub-headers, then the Short BSR, the Long BSR, and their MAC sub-
headers are included (or inserted) into the MAC PDU. In this procedure, the
MAC
Padding BSR may be included in front of the MAC SDUs or MAC CEs of the MAC
PDU. The MAC sub-headers related to the MAC Padding BSR may be included first
among all the MAC sub-headers of the MAC PDU.
[86] The present invention proposes that, upon triggering the Padding BSR,
the MAC
entity considers the size of the MAC sub-header related thereto. Namely, in
con-
structing the MAC PDU, the MAC entity considers whether the MAC PDU has any
padding space to thus consider the size of the BSR and the size of its related
sub-
header. For example, if the Short BSR size is 1 byte and its related sub-
header size is
also 1 byte, the size of this sub-header is also considered such that the BSR
procedure
(Short BSR) is triggered only if the MAC PDU remaining space is 2 bytes or
more.
Also, in this situation, the Padding BSR is triggered only if the sub-headers
of the other
MAC SDUs and the MAC CEs can be properly constructed. Here, proper
construction
means including a MAC sub-header that does not have a F/L field for MAC CEs
that
do not need an L field, including a MAC sub-header that has a F/L field for
the
remaining MAC SDUs excluding the MAC CE or the very last MAC SDU requiring
an L field, and including a MAC sub-header that does not have a F/L field for
the last
MAC SDU.
[87] In the above procedure, after the MAC PDU is constructed, and after
the Padding
BSR is triggered when there is some remaining space, the BSR is included
(inserted)
into the MAC PDU and such BSR is deemed to be a Regular BSR. Thus, the Padding
BSR is handled in the same manner as a Regular BSR. Namely, in this situation,
the
Padding BSR has the same restrictions of the same location construction as
that of a
Regular BSR.
[88] In the above procedure, when the Padding BSR procedure is triggered
due to
padding, in particular, when a Short BSR is included in the MAC PDU due to the
Padding BSR, the Short BSR includes buffer information of a logical channel
group
CA 02715075 2010-07-30
12
WO 2009/104928 PCT/KR2009/000826
related to the logical channel with highest priority among the logical
channels (having
buffered data) established for the mobile terminal.
[89] Second embodiment
[90] The present invention proposes that the LCID field be used to directly
(or explicitly)
inform about a BSR being included in the MAC PDU upon BSR triggering due to
padding, such that the receiver can easily determine and know that a BSR is
included
in the MAC PDU (especially when a BSR was included in the MAC PDU due to
padding). More specifically, it is proposed that the MAC sub-header be used to
indicate whether a BSR has been included.
[91] Referring to Figure 12, drawing (a) shows that when the MAC PDU
includes
padding, based on the size of the padding, the receiver can know that the
Padding BSR
has been included. In drawing (b), even if the BSR is included in the MAC PDU
due to
padding, a MAC sub-header having a set LCID field related to the included BSR
is
inserted into the MAC PDU such that the existence of the BSR is directly (or
ex-
plicitly) informed.
[92] According to another method of the present invention, the receiver
considers the
BSR to be a Padding BSR, when the BSR is included in the MAC PDU and when
padding exists for the MAC PDU.
[93] In the above procedure, when Padding BSR is triggered due to a padding
procedure,
and as a result, when BSR is included in the MAC PDU, a separate LCID that is
different from the allocated LCID can be designated to indicate either a Short
BSR or a
Long BSR. Namely, the mobile terminal sets the LCID field (that was separately
designated) in the MAC sub-header related to the BSR, if the BSR is included
in the
MAC PDU when the Padding BSR was triggered due to padding.
[94] Third embodiment
[95] Referring to Figure 13 having drawings (a), (b) and (c), when
constructing the MAC
PDU according to the present invention, the MAC entity of the sender (or
transmitting
side) takes the data transferred from each logical channel and the MAC Control
Elements, which are included (or filled or inserted) into the MAC PDU, and if
the
MAC PDU has a 2 byte space remaining, such remaining space is used for
handling
the Padding BSR. Various applications using this concept are described below.
[96] In the present invention, when constructing the MAC PDU, the MAC
entity of the
sender takes the data transferred from each logical channel and the MAC
Control
Elements (CE), which are included (or filled or inserted) into the MAC PDU,
and if the
MAC PDU has a 2 byte space remaining, a plurality of padding headers (each
padding
header being 1 byte long) are included to fill the remaining space of the MAC
PDU.
[97] In the present invention, when constructing the MAC PDU, the MAC
entity of the
sender takes the data transferred from each logical channel and the MAC
Control
CA 02715075 2010-07-30
13
WO 2009/104928 PCT/KR2009/000826
Elements (CE), which are included (or filled or inserted) into the MAC PDU,
and if the
MAC PDU has a 2 byte space remaining, such 2 byte space is filled such that an
L
field is included in the last MAC sub-header.
[98] In the present invention, when constructing the MAC PDU, the MAC
entity of the
sender takes the data transferred from each logical channel and the MAC
Control
Elements (CE), which are included (or filled or inserted) into the MAC PDU,
and if the
MAC PDU has a 2 byte space remaining, a Padding BSR (namely a 1 byte BSR for
the
MAC sub-header) and a 1 byte Short BSR are included to fill the remaining
space of
the MAC PDU.
[99] It should be noted that the above procedures can also be performed in
a similar
manner for a MAC PDU with a remaining space of not only 2 bytes, but for any
number of bytes, such as 4 bytes.
[100] Fourth embodiment
[101] When the base station constructs and transmits a MAC PDU to the
mobile terminal,
if a padding space is created after the MAC PDU is constructed, a command for
timing
alignment (i.e., a TAC command) may be included in the MAC PDU. Such TAC
command can be used by the mobile terminal to adjust its transmission timing
on the
uplink. For example, when 2 bytes in the MAC PDU remain after the MAC PDU is
constructed, the base station may allocate 1 byte for the sub-header of the
TAC
command and allocate the other 1 byte for the TAC command itself that provides
timing instructions for the mobile terminal to adjust its transmissions on the
uplink.
Also, even if 1 byte of padding space remains, the base station does not
include the
related MAC sub-header but the TAC command is included in the MAC PDU and
transmitted.
[102] Fifth embodiment
[103] If the mobile terminal determines that padding space exists and tries
to trigger the
Padding BSR, more accurate rules are provided such that the triggering of the
Padding
BSR is prevented if the padding BSR cannot actually be included in the MAC
PDU.
Thus in the present invention, when the mobile terminal uses the MAC CEs and
MAC
SDUs to construct a MAC PDU, the mobile terminal checks the remaining space by
obtaining the size of the padding byte, which is the MAC PDU size minus the
sum of
the sizes of the MAC SDUs, the MAC CEs, and their MAC sub-headers. In this cal-
culation, for the last element included in the MAC PDU (namely, the last MAC
SDU),
the mobile terminal assumes that an L field would be included in the MAC sub-
header
related to the MAC SDU. If the last element is a MAC CE, and if such MAC CE
has a
variable size, the mobile terminal assumes that an L field is included in the
MAC sub-
header related to that MAC CE and performs the calculation. Namely, assuming
that
the MAC sub-header for the last element is "R/R/E/LCID/F/L" and the size of
the
CA 02715075 2010-07-30
14
WO 2009/104928 PCT/KR2009/000826
padding bit for the MAC PDU is calculated. Also, only if the padding byte size
is the
same as or greater than the sum of the BSR size and the size of its related
MAC sub-
header, then the Padding BSR would be triggered.
[104] Namely, when calculating the number of padding bytes, the F/L
field(s) in the MAC
sub-header(s) related to all MAC SDUs included in the MAC PDU are included in
the
calculations. Here, even for the MAC CEs that have variable size, calculations
are
performed by including the F/L field in the MAC sub-header related to the MAC
CE.
Thus, if the number of padding bytes is the same as or greater than the sum of
the BSR
and its related MAC sub-headers, only then would the Padding BSR be triggered.
[105] Sixth embodiment
[106] Referring to Figure 14 having drawings (a) and (b) and Figure 15
having drawings
(a), (b) and (c), when constructing the MAC PDU, the MAC entity in the
transmitter
(sending side) the MAC PDUs are filled with the data from each logical channel
and
the MAC CEs, then if 2 bytes of remaining space are in the MAC PDU, and if a
Short
BSR is already included in the MAC PDU, the present invention proposes that
the
Short BSR be replaced with a Long BSR. Thus, the Long BSR is included in the
MAC
PDU instead of the Short BSR, as shown in Figure 14.
[107] Also, when constructing the MAC PDU, the MAC entity in the
transmitter (sending
side) the MAC PDUs are filled with the data from each logical channel and the
MAC
CEs, then if 4 bytes of remaining space are in the MAC PDU, such is used for
the
padding BSR, and particularly, the Long BSR is used. Here, the 4 bytes are
comprised
of a 1-byte MAC sub-header, a 1-byte Short BSR, and 2 bytes used for padding.
[108] When constructing the MAC PDU, the MAC entity of the transmitter
(sending side)
fills the MAC PDU with data from each logical channel and MAC CEs, if the MAC
PDU already includes a BSR, then one or more additional BSRs may also be
inserted
into the MAC PDU if there is any remaining space in the MAC PDU.
[109] Also, when constructing the MAC PDU, the MAC entity of the
transmitter (sending
side) fills the MAC PDU with data from each logical channel and MAC CEs, if
the
MAC PDU already includes a BSR, and if there is any remaining space, the
Padding
BSR is not triggered.
[110] Additionally, when constructing the MAC PDU, the MAC entity of the
transmitter
(sending side) fills the MAC PDU with data from each logical channel and MAC
CEs,
if there is any remaining space, and if a Periodic BSR or a Regular BSR has
been
triggered, then among the largest size Padding BSR and the BSRs that have been
triggered, only the largest BSR thereof is inserted.
[111] Furthermore, when constructing the MAC PDU, the MAC entity of the
transmitter
(sending side) fills the MAC PDU with data from each logical channel and MAC
CEs,
and if the Periodic BSR or the Regular BSR was triggered, then the Padding BSR
will
CA 02715075 2010-07-30
15
WO 2009/104928 PCT/KR2009/000826
not be triggered.
[112] As for the effects of the present invention, when the mobile terminal
constructs a
MAC PDU and if there is any space remaining in the MAC PDU, a method of ef-
fectively using such remaining space is provided in order to increase the
usability and
efficiency of radio resources.
[113] Some more details about the concepts and features of the present
invention will be
explained as follows:
[114] Details #1
[115] The Padding BSR can be included at the other places (or positions)
before last sub-
headers of MAC. Namely, when the padding has a size of 2 bytes after filling
the
Transport Block (TB) with sub-headers and related MAC SDUs or other MAC
control
elements, a 2 byte short BSR is included. For example, the first sub-header
can be a
short BSR if it can exactly remove padding.
[116] Namely, when the padding is of 2 byte length after filling the TB
with sub-headers
and related MAC SDUs or other MAC control elements, the last sub-header for
MAC
SDU can includes a 2 byte "L" field. Namely, the F field indicating a "long L"
field
and a "15 bit L field" are used. At each decoding of MAC sub-header, when the
total
sum of the size of sub-headers and the size of related MAC control elements or
related
MAC SDUs is exactly the same as the TB (assuming that the trailing 1-7 bit is
excluded), the receiving MAC entity considers that there are no more sub-
headers.
This is not considered as an error case. Namely, the last MAC sub-header can
include
an "L" field, if it can exactly fit the TB without having padding byte/LCID.
[117] Details #2
[118] Padding occurs at the end of the MAC PDU, except when single-byte or
two-byte
padding is required but cannot be achieved by padding at the end of the MAC
PDU.
[119] When single-byte or two-byte padding is required but cannot be
achieved by padding
at the end of the MAC PDU, one or two MAC PDU sub-headers corresponding to
padding are inserted before the first MAC PDU sub-header corresponding to a
MAC
SDU; or if such sub-header is not present, before the last MAC PDU sub-header
corre-
sponding to a MAC control element.
[120] For FDD, when, due to the quantization in the transport block sizes
that can be
supported or triggering of the Scheduling Information, the size of the data
plus header
is less than or equal to the TB size of the E-TFC selected by the UE minus 24
bits, the
DDI value [111111] shall be appended at the end of the MAC-e header and a
Scheduling Information shall be concatenated into this MAC-e PDU, where DDI
value
[111111] indicates that there is a Scheduling Information concatenated in this
MAC-e
PDU. Otherwise, if the size of the data plus header is less than or equal to
the TB size
of the E-TFC selected by the UE minus 18 bits, a Scheduling Information shall
be con-
CA 02715075 2010-07-30
16
WO 2009/104928 PCT/KR2009/000826
catenated into this MAC-e PDU. In any other case it is understood that another
MAC-
es PDU or Scheduling Information does not fit and it is therefore not
necessary to
reserve room in the transport block for an additional DDI field.
[121] Namely, in case of HSUPA, to decide what to include or when to stop
filling the
MAC TB, the transmitter continuously compares the size of MAC header plus MAC
data with the available transport block size. So, in some cases, scheduling
information
is added without any field indicating the existence of scheduling information.
Thus,
some header fields such as DDI can be omitted to increase efficiency.
[122] But, the current LTE MAC specification does not describe this kind of
operation.
Thus, the question arises as to whether the operation of HSUPA is forbidden or
not.
The case is shown in Figure 13.
[123] In (a), the remaining two bytes are used up by including 2 padding
sub-header. In (b),
the two bytes are replaced by "F" and "L" fields. Accordingly, the last sub-
header also
includes "F" and "L" fields. This is the similar approach taken in HSUPA.
Namely, by
comparing the total sum of sub-headers plus the data field with size of
Transport Block
(TB), the receivers can know that there is no padding. In (c), the two bytes
are replaced
by a Short BSR. In fact, the short BSR may not be an empty buffer status
report. The
useful scenario for (c) is shown in Figure 16.
[124] As shown in Figure 16, the existence of padding LCID does not
discriminate whether
there is still a data in the UE's buffer. To assist efficiency of the eNB
scheduler, it is
believed that approach (c) in Figure 13 is better than the approach (a).
Namely, rather
than wasting 2 bytes by Padding LCID, it would be more useful to use those 2
bytes
for short BSR.
[125] Referring back to Figures 4 through 6, an explanation of the MAC PDU
(DL-SCH
and UL-SCH) will be provided.
[126] A MAC PDU consists of a MAC header, zero or more MAC Service Data
Units
(MAC SDU), zero, or more MAC control elements, and optionally padding; as
described in Figure 4. Both the MAC header and the MAC SDUs are of variable
sizes.
A MAC PDU header consists of one or more MAC PDU sub-headers; each sub-header
corresponding to either a MAC SDU, a MAC control element or padding. In some
em-
bodiments, the MAC PDU sub-headers for padding should not occur more than once
in
the MAC PDU.
[127] A MAC PDU sub-header may consist of six header fields R/R/E/LCID/F/L,
but for
the last sub-header in the MAC PDU and for fixed sized MAC control elements.
The
last sub-header in the MAC PDU and sub-headers for fixed sized MAC control
elements consist solely of the four header fields R/R/E/LCID. It follows that
a MAC
PDU sub-header corresponding to padding consists of the four header fields R/
R/E/LCID.
CA 02715075 2010-07-30
17
WO 2009/104928 PCT/KR2009/000826
[128] MAC PDU sub-headers have the same order as the corresponding MAC
SDUs,
MAC control elements and padding. MAC control elements, except Padding BSR,
are
always placed before any MAC SDU. Padding BSR occurs at the end of the MAC
PDU. Padding occurs at the end of the MAC PDU, except when single-byte is
required
but cannot be achieved by padding at the end of the MAC PDU. When single-byte
is
required but cannot be achieved by padding at the end of the MAC PDU, one MAC
PDU sub-headers corresponding to padding are inserted before the first MAC PDU
sub-header corresponding to a MAC SDU; or if such sub-header is not present,
before
the last MAC PDU sub-header corresponding to a MAC control element. When two
bytes remain after filling the MAC PDU with MAC SDUs or MAC control elements
(except the BSR), then the short BSR is included.
[129] In some embodiments, a maximum of one MAC PDU can be transmitted per
TB per
UE. Also, depending on the physical layer category, one or two TBs can be
transmitted
per TTI per UE.
[130] It should be noted that it is FFS whether this MAC PDU applies only
to DL/UL SCH
or also to other transport channels.
[131] Details #3
[132] Padding BSR is included when there is some remaining space in the MAC
PDU that
is equal to or larger than the size of the BSR. If uplink (UL) resources are
allocated and
the number of padding bits is larger than the size of the Buffer Status Report
MAC
control element, such BSR is referred below to as "Padding BSR." But,
regarding how
to express the Padding BSR, the following issues need to be addressed: MAC
control
elements (except Padding BSR) are always placed before any MAC SDU. Padding
BSR occurs at the end of the MAC PDU and Padding occurs at the end of the MAC
PDU, except when single-byte or two-byte padding is required but cannot be
achieved
by padding at the end of the MAC PDU. Both Padding BSR and Padding may occur
at
the end of the MAC PDU. However, whether padding BSR is indicated explicitly
by
BSR LCID or implicitly by Padding LCID or whether Padding BSR follows Padding
or Padding follows Padding BSR are some of the issued that are resolved by the
present invention.
[133] How to indicate Padding BSR (4 proposals)
[134] Figure 17 shows two possible implementations (see drawings (a) and
(b)) on how to
indicate the existence of Padding BSR.
[135] In (a), depending on the size of padding area, either short BSR or
long BSR is
included without having a related SubHeader. In (a), BSR can be included
whenever
the size of padding is equal to or larger than 2 bytes. In this approach, if 3
bytes remain
after filling the MAC PDU with other Sub Header(s) or MAC SDU/CE, then the BSR
can be included.
CA 02715075 2010-07-30
18
WO 2009/104928 PCT/KR2009/000826
[136] In (b), the last 2 MAC Sub Headers are BSR Sub Header and Padding Sub
Header,
whereby Padding BSR is indicated explicitly. In this approach (b), when 4
bytes
remain after filling the MAC PDU with other Sub Header(s) or MAC SDU/CE, then
the BSR can be included.
[137] Namely, the difference between the two approaches (a) and (b) is what
the minimum
size of remaining bytes to include BSR is.
[138] Proposal 1
[139] It is proposed to decide whether to use implicit or explicit method
to indicate
Padding BSR, and the order between Padding BSR and Padding is considered.
[140] Figure 17 shows two possible implementations about the location of
Padding BSR in
case that implicit indication is used as in (a) of Figure 12. Either approach
is workable.
In Figure 17, is can be understood that the BSR may be placed before or after
the byte
used for padding.
[141] Figure 18 shows two possible implementations on the location of
Padding BSR in
case that explicit indication is used as in (b) of Figure 12. Both solutions
are based on
the "E" field. If the "E" field indicates another MAC Sub Header, the receiver
just
decodes next byte to know what is following. But, in approach (b), upon
detection of
BSR LCID after Padding LCID, the MAC receiver in eNB can immediately decode
the
last bytes to know the UE's buffer status. On the other hand, in approach (a),
upon
detection of BSR LCID, the MAC receiver in eNB first has to calculate the
starting
position of BSR before decoding the first byte of BSR.
[142] Proposal 2
[143] It is proposed to decide whether Padding BSR is last or Padding is
last in a MAC
PDU.
[144] Proposal 3
[145] When 2 byte remains after filling MAC PDU with MAC SDUs or MAC CEs
except
BSR, it should is used to deliver short BSR.
[146] Meanwhile, if two bytes remain after the BSR is already included in
the MAC PDU,
the situations in Figure 19 (case of 2 remaining bytes after short BSR is
included) and
in Figure 20 (case of 2 remaining bytes after long BSR is included, in case
explicit
Padding BSR indication) can be considered.
[147] Figure 19 drawing (a) shows the case where 2 bytes remain after short
BSR is
already included into a MAC PDU. This case means that 4 bytes originally
remained in
MAC PDU after filling data only from each logical channel. In other words, 4
bytes
were available after filling the MAC PDU with RLC PDUs before including the
short
BSR. Regardless of whether there was further data in the RLC entities, the 4
bytes
were initially padding bytes. Then, long BSR should have been included rather
than
the short BSR. Thus, (b) should be used than (a).
CA 02715075 2010-07-30
19
WO 2009/104928 PCT/KR2009/000826
[148] Figure 20 drawing (a) shows the case where 2 bytes remain after Long
BSR has been
included. It means that 6 bytes originally remained in MAC PDU after filling
data
from each logical channel. In other words, 6 bytes were available after
filling the MAC
PDU with only RLC PDUs from upper layer. There are three scenarios for this:
[149] 1. If there was no remaining data in every RLC entities, the 6 bytes
were initially
padding bytes, the BSR should have been cancelled or normal padding BSR must
have
been included. In this case, if explicit indication is used for padding BSR,
(b) and (c) in
figure 4 will occur rather than (a). If implicit indication is used for
padding BSR, (b)
and (c) in figure 5 will occur rather than (a).
[150] 2. If there was only one logical channel with data after filling MAC
PDU, short BSR
must have been triggered and the remaining 4 bytes must have been used to
include
data for the logical channel.
[151] 3. If there were more than one logical channel with data after
filling the MAC PDU,
long BSR should be included anyway. But this situation seems weird, because
(b) and
(c) in Figure 20 will occur in case explicit indication is used for padding
BSR. And (b)
and (c) in Figure 21 (Case of 2 remaining bytes after Long BSR is included, in
case
implicit Padding BSR indication) will occur in case implicit indication is
used for
padding BSR.
[152] Accordingly, the two-byte padding Sub Header case may not be obvious
and maybe
not always useful. And because current MAC structure can avoid two-byte
padding,
two-byte padding Sub Header should not exist.
[153] Proposal 4
[154] Two-byte padding Sub Header inside MAC Header should be avoided.
[155] Details #4
[156] For the network, certain concepts of the present invention may be
described in the
following manner:
[157] eNB composes MAC PDU using available data in RLC/PDCP buffers for one
UE
and additionally using MAC Control Elements.
[158] After filling MAC PDU with MAC SDUs/MAC CEs:
[159] - if two bytes remains after filling MAC PDU,
[160] -- the eNB includes Timing Alignment Command (TA CMD) into the MAC
PDU,
replacing the two bytes.
[161] --- in this case, one byte is used to include subheader for TA CMD
and
[162] ---- one byte is used to include actual value of timing command.
[163] - if more than two bytes remains after filling MAC PDU,
[164] -- the eNB includes TA CMD into the MAC PDU, replacing at least the
two bytes.
[165] --- in this case, one byte is used to include subheader for TA CMD
and
[166] ---- one byte is used to include actual value of timing command.
CA 02715075 2010-07-30
20
WO 2009/104928 PCT/KR2009/000826
[167] and at least one byte is used as subheader for padding.
[168] - Or, if more than two bytes remains after filling MAC PDU,
[169] -- the eNB includes TA CMD into the MAC PDU, replacing at least the
two bytes.
[170] --- in this case, one byte is used to include actual value of timing
command.
[171] ---- and one byte is used as subheader for padding.
[172] and other bytes are used as padding.
[173] --- Or, one byte of padding is replaced by TA CMD.
[174] For the mobile terminal, certain concepts of the present invention
may be described
in the following manner:
[175] a UE decodes/reassembles a received MAC PDU into MAC SDUs and/or MAC
CEs.
[176] - a UE decodes each MAC SubHeader and the MAC SDUs/CEs associated
with the
SubHeader
[177] -- a UE calculates the size sum of subheaders and MAC SDUs/CEs
[178] -- a UE compares the size sum with the MAC PDU size
[179] - if the padding is indicated and the size of padding (except padding
subheader) is
equal to or large than 1-bytes,
[180] -- the UE considers that a TA CMD is included in the padding part.
[181] Details #5
[182] For the uplink direction, the current MAC specification mandates that
UE shall
include BSR if padding space allows the inclusion of BSR. Considering that two
bytes
are required to include a short BSR, a BSR will be included in a MAC PDU
whenever
the remaining padding space is two-bytes.
[183] In Figure 22, because 2 bytes are enough for the inclusion of short
BSR, the situation
of drawing (a) should not occur. If we follow the intention of current
specification, UE
should send the format of drawing (b) of Figure 22.
[184] Thus, the special handing of two-byte padding according to the
following is not
needed:
[185] Padding occurs at the end of the MAC PDU, except when single-byte or
two-byte
padding is required but cannot be achieved by padding at the end of the MAC
PDU.
When single-byte or two-byte padding is required but cannot be achieved by
padding
at the end of the MAC PDU, one or two MAC PDU sub-headers corresponding to
padding are inserted before the first MAC PDU sub-header corresponding to a
MAC
SDU; or if such sub-header is not present, before the last MAC PDU sub-header
corre-
sponding to a MAC control element.
[186] By the way, BSR in drawing (b) of Figure 22 can be called a Padding
BSR, because
it is included due to the padding space. Because the BSR is not located at the
end of
MAC PDU, one may argue that this is inconsistent with current definition of
padding
BSR. However, the padding BSR need not be the last element in MAC PDU. Fur-
CA 02715075 2010-07-30
21
WO 2009/104928 PCT/KR2009/000826
thermore, padding BSR is indicated with explicit LCID. Thus, the padding BSR
can be
located anywhere within the MAC PDU.
[187] In the downlink direction, there is no need for BSR, the situation in
DL is different
from UL. Thus, special handling of 2 byte padding is still required in DL
direction.
Because the size of Timing Advance Command is 2 byte, one can argue that TA
CMD
can be included whenever 2 byte remains in MAC PDU. Sending more TA CMD is
beneficial because it can keep UE longer in synchronized state, but this
restricts eNB's
behaviour unnecessarily.
[188] Regarding further analysis, to be on the safe side, we also have to
consider the case
where 2 bytes remain for a MAC PDU which already included a BSR. This is shown
in
the Figure 23 for short BSR and Figure 24 for long BSR.
[189] Namely, if 2 bytes remain for a PDU which already included short BSR,
it means
that 4 bytes are available for a BSR. Then, short BSR will be replaced with
long BSR.
Thus, drawing (b) should occur rather than drawing (a) in Figure 23.
[190] Namely, if 2 bytes remain for a PDU which already included long BSR,
it means that
6 bytes are available for a BSR. Then, 4 bytes will be used for long BSR and
other 2
bytes can used for the L field for the last MAC SDU or Padding LCID. Thus, the
format in drawings (b) or (c) should be used rather than the format in drawing
(a) of
Figure 24.
[191] Details #6
[192] Features of the present invention may also be expressed as follows:
[193] For padding BSR:
[194] - if the number of padding bits is equal to or larger than the size
of the Short BSR but
smaller than the size of the Long BSR, report Short BSR of the LCG with the
highest
priority logical channel with buffered data;
[195] - else, if the number of padding bits is equal to or larger than the
size of the Long
BSR, report Long BSR.
[196] Location of Padding BSR
[197] The BSR in drawing (b) of Figure 22 is Padding BSR because it is
included due to
the padding space. But, due to the fact that the BSR is not located at the end
of MAC
PDU, one may argue that this is inconsistent with current definition of
padding BSR.
However, the padding BSR need not be the last element in MAC PDU. Furthermore,
padding BSR is indicated with explicit LCID. Thus, the padding BSR can be
located
anywhere within the MAC PDU.
[198] Figure 25 shows a use case of a 2 byte remaining space of TB (Padding
BSR is the
last one).
[199] If we still mandate that padding BSR should be the last element
except padding in a
MAC PDU, it means (b) of Figure 25 should be used.
CA 02715075 2010-07-30
22
WO 2009/104928 PCT/KR2009/000826
[200] In (b) of Figure 25, the second MAC SubHeader does not have "L"
field. But,
because it is not the last MAC SubHeader in the MAC PDU, (b) in Figure 25 may
be
incorrect.
[201] It is clear that having a BSR is better than not having a BSR. Thus,
(b) of Figure 22
should be used than (a) or (b) of Figure 25. As such, the location of BSR
within a
MAC PDU should not be restricted.
[202] MAC control elements (except Padding BSR) are always placed before
any MAC
SDU. Padding BSR occurs at the end of the MAC PDU.
[203] A MAC PDU sub-header consists of the six header fields R/R/E/LCID/F/L
but for
the last sub-header in the MAC PDU and for fixed sized MAC control elements.
The
last sub-header in the MAC PDU and sub-headers for fixed sized MAC control
elements consist solely of the four header fields R/R/E/LCID. It follows that
a MAC
PDU sub-header corresponding to padding consists of the four header fields R/
R/E/LCID.
[204] It is clear that having a BSR is better than not having a BSR. In
this sense, (b) of
Figure 22 should be used instead of (a) or (b) of Figure 25. One way to avoid
(b) of
Figure 25 is to allow for Padding BSR to be placed in any place within a MAC
PDU. If
this is allowed, the triggering condition of Padding BSR will guarantee that
(b) of
Figure 22 is sent whenever 2 byte padding space is available.
[205] A MAC PDU is a bit string that is byte aligned (i.e. multiple of 8
bits) in length. The
bit strings can be represented by a table (or list) in which the most
significant bit is the
leftmost bit of the first line of the table, the least significant bit is the
rightmost bit on
the last line of the table, and more generally the bit string is to be read
from left to right
and then in the reading order of the lines. The bit order of each parameter
field within a
MAC PDU is represented with the first and most significant bit in the leftmost
bit and
the last and least significant bit in the rightmost bit.
[206] MAC SDUs are bit strings that are byte aligned (i.e. multiple of 8
bits) in length. An
SDU is included into a MAC PDU from the first bit onward.
[207] MAC PDU sub-headers have the same order as the corresponding MAC
SDUs,
MAC control elements and padding.
[208] MAC control elements, except Padding BSR, are always placed before
any MAC
SDU. Padding BSR can be placed either before any MAC SDU or after any MAC
SDU.
[209] In the uplink direction, padding occurs at the end of the MAC PDU,
except when
single-byte is required but cannot be achieved by padding at the end of the
MAC PDU.
[210] In the downlink direction, padding occurs at the end of the MAC PDU,
except when
single-byte or two-byte padding is required but cannot be achieved by padding
at the
end of the MAC PDU.
CA 02715075 2010-07-30
23
WO 2009/104928 PCT/KR2009/000826
[211] In the uplink direction, when single-byte padding is required but
cannot be achieved
by padding at the end of the MAC PDU, one MAC PDU sub-headers corresponding to
padding are inserted before the first MAC PDU sub-header corresponding to a
MAC
SDU; or if such sub-header is not present, before the last MAC PDU sub-header
corre-
sponding to a MAC control element.
[212] In the downlink direction, when single-byte or two-byte padding is
required but
cannot be achieved by padding at the end of the MAC PDU, one or two MAC PDU
sub-headers corresponding to padding are inserted before the first MAC PDU sub-
header corresponding to a MAC SDU, or if such sub-header is not present,
inserted
before the last MAC PDU sub-header corresponding to a MAC control element.
[213] A maximum of one MAC PDU can be transmitted per TB per UE. Depending
on the
physical layer category, one or two TBs can be transmitted per TTI per UE.
[214] Details #7
[215] A MAC PDU header consists of one or more MAC PDU sub-headers; each
sub-
header corresponding to either a MAC SDU, a MAC control element or padding.
MAC
PDU sub-headers for padding should not occur more than once in the MAC PDU.
[216] MAC PDU sub-headers have the same order as the corresponding MAC
SDUs,
MAC control elements and padding.
[217] MAC control elements, except Padding BSR, are always placed before
any MAC
SDU. Padding BSR occurs at the end of the MAC PDU.
[218] Padding occurs at the end of the MAC PDU, except when single-byte is
required but
cannot be achieved by padding at the end of the MAC PDU.
[219] When single-byte is required but cannot be achieved by padding at the
end of the
MAC PDU, one MAC PDU sub-headers corresponding to padding are inserted before
the first MAC PDU sub-header corresponding to a MAC SDU; or if such sub-header
is
not present, before the last MAC PDU sub-header corresponding to a MAC control
element.
[220] When two bytes remain after filling the MAC PDU with MAC SDUs or MAC
control elements (except BSR), a short BSR is included.
[221] A maximum of one MAC PDU can be transmitted per TB per UE. Depending
on the
physical layer category, one or two TBs can be transmitted per TTI per UE.
[222] Details #8
[223] A MAC PDU sub-header consists of the six header fields R/R/E/LCID/F/L
but for
the last sub-header in the MAC PDU and for fixed sized MAC control elements.
The
last sub-header in the MAC PDU and sub-headers for fixed sized MAC control
elements consist solely of the four header fields R/R/E/LCID. It follows that
a MAC
PDU sub-header corresponding to padding consists of the four header fields R/
R/E/LCID.
CA 02715075 2010-07-30
24
WO 2009/104928 PCT/KR2009/000826
[224] The number of padding bits is equal to TB size minus the size of MAC
SDUs or
MAC CEs minus the size of their related MAC SubHeaders. In this calculation,
the
MAC SubHeader for the last MAC SDU is assumed to have "R/R/E/LCID/F/L".
[225] MAC control elements, except Padding BSR, are always placed before
any MAC
SDU. Padding BSR can be place anywhere within the MAC PDU.
[226] For padding BSR:
[227] - if the number of padding bits is equal to or larger than the size
of the Long BSR and
the Long BSR fits into the MAAC PDU, report Long BSR.
[228] - else, if the number of padding bits is equal to or larger than the
size of the Short
BSR and the Short BSR fits into the MAC PDU, report Short BSR of the LCG with
the
highest priority logical channel with buffered data.
[229] Details #9
[230] Two alternatives can be thought of:
[231] Alternative 1
[232] For padding BSR:
[233] - if the number of padding bits is equal to or larger than the size
of the Short BSR but
smaller than the size of the Long BSR, report Short BSR of the LCG with the
highest
priority logical channel with buffered data;
[234] - else if the number of padding bits is equal to or larger than the
size of the Long
BSR, report Long BSR.
[235] The number of padding bits is equal to TB size minus the size of MAC
SDUs or
MAC CEs minus the size of their related MAC subheaders. In this calculation,
if the
last NAC subheader except padding was for a MAC SDU, the last MAC subheader is
assumed to have "R/R/E/LC/LCID/F/L".
[236] Alternative 2
[237] For padding BSR:
[238] - if the number of padding bits is equal to or larger than the size
of the Long BSR and
if all the MAC subheaders for MAC SDUs within the MAC PDU can include F and L
fields, report Long BSR.
[239] - else, if the number of padding bits is equal to or larger than the
size of the Short
BSR and if all the MAC subheaders for MAC SDUs within the MAC PDU can include
F and L fields, report Short BSR of the LCG with the highest priority logical
channel
with buffered data.
[240] Hereafter, a possible ambiguity problem and a solution thereof will
be described.
[241] Figure 26 drawing (a) shows the remaining space is enough for the
inclusion of long
BSR. But the MAC PDU already included short BSR. According to the current
speci-
fication, only one BSR can be included into the MAC PDU when multiple BSR is
triggered. Thus, either one of "Short" and "Regular" BSR or "Long" and
"Padding"
CA 02715075 2010-07-30
25
WO 2009/104928 PCT/KR2009/000826
BSR is allowed in the Figure 26. Similar problems are shown in (b) and (c) of
Figure
26.
[242] Thus, it is unclear as to which one should be included. Namely,
whether "Regular" or
"Periodic" BSR has a higher priority than the "Padding" BSR. Perhaps a Long
BSR
should be chosen as much as possible. Or, perhaps the Short Regular BSR should
be
replaced by a Long Padding BSR. On the other hand, to ease the implementation
complexity, it also can be proposed to allow multiple BSRs in one MAC PDU.
This is
another way to remove such ambiguity.
[243] Thus, as one possible solution to the multiple BSR situations
described above,
multiple BSRs may be included in one MAC PDU, the format of Figure 27 would
replace that of Figure 26.
[244] As another possible solution, the UE may include one Long BSR.
Namely, when the
UE composes a MAC PDU, the UE combines the remaining space and the already
allocated space for "Regular" and "Periodic" BSR to include a long BSR. Figure
28
shows how the MAC PDU would look like when this solution is applied to problem
shown in Figure 26.
[245] Details #10
[246] It is important for the scheduler to be able to differentiate a
padding BSR from a
regular BSR. If the location restriction is removed, a separate LCID for
padding BSR
should be used. Here, the Padding BSR should be explicitly indicated by
Padding
Subheader.
[247] - if the number of padding bits is equal to or larger than the size
of the Short BSR
plus its subheader but smaller than the size of the Long BSR plus its
subheader, report
Short BSR of the LCG with the highest priority logical channel with buffered
data;
[248] - else if the number of padding bits is equal to or larger than the
size of the Long
BSR plus its subheader, report Long BSR.
[249] Having a general rule to handle padding may be simpler than
introducing exceptions:
regardless of whether a regular BSR is included, the UE always apply the same
rules to
include a padding BSR.
[250] If a BSR is already included in the MAC PDU, another BSR may not be
needed.
Another BSR may increase the MAC processing. The BSR fields are populated
after
the PDU is built, therefore the two BSRs may be identical copies.
[251] If a Short BSR is used, it may means that the other three not
reported groups have no
buffered data. Thus, the Short BSR ("Regular" or "Periodic") may imply the
buffer
status of all groups. On the other hand, if a Long BSR is used, the buffer
status of all
groups may also be reported.
[252] Details #11
[253] The type of BSR that should be included when multiple BSR is
triggered need con-
CA 02715075 2010-07-30
26
WO 2009/104928 PCT/KR2009/000826
sideration.
[254] Even if multiple events occur by the time a BSR can be transmitted,
only one BSR
may be included in the MAC PDU.
[255] For example, when a short BSR is triggered due to expiry of periodic
timer and the
remaining padding space is enough to include a long BSR, the type of BSR to be
included should be determined. When a Regular short BSR is triggered and
padding
space allows only a short BSR, the two short BSRs may be combined to generate
a
long BSR. Several solutions to the above situations seem possible:
[256] Option A: Padding BSR is not triggered when regular BSR or periodic
BSR has been
triggered. In this way, triggering of different size BSRs can be avoided.
[257] Option B: In a MAC PDU, maximum one of either Regular BSR or Periodic
BSR
can be included and maximum one of Padding BSR can be included.
[258] Option C: If Regular BSR or Periodic BSR is triggered and if a
padding BSR is also
triggered, the largest BSR that fits into a MAC PDU is included.
[259] Due to simplicity, the above option A may be most practical.
[260] It should be noted that there are several different types of BSR.
When multiple BSRs
are triggered, only one BSR is included.
[261] However, there is a question about which BSR should be included when
multiple
BSR is triggered. Padding BSR is not triggered when regular BSR or periodic
BSR is
already triggered. MAC entity cannot decide which BSR to include when multiple
BSR is triggered.
[262] The Buffer Status reporting procedure is used to provide the serving
eNB with in-
formation about the amount of data in the UL buffers of the UE. A Buffer
Status
Report (BSR) shall be triggered if any of the following events occur:
[263] - UL data arrives in the UE transmission buffer and the data belongs
to a logical
channel with higher priority than those for which data already existed in the
UE
transmission buffer, in which case the BSR is referred below to as "Regular
BSR";
[264] - UL resources are allocated and number of padding bits is larger
than the size of the
Buffer Status Report MAC control element, in which case the BSR is referred
below to
as "Padding BSR";
[265] - a serving cell change occurs, in which case the BSR is referred
below to as
"Regular BSR";
[266] - the PERIODIC BSR TIMER expires, in which case the BSR is referred
below to as
"Periodic BSR".
[267] For Regular and Periodic BSR:
[268] - if only one LCG has buffered data in the TTI where the BSR is
transmitted: report
short BSR;
[269] - else if more than one LCG has buffered data in the TTI where the
BSR is
CA 02715075 2010-07-30
27
WO 2009/104928 PCT/KR2009/000826
transmitted: report long BSR.
[270] For padding BSR:
[271] - if Regular BSR or Periodic BSR has not been triggered;
[272] - if the number of padding bits is equal to or larger than the size
of the Short BSR but
smaller than the size of the Long BSR, report Short BSR of the LCG with the
highest
priority logical channel with buffered data;
[273] - else if the number of padding bits is equal to or larger than the
size of the Long
BSR, report Long BSR.
[274] If the Buffer Status reporting procedure determines that a BSR has
been triggered
since the last transmission of a BSR:
[275] - if the UE has UL resources allocated for new transmission for this
TTI:
[276] - instruct the Multiplexing and Assembly procedure to generate a BSR
MAC control
element;
[277] - restart the PERIODIC BSR TIMER.
[278] - else if a Regular BSR has been triggered since the last
transmission of a BSR:
[279] - a Scheduling Request shall be triggered.
[280] It should be noted that even if multiple events occur by the time a
BSR can be
transmitted, only one BSR may be included in the MAC PDU.
[281] A pending BSR shall be cancelled in case the UL grant can accommodate
all pending
data but is not sufficient to accommodate the BSR MAC control element in
addition.
[282] As described above, the various exemplary embodiments of the present
invention
relate to a method and system for processing buffer status reports (BSRs).
When BSR
triggering is performed, the size(s) of the necessary sub-header(s) are also
to be
considered together in addition to the BSR size. Doing so allows the sub-
header(s) to
be inserted (included) into the MAC PDU (or transport block (TB) or other data
unit).
[283] The Buffer Status reporting procedure is used to provide the serving
eNB with in-
formation about the amount of data available for transmission in the UL
buffers of the
UE. For the Buffer Status reporting procedure, the UE shall consider all radio
bearers
which are not suspended and may consider radio bearers which are suspended.
[284] A Buffer Status Report (BSR) shall be triggered if any of the
following events occur:
[285] - UL data, for a logical channel which belongs to a LCG, becomes
available for
transmission in the RLC entity or in the PDCP entity, and either the data
belongs to a
logical channel with higher priority than the priorities of the logical
channels which
belong to any LCG and for which data is already available for transmission, or
there is
no data available for transmission for any of the logical channels which
belong to a
LCG, in which case the BSR is referred below to as "Regular BSR";
[286] - UL resources are allocated and number of padding bits is equal to
or larger than the
size of the Buffer Status Report MAC control element, in which case the BSR is
CA 02715075 2010-07-30
28
WO 2009/104928 PCT/KR2009/000826
referred below to as "Padding BSR";
[287] - a serving cell change occurs, in which case the BSR is referred
below to as
"Regular BSR";
[288] - the RETX BSR TIMER expires and the UE has data available for
transmission, in
which case the BSR is referred below to as "Regular BSR";
[289] - the PERIODIC BSR TIMER expires, in which case the BSR is referred
below to
as "Periodic BSR".
[290] For Regular and Periodic BSR:
[291] - if more than one LCG has data available for transmission in the TTI
where the BSR
is transmitted: report Long BSR;
[292] - else report Short BSR.
[293] For Padding BSR:
[294] - if the number of padding bits is equal to or larger than the size
of the Short BSR
plus its subheader but smaller than the size of the Long BSR plus its
subheader:
[295] - if more than one LCG has buffered data in the TTI where the BSR is
transmitted:
report Truncated BSR of the LCG with the highest priority logical channel with
data
available for transmission;
[296] - else report Short BSR.
[297] - else if the number of padding bits is equal to or larger than the
size of the Long
BSR plus its subheader, report Long BSR.
[298] If the Buffer Status reporting procedure determines that at least one
BSR has been
triggered since the last transmission of a BSR or if this is the first time
that at least one
BSR is triggered:
[299] - if the UE has UL resources allocated for new transmission for this
TTI:
[300] - instruct the Multiplexing and Assembly procedure to generate a BSR
MAC control
element;
[301] - start or restart the PERIODIC BSR TIMER except when the BSR is a
Truncated
BSR;
[302] - start (if not running) or restart (if running) the RETX BSR TIMER.
[303] - else if a Regular BSR has been triggered:
[304] - a Scheduling Request shall be triggered.
[305] A MAC PDU shall contain at most one MAC BSR control element, even
when
multiple events trigger a BSR by the time a BSR can be transmitted in which
case the
Regular BSR and the Periodic BSR shall have precedence over the padding BSR.
[306] The UE shall restart (if running) the RETX BSR TIMER upon reception
of a grant
for transmission of new data on UL-SCH.
[307] All triggered BSRs shall be cancelled in case the UL grant can
accommodate all
pending data available for transmission but is not sufficient to additionally
ac-
CA 02715075 2010-07-30
29
WO 2009/104928 PCT/KR2009/000826
commodate the BSR MAC control element. All triggered BSRs shall be cancelled
when a BSR is included in a MAC PDU for transmission.
[308] Hereafter, the MAC PDU (DL-SCH and UL-SCH except transparent MAC and
Random Access Response) will be explained further.
[309] A MAC PDU consists of a MAC header, zero or more MAC Service Data
Units
(MAC SDU), zero, or more MAC control elements, and optionally padding; as
described in Figure 4.
[310] Both the MAC header and the MAC SDUs are of variable sizes.
[311] A MAC PDU header consists of one or more MAC PDU sub-headers; each
subheader corresponding to either a MAC SDU, a MAC control element or padding.
[312] A MAC PDU subheader consists of the six header fields R/R/E/LCID/F/L
but for the
last subheader in the MAC PDU and for fixed sized MAC control elements. The
last
subheader in the MAC PDU and sub-headers for fixed sized MAC control elements
consist solely of the four header fields R/R/E/LCID. It follows that a MAC PDU
subheader corresponding to padding consists of the four header fields
R/R/E/LCID.
[313] MAC PDU sub-headers have the same order as the corresponding MAC
SDUs,
MAC control elements and padding.
[314] MAC control elements, are always placed before any MAC SDU.
[315] Padding occurs at the end of the MAC PDU, except when single-byte or
two-byte
padding is required but cannot be achieved by padding at the end of the MAC
PDU.
Padding may have any value and the UE shall ignore it.
[316] When single-byte or two-byte padding is required but cannot be
achieved by padding
at the end of the MAC PDU, one or two MAC PDU sub-headers corresponding to
padding are inserted before the first MAC PDU subheader corresponding to a MAC
SDU; or if such subheader is not present, before the last MAC PDU subheader
corre-
sponding to a MAC control element.
[317] A maximum of one MAC PDU can be transmitted per TB per UE.
[318] According to the present invention, regarding MAC Control Elements,
there are
Buffer Status Report MAC Control Elements.
[319] Buffer Status Report (BSR) MAC control elements consist of either:
[320] - Short BSR and Truncated BSR format: one LCG ID field and one
corresponding
Buffer Size field (Figure 7); or
[321] - Long BSR format: four Buffer Size fields, corresponding to LCG IDs
#0 through
#3 (Figure 8).
[322] The BSR formats are identified by MAC PDU subheaders with LCIDs.
[323] The fields LCG ID and Buffer Size are defined as follows:
[324] - LCG ID: The Logical Channel Group ID field identifies the group of
logical
channel(s) which buffer status is being reported. The length of the field is 2
bits;
CA 02715075 2010-07-30
30
WO 2009/104928 PCT/KR2009/000826
113251 - Buffer Size: The Buffer Size field identifies the total amount of
data available
across all logical channels of a logical channel group after the MAC PDU has
been
built. The amount of data is indicated in number of bytes. It shall include
all data that
is available for transmission in the RLC layer and in the PDCP layer. The size
of the
RLC and MAC headers are not considered in the buffer size computation. The
length
of this field is 6 bits.
[326] The present invention provides a method of processing a padding
buffer status report
(BSR) by a mobile terminal, comprising the steps of checking whether any
padding
region is available in a MAC PDU that was constructed, comparing the number of
padding bits with the size of the BSR plus its sub-header; and if the number
of padding
bits is larger than the size of the BSR plus its sub-header, triggering BSR.
[327] The method further comprises, receiving a grant from a network to
construct the
MAC PDU, and constructing the MAC PDU by using higher logical channel data and
MAC control elements. The MAC PDU may include a short BSR having a logical
channel identification (LCID) field of 2 bytes and a buffer size of 6 bytes. A
separate
logical channel identification (LCID) field may be set for a short BSR or for
a
truncated BSR. The LCID field may identify the logical channel instance of the
corre-
sponding MAC SDU or the type of the corresponding MAC control element or
padding for the DL-SCH and UL-SCH respectively. The LCID field may contain
either a first value for a short buffer status report or a second value for a
long buffer
status report. The size of the BSR may be 4 bytes or 8 bytes.
[328] Referring to Figure 29, the present invention also provides a medium
access control
(MAC) entity (2912, 2922) in a UE 2910 and in an eNB 2920. The MAC entity
comprises a checking unit (2913, 2923) that checks whether any padding region
is
available in a MAC PDU that was constructed, a comparing unit (2915, 2925)
that
compares the number of padding bits with the size of a buffer status report
(BSR) plus
its sub-header; and a processing unit (2914,2924) that cooperates with the
checking
unit and the comparing unit to trigger a buffer status report (BSR) procedure
if the
number of padding bits is larger than the size of the BSR plus its sub-header.
[329] The processing unit may further perform the steps of receiving a
grant from a
network to construct the MAC PDU, and constructing the MAC PDU by using higher
logical channel data and MAC control elements. The MAC PDU may include a short
BSR having a logical channel identification (LCID) field of 2 bytes and a
buffer size of
6 bytes. A separate logical channel identification (LCID) field may be set by
the
processing unit for a short BSR or for a truncated BSR. The LCID field may
identify
the logical channel instance of the corresponding MAC SDU or the type of the
corre-
sponding MAC control element or padding for the DL-SCH and UL-SCH
respectively.
The LCID field may contain either a first value for a short buffer status
report or a
CA 02715075 2010-07-30
31
WO 2009/104928 PCT/KR2009/000826
second value for a long buffer status report. The size of the BSR may be 4
bytes or 8
bytes.
[330] The various features and concepts described herein may be implemented
in software,
hardware, or a combination thereof. For example, a computer program (that is
executed in a computer, a terminal or a network device) for a method and
system for
processing buffer status reports (BSRs) may comprise one or more program code
sections for performing various tasks. Similarly, a software tool (that is
executed in a
computer, a terminal or a network device) for a method and system for
processing
buffer status reports (BSRs) may comprise program code portions for performing
various tasks.
[331] The method and system for processing buffer status reports (BSRs)
according to the
present invention are compatible with various types of technologies and
standards.
Certain concepts described herein are related to various types of standards,
such as
GSM, 3GPP, LTE, IEEE, 4G and the like. However, it can be understood that the
above exemplary standards are not intended to be limited, as other related
standards
and technologies would also be applicable to the various features and concepts
described herein.
Industrial Applicability
[332] The features and concepts herein are applicable to and can be
implemented in various
types of user devices (e.g., mobile terminals, handsets, wireless
communication
devices, etc.) and/or network entities that can be configured to support a
method and
system for processing buffer status reports (BSRs).
[333] As the various concepts and features described herein may be embodied
in several
forms without departing from the characteristics thereof, it should also be
understood
that the above-described embodiments are not limited by any of the details of
the
foregoing description, unless otherwise specified, but rather should be
construed
broadly within its scope as defined in the appended claims. Therefore, all
changes and
modifications that fall within such scope or equivalents thereof are therefore
intended
to be embraced by the appended claims.
CA 02715075 2010-07-30
