LTE-ADVANCED AND 4G WIRELESS
`COMMUNICATIONS: PART 2
`
`Minimization of
`Drive Tests Solution in 3GPP
`
`Wuri A. Hapsari, Anil Umesh, and Mikio lwamura, NTT DOCOMO, INC.
`Malgorzata Tomala, 86dog Gyu/a, and Benoist Sebire, Nokia Siemens Networks
`
`ABSTRACT
`Providing network coverage and quality of
`service (QoS) is an important task of a cellular
`network operator. This is because cellular spec(cid:173)
`trum is normally licensed under certain coverage
`obligations, and operators need to be competi(cid:173)
`tive in market. To improve their networks, oper(cid:173)
`ators often send engineers in the field to collect
`radio measurements, to discover problems such
`as coverage holes in the network, and to deter(cid:173)
`mine whet.her certain parameter tuning is need(cid:173)
`ed. However, such conventional "drive tests"
`require large Operation Expenditure (OPEX),
`while the collected measurements can only give
`limited snap shots of the entire network. In their
`Release 10 (Rel-10) specification, 3GPP studied
`and specified solutions to reduce this OPEX for
`drive tests, under the work item named " Mini(cid:173)
`mization of Drive Tests (MDT)." The solution
`utilizes the user (customer) equipments (UEs) to
`collect field measurements, including radio mea(cid:173)
`surements and location information. This article
`describes in details the solution adopted in
`3GPP MDT; how they were developed and
`intended to be used.
`
`INTRODUCTION
`
`Conventional drive test is a manual process. To
`collect network quality information, an operator
`often needs to send engineers directly to the
`concerning area and obtain radio measurements
`in a hand-operated manner. Typically, a mea(cid:173)
`surement vehicle, e.g., a van equipped with spe(cid:173)
`cially developed test terminals, measurement
`devices, and a Global Positioning System (GPS)
`receiver to obtain geographical location, is used
`to check coverage outdoors (1]. With such mea(cid:173)
`surement vehicle, engineers would perform test
`calls in the car and record measurement results
`along the drive route. For indoor coverage engi(cid:173)
`neers perform "drive tests" on foot, using spe(cid:173)
`cially developed measurement equipments that
`can be carried by hand. By analyzing these drive
`test results, the operator can take necessary
`measures to maintain and enhance the quality of
`the network, e.g., to decide whet.her to tune cer-
`
`tain parameters or to deploy new base stations.
`However, conventional drive tests consume
`significant time and human efforts to obtain reli(cid:173)
`able data, since typically, the obtained data only
`covers certain area of the network, e.g., roads
`and motorways. This has led to a huge amount
`of OPEX and delays in detecting problems on
`the network and in taking countermeasures.
`These problems have also been continuously dis(cid:173)
`cussed by the operators in the Next Generation
`Mobile Networks (NGMN) alliance, a non-stan(cid:173)
`dardization organization from where a consoli(cid:173)
`dated operators' requirement for automated
`drive tests and recommendation solutions were
`delivered (2).
`Driven by these problems and demands, oper(cid:173)
`ators proposed to standardize solutions in 3GPP
`to circumvent the cost for drive tests. In light of
`such necessity, a work item called "Minimization
`of Drive Tests (MDT)" was created in 3GPP in
`March 2009 (3] scoping two Radio Access Tech(cid:173)
`nologies (RATs), i.e., Long Term Evolution
`(LTE) and Universal Mobile Telecommunica(cid:173)
`tions System (UMTS). The main concept was to
`exploit commercial user equipments (UEs) -
`their measurement capabilities and geographi(cid:173)
`cally spread nature - for collecting radio mea(cid:173)
`surements. The work item was finalized in March
`2011 as part of 3GPP Rel-10 specification.
`The key features of MDT defined in Rel-10
`are as follows:
`• The ability of the UE to include location
`information as part of the UE radio mea(cid:173)
`surement reporting
`• The ability of the UE to log radio measure(cid:173)
`ments during the UE's idle state
`• Reuse of radio measurements to those that
`anyway have to be performed as part of
`normal R adio Resource Management
`(RRM) procedures, thereby minimizing
`additional complexity and battery consump(cid:173)
`tion by the UE.
`We describe the use case that would benefit
`from MDT. We discuss two fundamental
`approaches to realizing MDT from architecture
`perspective. We explain in detail the functionali(cid:173)
`ties and signaling procedures adopted in 3GPP
`Rel-10, and describe the security aspects.
`
`28
`
`IEEE Communications Magazine • June 2012
`0163-6804/12/$25.00 © 2012 IEEE
`Authorized licensed use limijed to: West Virgn ia University. Downloaded on January 26,2021 at 02:02 36 UTC from EEE Xplore. Restrictions apply.
`Samsung Ex. 1008
`
`

`

