throbber
R1-073676
`
`3GPP TSG RAN WG1 #50 Meeting
`Athens, Greece, August 20-24, 2007
`
`
`
`Nokia Siemens Networks, Nokia
`Source:
`Power control headroom reports for EUTRAN uplink
`Title:
`Agenda item: 7.4.2
`Document for: Discussion/Decision
`
`1. Introduction
`In this contribution we address the topic of power control headroom reporting in E-UTRAN LTE Uplink. We propose
`that the UE measures the used power, and then reports the difference between this and the maximum UE transmission
`power. We also propose a flexible power control headroom reporting scheme which is based on a set of e-Node B
`configurable parameters, and can support both periodic and event-triggered signalling (but also a combination of these
`two reporting methods).
`
`2. Power control headroom report
`The latest agreement on the power control for PUSCH is summarized in [1]. Basically the power spectral density (PSD)
`is determined by; (i) an open loop power control (OLPC) component calculated at the UE, and (ii) a closed loop power
`control (CLPC) correction transmitted by the eNode-B. A similar approach (but using different OLPC parameters and
`independent closed loop commands) has been agreed for the PUCCH [2]. Given such a power control scheme, it is
`unknown by the eNode-B at which PSD level the different terminals are operating. Information on the PSD is important
`for performing correct radio resource management decisions at the eNode-B, especially when allocating the
`transmission format (bandwidth and modulation & coding) to the different terminals. Not knowing the PSD used by a
`certain terminal could e.g. cause the allocation of a too high transmission bandwidth (given the maximum eUE power
`capabilities), thus resulting in a lower SINR. Information on the PSD used at the eUE can be obtained from the power
`control headroom reports, provided that the eNode-B knows the transmission bandwidth used when the power
`measurement was performed. Information on the PSD is primarily critical for the PUSCH as the transmission format for
`this channel is adaptively adjusted. On the other hand, the transmission format on the PUCCH is more constant per user,
`i.e. constant bandwidth, MCS, etc. It is therefore suggested that the UE only measures the power control headroom for
`the PUSCH as this is the only case where such a measurement is needed before adjusting the allocated bandwidth
`and/or modulation and coding scheme.
`
`Note: Alternatively to the power control headroom, the eUE could signal to the eNode-B the measured path-loss which
`is input to the OL standardized PC formula in [1]. Knowing the measured path loss at the eUE the eNode-B can easily
`calculate the PSD used at the terminal.
`
`2.1 Definition of ‘Power Control Headroom’
`In HSUPA the power control headroom is defined as the difference between the “nominal” maximum transmission
`power and the power measured at the UE. We propose to use the same measure in E-UTRAN uplink:
`
`Power Control Headroom = 10⋅log10 (PMAX) - 10⋅log10 (PMEASURED),
`
`where PMAX is the maximum eUE Tx power, and PMEASURED is the measured eUE Tx power. The power control
`headroom is calculated per TTI. It is FFS whether the power control headroom should be averaged before being
`reported to the eNode-B, and whether the averaging should be done in linear or in logarithmic domain.
`
`Apple Inc. v. Cellular Communications Equipment LLC
`APPL-1017 / Page 1 of 3
`
`

`
`2.2 Proposed Power Control Headroom reporting scheme
`We suggest the following criteria for sending a power control headroom report in the uplink:
`
`1.
`
`2.
`
`3.
`
`4.
`
`5.
`
`6.
`
`A power control headroom report is transmitted after N closed loop PC corrections have been (correctly)
`received by the terminal.
`
`After the OLPC component of the PSD is modified at the terminal (based on an updated path loss measurement),
`the eUE measures the power control headroom for M (consecutive) TTIs and afterwards transmits a power
`control headroom report.
`
`The UE sends a power control headroom report if the difference between the current and the latest path loss
`measurement is higher than a given threshold (X dB).
`
`A report is also triggered in case the power control headroom reaches a certain value, e.g. the eUE Tx power
`comes close (<Y dB) to its maximum possible value PMAX.
`
`A power control headroom report is in any case transmitted every P TTIs (periodic signaling).
`
`However, the UE is not allowed to transmit a power control headroom report if the time elapsed from the last
`report is < K TTIs (this criteria is introduced to limit the signaling overhead).
`
`Notice that standardizing the proposed criteria would allow the implementation of a variety of different reporting
`schemes by appositely tuning the parameters N, M, X, K, Y and P.
`
`2.3 Signaling of Power Control Headroom Reports
`Transmission of power control headroom measurement reports could be performed by means of either RRC or MAC
`signaling. Though this is mainly a RAN2 issue, we propose using MAC signaling to convey power control headroom
`reports from the eUEs to the eNode-B mainly due to the following two reasons: (i) MAC signaling is also used to report
`power headroom information in HSUPA, and (ii) MAC has been proposed as signaling protocol for the transmission of
`uplink buffer status reports in EUTRAN [3].
`
`Whether power control headroom and buffer status reports should be signaled using a fixed size MAC header as in
`HSUPA or separate MAC messages should be used is FFS (shall be discussed in RAN2).
`
`3. Conclusions
`In this contribution we have addressed power control headroom reports in EUTRAN uplink. We have underlined the
`importance of power control headroom reports, especially in relation to the allocation of the uplink transmission
`bandwidth and MCS to the different users. We recommend RAN1 to reach an agreement on the following points:
`
`- The power control headroom is measured and reported for the PUSCH only. No need to have power control
`headroom measured for the PUCCH as this channel is allocated constant bandwidth and MCS per user.
`
`- The “power control headroom” per TTI is defined as 10⋅log10 (PMAX) - 10⋅log10 (PMEASURED), where PMAX is the
`maximum eUE Tx power and PMEASURED is the measured eUE Tx power. It is FFS whether the power control
`headroom should be averaged before being reported to the eNode-B, and whether the averaging should be done
`in linear or in logarithmic domain
`
`- The standard should include the reporting rules and parameters described in Section 2.3. Notice that any of the
`reporting mechanisms can be deactivated by setting the corresponding parameter accordingly. The reporting
`parameters could be transmitted using the RRC protocol.
`
`-
`
`Power headroom reports are transmitted in the uplink using MAC signaling (same used in HSUPA), but with
`the possibility to define separate reports for the power control headroom and the buffer status (to be discussed
`in RAN2).
`
`APPL-1017 / Page 2 of 3
`
`

`
`4. References
`[1] R1-073224 - “Way Forward on Power Control of PUSCH” - CATT, Ericsson, et al. - 3GPP TSG RAN
`WG1, meeting #49-bis, Orlando, USA, 25th - 29th June, 2007.
`[2] R1-073209 - “Way Forward on Uplink Power Control of PUCCH” - CATT, Ericsson et al. - 3GPP TSG
`RAN WG1, meeting #49-bis, Orlando, USA, 25th - 29th June, 2007.
`[3] R2-060829, “Buffer Reporting for E-UTRAN” - Nokia - 3GPP TSG RAN WG1, meeting #52, Athens,
`Greece, 27th - 31st March, 2006.
`
`
`
`APPL-1017 / Page 3 of 3

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket