Patent Description:
3GPP document TS <NUM> v16. <NUM> describes aspects of EUTRA and RRC protocal specifications.

The present invention provides a method of wireless communication executed by a user equipment according to independent claim <NUM>, a user equipment according to independent claim <NUM>, a method of wireless communication executed by a base station according to independent claim <NUM> and a base station according to independent claim <NUM>.

Minimization of Drive Tests (MDT) measurements may be configured by a network and performed by a UE. Applicants have observed that, responsive to a base station request, all configured test results have been conventionally sent to the network via an RRC connection as part of one measurement report file from the UE. Applicants have also observed that, as new measurement types have been continuously added over the years, the size of this data file has increased dramatically. Applicants have also observed that, due to the current eight kilobyte maximum RRC transfer capability, this file is segmented into multiple RRC messages. Applicants have further observed that, transferring such a large file from the UE to the network can quickly drain the UE battery power. Moreover, Applicants have observed that, the RRC signaling overhead incurred by the segmenting also places an added strain on UE and network resources. In addition, Applicants have observed that the network core must filter the large data file to extract the different measurement results for forwarding to the different entities that need particular MDT measurement results.

Some of the techniques described herein may help reduce or eliminate these problems. For example, one technique may include logging MDT measurement reports at the UE as a plurality of single files, each file based on a corresponding MDT measurement type. The UE may receive a network request for structured MDT data, including, for example, a measurement report that is circumscribed to the specific types MDT measurement type(s) needed by the network at the time of request, rather than requesting a single data file that includes all measurements as is conventionally performed. Responsive to the network's request, the data corresponding to only to the requested measurement type(s) may be sent to the network. The structured nature of the data is broadly intended to take any of several forms. For example, the structured MDT data may simply be organized in an easily-recognizable or network friendly manner. In one exemplary configuration, the data can be structured such that the base station (or other network entity) can readily identify the MDT measurement type(s), e.g., without having to segment a large amount of data corresponding to all the different MDT measurements into their constituent types, for example. In other configurations, the structured data may optionally represent a protocol or format by the receiving network for enabling fast and easy retrieval and analyses of one or more individual MDT measurement types from a larger group of such types. However, this need not be the case, and the structured MDT data need not correspond to a defined format or protocol. As another example, in some configurations, the structured MDT data may simply refer to data representing the MDT measurement(s) requested by the network. The MDT measurement data may optionally include a structured report with results corresponding to at least one measurement type specified by the base station from a larger plurality of available measurements that can be performed by the UE. Further, in lieu of performing a single, large file transfer to send all the data to the base station at one time, the data specific to the requested measurement type may be sent to the base station. The UE may send the data as a single file in a structured report or as part of a single, non-real time data stream to the base station. UE battery power and network bandwidth consumption can be reduced as a result. Further, the tailored nature of the data sent to the base station responsive to the base station's request may reduce, if not altogether eliminate, the need for RRC segmentation. That is to say, since only the specific, structured MDT measurement data identified in the network request is sent at a time, the requirement for filtering the received data by the network can be reduced or eliminated altogether, depending on the circumstances.

By way of example, where a "processor" is referenced in this disclosure, the processor is deemed to include one or more processors.

The base stations <NUM> / UEs <NUM> may use spectrum up to YMHz (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, etc. MHz) bandwidth per carrier allocated in a carrier aggregation of up to a total of Yx MHz (x component carriers) used for transmission in each direction.

The electromagnetic spectrum is often subdivided, based on frequency/wavelength, into various classes, bands, channels, etc. In 5GNR, two initial operating bands have been identified as frequency range designations FR1 (<NUM> - <NUM>) and FR2 (<NUM> - <NUM>).

Referring again to <FIG>, in certain aspects, the base station <NUM> may include an MDT measurement & processing component <NUM>. The base station <NUM> may use component <NUM> during an RRC connection to configure a UE <NUM> to perform various types of MDT measurements (including providing measurement intervals and a measurement duration), to log the data into measurement reports to be received from a UE <NUM> pertaining to various MDT measurement types, and to receive the measurement reports and forward them to the core network for distributing to the appropriate entity. These measurement types may include, for example, serving/neighbor cell measurements, Multimedia Broadcast/Multicast service Single Frequency Network (MBSFN) measurements, wireless LAN (WLAN) measurements, Bluetooth measurements, location measurements, etc. Component <NUM> may also be configured to perform other actions involving the MDT measurement reports, including processing MDT information, making requests for different measurement reports such as MDT measurement type requests, and sending and receiving information concerning MDT activities and measurement reports to and from the UEs <NUM>, other base stations <NUM>/<NUM>, the core network <NUM>, and other network entities/clients that may require the data relevant to specific UE measurement types. In one configuration, component <NUM> is configured to include, in a measurement type request, an indication that the base station supports receiving MDT measurement data in data streams.