`MDT USE CASES
`The motives behind conventional drive test evo(cid:173)
`lution drove further the need to understand pos(cid:173)
`sible scenarios, in which the foreseen solutions
`would help to minimize the drive tests. The main
`triggers for drive test execution are comprised of
`(1, 5]:
`New base station deployment, where collec(cid:173)
`tion of downlink/uplink (DL/UL) coverage mea(cid:173)
`surements of the new cell and neighbor cells are
`essential for a 'coarse' tuning of the network.
`Construction of new highways/railways/major
`buildings, which are in fact new obstacles caus(cid:173)
`ing additional shadowing in the existing radio
`network and new sources of network traffic.
`Drive tests are performed to check whether cov(cid:173)
`erage or throughput requires improvement.
`Cus tomer 's complaint - when customers
`experience bad QoS and indicate these concerns,
`the operator performs measurements collection in
`the relevant area. This allows operators to identi(cid:173)
`fy, understand and solve the problem, and pro(cid:173)
`vide in effect high-quality service to the end user.
`Periodic drive tests -
`regular network moni(cid:173)
`toring helps to reflect the actual performance of
`"alive" networks, with always changing due traf(cid:173)
`fic conditions, and identify areas for improve(cid:173)
`ment. This kind of drive tests is also performed
`on a regular basis to perform benchmarking
`between operators.
`The solutions developed in Rel-10 focus on
`the Coverage Optimization use case that will
`benefit operators especially in the early phase of
`network deployment [6, 8]. The solutions enable
`collection of a set of MDT measurements that
`will provide information for the operator to
`design reliable coverage maps and consequently
`to detect coverage issues. The objectives for
`measuring coverage are as follows:
`Coverage map1>ing: concerns the collection of
`MDT measurements in all parts of the network
`to provide an insight into the signal levels distri(cid:173)
`bution per physical location and allow overall
`coverage visualization
`Coverage hole and weak coverage detection:
`concerns areas where the downlink signal (of
`both serving and neighbor cells) is below the
`level needed to maintain either basic service or
`to fulfill planned performance requirements
`therefore causing discontinuous or poor service
`to the end user
`Pilot pollution detection: concerns areas
`where large overlap of different cells' coverage
`or unexpected signal propagation between cells
`cause excessive interference levels, high power
`levels, high energy consumption, and low cell
`performance
`Overshoot coverage detection: concerns areas
`where coverage of a cell reaches far beyond
`what was initially planned
`Uplink coverage verifica tion: concerns the
`detection of areas with poor uplink communica(cid:173)
`tion and unbalanced coverage between the
`uplink and downlink connections
`Io all the cases above, the MDT information
`should enable to detect overall network coverage
`as well as reveal the locations where signal levels
`are the weakest and embed a risk for degrada(cid:173)
`tion of end user experience.
`
`MDT server
`
`MDT server
`
`RAN
`
`RAN
`
`UE
`
`UE
`
`Figure 1. U-plane MDT architecture (left) and C-plane MDT architecture
`(right).
`
`MDT ARCHITECTURE
`INITIAL STUDIES ((-PLANE VS. U-PLANE)
`In the first phase of the study in 3GPP, the fol(cid:173)
`lowing two architecture solutions were discussed
`[5]: Control-plane (C-plane) based MDT archi(cid:173)
`tecture and User-plane (U-plane) based MDT
`architecture. F igure 1 illustrates the two archi(cid:173)
`tectures. The C-plane based MDT architecture
`refers to an architecture where C-plane signaling
`is used for sending MDT configuration to the
`UE and for reporting MDT measurements to
`the network. In this architecture, the collected
`MDT measurements are visible to the Radio
`Access Network (RAN) node and Operation
`and Maintenance (OAM). On the other hand,
`U-plane based MDT architecture utilizes a cer(cid:173)
`tain application terminated directly between the
`UE and the MDT server. The application data,
`which may include measurement results and
`their reporting configuration, policy setting, etc.,
`is transported using a U-plane bearer. One of
`the foreseen applications was Open Mobile
`Alliance - Device Management (OMA-OM).
`Since OMA-OM is terminated between the UE
`and OMA-OM server within the operator's net(cid:173)
`work, the RAN node is unaware of the MDT
`measurements sent between the UE and OMA(cid:173)
`OM server.
`The conclusion of the study phase was that
`3GPP specification work is to be continued
`based on C-plane MDT architecture. The main
`reason was the visibility of the collected MDT
`measurements in the RAN node such that the
`MDT information can be used by the RAN itself
`to perform any automated network parameter
`optimization. In fact the work on MDT in 3GPP
`was closely related to the work item for Self(cid:173)
`Organizing Networks (SON) [4], to avoid any
`redundant features and to enable close inter(cid:173)
`working between the two features.
`Nevertheless, 3GPP noted that the informa-
`
`IEEE Communications Magazine • June 2012
`Authorized licensed use limijed to: West Virgn ia University. Downloaded on January 26,2021 at 02:02 36 UTC from EEE Xplore. Restrictions apply.
`Samsung Ex. 1008
`
`29
`
`

`

`The solutions
`dEVeloped in Rel-10
`focus on the
`Coverage
`Optimization use
`case that will benefit
`operators to design
`reliable coverage
`maps and
`consequently to
`detect coverage
`issues.
`
`OAM
`
`Signaling-based MDT
`
`HSS
`
`Signaling-based MDT
`
`Signaling-based MDT
`
`MD~~~:i~:~;e9Y ///
`conf1gurat7 m
`h
`Immediate MDT
`~ measurement report
`
`Management/
`area-based MDT
`
`MDT server
`(TCE)
`
`Immediate MDT
`measurement report
`Logged MDT
`measurement
`....==~.:..,_....:s......:,.__cr~eport
`
`rnd1cat,or»,
`-~
`
`ed MDT
`m~~urement
`retrieval procedure
`
`ogged MDT
`measurement
`configuration
`
`Logged data
`
`Lqi availability ti L
`1••••••• 1
`
`Connected state
`
`Idle state
`
`Connected state
`
`Figure 2. Overall MDT architecture.
`
`tion elements defined for MDT configuration
`and measurements in the C-plane architecture
`can be utilized by other protocols/specifications
`outside 3GPP, e.g., OMA-OM.
`REL-1 0 MDT ARCHITECTURE
`Figure 2 describes the overall MDT architecture
`defined in 3GPP R el- 10 for LTE. T he same
`architecture applies for both LTE and UMTS.
`Note that in the entire article, the terminology
`"RAN node" refers to "Evolved Node B (eNB),"
`i.e., base station in LTE, and " Radio Network
`Controller (RNC)," i.e ., radio resource con(cid:173)
`troller node in UMTS. The terminology "Core
`Network (CN) node" refers to "Mobility Man(cid:173)
`agement Entity (MME)" in LTE and "Serving
`General P acket Radio Service (SGS N)" or
`"Mobile services Switching Center (MSC)" in
`UMTS.
`MDT is always triggered by the network, i.e.,
`OAM decides the configuration of MDT param(cid:173)
`eters that need to be performed by the UE and
`sends these parameters to the RAN node for
`MDT activation. Upon reception of these MDT
`configuration parameters, the RAN node acti(cid:173)
`vates the MDT functionality in the UE by send(cid:173)
`ing the MDT configuration parameters to the
`UE. After the UE performs relevant measure(cid:173)
`ments, the UE reports the measurement results
`to the RAN node, which will then send these
`results to an MDT server, known as Trace Col(cid:173)
`lection Entity (TCE).
`For (inter-node) network signaling purposes,
`the existing Trace procedures (i.e., procedure for
`OAM to trace radio measurements in the RAN
`node defined in previous 3GPP Releases) were
`reused and extended for managing MDT mea(cid:173)
`surements and configuration [8]. For radio inter(cid:173)
`face signaling purposes, specific procedures and
`information elements were defined to support
`MDT configuration and reporting.
`
`F rom network signaling perspective, two
`types of MDT were defined [8]:
`Signaling-based MDT is used to collect mea(cid:173)
`surements from a certain/specific UE. The so(cid:173)
`called "signaling-based trace" feature [8] is used
`for managing signaling-based MDT.
`Management/area-based MDT is used to col(cid:173)
`lect measurements from randomly chosen UEs
`or a group of UEs that enter a ( certain) geo(cid:173)
`graphical area. In management/area-based MDT
`the so-called "management-based trace" or "cell
`trace" feature [8] is used to manage MDT.
`From radio configuration perspective, two
`types of MDT were defined [6]:
`Logged MIYf is a type of MDT where the UE
`stores the collected data for a certain period of
`time before the data is reported to the network.
`This type of MDT is performed when the UE is
`in idle state (i.e., the UE has no setup connec(cid:173)
`tion with the RAN node).
`Immediate MDT is a type of MDT where the
`UE promptly reports the collected data to the
`network. This type of MDT is performed when
`the UE is in active state (i.e., the UE has a setup
`connection with the RAN node).
`T he standard allows any combinations
`between the above MDT types. For example, the
`management/ area-based MDT can assign the
`UE to perform logged or immediate MDT, and
`the signaling-based MDT can be used also to
`assign the UE to perform logged or immediate
`MDT.
`
`MDT CONFIGURATION FROM
`OAM TO RAN
`SIGNALING-BASED MDT
`F igure 3 illustrates an example scenario how
`MDT is activated to the UE in signaling-based
`MDT [8].
`
`30
`
`IEEE Communications Magazine • June 2012
`Authorized licensed use limijed to: West Virgn ia University. Downloaded on January 26,2021 at 02:02 36 UTC from EEE Xplore. Restrictions apply.
`Samsung Ex. 1008
`
`

`

`UE
`
`RAN node
`
`CN node
`
`HSS
`
`OAM
`
`Idle state
`
`MDT activation
`(MDT configuration param ters)
`Storing MDT parameters
`
`User consent checking
`
`MDT confi uration a ameters
`
`Storing MDT parameters
`
`Call setup
`
`Active state
`
`MDT configuration pa ameters
`
`Storing MDT parameters
`
`M measurement confi uration
`
`Figure 3. Signaling-based MDT activation procedure.
`
`The MDT configura(cid:173)
`tion parameters are
`sent from the OAM
`direct}; to the RAN
`node, and the RAN
`node stores these
`parameters for later
`configuration
`towards UEs. This
`type of MDT is acti-
`vated typically in
`RAN nodes of a spe(cid:173)
`cific area, where the
`area is identified by a
`list of cells or paging
`location area
`identities.
`
`I n signaling-based MDT, UE selection is
`performed in the OAM based on a permanent
`UE identity, which uniquely identifies the UE
`in the network, such as International Mobile
`Subscriber Identity (IMSI) or International
`Mobile Equipment Identity and Software Ver(cid:173)
`sion (IMEi SY). From OAM the MDT configu(cid:173)
`ration parameters are sent to the H ome
`Subscriber Service (HSS), where decision is
`taken whether MDT can be activated for a UE,
`based on whether the corresponding end user
`has consented to contribute to MDT. The HSS
`performs MDT activation towards the relevant
`CN node, e.g., MME in case of LTE. This acti(cid:173)
`vation is typically done when the UE initially
`attaches to the network or updates its paging
`location area, but the MDT configuration
`parameters can be propagated also as a stan(cid:173)
`dalone procedure at any time. This activation
`of MDT from CN to RAN is performed when a
`call or session is established.
`
`MANAGEMENT/AREA-BASED MDT
`The procedure used for activating MDT in man(cid:173)
`agement/area-based MDT is shown in Fig. 4 [8].
`The MDT configuration parameters are sent
`from the OAM directly to the RAN node, and
`the RAN node stores these parameters for later
`configuration towards UEs. This type of MDT is
`activated typically in RAN nodes of a specific
`area, where the area is identified by a list of cells
`or paging location area identities.
`One of the differences between signaling(cid:173)
`based MDT and management/area-based MDT
`is how the UE selection is performed. In man(cid:173)
`agement/area-based MDT, selection of UEs to
`commit to MDT is done by the RAN node,
`based on the received parameters from OAM,
`UE radio capability, and the "MDT allowed
`flag" received from the CN node during call
`setup. This flag is set by the CN node based
`on the UE's roaming status and whether the
`corresponding end user has consented to par-
`
`ticipate in MDT. Roaming users and not-con(cid:173)
`sented users are excluded from any MDT cam(cid:173)
`paign.
`
`MDT CONFIGURATION FROM
`RAN TO UE
`LOGGED MDT
`In logged MDT, measurements are configured
`to the UE "in advance," i.e., the received MDT
`configuration is stored in the UE and becomes
`only valid when the UE releases the connection
`and enters idle state [6]. The logging operation
`itself is therefore performed by the UE in idle
`state. For the UE to log MDT measurements,
`the UE must be able to detect, track, and mea(cid:173)
`sure radio signals from base stations, i.e., the sig(cid:173)
`n al level has to be above the UE receiver
`sensitivity. Once the signal level from all cells
`has dropped below the minimum level for camp(cid:173)
`ing, the UE encounters a "coverage hole." To
`save the amount of data, the UE performs no
`logging while in a coverage hole. The UE sensi(cid:173)
`tivity would be inferior compared to specialized
`equipment in conventional drive tests, as such
`equipment is normally designed to have higher
`sensitivity and accuracy in measuring low level
`signals. However, in MDT the UE has the ability
`to log measurements for a period of 10 s in LTE
`( or 12 s in UMTS) from the time the UE enters
`a coverage hole.
`By statistically analyzing these measurement
`logs, an operator can detect nearly where the
`coverage hole is. Such information would also
`provide a hint how to improve coverage, e.g.,
`which base stations need parameter adjustments
`and which base stations would become neighbors
`if a new base station is placed on the dark spot.
`If the operator has other carrier frequencies or
`systems that cover the area, handover thresholds
`can be adjusted such that inter-frequency or
`inter-system handover can be triggered before
`
`IEEE Communications Magazine • June 2012
`Authorized licensed use limijed to: West Virgn ia University. Downloaded on January 26.2021 at 02:02 36 UTC from EEE Xplore. Restrictions apply.
`Samsung Ex. 1008
`
`31
`
`

`

