3GPP TR 36.805 V9.0.0 (2009-12)
`
`Technical Report
`
`3rd Generation Partnership Project;
`Technical Specification Group Radio Access Network;
`Study on Minimization of drive-tests
`in Next Generation Networks;
`(Release 9)
`
`
`Lte~
`
`
`
`
`
`
`
`
`
`
`
`
`
`The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.
`The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.
`This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification.
`Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.
`
`
`
`Samsung Ex. 1009
`
`

`

`
`Release 9
`
`2
`
`3GPP TR 36.805 V9.0.0 (2009-12)
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Keywords
`<keyword[, keyword]>
`
`3GPP
`
`Postal address
`
`
`3GPP support office address
`650 Route des Lucioles - Sophia Antipolis
`Valbonne - FRANCE
`Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
`
`Internet
`http://www.3gpp.org
`
`Copyright Notification
`
`No part may be reproduced except as authorized by written permission.
`The copyright and the foregoing restriction extend to reproduction in all media.
`
`© 2009, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TTA, TTC).
`All rights reserved.
`
`
`
`UMTS™ is a Trade Mark of ETSI registered for the benefit of its members
`3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
`LTE™ is a Trade Mark of ETSI currently being registered for the benefit of its Members and of the 3GPP Organizational Partners
`GSM® and the GSM logo are registered and owned by the GSM Association
`
`3GPP
`
`Samsung Ex. 1009
`
`

`

`
`Release 9
`
`3
`
`3GPP TR 36.805 V9.0.0 (2009-12)
`
`Contents
`Foreword............................................................................................................................................................. 4
`1
`Scope ........................................................................................................................................................ 5
`2
`References ................................................................................................................................................ 5
`3
`Definitions, symbols and abbreviations ................................................................................................... 5
`3.1
`Definitions ......................................................................................................................................................... 5
`3.2
`Symbols ............................................................................................................................................................. 6
`3.3
`Abbreviations ..................................................................................................................................................... 6
`4
`Requirements and constraints ................................................................................................................... 6
`5
`Use cases .................................................................................................................................................. 7
`5.1
`Coverage optimization ....................................................................................................................................... 7
`5.2
`Mobility optimization ........................................................................................................................................ 8
`5.3
`Capacity optimization ........................................................................................................................................ 8
`5.4
`Parameterization for common channels ............................................................................................................. 8
`5.5
`QoS verification ................................................................................................................................................. 8
`6
`UE measurements ..................................................................................................................................... 9
`6.1
`UE measurement logging ................................................................................................................................. 10
`6.1.1
`Periodical downlink pilot measurements.................................................................................................... 10
`6.1.2
`Serving Cell becomes worse than threshold ............................................................................................... 11
`6.1.3
`Transmit power headroom becomes less than threshold ............................................................................ 11
`6.1.4
`Random access failure ................................................................................................................................ 13
`6.1.5
`Paging Channel Failure (PCCH Decode Error) .......................................................................................... 14
`6.1.6
`Broadcast Channel failure .......................................................................................................................... 15
`6.1.7
`Radio link failure report ............................................................................................................................. 16
`6.2
`UE measurement Reporting ............................................................................................................................. 17
`7
`Impact analysis ....................................................................................................................................... 17
`7.1
` UE impact ....................................................................................................................................................... 17
`7.1.1
`UE power consumption .............................................................................................................................. 17
`7.1.2
`UE memory impact .................................................................................................................................... 18
`7.2
` End user impact .............................................................................................................................................. 19
`7.3
` Other impact ................................................................................................................................................... 19
`8
`Conclusion .............................................................................................................................................. 19
`Simulation results ................................................................................................................. 22
`Annex A:
`A.1
`Simulation [6] .................................................................................................................................................. 22
`A.2
`Simulation [7] .................................................................................................................................................. 22
`A.3
`Simulation [8] .................................................................................................................................................. 22
`A.4
`Simulation [9] .................................................................................................................................................. 22
`Change history ...................................................................................................................... 24
`Annex B:
`
`
`3GPP
`
`Samsung Ex. 1009
`
`

`