The UE <NUM> may include an MDT data transmission component <NUM>(<NUM>) and an MDT measurement component <NUM>(<NUM>). The MDT measurement component <NUM>(<NUM>) of the UE <NUM> may be configured to receive configuration information, including measurement intervals and a measurement duration, from the base station <NUM> during an RRC connection for subsequently performing MDT measurements during a UE idle state. The MDT component <NUM>(<NUM>) may further be configured to perform the different MDT measurements configured previously by the base station <NUM>. The MDT component <NUM>(<NUM>) may be configured to perform these measurements during the specified measurement intervals and over the length of the MDT measurement duration. After the measurements, when the RRC connection is released, the UE <NUM> enters the idle state. The MDT component <NUM>(<NUM>) may further be configured to log the measurement data, including storing information corresponding to different types of measurements, into different respective data files, for example.

The MDT data transmission component <NUM>(<NUM>) may be configured to receive MDT measurement type requests from the base station <NUM> during an RRC connection that occurs subsequent to performing the measurements. The MDT data transmission component <NUM>(<NUM>) may be configured to receive an indication in the measurement type request that the base station supports, or is capable of, receiving MDT data in the requested. Responsive to this type of request, component <NUM>(<NUM>) may be configured to send a structured measurement report as one or more files or as a non-real time data stream to the base station <NUM> which includes measurement data corresponding to the specific type of measurement identified in the MDT measurement type request from the larger group of available MDT measurements. Component <NUM>(<NUM>) may also be configured, in the case where the base station identifies in the MDT measurement type request more than one type of MDT measurement, to send during successive time periods different time periods. MDT data transmission component <NUM>(<NUM>) may also be configured for performing other MDT-related functions.

The MDT measurement & processing component <NUM>, MDT data transmission component <NUM>(<NUM>) and MDT measurement component <NUM>(<NUM>) may be implemented, in part or in whole, as software stored in memory and executed on one or more general purpose or specialized processors. Alternatively, these components <NUM>(<NUM>), <NUM>(<NUM>) and <NUM> may be implemented, in part or in whole, in firmware, or as hardware including one or more digital signal processors (DSPs), gate arrays, SoCs, digital logic circuits, application specific integrated circuits (ASICs), and the like.

Although the following description may be focused on MDT measurement reports, the concepts described herein may be applicable to other similar areas, such as other types of network measurements, including signal-strength and round-trip time (RTT) measurements, for example. Further, although the following description may be focused on <NUM> NR, the concepts described herein may be applicable to other similar areas, such as LTE, LTE-A, CDMA, GSM, and other wireless technologies.

In the examples provided by <FIG>, the <NUM> NR frame structure is assumed to be TDD, with subframe <NUM> being configured with slot format <NUM> (with mostly DL), where D is DL, U is UL, and F is flexible for use between DL/UL, and subframe <NUM> being configured with slot format <NUM> (with mostly UL).

For slot configuration <NUM>, different numerologies µ <NUM> to <NUM> allow for <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> slots, respectively, per subframe. <FIG> provide an example of slot configuration <NUM> with <NUM> symbols per slot and numerology µ=<NUM> with <NUM> slots per subframe. The slot duration is <NUM>, the subcarrier spacing is <NUM>, and the symbol duration is approximately <NUM>. Within a set of frames, there may be one or more different bandwidth parts (BWPs) (see <FIG>) that are frequency division multiplexed. Each BWP may have a particular numerology.

A PDCCH within one BWP may be referred to as a control resource set (CORESET). Additional BWPs may be located at greater and/or lower frequencies across the channel bandwidth. The physical broadcast channel (PBCH), which carries a master information block (MIB), may be logically grouped with the PSS and SSS to form a synchronization signal (SS)/PBCH block (also referred to as SS block (SSB)).

At least one of the TX processor <NUM>, the RX processor <NUM>, and the controller/processor <NUM> may be configured to perform aspects in connection with <NUM>(<NUM>) and <NUM>(<NUM>) of <FIG>. Similarly, at least one of the TX processor <NUM>, the RX processor <NUM>, and the controller/processor <NUM> may be configured to perform aspects in connection with MDT measurement & processing component <NUM> of <FIG>. Alternatively, in some configuration as shown in <FIG>, any portion or each of MDT measurement & processing component <NUM>, MDT data transmission component <NUM>(<NUM>) and MDT measurement component <NUM>(<NUM>) may be configured, in part or in whole, as one or more special-purpose processors, or in other hardware implementations, e.g., those described with reference to <FIG>.

Current implementations of the MDT measurements are configured by the base station, performed and logged by the UE, and transmitted to the base station as a single data file including measurement report data for all of the configured measurement types. Upon the base station's request for the measurement report, the UE proceeds to transfer the single file to the base station.

This conventional limitation introduces increasingly intolerable limitations into the respective LTE and <NUM>-NR architectures. Over the past several years beginning at release <NUM> of the relevant 3GPP standard up to and including release <NUM>, a number of new measurement types have been added to the MDT measurement-reporting scheme. Because all measurement results for all measurement types are transmitted by the UE back to the network as a single, very large file, the growing number of measurements requested by the network has naturally resulted in a measurement report that is much larger than when the initial specification was first promulgated. When this file is transmitted back to the base station responsive to the base station's information request, the file transfer drains UE battery life while introducing additional network bandwidth impositions and straining network resources.

A further shortcoming of the current approach relates to the nature of the radio resource control (RRC) connection, which currently can transfer messages with a maximum size of eight (<NUM>) kilobytes. Because the UE's MDT measurement report can be hundreds of kilobytes to several megabytes or more (depending in part on the number of measurements stored on the file and the amount of data generated by those measurements during the specified intervals), the single file must be segmented into a number of smaller <NUM> KB data segments and reconstructed at the recipient side. Among other problems, this partitioning leads to an undesirable imposition of network processing resources, with back to back RRC signaling overhead occupying an appreciable portion of the data transfer.

In addition, the single file must be filtered by the core network to partition the file into a plurality of files such that each partitioned file includes only the data pertaining to one measurement type. This filtering is necessary because different types of measurement information may be needed by different clients or other network entities. Only after the filtering process can the data can be forwarded to the necessary client.

To this end, <FIG> is a conceptual diagram <NUM> illustrating an example of a UE <NUM> establishing an RRC connection with a base station (eNB <NUM>) and the base station forwarding measurement data to an Operations & Management (operations, administration and management/maintenance) facility <NUM>. Responsive to a base station <NUM> request, UE <NUM> transfers the MDT measurement report as a large file over the established RRC connection <NUM>. The UE <NUM> may include with the reported MDT data one or more parameters from the UE's memory (such as a trace reference, trace recording session, or trace collection entity (TCE) identifier, for example). The base station <NUM>, which may be an eNB, gNB, or other type of base station enumerated above, may receive and reconstruct the file. The base station <NUM> may then extract the one or more parameters to correlate the data at the TCE that belongs to the same trace (MDT session). The base station <NUM> may use the TCE ID to obtain the IP address of the TCE, which in turn identifies where the MDT data should be forwarded.

Referring still to <FIG>, the base station <NUM> may establish an O&M connection <NUM> to O&M entity <NUM>, which can be an entity of the core network that performs the filtering of the measurement data by type. That data can finally be passed to the correct network entities as described above.

<FIG> is a timing diagram <NUM> illustrating an example of logged MDT reporting procedure between a UE <NUM> and a network including a base station <NUM> and a TCE <NUM>. An RRC connection may be established at <NUM>. Thereupon, at <NUM>, a logged measurement configuration may be performed in which the base station <NUM> sends one or more messages to the UE <NUM> specifying all of the types of MDT measurement that the UE <NUM> should perform, the measurement intervals for each of the measurements, and the overall MDT measurement duration (see, e.g., block <NUM>). Thus, via this signaling <NUM>, the base station <NUM> may configure the UE <NUM> to perform each MDT measurement required by the network.

After the MDT measurements are configured, when the RRC connection is released at <NUM>, the UE <NUM> may enter the idle state. During the idle state, the UE <NUM> may perform the measurements and log the results as configured by the base station <NUM>. For example, the UE <NUM> may perform an MDT measurement at each logging interval until a logging duration timer is expired, after which the UE <NUM> may perform an MDT measurement for another interval. For example, if the logging duration is ten minutes and the logging interval is <NUM> milliseconds (ms), then during each <NUM> interval one MDT measurement may be performed and the interval may be repeated for ten minutes. After all the measurements are performed, a large amount of data corresponding to all of the measurement reports is ready to be sent.

Next, another RRC connection may be established and completed at <NUM> and <NUM>. During the RRC connection setup, the UE <NUM> may optionally provide an indication to the base station <NUM> that the measurement logging is complete. At <NUM>, the base station <NUM> sends a UE information request to the UE <NUM> asking the UE <NUM> to send the MDT measurement report. Notably, in the signal <NUM>, the base station may request the report without specifying measurement types, as is conventional. In response to the UE information request <NUM>, the UE <NUM> may send a UE information response <NUM> in which the single MDT measurement report is transferred as a single large file and segmented as necessary for each of the (currently <NUM> KB max) RRC blocks. The multiple RRC segmented messages may be sent as discussed above, including all the signaling overhead and the attendant UE battery drain, consuming network time until the file transfer is finally complete - only to await the next transfer by the base station <NUM> and further filtering step by the network.