`The RAN node is not
`required to retrieve
`the logged data
`direct}; after the log
`availability is received
`from the UE. The
`RAN node can h iti(cid:173)
`ate data retrieval at
`any time while the
`UE is connected.
`Hence, the UE is
`required to keep the
`non-retrieved report
`for 48 hours from
`the moment the log(cid:173)
`gh g duration timer
`expires.
`
`UE
`
`RAN node
`
`CN node
`
`HSS
`
`OAM
`
`Act ive state
`
`MDT activat ion
`(MD configurat ion parame ers)
`
`Storing MDT parameters
`
`Call setup
`
`Context setup
`(MDT conf urat ion parameters, M T allowed bit)
`
`UE selection
`
`M measurement conf guration
`
`Figure 4. Management/area-based MDT activation procedure.
`
`the UE enters the coverage hole . The logged
`measurements would allow the operator to
`decide which base stations need such parameter
`tuning.
`The overall principle of logged MDT opera(cid:173)
`tion is illustrated in Fig. 5. The measurement
`configuration for logged MDT sent from the
`RAN node to the UE is created based on the
`MDT configuration parameters received from
`OAM (7, 8]. The followings are the configura(cid:173)
`tion parameters:
`• Logging interval which defines the periodic(cid:173)
`ity of the measurements that should be
`logged
`• Logging duration which determines how
`long the logged MDT configuration is valid
`• Trace Reference which identifies the Trace
`Session used for the MDT
`• Trace Recording Session Reference which is
`used together with the Trace Reference for
`correlating the collected log data of an
`MDT session and the UE
`• TCE ID identifies the TCE to where the
`MDT measurements should be sent. T his
`parameter is sent back by the UE within
`the log data to the network.
`T he measurement results are tagged with
`available location information, i.e., location
`information that happened to have been
`acquired by the UE at the time of measure(cid:173)
`ment.
`The UE stores the received configuration
`regardless of a state change (idle to active
`and vice versa) within the logging duration
`timer . T his applies also for a change of
`camped operator network, i.e ., P ublic Land
`Mobile Network (PLMN) and R AT (i .e .,
`LTE and UMTS) . In case of PLMN, RAT or
`state change, the logging by the UE is sus(cid:173)
`pended. Effectively, logged MDT will resume
`when the UE returns to idle state or comes
`back to the RAT that configured MDT. T he
`UE maintains only one logged MDT configu-
`
`ration (i.e ., one MDT context) at a time .
`Thus, if other RAT or PLMN provides a new
`logged MDT configuration to the UE , the
`UE overwrites the previously received con(cid:173)
`figuration .
`T he UE reports the logged data upon
`request from the network. T he R AN node
`requests reporting based on indication from
`the UE, upon connection establishment, of
`the availability of logged data. The RAN node
`is not required to retrieve the logged data
`directly after the log availability is received
`from the UE. The RAN node can initiate data
`retrieval at any time while the UE is connect(cid:173)
`ed . Hence, the UE is required to keep the
`non- retrieved report for 48 hours from the
`moment the logging duration timer expires.
`The 48-hour timer can also be started when
`the logged data volume exceeds the available
`storage space in the UE reserved for MDT
`purposes. A UE supporting Rel-10 MDT is
`equipped with a minimum of 64 kB memory
`for log storage.
`With this reporting mechanism, the amount
`of signaling is reduced compared to immediate
`MDT, as the UE reports all logs in one report.
`However, logged MDT requires additional mem(cid:173)
`ory for log storage and specific procedures for
`log reporting.
`
`IMMEDIATE MDT
`Immediate MDT utilizes procedures defined for
`RRM in previous 3GPP Releases to a great
`extent. The RAN node translates the MDT con(cid:173)
`figuration parameters received from the
`OAM/CN node into RRM measurement config(cid:173)
`uration before sending to the UE (7, 8] . T he
`main change introduced for immediate MDT
`was the configuration and reporting of location
`information. The followings are the configura(cid:173)
`tion parameters:
`• List of measurements which identifies what
`measurements the UE should collect
`
`32
`
`IEEE Communications Magazine • June 2012
`Authorized licensed use limijed to: West Virgn ia University. Downloaded on January 26,2021 at 02:02 36 UTC from EEE Xplore. Restrictions apply.
`Samsung Ex. 1008
`
`

`