`
`Release 9
`
`4
`
`3GPP TR 36.805 V9.0.0 (2009-12)
`
`Foreword
`This Technical Report has been produced by the 3rd Generation Partnership Project (3GPP).
`
`The contents of the present document are subject to continuing work within the TSG and may change following formal
`TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
`identifying change of release date and an increase in version number as follows:
`
`Version x.y.z
`
`where:
`
`x
`
`the first digit:
`
`1 presented to TSG for information;
`
`2 presented to TSG for approval;
`
`3 or greater indicates TSG approved document under change control.
`
`y
`
`the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
`updates, etc.
`
`z
`
`the third digit is incremented when editorial only changes have been incorporated in the document.
`
`
`
`3GPP
`
`Samsung Ex. 1009
`
`

`

`
`Release 9
`
`5
`
`3GPP TR 36.805 V9.0.0 (2009-12)
`
`Scope
`1
`The present document is intended to capture findings produced in the context of the Feasibility Study on Minimization
`of Drive-Tests (MDT) in next generation networks.
`
`The study aims at assessing the feasibility, benefits and complexity of automating the collection of UE measurements to
`minimize the need of manual drive-tests. The work under this study should take the following steps.
`
`1. Define use cases and requirements for minimizing drive tests in next generation LTE/HSPA networks
`
`2. Based on the defined use cases and requirements, study the necessity of defining new UE measurements
`logging and reporting capabilities for minimizing drive tests and analyse the impact on the UE
`
`Policy control mechanism and transport mechanism (including message syntax) for the new UE measurement logging
`and reporting capabilities are outside of the scope of the study. The study should focus on new logging and reporting
`capabilities for measurements already available at the UE.
`
`References
`2
`The following documents contain provisions which, through reference in this text, constitute provisions of the present
`document.
`
`- References are either specific (identified by date of publication, edition number, version number, etc.) or
`non-specific.
`
`- For a specific reference, subsequent revisions do not apply.
`
`- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
`a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
`Release as the present document.
`
`[1]
`
`[2]
`
`[3]
`
`[4]
`
`[5]
`
`[6]
`
`[7]
`
`[8]
`
`[9]
`
`3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
`
`3GPP TR 41.001: "GSM Release specifications".
`
`3GPP TR 21 912 (V3.1.0): "Example 2, using fixed text".
`
`3GPP TS 25.331:"Universal Terrestrial Radio Access (UTRA); Radio Resource Control (RRC);
`Protocol specification".
`
`3GPP TS 36.331: "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource
`Control (RRC) protocol specification".
`
`R2-096049 MDT coverage and capacity optimization.
`
`R2-096737 Further simulations on network based solutions for coverage optimization.
`
`R2-095910 Simulation results for MDT logging with UE under RLF.
`
`R2-097031 MDT uplink coverage optimization.
`
`3
`
`Definitions, symbols and abbreviations
`
`Definitions
`3.1
`For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A
`term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1].
`
`Definition format (Normal)
`
`<defined term>: <definition>.
`
`3GPP
`
`Samsung Ex. 1009
`
`

`

`
`Release 9
`
`6
`
`3GPP TR 36.805 V9.0.0 (2009-12)
`
`example: text used to clarify abstract rules by applying them literally.
`
`Symbols
`3.2
`For the purposes of the present document, the following symbols apply:
`
`Symbol format (EW)
`
`<Explanation>
`
`<symbol>
`
`Abbreviations
`3.3
`For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An
`abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
`TR 21.905 [1].
`
`Abbreviation format (EW)
`
`<ACRONYM> <Explanation>
`
`
`Requirements and constraints
`4
`The solutions for the minimisation of drive tests shall comply with the following requirements.
`1) UE measurement configuration
`The operator shall be able to configure the UE measurements for the UE logging purpose independently from the
`network configurations for normal RRM purposes.
`
`2) UE measurement collection and reporting
`Measurement logs usually consist of multiple events and measurements taken over time. A real time reporting of a
`measurement log at every measurement logging trigger is not necessary. The time interval for measurement
`collection and reporting shall be separately configurable in order to limit the impact on the UE battery consumption
`and network signalling load. It shall be possible to collect measurement logs preceding a particular event (e.g. radio
`link failure).
`3) Geographical scope of measurement logging
`Drive testing of a targeted geographical area (e.g. problem area) is part of usual activities for operators. It shall be
`possible for the operator to configure the geographical area where the defined set of measurements shall be
`performed. Some measurements (e.g. the continuous logging function) might run independent of any
`geographically defined area.
`
`4) Location information
`The measurements in measurement logs shall be linked to available location information and/or other information
`or measurements that can be used to derive location information.
`5) Time information
`The measurements in measurement logs shall be linked to a time stamp that is available in the UE. Accuracy of
`time information (absolute time, relative time) is FFS.
`6) Device type information
`The terminal used for measurements shall be able to indicate a set of terminal capabilities which allows the network
`to carefully select the right terminals for specific measurements. It is FFS if existing UE capability reporting is
`sufficient.
`7) Dependency on SON
`The solutions for minimization of drive tests shall be able to work independently from SON support in the network.
`
`The solutions for the minimization of drive tests shall take into account the following constraints.
`
`3GPP
`
`Samsung Ex. 1009
`
`

`

`
`Release 9
`
`7
`
`3GPP TR 36.805 V9.0.0 (2009-12)
`
`1) UE measurements
`The UE measurement logging mechanism is an optional feature. In order to limit the impact on UE power
`consumption and processing, the UE measurement logging should as much as possible rely on the measurements
`that are available in the UE according to radio resource management enforced by the access network.
`
`2) Location information
`The availability of location information is subject to UE capability and/or UE implementation. The solutions
`requiring the location information shall take into account power consumption of the UE due to having to run its
`positioning components.
`
`5
`
`Use cases
`
`Coverage optimization
`5.1
`Information about radio coverage is essential for network planning, network optimization and Radio Resource
`Management (RRM) parameter optimization (e.g. idle mode mobility parameter setting, common channel
`parameterization), as well as backend network management activities, such as network dimensioning, CAPEX/OPEX
`planning and marketing. Additionally the detection of coverage problems (e.g. coverage holes, pilot pollution, low user
`throughput, etc.) in specific areas is performed, e.g. based on customers complaints, along roads or train lines, in case of
`special events.
`
`Coverage is something that a customer can easily notice through the terminal UI (i.e. out-of-service area indication),
`and is a major criteria that a customer considers when comparing service provided by different operators. With the
`increase in data service provision, DL throughput is also an important criterion by which many customers judge the
`performance of the network (either by observing download time or by reading review articles written by mass media).
`Poor UL coverage will impact user experience in terms of call setup failure / call drop / poor UL voice quality.
`
`Accordingly, it is very important for operators to be aware of the coverage / throughput their networks provide, and
`rigorous “drive tests” are performed to collect such information.
`
`The main triggers for operators to perform drive tests to collect network performance metrics in their network are
`outlined below. If these measurements can be collected from UEs within the framework of Drive test minimisations, the
`rigorous drive tests explained below can be reduced, which will significantly reduce network maintenance costs for
`operators, ensure faster optimisation cycle resulting in higher customer satisfaction and nonetheless help to reduce the
`carbon emission to protect the environment. Furthermore, it will enable operators to collect measurements from areas
`which are not accessible for drive tests (e.g. narrow roads, forests, private land/house/office).
`
`1) Deployment of new base stations / cells
`
`This is the first phase of drive test that is performed for a particular cell / smaller network area.
`
`When new base stations / cells are deployed, drive tests are performed before and after service activation of the new
`cell. Specifically speaking, first, radio waves will be transmitted from a new cell in a “test mode” (i.e. cell barred for
`normal access classes), and initial collection of DL/UL coverage measurements of the new cell and neighbour cells
`will be made in the intended area of coverage improvement. During this phase, initial area tuning is performed (e.g.
`selection of an appropriate antenna for the new cell, adjustment of antenna tilting of the new cell and neighbour cells,
`etc.). Service with the new cell will be started after such initial tuning. However, drive tests are continued to collect
`more extensive data of DL/UL coverage measurements in the intended area to make sure good DL/UL coverage is
`being provided. Further area tuning will be performed during this phase as necessary.
`
`Deployment of new base stations / cells is a continuous / long lasting process for a new system, but also established
`systems need continuous redesign and extension. This trend is becoming more and more apparent now that there are
`many RAN elements to fine tune coverage of the operator’s network (e.g. Remote Radio Heads, picos, femtos).
`
`2) Construction of new highways / railways / major buildings
`
`This is the additional phase of drive test that is performed for a particular cell / smaller network area in an event
`driven manner.
`
`Areas where new highways / railways / major buildings are constructed are potential areas which residing population
`will increase, and are important areas to provide good coverage. Also, such large constructions normally introduce
`
`3GPP
`
`Samsung Ex. 1009
`
`