At <NUM>, the base station <NUM> may obtain the TCE's address from the TCE ID, as described above. After sending to the TCE <NUM> an MDT file ready notification <NUM>, the base station <NUM> may proceed to transfer the MDT file to the TCE <NUM> at <NUM>, where the file may be further forwarded to the network core or portions thereof as necessary to filter the file and provide the individual measurement results to the correct entities.

<FIG> is a timing diagram <NUM> illustrating an example of logged MDT reporting including sending or non-real time streaming a requested type of measurement report from the UE <NUM> to the network including base station <NUM> and TCE <NUM> according to the main embodiment of the invention. As before, an RRC connection establishment process may be initiated (<NUM>). At <NUM>, the network may issue a UE capability inquiry <NUM>. The UE may respond with a UE capability information message <NUM>, inside of which a new bit may be included to indicate UE capability for streaming Logged MDT for MDT measurement type requests. While the non-real time streaming may be used, this feature is optional and the data may be transmitted as a structured file or otherwise in any manner over the network. As described in block <NUM>, the UE capable signal <NUM> can alternatively be included elsewhere, for example in with the subsequent RRC connection establishment and setup signal exchanges <NUM> and <NUM>, and it need not be included in the current RRC connection. In some configurations, the base station <NUM> is already aware of the capability and it need not be explicitly conveyed by the UE <NUM>. Thereupon, at <NUM> the RRC connection can be validated and completed. At <NUM>, the base station signals the UE <NUM> and issues an indication of the measurement types the network requires, and the measurement duration and intervals, as in <FIG>.

At <NUM>, the RRC connection can be released, and the UE <NUM> may enter into an idle state. At <NUM>, the UE <NUM> commences logging, and the UE <NUM> stores and accumulates MDT measurement results within its memory pertaining to the measurements configured in <NUM> by the base station <NUM>. In various implementations, in lieu of storing all of the measurement data in one file, the UE <NUM> may store data corresponding to a single type of measurement result in one corresponding file, and the UE <NUM> may store data corresponding to another type of measurement result in another file, and so on for the remaining measurement intervals in the specified duration.

At <NUM>, another RRC connection may be established. At <NUM>, the UE <NUM> may indicate that the connection setup is complete, and in so doing, the UE <NUM> may indicate to the base station <NUM> that the MDT measurement results are ready. In one aspect of the disclosure, the base station <NUM> performs an MDT measurement type request at <NUM>. In lieu of requesting the entire MDT measurement report as in request <NUM> of <FIG>, the base station <NUM> in <FIG> requests data corresponding to the type of measurement required by the network at the time of the request. The MDT measurement type request of the claimed embodiment includes an indication that the base station is "data stream capable", that is to say, the base station supports the capability of receiving non-real time measurement-type specific data streams in lieu of the conventional all-enveloping data file transfer. As noted above, the non-real time streaming need not be used and the data may be sent, e.g., over a control plane using conventional transmission techniques.

At <NUM>, the UE <NUM> may optionally send a not ready / not capable indication <NUM> to the base station <NUM>, in which case the devices may fall back to the legacy technique or in some configurations, the devices may omit the MDT exchange altogether. Otherwise, in one implementation, the UE <NUM> responds by sending a non-real time data stream or by sending directly data <NUM> corresponding only to the measurement report data for the type of measurement requested by the base station <NUM>.

In various configurations, the base station <NUM> may in the MDT measurement type request <NUM> send a request for two or more MDT measurements required by the network at the time of the request. Here, the UE <NUM> sends the relevant measurement reports sequentially, with data corresponding to one type of measurement at a time. Thus in this case, at <NUM>, the UE <NUM> may respond by sending first data that includes data corresponding to a first type of requested measurement, and thereafter second data that includes data corresponding to a second type of requested measurement, and so on until data is sent for all the types of measurements that were requested by the base station <NUM> in request <NUM>.

In various configurations, the base station <NUM> may in step <NUM> make a request for a structured measurement report specific to one MDT measurement type (as above), in response to which the UE <NUM> may send the data including a report with results for that measurement report. At some later time, when the network informs the base station <NUM> that the information is necessary, for example, the base station <NUM> may make another MDT measurement type request for data corresponding to another type of MDT measurement, in response to which the UE <NUM> may respond by sending the data corresponding to that MDT measurement type at <NUM>. At various stages during the same or different RRC connections at subsequent times, the base station <NUM> may issue yet additional MDT measurement type requests <NUM> in which data corresponding to other measurement types is requested. Thus the requests in these implementations can be made in a sequential manner for one or more data types, and that data is requested and sent only when the data is needed by the network in a structured manner, rather than being arbitrarily sent as one big measurement report.

After the measurement report corresponding to the requested measurement type(s) is received by the base station <NUM>, the base station <NUM> may obtain a TCE address from the TCE ID sent with the data (<NUM>). The base station <NUM> may notify the TCE entity <NUM> of the anticipated transfer at <NUM> and thereafter the base station <NUM> may transfer the MDT data to the TCE <NUM> at <NUM>, and the data may be forwarded to the entity that requires the information.

The technique of <FIG> has several benefits to both the UE <NUM> and the network. Because each measurement report can be transmitted to the base station as a single type of measurement data or corresponding result, the requirement of filtering the data by the network may be obviated or reduced, and instead the data can be directly sent to the network entity that needs it. Further, because the data can optionally be sent in non-real time streams by the UE <NUM> depending on the type of MDT measurement, the streams are typically much smaller, and may not exceed the RRC maximum data size, meaning that the requirement to segment the data into <NUM> KB chunks is reduced or eliminated. This in turn can minimize the amount of RRC signaling overhead required by the network, since different data segments do not have to be managed with corresponding RRC control information. Further, because each measurement report for a single type of MDT measurement may correspond to a single non-real time data stream (or the data is simply transmitted using conventional techniques), bandwidth and network resources are conserved. This technique also eliminates the conventional problems associated with UE battery drain, since the files streamed are substantially smaller and the UE battery power status can be revisited, if necessary, following the successful transmission of a single data stream.

While only the data logged for a requested type of measurement is sent, the UE performs and logs all measurements configured by the base station as before. Therefore, the UE keeps this information at its disposal, and it can be made incumbent on the network to determine what types of MDT data are needed and when, rather than the UE (which has far more limited processing resources compared with the network), to have to track this information. The network can issue MDT measurement type requests corresponding to the information it needs, and the UE can send that information as a data report formatted to be responsive to the base station's specific MDT requests, for example. The remaining measurement reports can be preserved in UE unless and until that information is needed.

<FIG> is a flowchart <NUM> of a method of wireless communication according to the main embodiment of the invention. At step <NUM>, a UE (such as the UE <NUM>, <NUM> or <NUM> of <FIG>, <FIG> or <FIG>, respectively) may receive configurations from a base station (such as the base station <NUM>/<NUM>, <NUM>, or <NUM> of <FIG>, <FIG> or <FIG>, respectively) receives configurations for a plurality of different MDT measurement types from a base station. This information may specify the measurement intervals and duration. These measurement types may typically represent all of the different measurement types for which the network anticipates needing data over a subsequent period of time. At step <NUM>, the UE may optionally send a message to the base station that the UE supports the capability of sending one non-real time stream of measured MDT data for one measurement type. In other configurations, the data may be transmitted directly, without using MDT streaming. As noted above, this information may be included elsewhere in the process flow, and in some configurations it may already be understood.

Next, at step <NUM>, the UE can make or perform, during an ensuing idle period of the UE, the corresponding plurality of MDT measurements specified by the base station in step <NUM>. At step <NUM>, which may be performed concurrently with the procedures of step <NUM>, the UE may log these measurements during respective intervals by saving data obtained from each of the measurements in a separate file. The UE may perform measurements for all configured measurement types up to the total specified measurement duration.

At step <NUM>, the UE receives, from the base station, a request for structured minimization of driving test (MDT) data, the requested data corresponding to at least one type of MDT measurement specified by the base station from a larger plurality of available MDT measurement types that can be performed by the UE. For example, in some embodiments, the UE may receive, from a base station during a period such as during a subsequent RRC connection, a request for MDT data specifying a report for at least one type of MDT measurement from a larger number of MDT measurement types. Responsive to step <NUM>, the UE sends the data including results corresponding to the specified at least one type of MDT measurement to the base station at step <NUM>. For example, the UE sends at step <NUM> a report with the requested measurement type to the base station. If data corresponding to more than one type of measurement was requested by the base station, the UE may successively send one or more non-real time data streams or other transmissions corresponding to those one or more additional requested measurement types, one data stream at a time until all streams are transmitted and the base station successfully receives them.

The base station includes in the message of step <NUM> an indication that it supports receiving MDT streams. In other configurations, the base station may provide this information at an earlier time.

If, during some specified time of network operation, for example, there are no further MDT measurement type requests from the base station (step <NUM>), then the process can end <NUM> at least until another such request is made or the UE receives another configuration. If, however, at step <NUM> the UE receives another request for data corresponding to another type (or other types) of MDT measurements required by the network, the UE again may send one non-real time data stream corresponding to one measurement type, then another data stream corresponding to another measurement type if applicable, and so on until the data is provided to the base station.

<FIG> is a flowchart of a method of wireless communication according to the main embodiment of the invention from the perspective of the base station (such as the base station identified in <FIG>, <FIG>, <FIG> or <FIG>, described above, for example). At step <NUM>, the base station may transmit to a UE (such as the UE identified in <FIG>, <FIG>, <FIG> or <FIG>, described above) during an RRC connection MDT measurement configurations for a plurality of MDT measurements to be performed and logged by the UE. Subsequently, upon receiving a notification from the UE that the configured measurements were logged, for example, the base station at step <NUM> sends a request to a UE for structured minimization of driving test (MDT) data, the requested MDT data corresponding to at least one type of MDT measurement specified by the base station from a larger plurality of available MDT measurement types that can be performed by the UE. For instance, in some embodiments, the base station may send a structured MDT measurement type request to the UE for a type of MDT measurement data during another RRC connection. The MDT measurement type request includes a data bit or other indication that the base station supports receiving the MDT information in a measurement-type specific data stream.

Responsive to the request (<NUM>), the base station at step <NUM> receives the data including results corresponding to the specified at least one type of MDT measurement from the UE. For instance, in some embodiments, the base station may receive from the UE a non-real time data stream or other type of transmission corresponding to the requested type of measurement. If the base station identified multiple measurement types at request <NUM>, the base station may receive a plurality of sequential data streams, each data stream corresponding to a measurement report for a single measurement type identified by the base station. Further at step <NUM>, the base station may receive the data including results corresponding to the specified at least one type of MDT measurement from the UE. For example, the base station may receive the one or more data streams or other transmissions and save data from each of them to a separate file.

The base station may also identify, along with the requested MDT data, TCE addresses from the data streams or other transmissions. Accordingly, at step <NUM>, the base station may forward the requested MDT data via a trace collection entity (TCE) to a core network for distributing to clients. For example, the base station may extract information from each of the one or more data streams or other data transmissions to identify the intended TCE recipient as described above. Using this information, the base station may send the received data in a data stream or other transmission type to the TCE for forwarding to the appropriate client or entity that may require the information. In some implementations, the base station may be configured to transmit the received data directly to the entity that requested data for that measurement type. If the base station receives multiple data streams in sequence corresponding to a request for multiple measurement types, the base station, in an exemplary implementation, may send each received data stream, such as in the form of a file, for example, to the TCE for routing to the intended entity.

The base station may subsequently determine, or the base station may be subsequently informed by the network, that another one or more measurement reports corresponding to additional data types configured by the base station may be needed (<NUM>). If so, the base station may return to step <NUM> to issue a new MDT measurement type request identifying the new data types, and the process resumes from step <NUM> as described above. If no other MDT data is requested, the process ends (<NUM>) until such time that another request is made, or the UE is reconfigured, etc..

In one optional implementation, a new information element may be added as an information element (IE) that can represent a basis for writing code to identify the type(s) of measurement for which a measurement report is required. In this example implementation, an octet bit string (XXXXXXXX) may be used to enable the base station to identify the type of measurement. Thus, for instance, a Bluetooth measurement may be represented by the fourth bit position in the octet (i.e., XXXXXXXX), and a WLAN measurement may be represented by the seventh bit position (XXXXXXXX). The measurement types may be enabled by setting the relevant bits to "<NUM>" or "true". In the example where the base station is requesting MDT information in the MDT information type request for the Bluetooth and WLAN MDT tests, the base station may provide the bit string <NUM>, for example, which identifies those to tests.

An MDT information type request may optionally include the following IE for a <NUM> NR network, for example.

The octet in the example above can be predefined to have any value from <NUM> to <NUM>. Specifying a <NUM> enables a stream ID corresponding to the MDT measurement type. In configurations where additional measurement types are required, a larger bit string, or multiple bit strings, can be used. Code or hardware that may implement this IE or a similar IE can be used to define the MDT measurement type to be selected in an actual device. The MDT Stream from the UE can be tagged with a stream ID, (e.g., cell measurements, MDT Stream (serving and neighbors), IRAT measurement stream, MBSFN MDT measurement stream, WLAN MDT measurement stream, BT MDT measurement stream, and the like) to distinguish between different types of MDT information.

As noted above, the base station may inform the UE that the base station supports the selective MDT report capability. A data bit or other indicator may be added to the base station's MDT measurement type report. Accordingly, an IE indicating non-real time MDT streaming support can be optionally added as follows:
<IMG>.

In the underscored portion of the above IE, the Boolean value can be optionally set to "true" to indicate non real-time MDT streaming capability. Once this bit is set to true, then the base station can issue the MDT measurement type request.

It should be understood that the IEs above are exemplary only, and other IEs or hardware and software implementations are possible for use in various configurations described in this disclosure. Thus the IEs are not intended to be limiting, but rather purely illustrative in nature.

<FIG> is a diagram illustrating an example of a hardware implementation <NUM> for an example UE <NUM>. The UE <NUM> may include a cellular baseband processor <NUM> (also referred to as a modem) coupled to a cellular RF transceiver <NUM> and one or more subscriber identity modules (SIM) cards <NUM>, an application processor <NUM> coupled to a secure digital (SD) card <NUM> and a screen <NUM>, a Bluetooth module <NUM>, a wireless local area network (WLAN) module <NUM>, a Global Positioning System (GPS) module <NUM>, and a power supply <NUM>. The cellular baseband processor <NUM> may communicate through the cellular RF transceiver <NUM> with the UE <NUM> and/or base station <NUM>/<NUM>. The cellular baseband processor <NUM> may be responsible for general processing, including the execution of software stored on the computer-readable medium / memory. The software, when executed by the cellular baseband processor <NUM>, may cause the cellular baseband processor <NUM> to perform the various functions described throughout this disclosure. The cellular baseband processor <NUM> may further include a reception component <NUM>, a communication manager <NUM>, and a transmission component <NUM>. The communication manager <NUM> may include the one or more illustrated components. The UE <NUM> may include a modem chip and the baseband processor <NUM>, and may include the aforediscussed additional modules of the UE <NUM>.

The communication manager <NUM> can include a measurement types component <NUM> that may be internal to the UE and that may be used as needed to store data and code used to assist in performing MDT measurements. The communication manager <NUM> can further include an MDT measurement component <NUM> that optionally receives input in the form of information and code from component <NUM> for performing different measurements and that also optionally receives information from the reception component <NUM> such as MDT configurations from the base station. The MDT measurement component <NUM> may be configured to receive MDT configuration information, including measurement intervals and a measurement duration as described in step <NUM> from <FIG> and signal(s) <NUM> from <FIG>. The MDT measurement component <NUM> may be configured to perform the different types of MDT measurements over the measurement intervals and the MDT duration provided by the base station <NUM>, as shown in step <NUM> of <FIG> and block <NUM> of <FIG>. The MDT measurement component <NUM> may also use input in the form of UE-specific measurement information from the measurement types component <NUM>. The MDT measurement component <NUM> is also configured to perform these measurements when the UE <NUM> is in an idle state. The MDT measurement component <NUM> may be configured to log the measurement data, including storing information corresponding to different types of measurements into different respective data files, e.g., as described in connection with step <NUM> and <NUM> of <FIG> and blocks <NUM> and <NUM> of <FIG>.

The communication manager <NUM> may further include a non-real time MDT data stream component <NUM> that can receive input in the form of measurement data from the component <NUM> and that may be configured to receive MDT measurement type requests from the base station during an RRC connection, e.g., as described in connection with step <NUM> of <FIG> and signal(s) <NUM> of <FIG>. The MDT data stream component <NUM> may be configured to receive an indication in the measurement type request that the base station supports receiving MDT type-specific data streams, e.g., as is also shown in step <NUM> of <FIG>. Responsive to one of these requests, MDT data stream component <NUM> may be configured to send a non-real time data stream to the base station <NUM> which includes measurement data corresponding to the information requested in the MDT measurement type request, e.g., as shown in step <NUM> of <FIG> and signal <NUM> of <FIG>. Component <NUM> may also be configured, in the case where the base station identifies in the MDT measurement type request more than one type of MDT measurement, to send different non-real time data streams during successive time periods, with each data stream corresponding to one data type, e.g., as shown in steps <NUM>, <NUM> and <NUM> of <FIG> and signal <NUM> and block <NUM> of <FIG>.

The communication manager <NUM> may further include an RRC component <NUM> that can receive input in the form of RRC connection/release requests from the reception component <NUM> and is configured to establish or release an RRC connection. The communication manager <NUM> may further include a capability reporting component <NUM> that receives input in the form of a configuration message or an MDT measurement type request from the components <NUM> and <NUM> and is configured to optionally send an indication to the base station that the UE is capable of MDT measurement-type specific data streaming, e.g., as described in connection with step <NUM> of <FIG> and signal <NUM> and block <NUM> of <FIG>. The communication manager <NUM> further may include a ready/not ready component <NUM> that receives input from the MDT data stream component <NUM> in the form of an MDT measurement type request and that is configured to indicate to the base station that it is ready or not ready, or not capable, of sending the requested data stream, e.g., as show in signal <NUM> of <FIG>.

The UE may include additional components that perform each of the blocks of the algorithm in the aforementioned timing diagram and flowchart of <FIG> and <FIG>, respectively. As such, each block in the aforementioned timing diagrams and flowcharts of <FIG> and <FIG>, respectively, may be performed by a component and the UE may include one or more of those components.

In one configuration, the UE <NUM>, and in particular the cellular baseband processor <NUM>, includes means for receiving, from a base station, a request for minimization of driving test (MDT) data corresponding to a type of measurement by the UE, means for sending a data stream comprising the requested data to the base station, means for making a plurality of MDT measurements specified by the base station, and means for saving each of the plurality of measurements in a separate file. The aforementioned means may be one or more of the aforementioned components of the UE <NUM> configured to perform the functions recited by the aforementioned means. As described above, the UE <NUM> may include the TX Processor <NUM>, the RX Processor <NUM>, and the controller/processor <NUM>.

