WO2012095693A2

WO2012095693A2 - Method of transmitting a power headroom report in a wireless communication network

Info

Publication number: WO2012095693A2
Application number: PCT/IB2011/003211
Authority: WO
Inventors: Tao Yang; Chandrika Worrall
Original assignee: Alcatel Lucent
Priority date: 2011-01-10
Filing date: 2011-11-08
Publication date: 2012-07-19
Also published as: CN102595490A; TW201234900A; CN102595490B; WO2012095693A3

Abstract

The present invention relates to a method of transmitting a power headroom report in a wireless communication network and its corresponding apparatuses. The power headroom report includes a sub-header and a data payload. And the method includes: A. Determining the size of the data payload according to a combination of contents of the sub-header; B. Resolving the data payload according to a combination of indication information in the data payload. With some embodiments of these technical solutions, power headroom reports of variable size can be resolved correctly and good compatibility with existing networks is realized.

Description

METHOD OF TRANSMITTING A POWER HEADROOM REPORT IN A

WIRELESS COMMUNICATION NETWORK

FIELD OF THE INVENTION

The present invention relates to wireless communication networks, and more particularly, to a method of transmitting a power headroom report between an eNodeB and a user equipment in a wireless communication network and a corresponding apparatus. BACKGROUND OF THE INVENTION

Currently, medium access control (MAC) control entity (CE) format of the power headroom report (PHR) for RIO carrier aggregation (CA) capable user equipment (UE) is agreed on and adopted in 36.321 (R2- 106860), which includes the following features:

1) One byte F/L is adopted in MAC CE sub-header since the R10

CA capable UE' s PHR CE size is variable.

2) One byte based on bit-map is used in the data payload of the PHR to indicate which component carrier (CC) has PHR data payload included in the current MAC PHR CE.

These two features are adopted to adapt to the dynamic variable CC number per transmission time interval (TTI) in R10 CA scenarios.

One extra byte F/L is designed for R10 CA capable UE PHR sub-header, wherein the L field indicates the variable PHR data payload size and the F field is used to indicate whether the PHR data payload size is below 128 bytes or above 128 bytes, which will determine the L field is 7 bits or 15 bits.

Another byte in form of bit-map is typically used to indicate which CC has PHR message included in the current MAC PHR CE.

However, it is not appropriate to directly reuse PHR format for R10 CA capable UE in a PHR of RIO non-CA UE without modification. Consequently, it is desired to design PHR message for RIO non-CA UE.

SUMMARY OF THE INVENTION

However, it is discovered during research that legacy R8 PHR format generally cannot be used for RIO non-CA PHR message since R8 PHR size is fixed to be 1 byte and is not enough to include maximum available power information (Pcmax,c) for RIO non-CA UE.

Another possible solution is to reuse the format for CA case. However, it has at least two drawbacks:

Since only one CC is operated for RIO non-CA UE, the bit-map byte is really not necessary, which would otherwise lead to extra overhead.

For the F/L byte in the above sub-header, it is also dispensable if RIO non-CA UE PHR reporting size is fixed.

According to an embodiment of the present invention, a method of receiving a power headroom report in an eNodeB of a wireless communication network is provided. The power headroom report includes a sub-header and a data payload. And the method includes: A. determining the size of the data payload according to a combination of contents of the sub-header; B. resolving the data payload according to a combination of indication information in the data payload.

Preferably, the following step may be included before step A in the stage when the eNodeB configures a UE: configuring an RIO non-CA user equipment in the wireless communication network to support the power headroom report of extend format. And in the execution stage of the method, the eNodeB determines whether the user equipment corresponding to the power headroom report supports the power headroom report of extend format if a logical channel identifier (LCID) is a first value.

Similarly, it is preferable that the first value may be 11010, the contents of the sub-header include a length field indicator and a length indication field, or a first reserved field and a second reserved field, and step A further includes: determining the size of the data payload to be 1 byte if the user equipment corresponding to the power headroom report is not configured to support the power headroom report of extend format; determining the size of the data payload according to a combination of the length field indicator and the length indication field, or a combination of the first reserved field and the second reserved field, if the user equipment corresponding to the power headroom report is configured to support the power headroom report of extend format.

According to another embodiment of the present invention, a method of transmitting a power headroom report in a user equipment of a wireless communication network is provided. The power headroom report includes a sub-header and a data payload. And the method includes: A. notifying an eNodeB of the size of the data payload via a combination of contents of the sub-header; B. notifying the eNodeB of the structure of the data payload via a combination of indication information in the data payload.

According to yet another embodiment of the present invention, an apparatus for receiving a power headroom report in an eNodeB of a wireless communication network is provided. The power headroom report includes a sub-header and a data payload. And the apparatus includes: a data payload size determining module for determining the size of the data payload according to a combination of contents of the sub-header; a data payload resolving module for resolving the data payload according to a combination of indication information in the data payload. According to another embodiment of the present invention, an apparatus for transmitting a power headroom report in a user equipment of a wireless communication network is provided. The power headroom report includes a sub-header and a data payload. And the apparatus includes: a data payload size notifying module for notifying an eNodeB of the size of the data payload via a combination of contents of the sub-header; a data payload structure notifying module for notifying the eNodeB of the structure of the data payload via a combination of indication information in the data payload.

In some embodiments of the above method of receiving a power headroom report in an eNodeB, newly-defined/existing LCID may be used to resolve power headroom reports of variable size correctly. In addition, with configuration of extendable format or use of F/L, it can be determined unambiguously whether an associated MAC CE PHR reporting has come from a R8/9 UE or an RIO non-CA UE. Moreover, if the original LCID of the system is used instead of configuring a new LCID, good compatibility with existing networks is realized and the impact on the existing networks is minimized. In some embodiments, bit-map byte and/or F/L byte is not needed, which reduces overhead and protocol complexity.

BRIEF DESCRIPTION OF THE DRAWINGS

Other features, objectives and advantages of the present invention will become more apparent after reading the following detailed description of non-limiting embodiments, with reference to the accompanying drawings, wherein below:

FIG. 1 is a flowchart illustrating a method of receiving a power headroom report in an eNodeB of a wireless communication network according to an embodiment of the present invention; FIG. 2 is a flowchart illustrating a method of transmitting a power headroom report in a user equipment of a wireless communication network according to an embodiment of the present invention;

FIG. 3 is a structural diagram illustrating an apparatus for receiving a power headroom report in an eNodeB of a wireless communication network according to an embodiment of the present invention;

FIG. 4 is a structural diagram illustrating an apparatus for transmitting a power headroom report in a user equipment of a wireless communication network according to an embodiment of the present invention;

FIG. 5 is a structural diagram illustrating a sub-header of a power headroom report transmitted between an eNodeB and a user equipment in a wireless communication network according to an embodiment of the present invention;

FIGs. 6a-6e are structural diagrams illustrating a sub-header and a data payload of a power headroom report transmitted between an eNodeB and a user equipment in a wireless communication network according to an embodiment of the present invention;

FIG. 7 is a structural diagram illustrating a sub-header of a power headroom report transmitted between an eNodeB and a user equipment in a wireless communication network according to another embodiment of the present invention;

FIG. 8 is a structural diagram illustrating a sub-header of a power headroom report transmitted between an eNodeB and a user equipment in a wireless communication network according to yet another embodiment of the present invention;

FIGs. 9a-9e are structural diagrams illustrating a sub-header and a data payload of a power headroom report transmitted between an eNodeB and a user equipment in a wireless communication network according to an embodiment of the present invention;

FIG. 10 is a structural diagram illustrating a sub-header of a power headroom report transmitted between an eNodeB and a user equipment in a wireless communication network according to yet another embodiment of the present invention;

Wherein, identical or similar reference signs represent identical or similar apparatuses/devices or steps.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

It is discovered that there is only one uplink CC in operation for

RIO non-CA UE. Taking into account the current RANI agreement on Pcmax,c reporting for RIO non-CA UE and Pcmax,c transmission enhancement protocols proposed in the literature, there are several cases with respect to PHR reporting for RIO non-CA UE:

Case 1 : the physical uplink control channel (PUCCH) and the physical uplink sharing channel (PUSCH) are not configured to transmit simultaneously. Therefore, The RIO non-CA UE only reports type 1 and Pcmax,c. And there are three possible sub-cases:

Case 1.1 : virtual type 1 PHR is reported, and no Pcmax,c is reported. Thus, the PHR content size is only 1 byte, which is the virtual type 1.

Case 1.2: real PHR is reported, hence Pcmax,c is also included. So the PHR content size is 2 bytes, which are real type 1 PHR content and Pcmax,c for type 1 PHR.

Case 1.3: real PHR is reported, but Pcmax,c is identical to the previous Pcmax,c and thus doesn't need to be reported. So the PHR content size is 1 byte, which is real type 1 PHR.

Case 2: the PUCCH and the PUSCH are configured to transmit simultaneously. Therefore, The R10 non-CA UE reports both type 1 and type 2. Consequently, the PHR contents have following sub-cases:

Case 2.1 : only virtual type 1 and type 2 are reported, and Pcmax,c is not included. So the PHR content size is 2 bytes, which are virtual type 1 and virtual type 2.

Case 2.2: one of types 1 and 2 is virtual and the other is real, so only one Pcmax,c is included. Then the PHR size is 3 bytes, which are virtual type 1/2, real type 2/1 and Pcmax,c.

Case 2.3 : both real types 1 and 2 are reported. Therefore, the PHR size is 4 bytes, which are real type 1 , real type 2, Pcmax,c for type 1 and Pcmax,c for the type 2.

Case 2.4: both real types 1 and 2 are reported, but Pcmax,c for the types 1 and 2 is identical to the previously reported one and thus no Pcmax,c is included. Therefore, the PHR size is 2 bytes, which are real type 1 and real type 2.

Case 2.5: both real type 1 and type 2 are reported, but the Pcmax,c for either type 1 or 2 is identical to the previously reported one and thus doesn't need to be included in the current PHR MAC CE. Therefore, the current PHR size is 3 bytes, which are real type 1 , real type 2 , and Pcmax,c for type 1 or 2.

In summary, possible RIO non-CA UE PHR content size has the following scenarios, as shown in Table 1 :

Table 1: non-CA RIO UE PHR content size

Therefore, the PHR format should be carefully designed so that the eNodeB can clearly identify each case. It should be noted that for scenario 1 in Table 1 , although the PHR size is 1 byte, the conventional R8 PHR format can not be used which is different from previous common understanding. The reason is that at least R bits in the PHR content is used as virtual indication bits to identify whether the PHR is based on reference format or real format. This can not be realized by R8 PHR format, meaning R8 PHR format can not be used by RIO.

Hereinafter described in connection with the accompanying drawings are possible embodiments of transmitting a power headroom report between an eNodeB and a UE corresponding in various scenarios.

FIG. 1 is a flowchart illustrating a method of receiving a power headroom report in an eNodeB (not shown) of a wireless communication network according to an embodiment of the present invention. As shown, the method includes step S l l of determining the size of a data payload and step S 12 of resolving the data payload.

In step S l l , the eNodeB determines the size of the data payload according to a combination of contents of the sub-header.

In step S 12, the eNodeB resolves the data payload according to a combination of indication information in the data payload.

FIG. 2 is a flowchart illustrating a method of transmitting a power headroom report in a user equipment of a wireless communication network according to an embodiment of the present invention. As shown, the method includes step S21 of determining the size of a data payload and step S22 of resolving the data payload.

The power headroom report transmitted by the UE may include a sub-header and a data payload. In step S21 , the UE notifies an eNodeB of the size of the data payload via a combination of contents of the sub-header. And in step S22, the UE notifies the eNodeB of the structure of the data payload via a combination of indication information in the data payload.

FIG. 5 is a structural diagram illustrating a sub-header of a power headroom report transmitted between an eNodeB and a user equipment in a wireless communication network according to an embodiment of the present invention. The meaning of each reference sign is: F representing length field indication bits, L representing length indication field, E representing extended bits, and R representing reserved bits, wherein F/L bits are optional and may be absent or be included in the sub-header of the power headroom report according to application scenarios.

FIGS. 6a-6e are structural diagrams illustrating a sub-header and a data payload of a power headroom report transmitted between an eNodeB and a user equipment in a wireless communication network according to an embodiment of the present invention. In this embodiment, LCID value in the PHR MAC sub-header format used by the RIO non-CA UE shown in FIG. 6a may be one of newly defined { 10101 , 10110, 10111 , 11000 } . And FIGS. 6b-6e illustrate four possible structures of the PHR data payload.

In this embodiment, the eNodeB performs in step S 11 the following sub-steps according to the LCID included in the contents of the sub-header: determining the size of the data payload to be 1 byte if the logical channel identifier is a first value; determining the size of the data payload to be 2 bytes if the logical channel identifier is a second value; determining the size of the data payload to be 3 bytes if the logical channel identifier is a third value; determining the size of the data payload to be 4 bytes if the logical channel identifier is a fourth value. Optionally, the above first, second, third, and fourth values may be 10101 , 10110, 10111 , and 11000, respectively, or in other orders, or they may be some other values. However, specific value of LCID is not intended to limit the present invention. In particular, different newly defined LCID may be used to indicate PHR of RIO non-CA UE.

For PHR of RIO non-CA UE, although there are up to four scenarios as shown in Table 1 above, PHR content size in each of them is necessarily fixed. Consequently, different LCIDs are used to identify the four scenarios. For example, LCID may be set to 10101-11000 for this purpose.

For instance, when the eNodeB detects 10101 - 11000, it finds out that the PHR has come from R10 non-CA UE and the PHR size is 1 byte, 2 bytes, 3 bytes or 4 bytes, respectively. Therefore, F/L doesn't need to be included in MAC sub-header, and bit-map doesn't need to be included in PHR content. It is easy for the eNodeB to identify the sub-cases of scenarios 1 , 2, and 3 in Table 1.

For example, if 10101 is detected, the eNodeB finds out that the PHR size is only 1 byte. Further, if the virtual indication bits are configured in the PHR, the eNodeB can determine that this is case 1.1. On the other hand, if the virtual indication bits are not configured, the eNodeB can determine that this is case 3 and the Pcmax,c is identical to the previously received one.

For example, if 10110 is detected, the eNodeB finds out that the

PHR size is 2 bytes. In addition, two following solutions may be used to further identify the sub-cases 1.2, 2.1 and 2.4.

Solution 1 is based on simultaneous transmission configuration of the PUCCH and the PUSCH.

If the PUCCH and the PUSCH are not configured to transmit simultaneously, sub-case 1.2 is identified.

If the PUCCH and the PUSCH are configured by the eNodeB to transmit simultaneously, sub-case 2.1 or 2.4 is identified.

And if V bits used in the two bytes are configured to be virtual type 1/2, the eNodeB can determine that this is sub-case 2.1.

On the other hand, if the two V bits are configured to be real type 1/2, the eNodeB can find out that this is sub-case 2.4 and the previously- received Pcmax,c for types 1 and 2 will be used.

Solution 2 uses T field mentioned above.

Here, the eNodeB can determine that the first byte is necessarily PHR information: type 1 or 2.

If the second byte is Pcmax,c, sub-case 1.2 is identified.

If the second byte is also PHR information, sub-case 2.1 or 2.4 is identified.

Further, V bits can be used to distinguish between sub-case 2.1 and sub-case 2.4, as is the same with solution 1.

As for scenario 3, the above solution 2 may be used to distinguish between sub-case 2.2 and sub-case 2.5 without ambiguity.

Redundant bytes such as F/L and bit-map are not necessary in the method in the embodiment. This is a preferable solution as far as overhead reduction is concerned. Meanwhile, four newly defined LCIDs need to be employed.

FIG. 7 is a structural diagram illustrating a sub-header of a power headroom report transmitted between an eNodeB and a user equipment in a wireless communication network according to another embodiment of the present invention. The contents of the sub-header in the embodiment include LCID (e.g, 11000), length field indicator (F) and length indication field (L).

In particular, in step S I 1 , if LCID is a first value such as 11000, the eNodeB determines the size of the data payload according to a combination of the length field indicator and the length indication field.

In the embodiment, a new LCID (e.g, 11000) may be employed to identify PHR of R10 non-CA UE. And an F/L byte is included in the MAC sub-header to further indicate the four PHR reporting scenarios of RIO non-CA UE.