`

`
`Release 9
`
`8
`
`3GPP TR 36.805 V9.0.0 (2009-12)
`
`weak pilot areas as they become new sources of shadowing losses. Therefore, whenever new highways / railways /
`major buildings are constructed, operators perform drive tests in the relevant area to see if the coverage needs to be
`improved. If coverage improvement is deemed as necessary, operators take action by deploying new cells, adjusting
`antenna tilting of existing cells, etc. Drive tests to collect performance metrics are performed again after such actions
`to check that coverage has improved in the area to an adequate level.
`
`3) Customer’s complaints
`
`This is another additional phase of drive test that is performed for a particular cell / smaller network area in an event
`driven manner.
`
`Customer’s complaints are an important trigger to perform drive tests. When customers indicate coverage /
`throughput concerns (e.g. poor DL coverage at their home, office, etc.), operators perform “drive tests” in the
`relevant area to observe the coverage quality. If coverage improvement is deemed as necessary, operators take action
`by deploying new cells, adjusting antenna tilting of existing cells, etc. Drive tests to collect performance metrics are
`performed again after such actions to check that coverage has improved in the area to an adequate level.
`
`4) Periodic drive tests
`
`This is the additional phase of drive test that is performed for a particular cell / smaller network area or the entire
`network in a regular and on demand manner.
`
`DL/UL coverage is affected when new constructions (or destruction) are performed due to shadowing loss changes. As
`indicated in 2), operators are conscious of major constructions and perform drive tests around such area in a timely
`manner. However, operators cannot follow each and every construction, especially for smaller scale constructions.
`Therefore, it is important for operators to periodically perform drive tests in order to update their understanding of the
`coverage levels provided in their networks. If coverage improvement is deemed as necessary after such periodic drive
`tests, operators take action by deploying new cells, adjusting antenna tilting of existing cells, etc. Drive tests to collect
`performance metrics are performed again after such actions to check that coverage has improved in the relevant area to
`an adequate level. This kind on drive tests is also performed on a regular basis to perform benchmarking between
`operators.
`
`Mobility optimization
`5.2
`Mobility optimization is an important part of network operation. Information about mobility problems or failures can be
`used to identify localized lack of coverage or the need to adapt the network parameters setting, e.g. in order to avoid too
`early or too late handover and to improve the handover success rate and overall network performance.
`
`Capacity optimization
`5.3
`The operator needs to be able to determine if there is too much/little capacity in certain parts of the network i.e. to
`detect locations where e.g. the traffic is unevenly distributed or the user throughput is low. This helps to e.g. determine
`placement of new cells, configure common channels and optimize other capacity related network parameters.
`
`Parameterization for common channels
`5.4
`User experience and/or network performance can be degraded by suboptimal configuration of common channels (e.g.
`random access, paging and broadcast channels). Detecting problems (e.g. on UL or DL common channel coverage) or
`analyzing the performance (e.g. connection setup delay) for the procedures associated with common channels, helps
`network parameter setting and configuration change for system performance optimization, (e.g. RACH channel
`parameters are set as a trade off between congestion and capacity)
`
`QoS verification
`5.5
`One of the objectives of the network performance analysis is the verification of the quality of service (e.g. user
`throughput). This also allows detecting critical conditions and determining the need to change the network
`configuration, parameter settings or capacity extension.
`
`3GPP
`
`Samsung Ex. 1009
`
`

`