<FIG> is a diagram <NUM> illustrating an example of a hardware implementation for a base station <NUM>. The base station <NUM> includes a baseband unit <NUM>. The baseband unit <NUM> may communicate through a cellular RF transceiver with the UE <NUM>. The baseband unit <NUM> may include a computer-readable medium / memory. The baseband unit <NUM> is responsible for general processing, including the execution of software stored on the computer-readable medium / memory. The software, when executed by the baseband unit <NUM>, causes the baseband unit <NUM> to perform the various functions described above. The computer-readable medium / memory may also be used for storing data that is manipulated by the baseband unit <NUM> when executing software. The baseband unit <NUM> further includes a reception component <NUM>, a communication manager <NUM>, and a transmission component <NUM>. The components within the communication manager <NUM> may be stored in the computer-readable medium / memory and/or configured as hardware within the baseband unit <NUM>. The baseband unit <NUM> may be a component of the base station <NUM> and may include the memory <NUM> and/or at least one of the TX processor <NUM>, the RX processor <NUM>, and the controller/processor <NUM>.

The communication manager <NUM> may include an MDT configuration component <NUM> that is configured to send an MDT configuration message to a UE for configuring a plurality of different MDT measurement types for the UE to perform, as well as to provide the UE with specified measurement intervals and an MDT measurement duration, e.g., as described in connection with step <NUM> of <FIG> and step <NUM> and block <NUM> of <FIG>. The communication manager <NUM> further includes an MDT data stream component <NUM> that receives input in the form of MDT measurement configuration type, measurement parameters, and measurement intervals and duration from the MDT configuration component <NUM>, and that is configured to send an MDT measurement type message to the UE e.g., as described in connection with steps <NUM> and <NUM> of <FIG> and signal <NUM> of <FIG>. The communication manager <NUM> further includes an MDT processing component <NUM> that is configured to receive input in the form of data streams from component <NUM> and is configured to receive the data streams and optionally save them into individual files, e.g., as described in connection with step <NUM> of <FIG>. The communication manager <NUM> may further include an RRC component <NUM> that receives input in the form of RRC connection/release requests from the reception component <NUM> and is configured to establish or release an RRC connection. The communication manager <NUM> further receives a network component <NUM> that is configured to receive input in the form of data streams from component <NUM> and/or data files from component <NUM> and to extract TCE information from the data to identify a TCE address for sending the data file to the correct TCE entity, e.g., as described in connection with step <NUM> of <FIG> and signals <NUM>, <NUM> and <NUM> and block <NUM> of <FIG>. The communication manager <NUM> further receives a legacy enabling component <NUM> that receives input from the reception component <NUM> in the form of information as to the measurement-type data streaming capabilities, or lack thereof, sent from the UE.

The base station may include additional components that perform each of the blocks of the algorithm in the aforementioned timing diagram and flowchart of <FIG> and <FIG>, respectively. As such, each block in the aforementioned flowcharts of <FIG> and <FIG>, respectively, may be performed by a component and the base station may include one or more of those components.

In one configuration, the base station <NUM>, and in particular the baseband unit <NUM>, includes means for sending a request to a UE for minimization of driving test (MDT) data corresponding to a type of measurement by the UE, and means for receiving a stream comprising the requested data corresponding to the type of measurement. The aforementioned means may be one or more of the aforementioned components of the base station <NUM> configured to perform the functions recited by the aforementioned means. As described above, the base station <NUM> may include the TX Processor <NUM>, the RX Processor <NUM>, and the controller/processor <NUM>.

As noted, one or more aspects of the present disclosure may enable the network to selectively identify requested data for MDT measurements that are pertinent at the time of request, thereby reducing or eliminating the network resources expended on filtering the data. The data can also be streamed from the UE on a type-specific basis. As a result, the data streams can be far smaller than the conventional data file inclusive of all measurements and the possibility of requiring that the streamed data be segmented is reduced or eliminated. This in turn can reduce or eliminate the resource bottlenecks associated with excessive RRC signaling. Additionally, the problem regarding the power drain on the battery may be mitigated or solved.

Claim 1:
A method of wireless communication executed by a user equipment, UE, comprising:
receiving (<NUM>), from a base station, a request for structured minimization of driving test, MDT, data, the requested data corresponding to at least one type of MDT measurement specified by the base station from a larger plurality of available MDT measurement types that can be performed by the UE, wherein the request for the structured MDT data comprises an indication that the base station supports non-real time streaming MDT data; and
sending (<NUM>) the data including results corresponding to the specified at least one type of MDT measurement to the base station.