`• Reporting Trigger which determines
`whether periodical or event based reporting
`is requested
`• Re1>ort interval which defines the interval of
`periodical measurements
`• Report amount which indicates the number
`of measurement reports to be sent with
`periodical measurements
`• Event tbresbolcl indicates the threshold
`(against signal quality) for event based
`reporting
`in
`present
`if
`• Area
`sco pe
`management/ area-based MDT, this indi(cid:173)
`cates to the RAN node in which cells MDT
`should be activated; if present in signaling(cid:173)
`based MDT, this indicates that the mea(cid:173)
`surement configuration is sent to the
`selected UE only if it is connected in the
`cell which is part of the area scope.
`Unlike logged MDT, the TCE ID, Trace Ref(cid:173)
`erence and Trace Recording Session Reference
`parameters are not sent to the UE, since those
`are already known by the network and the UE
`has continuous connection with the network.
`Once the UE receives the configuration, the
`UE applies it immediately and starts sending
`measurement reports when the reporting condi(cid:173)
`tions are met. Based on the conventional mea(cid:173)
`surement capabilities for RRM, two reporting
`triggers have been identified for MDT purposes:
`Event A2 (i.e., the quality of serving cell
`becomes less than a threshold) and periodical
`reporting. The overall principle of immediate
`MDT operation in RAN is illustrated in Fig. 6.
`With immediate MDT the UE may also send
`separate reports on connection failures ( e.g.,
`radio link failures or handover failures). Such
`Radio Link Failure (RLF) reporting requires no
`prior configuration. That is, a UE supporting the
`feature autonomously collects data related to the
`failure and sends them to the network upon
`request after recovery. The data consist of radio
`measurement results available at the time of
`connection failure, tagged by available location
`information and identification of cells involved
`in the event. Reporting is performed in a similar
`way to logged MDT, i.e., the UE indicates first
`the availability of an RLF report after successful
`connection recovery, upon which the RLF report
`can be retrieved by the RAN node.
`
`HANDLING OF
`MDT CONFIGURATION UPON HANDOVER
`
`In general, MDT does not introduce additional
`requirements for UE measurements handling
`during handover. In signaling-based MDT, since
`the purpose is to collect measurements from a
`particular UE, the MDT configuration and
`reporting are continued during and after han(cid:173)
`dover. MDT configuration is transferred from
`the handover source RAN node to the target
`RAN node, as the target RAN node also needs
`to be aware of what measurements are being
`continued in the UE, so that any further recon(cid:173)
`figurations can be performed as necessary. In
`contrast, in management/ area- based MDT,
`since the purpose is to collect measurements in a
`certain area, the configuration and measure(cid:173)
`ments do not continue upon handover.
`
`UE
`
`RAN node
`
`Active state
`
`Logged MDT measurement configuration
`
`Log availability indication
`
`Logged measurement request
`
`Logged measurement report
`
`Figure 5. Logged MDT configuration and reporting.
`
`LOCATION INFORMATION FOR MDT
`PRINCIPLES OF
`LOCATION INFORMATION IN MDT
`
`Inclusion of location information in MDT
`reports is essential in MDT. Location informa(cid:173)
`tion for MDT can be categorized into the fol (cid:173)
`lowings:
`Detailed location information is geographical
`location information which at least consists of
`latitude and longitude. This type of location
`information gives the exact geographical point of
`the earth where the radio measurement sample
`was taken (subject to the positioning method
`accuracy). Detailed location information is typi(cid:173)
`cally obtained by GPS or Global Navigation
`Satellite System (GNSS) positioning method, but
`can also be obtained by other positioning meth(cid:173)
`ods supported by the UE and the network, e.g.,
`Observed Time Difference of Arrival (OTDOA),
`Assisted -GNSS (Assisted-GPS), Enhanced Cell
`ID (E-CID) or even Secure User-Plane Location
`(SUPL).
`RF fingerprint refers to the profile of mea(cid:173)
`sured quality of signals from the neighboring
`cells. This information can be used by the net(cid:173)
`work to calculate the approximate location of
`the UE by means of e.g., triangulation of the
`geographical location of the cell or the base sta(cid:173)
`tion.
`Io Rel-10 MDT, inclusion of detailed location
`information is based on 'best effort', i.e., includ(cid:173)
`ed only if it happens to be available in the UE at
`the time when the UE performs radio measure(cid:173)
`ments. Its availability depends on the ongoing
`location services, e.g., map application and loca(cid:173)
`tion search application, which are independent
`from MDT control.
`The main benefit of this best effort approach
`
`IEEE Communications Magazine • June 2012
`Authorized licensed use limijed to: West Virgn ia University. Downloaded on January 26,2021 at 02:02 36 UTC from EEE Xplore. Restrictions apply.
`Samsung Ex. 1008
`
`33
`
`

`

`UE
`
`RAN node
`
`Active st at e
`
`Immediate M DT measurement configuration
`(using RRM procedure)
`
`Immediate M DT measurement configuration
`acknowledgement (using RRM procedure)
`
`Reporting trigger (event/
`report int erval) met
`
`Measurement report
`
`Figure 6. Immediate MDT configuration and reporting.
`
`is limited UE impact. No additional battery con(cid:173)
`sumption nor additional processing is incurred,
`since the UE does not need to start any posi(cid:173)
`tioning function to obtain its detailed location
`when an MDT measurement is taken. The speci(cid:173)
`fications were intentionally defined as such to
`lower the hurdle for implementing MDT fea(cid:173)
`tures in the UE, as MDT is more useful in the
`initial phases of network deployment and the
`number of participating UEs is essential to
`achieve reliability. However, this has created
`some disadvantages for MDT as a system, since
`not every MDT measurement sample is associat(cid:173)
`ed with detailed location information, and not
`all location information associated to MDT sam(cid:173)
`ples are accurate enough to point the exact loca(cid:173)
`tion where the sample was taken.
`In this approach, validity of the location
`information becomes an important factor. To
`decide whether the obtained location informa(cid:173)
`tion is valid for reliable use, a network operator
`needs to carefully consider the time difference
`between when the location information was
`obtained and when the radio measurement was
`obtained.
`LOCATION INFORMATION FOR LOGGED MDT
`For logged MDT, standalone GNSS/GPS posi(cid:173)
`tioning is the only realistic method to obtain
`detailed location information, since the UE has
`no connection in idle state. The location infor(cid:173)
`mation is included to a measurement sample if
`the location information is taken within the con(cid:173)
`figured logging interval. This condition is illus(cid:173)
`trated in Fig. 7.
`The detailed location information taken with(cid:173)
`in a logging interval N is included as part of an
`MDT measurement sample n. T hen, this loca(cid:173)
`tion information is discarded. In other words
`validity of the location information is equal to
`the logging interval.
`LOCATION INFORMATION FOR IMMEDIATE MDT
`For immediate MDT, as explained earlier, event
`triggers (i.e., Event A2) can be used to collect
`
`measurements. Since there is no 'interval'
`defined for this kind of triggers, unlike logged
`MDT, the reporting interval cannot be used as
`guidance for assessing the validity of detailed
`location information. To address this problem,
`the GPS timestamp (if available) can also be
`reported as part of location information. With
`the assumption that the network is also aware of
`the GPS timing, the network can judge the valid(cid:173)
`ity by comparing the GPS timestamp from the
`UE to the G PS timestamp maintained in the
`network. The same mechanism also applies to
`periodical reporting.
`
`SECURITY ASPECT OF MDT
`Security aspects of MDT can be classified into
`the user perspective and the operator network
`perspective.
`From the user perspective, a user might not
`want his/her handset to be used for MDT pur(cid:173)
`poses due to various reasons, e.g., not willing to
`reveal its location. The MDT mechanism speci(cid:173)
`fied in 3GPP provides the following security pro(cid:173)
`tection
`towards
`the user: user data
`confidentiality, user data anonymity and privacy,
`and consent-based MDT activation.
`Confidentiality of user data is achieved by
`sending the MDT related signaling using integri(cid:173)
`ty protected protocols, both in radio interface
`and network interface. Data anonymity and pri(cid:173)
`vacy is achieved by assuring that the collected
`data cannot be linked to a real user identity, e.g.,
`IMSI. Thus, the CN node is forbidden to send
`any user identity, e.g., IMSI, to the TCE.
`To address the user consent requirement, a
`mechanism is adopted to ascertain that the oper(cid:173)
`ator can only utilize the UE of those users who
`have given their consent. This consent for MDT
`can be part of user subscription and can be
`revoked anytime by the user. For signaling-based
`MDT, th