`
`Release 9
`
`9
`
`3GPP TR 36.805 V9.0.0 (2009-12)
`
`This aspect is important also in the initial deployment of a new radio access technology, in order to check if the quality
`of service experienced by the end user is in line with the performance target defined in the planning strategy and more
`in general to test the overall performance of the technology along the subsequent deployment phases.
`
`Traditionally the first step is to verify the coverage, possibly also in indoor and the reliability of the mobility procedures
`(e.g. railways and highways). However since the introduction of HSPA, the verification of the quality of service in a
`way that allows to correlate with the user experience, e.g. in terms of user throughput has become an important KPI,
`also in the first phase of the network deployment. This will be even more important for LTE where the mix of different
`type of service classes scheduled on the same radio resources will happen very soon.
`
`The reasons for un unexpectedly low QoS may be different, e.g. coverage, load or user mobility. Moreover the problem
`may occur at the border region of several cells or localized in the cell due to particular propagation conditions or uneven
`traffic distribution. Only looking at the cell level statistics is not an effective way to understand the origin of the
`problem and take the proper actions (e.g. whether to increase the coverage, the capacity or to change the RRM settings)
`
`The verification of the QoS is a crucial task of the current drive test campaigns; moreover, in order to provide a reliable
`statistical analysis of this kind of performance, extensive drive test should be performed with huge costs for the operator.
`
`The possibility to periodically collect such measurements, even if for short periods and on a limited number of UEs,
`would be more cost effective and more reliable from the statistical point of view. Moreover, the possibility to collect the
`measurements by the UE increases the “coverage” of the analysis, as it is possible in inaccessible areas or in indoor, i.e.
`where a considerable portion of the traffic is generated.
`
`UE measurements
`6
`General principles for UE measurement logging are captured in the following. The UE measurement logging function is
`a UE optional feature and some measurements may or may not be available in the UE as indicated below.
`While defining the measurement logs and the need for those, it shall be considered how normal existing reporting
`principles through RRC signalling can be utilized in order to collect appropriate information for a given use case. The
`available RRC measurements and SON measurements, potentially with some additional reporting and/or together with
`(e)NB measurements, may be enough to supply the measurement logs identified for particular target use cases. This
`shall be used as benchmark when assessing the need and/or value for new functionalities and reporting in the scope of
`this Study Item.
`
`If the new functionality is defined, it is beneficial to evaluate its usability in terms of SON.
`
`Basic model / principles
`The network can request the UE to perform some logging of measurements. The UE executes the logging as requested
`by the network with certain constraints, e.g. location information availability. Reporting of UE measurement log can be
`separately configured. Period of logging and that for reporting can be different.
`
`Radio environment measurement (aka. cell measurements)
`While measurements for the measurement logging are configured based on OAM requirements, the availability of those
`measurements is under control of RRM in the access network. It is however expected that that relevant measurements
`would be available for a certain period before and after a concerned event where the measurements need to be logged. It
`is therefore considered that as a baseline, the UE does not have to perform additional radio environment measurements
`for measurement logging purposes. The need for additional radio environment measurements shall be motivated case by
`case.
`
`Location information
`The extensive use of positioning component of the UE shall be avoided since it would significantly increase the UE
`power consumption. It is expected that the availability of location information depends on the UE implementation
`and/or capability.
`
`3GPP
`
`Samsung Ex. 1009
`
`