In the embodiment, only one new LCID is need, such as Ί ΙΟΟΟ' . One F/L byte is used in the MAC sub-header to indicate the four scenarios, i.e., to indicate specific PHR content size. However, no bit-map is adopted in PHR contents, which is different from current CA PHR format. Specific structure of the PHR sub-header is shown in FIG. 7, and the structure of the data payload in the PHR may be similar to those shown in FIGs. 6b-6e.

A person skilled in the art would understand that in the solution of this embodiment, only one new LCID is need, and no bit-map is needed in PHR contents. However, it is still needed to include one F/L byte in the MAC sub-header to indicate different non-CA PHR reporting scenarios.

Similarly, the solutions 1 and 2 in the above embodiments may be used to further identify various data payload structures of different PHRs and be applied to the following embodiments, which are omitted hereinafter.

FIG. 8 is a structural diagram illustrating a sub-header of a power headroom report transmitted between an eNodeB and a user equipment in a wireless communication network according to yet another embodiment of the present invention. Contents in the sub-header of the PHR in the embodiment include an LCID, a first reserved field and a second reserved field, which may have four possible combinations, i.e., 01/00/10/11 , as shown in FIG. 8. In addition, step S l l further includes: determining the size of the data payload according to a combination of the first reserved field and the second reserved field if the LCID is a first value.

In the embodiment, a new LCID is employed to identify PHR of RIO non-CA UE. Two R bits in the MAC sub-header are used to further distinguish between four possible non-CA PHR scenarios.

And a new LCID is used to distinguish PHR of RIO CA or non-CA UE. For example, 11000 may be used to indicate PHR of R10 non-CA UE. Two R bits in the MAC sub-header can be further re-defined to indicate four possible non-CA PHR scenarios. For example, the values 00, 01 , 10 and 11 of R may correspond to scenarios 1 , 2, 3 and 4, respectively.

Consequently, when the eNodeB detects that LCID is 11000, it finds out this is a PHR of R10 non-CA UE and may read the two R bits in the MAC sub-header to know the PHR content size for further processing.

With this embodiment, no F/L byte is needed for PHR transmission procedure between the eNodeB and the UE, thereby optimizing PHR size. Besides, two original R bits in the MAC sub-header are needed to be redefined.

FIGs. 9a-9e are structural diagrams illustrating a sub-header and a data payload of a power headroom report transmitted between an eNodeB and a user equipment in a wireless communication network according to an embodiment of the present invention. FIG. 9c illustrates a PHR MAC sub-header in the embodiment, wherein the contents of the sub-header include an LCID. Other figures in FIG. 9 illustrate data payload structure of a centralized PHR message applicable for the embodiment.

Optionally, during the system configuration stage before step S I 1 , the eNodeB may configure an R10 non-CA user equipment in the wireless communication network to support the PHR of extend format. Correspondingly, when the system enters normal operation stage, the following step may be included before step S I 1 : the eNodeB determining whether the UE corresponding to the PHR supports the PHR of extend format if the LCID is a first value.

Optionally, the first value may be 11010, and the contents of the sub-header may include a length field indicator and a length indication field, or a first reserved field and a second reserved field. Here, optionally, the following step may be included before step S I 1 : determining the size of the data payload to be 1 byte if the user equipment corresponding to the power headroom report is not configured to support the power headroom report of extend format; determining the size of the data payload according to a combination of the length field indicator and the length indication field (e.g., F field and L field shown in FIG. 5), or a combination of the first reserved field and the second reserved field (e.g., R/R field shown in FIG. 9c), if the user equipment corresponding to the power headroom report is configured to support the power headroom report of extend format.

In the embodiment, the R8/9 LCID (11010) is reused for R10 non-CA UE. Meanwhile, the RRC needs to configure R10 non-CA UE such that these UE use extend format during PHR processing. Optionally, specific data payload format of the PHR message may be configured as shown in FIGs. 9a-9b and 9d-9e.

In the embodiment, the RRC needs to configure R10 non-CA UE to use the extend format. Therefore, when the eNodeB detects a MAC CE message with LCID=11010 from the UE without having done RRC configuration to the UE , the eNodeB can determine that the MAC CE message is a PHR from an R8/9 UE and thus the PHR size is 1 byte. However, if particular configuration (e.g., extend format is applied in the corresponding PHR data payload) has been performed to the UE, the eNodeB can determine that the PHR is from an R10 non-CA UE, and the MAC CE may be further resolved according to the above solutions 1 and 2.

In the embodiment, the original LCID of the system is used without configuring a new LCID and in order to reduce overhead, no bit-map and/or F/L byte is needed.

FIG. 10 is a structural diagram illustrating a sub-header of a power headroom report transmitted between an eNodeB and a user equipment in a wireless communication network according to yet another embodiment of the present invention. As shown, the contents of the sub-header include an LCID and may further include a length field indicator F. The length field indicator F is defined to indicate whether the UE corresponding to the PHR supports CA.

Based on the above PHR structure, step S l l further comprises the step of: determining the size of the data payload according to a combination of the length field indicator F and the length indication field L if the LCID is a first value, such as 11001. For example, it is determined whether the source of the PHR is an R10 CA capable UE or a non-CA UE according to the length field indicator F, and then the size of the data payload is determined according to the length indication field L.

In the embodiment, the LCID and F/L byte defined for R10 CA capable UE are reused. The F field in the MAC sub-header is redefined to indicate whether this is an R10 CA capable UE or a non-CA UE.

In the embodiment, it is not necessary to define a new LCID for the PHR of R10 non-CA UE. Instead, the F field in the F/L byte is redefined to indicate whether the coming PHR contents are used for CA capable UE or non-CA UE. As for the latter, no bit-map is needed to be included in the PHR contents. Therefore, non-CA PHR size is optimized. In the current standards, the F field in the F/L byte is used to indicate whether the corresponding data payload size is above 128 bytes. However, in a MAC PHR CE, it is impossible for the PHR size to be above 128 bytes. Therefore, the F field is useless for a MAC PHR CE. In the embodiment, this field is reused to indicate whether a PHR is CA capable or non-CA, thereby optimizing the non-CA PHR size.

Optionally, in some embodiments above, indication information in the data payload includes a virtual indication field V, and step S 12 may further include: based on the size of the data payload, resolving the data payload according to a combination of the virtual indication field and simultaneous transmission configuration state of the physical uplink control channel and the physical uplink shared channel.

Optionally again, in some embodiments above, indication information in the data payload may include a virtual indication field and a maximum available power indicator, and thus step S 12 may further comprise: based on the size of the data payload, resolving the data payload according to a combination of the virtual indication field and the maximum available power indicator.

Optionally again, in some embodiments above, indication information in the data payload includes a maximum available power indicator, and thus step S l l may further comprise: determining the size of the data payload to be 4 bytes if the physical uplink control channel and the physical uplink shared channel are configured to be capable of simultaneous transmission; determining the size of the data payload to be 2 bytes if the physical uplink control channel and the physical uplink shared channel are configured to be incapable of simultaneous transmission. Since the PHR data payload size is fixed, no F/L field is needed in the report, and it is not necessary to redefine two reserved fields R/R either, thereby overhead is reduced. Here, optionally, indication information in the data payload may further include a virtual indication field, and thus step S 12 may further comprise: resolving the data payload into "a power headroom value and a maximum available power of the physical uplink control channel", or "a power headroom value and a maximum available power of the physical uplink shared channel" and PHR data payload corresponding to the above 2 bytes size, according to simultaneous transmission configuration state of the physical uplink control channel and the physical uplink shared channel (e.g. when the physical uplink control channel and the physical uplink shared channel are not configured to transmit simultaneously); or resolving the data payload into "a power headroom value and a maximum available power of the physical uplink control channel" and "a power headroom value and a maximum available power of the physical uplink shared channel" and PHR data payload corresponding to the above 4-bytes size, according to simultaneous transmission configuration state of the physical uplink control channel and/or the physical uplink shared channel (e.g. when the physical uplink control channel and the physical uplink shared channel are configured to transmit simultaneously).

A person skilled in the art would understand that RANI has notified RAN2 of the discussion related to Pcmax reporting in the case of RIO non-CA scenarios and requested RAN2 to include Pcmax, c reported by all RIO UE in a PHR. Therefore, in some embodiments above, what is focused on is the MAC CE format in the case of Pcmax reporting of RIO non-CA UE. In these embodiments, whatever CA configuration is, the PUCCH and the PUSCH may be configured to transmit simultaneously on the UE side. And if the PUCCH and the PUSCH are configured to be capable of transmitting simultaneously, then the type 2 PHR and its corresponding Pcmax may be reported as well as the type 1 PHR and its corresponding Pcmax. On the other hand, if the PUCCH and the PUSCH are configured to be incapable of transmitting simultaneously, then only the type 1 PHR and its corresponding Pcmax may be reported in non-CA scenarios. Consequently, MAC CE length depends to some extent on whether the PUCCH and the PUSCH are configured to be capable of transmitting simultaneously. These two cases are shown in FIGS 9a-9b or FIGs 9d-9e.

In summary, there are two optional methods of determining MAC CE format in non-CA scenarios: reusing PHR MAC CE of extend format, or using a new MAC CE structure.

The former is direct and won't have any impact to the current communication standards. FIGs. 9a-9b illustrate a PHR MAC CE of extend format in non-CA scenarios.

Taking into account that only one cell is configured in non-CA scenarios, the first byte bit-map (C7-C1 and R shown in FIGs. 9a-9b) indicating activation/deactivation of secondary cells is not needed in non-CA scenarios. If a corresponding Pcmax is always reported along with the PHR, the data payload of the generated MAC CE will have fixed size. Accordingly, a PHR sub-header of the fixed size may be used. In general, if a new MAC CE is designed for non-CA scenarios, at most two bytes may be saved for each PHR.

FIGS. 9c-9e illustrate an embodiment of a MAC CE format optimized designed for non-CA scenarios, wherein the LCID in R8/9 PHR MAC CE may be reused in the new frame structure. For RIO UE in an RIO network, the use of theframe structure involved in the above embodiment is typically configured via RRC signaling. And for R 8/9 UE in an RIO network, R8/9 PHR MAC CE structure may still be used.

FIG. 3 is a structural diagram illustrating an apparatus 100 for receiving a power headroom report in an eNodeB of a wireless communication network according to an embodiment of the present invention. The apparatus 100 for receiving the power headroom report includes a data payload size determining module 101 and a data payload resolving module 102.

The data payload size determining module 101 is configured to determine the size of the data payload according to a combination of contents of the sub-header.

And the data payload resolving module 102 is configured to resolve the data payload according to a combination of indication information in the data payload.

FIG. 4 is a structural diagram illustrating an apparatus for transmitting a power headroom report in a user equipment of a wireless communication network according to an embodiment of the present invention. The apparatus 200 for transmitting the power headroom report is typically used in UE and comprises a data payload size notification module 201 and a data payload structure notification module 202.

The data payload size notifying module 201 is configured to notify an eNodeB of the size of the data payload via a combination of contents of the sub-header.

And the data payload structure notifying module 202 is configured to notify the eNodeB of the structure of the data payload via a combination of indication information in the data payload.

The embodiments of the present invention are described above. It should be understood that the present invention is not limited to the above specific embodiments, and variations or modifications may be made by an ordinary person skilled in the art without departing from the scope of the appended claims. And the technical solutions of the present invention may be implemented by either software or hardware.

Claims

1 . A method of receiving a power headroom report in an eNodeB of a wireless communication network, wherein the power headroom report comprises a sub-header and a data payload, the method comprising:

A. determining the size of the data payload according to a combination of contents of the sub-header;

B. resolving the data payload according to a combination of indication information in the data payload.

2. The method of claim 1 , wherein the contents of the sub-header in step A comprise a logical channel identifier, and step A further comprises:

determining the size of the data payload to be 1 byte if the logical channel identifier is a first value;

determining the size of the data payload to be 2 bytes if the logical channel identifier is a second value;

determining the size of the data payload to be 3 bytes if the logical channel identifier is a third value;

determining the size of the data payload to be 4 bytes if the logical channel identifier is a fourth value.

3. The method of claim 1 , wherein the contents of the sub-header in step A comprise a logical channel identifier, a length field indicator (F) and a length indication field (L), and step A further comprises:

determining the size of the data payload according to a combination of the length field indicator and the length indication field if the logical channel identifier is a first value.

4. The method of claim 1 , wherein the contents of the sub-header in step A comprise a logical channel identifier, a first reserved field and a second reserved field, and step A further comprises:

determining the size of the data payload according to a combination of the first reserved field and the second reserved field if the logical channel identifier is a first value.

5. The method of claim 1 further comprising the following step before step A:

configuring an RIO non-Carrier Aggregation user equipment in the wireless communication network to support the power headroom report of extend format.

6. The method of claim 5, wherein the contents of the sub-header in step A comprise a logical channel identifier, and the method comprises the following step before step A:

determining whether the user equipment corresponding to the power headroom report supports the power headroom report of extend format if the logical channel identifier is a first value.

7. The method of claim 6, wherein the first value is ' 11010' , the contents of the sub-header comprise a length field indicator and a length indication field, or a first reserved field and a second reserved field, and step A further comprises:

determining the size of the data payload to be 1 byte if the user equipment corresponding to the power headroom report is not configured to support the power headroom report of extend format;

determining the size of the data payload according to a combination of the length field indicator and the length indication field, or a combination of the first reserved field and the second reserved field, if the user equipment corresponding to the power headroom report is configured to support the power headroom report of extend format.

8. The method of claim 1 , wherein the contents of the sub-header in step A comprise a logical channel identifier and a length field indicator (F) to indicate whether a user equipment corresponding to the power headroom report supports carrier aggregation, and step A further comprises:

determining the size of the data payload according to a combination of the length field indicator (F) and the length indication field (L) if the logical channel identifier is a first value.

9 . The method of any of claims 1-8, wherein the indication information in the data payload comprises a virtual indication field, and step B further comprises:

based on the size of the data payload, resolving the data payload according to a combination of the virtual indication field and a simultaneous transmission configuration state of the physical uplink control channel and the physical uplink shared channel.

10. The method of any of claims 1-8, wherein the indication information in the data payload comprises a virtual indication field and a maximum available power indicator, and step B further comprises: based on the size of the data payload, resolving the data payload according to a combination of the virtual indication field and the maximum available power indicator.

11 . The method of any of claims 1-8, wherein the indication information in the data payload comprises a maximum available power indicator, and step A further comprises:

determining the size of the data payload to be 4 bytes if the physical uplink control channel and the physical uplink shared channel are configured to be capable of simultaneous transmission;

determining the size of the data payload to be 2 bytes if the physical uplink control channel and the physical uplink shared channel are configured to be incapable of simultaneous transmission.

12. The method of claim 11 , wherein the indication information in the data payload comprises a virtual indication field, and step B further comprises:

resolving the data payload into a power headroom value and a maximum available power of the physical uplink control channel and/or a power headroom value and a maximum available power of the physical uplink shared channel, respectively, according to the simultaneous transmission configuration state of the physical uplink control channel and the physical uplink shared channel.

13. A method of transmitting a power headroom report in a user equipment of a wireless communication network, wherein the power headroom report comprises a sub-header and a data payload, the method comprising:

A. notifying an eNodeB of the size of the data payload via a combination of contents of the sub-header;

B. notifying the eNodeB of the structure of the data payload via a combination of indication information in the data payload.

14. An apparatus for receiving a power headroom report in an eNodeB of a wireless communication network, wherein the power headroom report comprises a sub-header and a data payload, the apparatus comprising:

a data payload size determining module for determining the size of the data payload according to a combination of contents of the sub-header;

a data payload resolving module for resolving the data payload according to a combination of indication information in the data payload.

15. An apparatus for transmitting a power headroom report in a user equipment of a wireless communication network, wherein the power headroom report comprises a sub-header and a data payload, the apparatus comprising:

a data payload size notifying module for notifying an eNodeB of the size of the data payload via a combination of contents of the sub-header;

a data payload structure notifying module for notifying the eNodeB of the structure of the data payload via a combination of indication information in the data payload.