`

`
`Release 9
`
`10
`
`3GPP TR 36.805 V9.0.0 (2009-12)
`
`UE measurement logging
`6.1
`In the following subsections, UE measurement logs for minimizing drive tests are described. Measurement logs are
`taken at the occurrence of predefined “triggers” (e.g. periodic trigger, a failure event). A UE log can consist of basic
`components captured in the previous section and/or records of events themselves.
`
`Periodical downlink pilot measurements
`
`6.1.1
`Description:
`Radio environment measurements, such as CPICH RSCP, CPICH Ec/No, or TDD P-CCPCH RSCP and ISCP, RSRP
`and RSRQ (connected mode only) are logged periodically.
`
`Benefits:
`This measurement log corresponds to the use case “coverage optimization”.
`
`The main measurements collected by operators to be aware of the DL coverage / achievable throughput are the DL
`common pilot reception levels and SIR levels.
`
`Existing RRM measurements mainly rely on the event triggered measurement reporting and periodical reporting is only
`configured on demand. Also there are a number of restrictions.
`
`- There is no accompanying location information. Even though the operator can identify cells with DL coverage
`problems, operators would still need to perform drive tests to figure out the problematic area in the cell as the
`exact location on where the low DL common pilot reception levels / SIR levels are being experienced is not
`known from existing RRM mechanisms.
`
`- The existing RRM mechanisms only allow for measurements to be reported when the UE has RRC connection
`with the particular cell, and there is sufficient UL coverage to transport the MEASUREMENT REPORT. This
`will restrict measurements to be collected from UEs not experiencing RLF and experiencing sufficient UL
`coverage.
`
`Detailed measurement info:
`
`Trigger type: Periodical
`
`Triggered when configured periodical timer expires.
`
`Configuration parameter(s):
`Periodic timer
`-
`- The number of logging
`
`Measurement
`
`Location info
`
`Time info
`
`Definition
`・ Location at which concerned trigger took place
`・ Time at which concerned trigger took place
`
`Remarks
`
`
`
`
`
`Cell Identification ・ CGI of the serving / current cell at which concerned
`trigger took place
`・ PCI/PSC of other cells for which measurement is logged
`・ Cell measurements that are available at the trigger
`
`Radio
`environment
`measurement
`
`Availability of CGI for HSPA is
`FFS
`
`
`
`
`
`3GPP
`
`Samsung Ex. 1009
`
`

`

`
`Release 9
`
`11
`
`3GPP TR 36.805 V9.0.0 (2009-12)
`
`Serving Cell becomes worse than threshold
`
`6.1.2
`Description:
`Radio environment measurements, such as CPICH RSCP, CPICH Ec/No, or TDD P-CCPCH RSCP and ISCP, RSRP
`and RSRQ (connected mode only), are logged when the serving cell metric becomes worse than the configured
`threshold. A measurement logging window (i.e. “sliding window” in which collected logs are kept in the UE) is used in
`order to be able to collect information during a certain period before and after the occurrence of event.
`Benefits:
`This measurement log corresponds to the use case “coverage optimization”.
`
`If the operator is interested in a particular DL coverage problem, it is efficient to take measurement logs corresponding
`to the problem of their interest. The operator can translate their criterion (e.g. out of coverage) into the threshold in
`order to be able to find out problem areas. In order to identify the characteristics of the problem (e.g. happened in a
`particular mobility scenario), it is beneficial measurement logs provide information preceding the measurement logging
`trigger.
`See 6.1.1.
`
`Detailed measurement info:
`Trigger type: Serving cell becomes worse than threshold
`
`Triggered when a cell becomes worse than the preconfigured threshold.
`
`Location
`
`Time stamp
`
`Configuration parameter(s):
`- Threshold
`- Measurement logging window
`- Measurement logging interval (within the measurement logging window)
`Measurement
`Definition
`・ Location at which concerned trigger took place
`・ Location at which concerned measurements took
`place
`・ Time at which concerned trigger took place
`・ Time at which concerned measurements took place
`Cell Identification ・ CGI of the serving / current cell at which concerned
`trigger took place
`・ PCI/PSC of other cells for which measurement is
`logged
`・ Cell measurements that are available at the occurrence
`of the trigger
`・ Cell measurements that are available during a certain
`period before and after the occurrence of concerned
`trigger
`
`Radio
`environment
`measurement
`
`Remarks
`
`
`
`
`
`Availability of CGI for HSPA is
`FFS
`
`
`
`
`
`6.1.3
`Description:
`
`Transmit power headroom becomes less than threshold
`
`3GPP
`
`Samsung Ex. 1009
`
`

`

`
`Release 9
`
`12
`
`3GPP TR 36.805 V9.0.0 (2009-12)
`
`Transmit power headroom and radio environment measurements, such as CPICH RSCP, CPICH Ec/No, or TDD P-
`CCPCH RSCP and ISCP, RSRP and RSRQ (connected mode only) are logged when UE transmit power headroom
`becomes less than the configured threshold.
`Benefits:
`This measurement log corresponds to the use case “coverage optimization”.
`
`From observing UL transmit power levels, operators can spot areas of insufficient UL link budget and also deduce
`achievable UL throughput levels