Method and apparatus for structured minimization of drive test measurement data

Abstract

Aspects of transmitting structured measurement data based on a particular type of measurement requested by a network are disclosed. A user equipment (UE) can receive, from a base station, a request for minimization of drive test (MDT) data corresponding to a specified type of measurement from a plurality of available MDT measurements that the UE can make. The UE can transmit, to the base station, the requested data including a structured report with results for the specified type of measurement. In other aspects, a base station can transmit, to a UE, a request for minimization of drive test (MDT) data corresponding to a type of measurement made by the UE. The base station can receive the requested data corresponding to the type of measurement.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit and priority of Indian Provisional Patent Application No. 202041030556, filed on July 17, 2020, entitled “Streaming Minimization of DriveTest Measurements From a User Equipment to a Network,” the entire contents of which are incorporated herein by reference. background Technical Field

[0004] This disclosure generally relates to communication systems, and more particularly to transmitting measurement data over a network. Background Technology

[0006] Wireless communication systems are widely deployed to provide a variety of telecommunications services such as telephone, video, data, messaging, and broadcasting. Typical wireless communication systems employ multiple access technologies that enable communication with multiple users by sharing available system resources. Examples of such multiple access technologies include Code Division Multiple Access (CDMA) systems, Time Division Multiple Access (TDMA) systems, Frequency Division Multiple Access (FDMA) systems, Orthogonal Frequency Division Multiple Access (OFDMA) systems, Single Carrier Frequency Division Multiple Access (SC-FDMA) systems, and Time Division Synchronous Code Division Multiple Access (TD-SCDMA) systems.

[0007] These multiple access technologies have been adopted in various telecommunications standards to provide a common protocol enabling different wireless devices to communicate at the city, country, region, and even global levels. An example telecommunications standard is 5G New Radio (NR). 5G NR is part of the continuous evolution of mobile broadband, promulgated by the 3rd Generation Partnership Project (3GPP) to meet new requirements associated with latency, reliability, security, scalability (e.g., with the Internet of Things (IoT), and other requirements. 5G NR includes services associated with enhanced mobile broadband (eMBB), massive machine-type communications (mMTC), and ultra-reliable low latency communications (URLLC). Some aspects of 5G NR can be based on the 4G Long Term Evolution (LTE) standard. There is a need for further improvements to 5G NR technology. These improvements can also be applied to other multiple access technologies and telecommunications standards that adopt them. Summary of the Invention

[0008] The following provides a brief overview of one or more aspects to offer a basic understanding of such aspects. This overview is not an exhaustive summary of all conceived aspects, nor is it intended to identify the key or decisive elements of all aspects, nor to define the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as an introduction to the more detailed description that follows.

[0009] Accordingly, in one aspect of this disclosure, a method and apparatus are provided. The apparatus may be a user equipment (UE). The UE may include a processor configured to receive a request for structured minimized drive test (MDT) data from a base station. The requested data may correspond to at least one type of MDT measurement specified by the base station from a plurality of available types of MDT measurements that can be performed by the UE. The processor may also be configured to send data to the base station including the results corresponding to the specified at least one type of MDT measurement.

[0010] The device may also be a base station. The base station may include a processor configured to send a request to the UE for structured minimized drive test (MDT) data. The requested MDT data may correspond to at least one type of MDT measurement specified by the base station from a plurality of available MDT measurement types that can be performed by the UE. The processor may be further configured to receive the requested structured data corresponding to that type of measurement.

[0011] To achieve the foregoing and related objectives, these one or more aspects include the features fully described below and specifically pointed out in the claims. Certain illustrative features of these one or more aspects are set forth in detail in the following description and drawings. However, these features merely indicate a few of the various ways in which the principles of these various aspects may be employed, and this description is intended to cover all such aspects and their equivalents. Attached Figure Description

[0012] Figure 1 This is a diagram illustrating an example of a wireless communication system and access network.

[0013] Figure 2A This is an example illustration of the first frame explaining various aspects of this disclosure.

[0014] Figure 2B This is a diagram illustrating an example of a DL channel within a subframe according to various aspects of this disclosure.

[0015] Figure 2C This is an example illustration of the second frame explaining various aspects of this disclosure.

[0016] Figure 2D This is a diagram illustrating an example of a UL channel within a subframe according to various aspects of this disclosure.

[0017] Figure 3 This is a diagram illustrating an example of a base station and user equipment (UE) in an access network.

[0018] Figure 4 This is a conceptual diagram illustrating an example of a UE establishing an RRC connection with a base station and the base station forwarding measurement data to the operation and management facilities.

[0019] Figure 5 This is a timing diagram illustrating an example of an MDT report recorded between the UE and the network.

[0020] Figure 6 This is a timing diagram illustrating an example of a recorded MDT report, which includes the UE sending a requested type of measurement report to the network.

[0021] Figure 7 This is a flowchart of a wireless communication method.

[0022] Figure 8 This is a flowchart of a wireless communication method.

[0023] Figure 9 This is a diagram illustrating an example of the hardware implementation used for the sample UE.

[0024] Figure 10 This is a diagram illustrating an example of the hardware implementation used for a sample base station. Detailed Implementation

[0025] The detailed description that follows, taken in conjunction with the accompanying drawings, is intended as a description of various configurations and is not intended to represent only the configurations in which the concepts described herein can be practiced. This detailed description includes specific details to provide a thorough understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts can be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form to avoid obscuring such concepts.

[0026] Minimized Drive Test (MDT) measurements can be configured by the network and performed by the UE. The applicant has observed that, in response to base station requests, all configured test results are routinely sent to the network via RRC connections as part of a measurement report file from the UE. The applicant has also observed that the size of this data file has increased significantly over the years as new measurement types have been continuously added. The applicant has further observed that, due to the current maximum RRC transmission capacity of 8 kilobytes, the file is fragmented into multiple RRC messages. The applicant has further observed that transmitting such a large file from the UE to the network rapidly depletes the UE's battery power. In addition, the applicant has observed that the RRC signaling overhead caused by fragmentation also places additional pressure on the UE and network resources. Furthermore, the applicant has observed that the network core must filter large data files to extract different measurement results in order to forward them to different entities that require specific MDT measurement results.

[0027] Some of the techniques described herein can help reduce or eliminate these problems. For example, one technique may include logging MDT measurement reports at the UE as multiple individual files, each based on a corresponding MDT measurement type. The UE may receive a network request for structured MDT data, which includes measurement reports, for example, limited to specific types(s) of MDT measurement(s) required by the network at the time of request, rather than requesting a single data file including all measurements performed as routinely. In response to the network request, only data corresponding to the requested type(s) of measurement(s) may be sent to the network. The structured nature of the data is broadly intended to take any of several forms. For example, structured MDT data may simply be organized in an easily identifiable or network-friendly manner. In one exemplary configuration, the data may be structured such that the base station (or other network entity) can easily identify the type(s) of MDT measurement(s), for example, without needing to segment large amounts of data corresponding to all different MDT measurements into, for example, their constituent types. In other configurations, the structured data may optionally be represented by a protocol or format by the receiving network to enable rapid and easy retrieval and analysis of one or more individual MDT measurement(s) from a larger group of such types. However, this is not necessarily the case, and structured MDT data does not need to correspond to a defined format or protocol. As another example, in some configurations, structured MDT data can simply refer to data representing MDT measurements requested by the network. MDT measurement data may optionally include a structured report having results corresponding to at least one measurement type specified by the base station from a plurality of available measurements that can be performed by the UE. Furthermore, instead of performing a single large file transfer to send all data to the base station at once, data specific to the requested measurement type can be sent to the base station. The UE can send data to the base station as a single file in a structured report or as part of a single non-real-time data stream. As a result, UE battery power and network bandwidth consumption can be reduced. Furthermore, the customized nature of the data sent to the base station in response to a request from the base station can reduce (if not completely eliminate) the need for RRC segmentation. That is, since only the specific, structured MDT measurement data identified in the network request is sent at a time, the requirement for data received by network filtering can be reduced or completely eliminated, depending on the circumstances.

[0028] Several aspects of a telecommunications system will now be described with reference to various apparatuses and methods. These apparatuses and methods will be described in detail below and explained in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively, “elements”). These elements can be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system.

[0029] As an example, wherever the term "processor" is referenced in this disclosure, "processor" is considered to include one or more processors. Examples of processors include: microprocessors, microcontrollers, graphics processing units (GPUs), central processing units (CPUs), application processors, digital signal processors (DSPs), reduced instruction set computing (RISC) processors, system-on-a-chip (SoCs), baseband processors, field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuitry, and other suitable hardware configured to perform the various functionalities described throughout this disclosure. One or more processors in a processing system can execute software. Software should be broadly interpreted as instructions, instruction sets, code, code segments, program code, programs, subroutines, software components, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description languages, or other terms.

[0030] Accordingly, in one or more example embodiments, the described functionality can be implemented in hardware, software, or any combination thereof. If implemented in software, the functionality can be stored or encoded as one or more instructions or code on a computer-readable medium. Computer-readable media includes computer storage media. Storage media can be any available medium accessible to a computer. By way of example and not limitation, such computer-readable media may include random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), optical disc storage, magnetic disk storage, other magnetic storage devices, combinations of computer-readable media of the types described above, or any other medium capable of being used to store computer-executable code in the form of instructions or data structures accessible to a computer.

[0031] Figure 1 This is a diagram illustrating an example of a wireless communication system and access network 100. The wireless communication system (also known as a wireless wide area network (WWAN)) includes base station 102, UE 104, evolved packet core (EPC) 160, and another core network 190 (e.g., a 5G core (5GC)). Base station 102 may include macrocells (high-power cellular base stations) and / or small cells (low-power cellular base stations). Macrocells include base stations. Small cells include femtocells, picocells, and microcells.

[0032] Base station 102 configured for 4G LTE (collectively referred to as Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN)) can interface with EPC 160 via a first backhaul link 132 (e.g., S1 interface). Base station 102 configured for 5G NR (collectively referred to as Next Generation RAN (NG-RAN)) can interface with core network 190 via a second backhaul link 184. Among other functions, base station 102 can also perform one or more of the following functions: user data delivery, radio channel cryptography and cryptography decoding, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity), inter-cell interference coordination, connection establishment and release, load balancing, distribution of Non-Access Stratum (NAS) messages, NAS node selection, synchronization, Radio Access Network (RAN) sharing, Multimedia Broadcast Multicast Service (MBMS), subscriber and equipment tracking, RAN Information Management (RIM), paging, location, and delivery of alarm messages. Base station 102 can communicate with each other directly or indirectly (e.g., via EPC 160 or core network 190) on third backhaul link 134 (e.g., X2 interface). First backhaul link 132, second backhaul link 184 and third backhaul link 134 can be wired or wireless.

[0033] Base station 102 can wirelessly communicate with UE 104. Each base station 102 can provide communication coverage for its respective geographical coverage area 110. Overlapping geographical coverage areas 110 may exist. For example, small cell 102' may have coverage areas 110' that overlap with the coverage areas 110 of one or more macro base stations 102. A network that includes both small cells and macro cells may be referred to as a heterogeneous network. The heterogeneous network may also include a Home Evolved B Node (eNB) (HeNB) that can provide services to a restricted group referred to as a Closed Subscriber Group (CSG). The communication link 120 between base station 102 and UE 104 may include uplink (UL) (also known as reverse link) transmission from UE 104 to base station 102 and / or downlink (DL) (also known as forward link) transmission from base station 102 to UE 104. The communication link 120 may use multiple-input multiple-output (MIMO) antenna technologies, including spatial multiplexing, beamforming, and / or transmit diversity. These communication links may use one or more carriers. For each carrier allocated in a total of up to Yx MHz (x component carriers) for transmission in each direction, the base station 102 / UE 104 may use a spectrum with a bandwidth of up to Y MHz (e.g., 5, 10, 15, 20, 100, 400 MHz, etc.). These carriers may or may not be adjacent to each other. The allocation of carriers may be asymmetric with respect to DL and UL (e.g., more or fewer carriers may be allocated to DL compared to UL). Component carriers may include primary component carriers and one or more secondary component carriers. The primary component carrier may be referred to as the primary cell (PCell), and the secondary component carrier may be referred to as the secondary cell (SCell).

[0034] Some UEs 104 may communicate with each other using device-to-device (D2D) communication link 158. D2D communication link 158 may use DL / UL WWAN spectrum. D2D communication link 158 may use one or more sidelink channels, such as the Physical Sidelink Broadcast Channel (PSBCH), Physical Sidelink Discovery Channel (PSDCH), Physical Sidelink Shared Channel (PSSCH), and Physical Sidelink Control Channel (PSCCH). D2D communication can be achieved through a wide variety of wireless D2D communication systems, such as, for example, WiMedia, Bluetooth, ZigBee, Wi-Fi based on the IEEE 802.11 standard, LTE, or NR.

[0035] The wireless communication system may further include a Wi-Fi access point (AP) 150 communicating with a Wi-Fi station (STA) 152 via a communication link 154, for example, in an unlicensed spectrum such as 5 GHz. When communicating in unlicensed spectrum, the STA 152 / AP 150 may perform a clear channel assessment (CCA) before communication to determine whether the channel is available.

[0036] Small cell 102' can operate in licensed and / or unlicensed spectrum. When operating in unlicensed spectrum, small cell 102' can employ NR and use the same unlicensed spectrum (e.g., 5 GHz, etc.) used by Wi-FiAP 150. Small cell 102' employing NR in unlicensed spectrum can enhance access network coverage and / or increase access network capacity.

[0037] The electromagnetic spectrum is typically subdivided into various classes, bands, channels, etc., based on frequency / wavelength. In 5G NR, two initial operating bands have been designated as frequency ranges FR1 (410MHz–7.125GHz) and FR2 (24.25GHz–52.6GHz). The frequencies between FR1 and FR2 are generally referred to as the mid-band frequencies. Although a portion of FR1 is greater than 6GHz, FR1 is often (interchangeably) referred to as the “sub-6GHz” band in various documents and articles. Similar naming issues sometimes arise regarding FR2; although different from the Very High Frequency (EHF) band (30GHz–300GHz) designated as the “millimeter wave” band by the International Telecommunication Union (ITU), FR2 is often (interchangeably) referred to as the “millimeter wave” band in various documents and articles.

[0038] In light of the foregoing, unless otherwise stated, it should be understood that, as used herein, the term "sub-6GHz" and the like can broadly refer to frequencies less than 6GHz, within FR1, or including intermediate frequency band frequencies. Furthermore, unless otherwise stated, it should be understood that, as used herein, the term "millimeter wave" and the like can broadly refer to frequencies that can include intermediate frequency band frequencies, within FR2, or within the EHF band.

[0039] Whether it is a small cell 102' or a large cell (e.g., a macro base station), base station 102 may include and / or be referred to as an eNB, gB node (gNB), or another type of base station. Some base stations (such as gNB 180) may operate in conventional sub-6 GHz spectrum, millimeter wave frequencies, and / or near-millimeter wave frequencies to communicate with UE 104. When gNB 180 operates in millimeter wave frequencies or near-millimeter wave frequencies, gNB 180 may be referred to as a millimeter wave base station. Millimeter wave base station 180 may utilize beamforming 182 with UE 104 to compensate for path loss and short range. Base station 180 and UE 104 may each include multiple antennas, such as antenna elements, antenna panels, and / or antenna arrays, to facilitate beamforming.

[0040] Base station 180 may transmit beamformed signals to UE 104 in one or more transmission directions 182'. UE 104 may receive beamformed signals from base station 180 in one or more reception directions 182'. UE 104 may also transmit beamformed signals to base station 180 in one or more transmission directions. Base station 180 may receive beamformed signals from UE 104 in one or more reception directions. Base station 180 / UE 104 may perform beam training to determine the optimal reception and transmission directions for each of base station 180 / UE 104. The transmission and reception directions of base station 180 may be the same or different. The transmission and reception directions of UE 104 may be the same or different.

[0041] EPC 160 may include Mobility Management Entity (MME) 162, other MMEs 164, Serving Gateway 166, Multimedia Broadcast Multicast Service (MBMS) Gateway 168, Broadcast Multicast Service Center (BM-SC) 170, and Packet Data Network (PDN) Gateway 172. MME 162 may communicate with Home Subscriber Server (HSS) 174. MME 162 is the control node that handles signaling between UE 104 and EPC 160. Generally, MME 162 provides bearer and connection management. All user Internet Protocol (IP) packets are delivered through Serving Gateway 166, which is itself connected to PDN Gateway 172. PDN Gateway 172 provides UE IP address allocation and other functions. PDN Gateway 172 and BM-SC 170 are connected to IP Service 176. IP Service 176 may include the Internet, intranet, IP Multimedia Subsystem (IMS), PS streaming service, and / or other IP services. The BM-SC 170 provides functionality for MBMS user service provisioning and delivery. The BM-SC 170 can serve as an entry point for content provider MBMS transmissions, authorize and initiate MBMS bearer services within a Public Land Mobile Network (PLMN), and schedule MBMS transmissions. The MBMS gateway 168 can be used to distribute MBMS traffic to base station 102 within a Broadcast-Specific Service Single Frequency Network (MBSFN) area, and can be responsible for session management (start / stop) and collecting eMBMS-related billing information.

[0042] The core network 190 may include Access and Mobility Management Functions (AMF) 192, other AMFs 193, Session Management Functions (SMF) 194, and User Plane Functions (UPF) 195. AMF 192 may communicate with Unified Data Management (UDM) 196. AMF 192 is the control node that handles signaling between UE 104 and the core network 190. Generally, AMF 192 provides QoS flow and session management. All user Internet Protocol (IP) packets are transmitted through UPF 195. UPF 195 provides UE IP address allocation and other functions. UPF 195 connects to IP services 197. IP services 197 may include the Internet, intranet, IP Multimedia Subsystem (IMS), Packet Switched (PS) Streaming (PSS) services, and / or other IP services.

[0043] Base stations may include and / or be referred to as gNB, B-node, eNB, access point, base transceiver station, radio base station, radio transceiver, transceiver function, basic service set (BSS), extended service set (ESS), transmit / receive point (TRP), or some other suitable term. Base station 102 provides UE 104 with access to EPC 160 or core network 190. Examples of UE 104 include cellular phones, smartphones, Session Initiation Protocol (SIP) phones, laptop devices, personal digital assistants (PDAs), satellite radios, GPS devices, multimedia devices, video devices, digital audio players (e.g., MP3 players), cameras, game consoles, tablet devices, smart devices, wearable devices, vehicles, electricity meters, air pumps, large or small kitchen appliances, healthcare devices, implants, sensors / actuators, displays, or any other similar functional devices. Some UE 104 may be referred to as IoT devices (e.g., parking timers, oil pumps, ovens, vehicles, heart monitors, etc.). UE 104 may also be referred to as a station, mobile station, subscriber station, mobile unit, subscriber unit, radio unit, remote unit, mobile device, radio device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, radio terminal, remote terminal, handheld device, user agent, mobile client, client, or some other suitable term.

[0044] Referring again to 1, in some respects, base station 180 may include MDT measurement and processing component 199. Base station 180 may use component 199 during RRC connections to configure UE 104 to perform various types of MDT measurements (including providing measurement intervals and measurement durations); log data to measurement reports related to various MDT measurement types to be received from UE 102; and receive these measurement reports and forward them to the core network for distribution to appropriate entities. These measurement types may include, for example, serving / neighbor cell measurements, multimedia broadcast / multicast serving single-frequency network (MBSFN) measurements, wireless local area network (WLAN) measurements, Bluetooth measurements, location measurements, etc. Component 199 may also be configured to perform other actions involving MDT measurement reports, including processing MDT information, requesting different measurement reports (such as MDT measurement type requests), and sending and receiving information about MDT activities and measurement reports to and from UE 104, other base stations 102 / 180, the core network 190, and other network entities / clients that may require data related to specific UE measurement types. In one configuration, component 199 is configured to include an indication in the measurement type request that the base station supports receiving MDT measurement data in the data stream.

[0045] UE 104 may include an MDT data transmission component 198(1) and an MDT measurement component 198(2). The MDT measurement component 198(2) of UE 104 may be configured to receive configuration information, including measurement intervals and measurement durations, from base station 180 during RRC connections for subsequent MDT measurements during UE idle states. The MDT measurement component 198(2) may be further configured to perform different MDT measurements previously configured by base station 180. The MDT measurement component 198(2) may be configured to perform these measurements during specified measurement intervals and over the length of the MDT measurement duration. After these measurements, UE 104 enters an idle state when the RRC connection is released. The MDT measurement component 198(2) may be further configured to record measurement data, including storing information corresponding to different types of measurements into, for example, different corresponding data files.

[0046] MDT data transmission component 198(1) can be configured to receive an MDT measurement type request from base station 180 during an RRC connection that occurs after a measurement is performed. MDT data transmission component 198(1) can be configured to receive an indication in the measurement type request regarding whether the base station supports or is capable of receiving the requested MDT data. In response to this type of request, component 198(1) can be configured to send a structured measurement report as one or more files or as a non-real-time data stream to base station 180, including measurement data corresponding to a specific type of measurement from a larger group of available MDT measurements identified in the MDT measurement type request. Where the base station identifies more than one type of MDT measurement in the MDT measurement type request, component 198(1) can also be configured to send the data in different time periods during successive time periods. MDT data transmission component 198(1) can also be configured to perform other MDT-related functions.

[0047] The MDT measurement and processing component 199, the MDT data transmission component 198(1), and the MDT measurement component 198(2) can be implemented, in part or in whole, as software stored in memory and executed on one or more general-purpose or special-purpose processors. Alternatively, these components 198(1), 198(2), and 199 can be implemented, in part or in whole, as firmware or as hardware including one or more digital signal processors (DSPs), gate arrays, SoCs, digital logic circuits, application-specific integrated circuits (ASICs), etc.

[0048] While the following description may focus on MDT measurement reporting, the concepts described herein are applicable to other similar areas, such as other types of network measurements, including signal strength and round-trip time (RTT) measurements. Furthermore, while the following description may focus on 5G NR, the concepts described herein are applicable to other similar areas, such as LTE, LTE-A, CDMA, GSM, and other wireless technologies.

[0049] Figure 2A This is a diagram 200 illustrating an example of the first subframe within the 5G NR frame structure. Figure 2B Figure 230 is an example illustrating the DL channel within a 5G NR subframe. Figure 2C This is a diagram 250 illustrating an example of the second subframe within the 5G NR frame structure. Figure 2D Figure 280 illustrates an example of the UL channel within a 5G NR subframe. The 5G NR frame structure can be Frequency Division Duplex (FDD), where subframes within a specific set of subcarriers (carrier system bandwidth) are dedicated to either DL or UL; or it can be Time Division Duplex (TDD), where subframes within a specific set of subcarriers (carrier system bandwidth) are dedicated to both DL and UL. Figure 2A , 2C In the provided example, the 5G NR frame structure is assumed to be TDD, where subframe 4 is configured with slot format 28 (mostly DL) and subframe 3 is configured with slot format 34 (mostly UL), where D is DL, U is UL, and F is for flexible use between DL and UL. Although subframes 3 and 4 are shown as having slot formats 34 and 28, respectively, any particular subframe can be configured with any of the various available slot formats 0-61. Slot formats 0 and 1 are full DL and full UL, respectively. Other slot formats 2-61 include a mixture of DL, UL, and flexible symbols. The UE is configured to have a slot format via the received Slot Format Indicator (SFI) (dynamically configured via DL Control Information (DCI) or semi-statically / statically configured via Radio Resource Control (RRC) signaling). Note that the following description also applies to 5G NR frame structures for TDD.

[0050] Other wireless communication technologies may have different frame structures and / or different channels. A frame (10 ms) can be divided into 10 equally sized subframes (1 ms). Each subframe may include one or more time slots. Subframes may also include mini-time slots, which may include 7, 4, or 2 symbols. Each time slot may include 7 or 14 symbols, depending on the time slot configuration. For time slot configuration 0, each time slot may include 14 symbols, while for time slot configuration 1, each time slot may include 7 symbols. Symbols on the DL can be Cyclic Prefix (CP) OFDM (CP-OFDM) symbols. Symbols on the UL can be CP-OFDM symbols (for high-throughput scenarios) or Discrete Fourier Transform (DFT) Extended OFDM (DFT-s-OFDM) symbols (also known as Single Carrier Frequency Division Multiple Access (SC-FDMA) symbols) (for power-constrained scenarios; limited to single-stream transmission). The number of time slots within a subframe is based on the time slot configuration and parameter design. For slot configuration 0, different parameter designs μ of 0 to 4 allow 1, 2, 4, 8, and 16 slots per subframe, respectively. For slot configuration 1, different parameter designs 0 to 2 allow 2, 4, and 8 slots per subframe, respectively. Correspondingly, for slot configuration 0 and parameter design μ, there are 14 symbols per slot and 2 symbols per subframe. μ Each time slot. The subcarrier spacing and symbol length / duration vary depending on the design parameters. The subcarrier spacing can be equal to 2. μ *15kHz, where μ is the parameter design from 0 to 4. Thus, parameter design μ = 0 has a subcarrier spacing of 15kHz, while parameter design μ = 4 has a subcarrier spacing of 240kHz. Symbol length / duration is inversely correlated with subcarrier spacing. Figures 2A to 2D An example of a slot configuration of 0 and parameter design μ=2 with 14 symbols per slot and 4 slots per subframe is provided. The slot duration is 0.25ms, the subcarrier spacing is 60kHz, and the symbol duration is approximately 16.67μs. Within the frame set, there may be one or more different bandwidth portions (BWPs) that are frequency-division multiplexed (see [link to relevant documentation]). Figure 2B Each BWP can have specific parameter designs.

[0051] A resource grid can be used to represent the frame structure. Each time slot includes a resource block (RB) extending 12 consecutive subcarriers (also known as a physical RB (PRB)). The resource grid is divided into multiple resource elements (REs). The number of bits carried by each RE depends on the modulation scheme.

[0052] like Figure 2AAs explained in the text, some REs carry reference (pilot) signals (RS) for the UE. RSs may include demodulation RS (DM-RS) for channel estimation at the UE (indicated as Rx for a specific configuration, where 100x is the port number, but other DM-RS configurations are possible) and channel state information reference signals (CSI-RS). RSs may also include beam measurement RS (BRS), beam refinement RS (BRRS), and phase tracking RS (PT-RS).

[0053] Figure 2B Examples of various DL channels within a subframe of a frame are explained. The Physical Downlink Control Channel (PDCCH) carries the DCI within one or more Control Channel Elements (CCEs), each CCE comprising 9 RE Groups (REGs), each REG comprising 4 consecutive REs in OFDM symbols. The PDCCH within a BWP can be referred to as a Control Resource Set (CORESET). Additional BWPs can be located at higher and / or lower frequencies spanning the channel bandwidth. The Primary Synchronization Signal (PSS) is located within symbol 2 of a specific subframe of the frame. The PSS is used by the UE 104 to determine subframe / symbol timing and physical layer identity. The Secondary Synchronization Signal (SSS) is located within symbol 4 of a specific subframe of the frame. The SSS is used by the UE to determine the Physical Layer Cell Identity Group Number and radio frame timing. Based on the Physical Layer Identity and Physical Layer Cell Identity Group Number, the UE can determine the Physical Cell Identifier (PCI). Based on the PCI, the UE can determine the location of the aforementioned DM-RS. The Physical Broadcast Channel (PBCH), carrying the Master Information Block (MIB), can logically group with the PSS and SSS to form a Synchronization Signal (SS) / PBCH block (also known as an SS block (SSB)). The MIB provides the number of RBs in the system bandwidth and the System Frame Number (SFN). The Physical Downlink Shared Channel (PDSCH) carries user data, broadcast system information not transmitted via the PBCH (such as the System Information Block (SIB)), and paging messages.

[0054] As in Figure 2CAs explained, some REs carry DM-RS for channel estimation at the base station (indicated as R for a specific configuration, but other DM-RS configurations are possible). The UE can transmit DM-RS for the Physical Uplink Control Channel (PUCCH) and DM-RS for the Physical Uplink Shared Channel (PUSCH). The PUSCH DM-RS can be transmitted in the first or first two symbols of the PUSCH. The PUCCH DM-RS can be transmitted in different configurations depending on whether a short or long PUCCH is being transmitted and on the specific PUCCH format used. The UE can transmit a probe reference signal (SRS). The SRS can be transmitted in the last symbol of a subframe. The SRS can have a comb structure, and the UE can transmit the SRS on one of the combs. The SRS can be used by the base station for channel quality estimation to enable frequency-dependent scheduling on the UL.

[0055] Figure 2D Examples of various UL channels within a subframe of the explanatory frame. The PUCCH can be located as indicated in one configuration. The PUCCH carries uplink control information (UCI), such as scheduling requests, channel quality indicators (CQI), precoding matrix indicators (PMI), rank indicators (RI), and hybrid automatic repeat request (HARQ) ACK / NACK feedback. The PUCCH carries data and may additionally be used to carry buffer status reports (BSR), power clearance reports (PHR), and / or UCI.

[0056] Figure 3This is a block diagram showing the communication between base station 310 and UE 350 in the access network. In the DL, IP packets from EPC 160 can be provided to controller / processor 375. Controller / processor 375 implements Layer 3 and Layer 2 functionality. Layer 3 includes the Radio Resource Control (RRC) layer, and Layer 2 includes the Serving Data Adaptation Protocol (SDAP) layer, Packet Data Convergence Protocol (PDCP) layer, Radio Link Control (RLC) layer, and Media Access Control (MAC) layer. The controller / processor 375 provides RRC layer functionality associated with broadcasting system information (e.g., MIB, SIB), RRC connection control (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), inter-Radio Access Technology (RAT) mobility, and measurement configuration of UE measurement reports; PDCP layer functionality associated with header compression / decompression, security (cryptography, cryptographic decoding, integrity protection, integrity verification), and handover support functions; RLC layer functionality associated with upper-layer packet data unit (PDU) delivery, error correction via ARQ, concatenation, segmentation and reassembly of RLC service data units (SDUs), resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing MAC SDUs onto transport blocks (TBs), demultiplexing MAC SDUs from TBs, scheduling information reporting, error correction via HARQ, priority handling, and logical channel priority differentiation.

[0057] Transmit (TX) processor 316 and receive (RX) processor 370 implement Layer 1 functionality associated with various signal processing functions. Layer 1, including the physical (PHY) layer, may include error detection on the transport channel, forward error correction (FEC) decoding / decoding of the transport channel, interleaving, rate matching, mapping to the physical channel, modulation / demodulation of the physical channel, and MIMO antenna processing. TX processor 316 processes the mapping to the signal constellation based on various modulation schemes (e.g., binary phase shift keying (BPSK), quadrature phase shift keying (QPSK), M-phase shift keying (M-PSK), M-quadrature amplitude modulation (M-QAM)). The encoded and modulated symbols may then be split into parallel streams. Each stream may then be mapped to an OFDM subcarrier, multiplexed with a reference signal (e.g., a pilot) in the time and / or frequency domains, and subsequently combined using an inverse fast Fourier transform (IFFT) to produce a physical channel carrying a time-domain OFDM symbol stream. The OFDM stream is spatially precoded to generate multiple spatial streams. Channel estimates from channel estimator 374 can be used to determine coding and modulation schemes and for spatial processing. The channel estimates can be derived from reference signals and / or channel condition feedback transmitted by UE 350. Each spatial stream can then be provided to a different antenna 320 via a separate transmitter 318TX. Each transmitter 318TX can use the corresponding spatial stream to modulate an RF carrier for transmission.

[0058] At UE 350, each receiver 354RX receives signals via its corresponding antenna 352. Each receiver 354RX recovers the information modulated onto the RF carrier and provides this information to the receive (RX) processor 356. The TX processor 368 and RX processor 356 implement Layer 1 functionality associated with various signal processing functions. The RX processor 356 can perform spatial processing on the information to recover any spatial stream destined for UE 350. If there are multiple spatial streams destined for UE 350, they can be combined by the RX processor 356 into a single OFDM symbol stream. The RX processor 356 then uses a Fast Fourier Transform (FFT) to transform the OFDM symbol stream from the time domain to the frequency domain. The frequency domain signal consists of a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols on each subcarrier, along with the reference signal, are recovered and demodulated by determining the signal constellation points most likely to be transmitted by base station 310. These soft decisions can be based on a channel estimate calculated by channel estimator 358. These soft decisions are then decoded and deinterleaved to recover the original data and control signals transmitted by base station 310 over the physical channel. This data and control signals are then provided to controller / processor 359, which implements layer 3 and layer 2 functionality.

[0059] The controller / processor 359 may be associated with a memory 360 that stores program code and data. The memory 360 may be referred to as a computer-readable medium. In the UL, the controller / processor 359 provides demultiplexing between transport and logical channels, packet reassembly, cipher decoding, header decompression, and control signal processing to recover IP packets from the EPC 160. The controller / processor 359 is also responsible for error detection using ACK and / or NACK protocols to support HARQ operation.

[0060] Similar to the functionality described in conjunction with DL transmissions performed by base station 310, controller / processor 359 provides RRC layer functionality associated with system information (e.g., MIB, SIB) capture, RRC connection, and measurement reporting; PDCP layer functionality associated with header compression / decompression and security (cryptography, cryptographic decoding, integrity protection, integrity verification); RLC layer functionality associated with upper-layer PDU delivery, error correction via ARQ, concatenation, segmentation, and reassembly of RLC SDUs, resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing MAC SDUs onto TBs, demultiplexing MAC SDUs from TBs, scheduling information reporting, error correction via HARQ, priority handling, and logical channel priority differentiation.

[0061] The channel estimate derived by the channel estimator 358 from the reference signal or feedback transmitted by the base station 310 can be used by the TX processor 368 to select an appropriate coding and modulation scheme and to facilitate spatial processing. The spatial stream generated by the TX processor 368 can be provided to different antennas 352 via separate transmitters 354TX. Each transmitter 354TX can use the corresponding spatial stream to modulate an RF carrier for transmission.

[0062] UL transmissions are processed at base station 310 in a manner similar to that described in conjunction with the receiver function at UE 350. Each receiver 318RX receives signals via its corresponding antenna 320. Each receiver 318RX recovers the information modulated onto the RF carrier and provides that information to the RX processor 370.

[0063] The controller / processor 375 may be associated with a memory 376 that stores program code and data. The memory 376 may be referred to as a computer-readable medium. In the UL, the controller / processor 375 provides demultiplexing between transport and logical channels, packet reassembly, cipher decoding, header decompression, and control signal processing to recover IP packets from the UE 350. IP packets from the controller / processor 375 may be provided to the EPC 160. The controller / processor 375 is also responsible for error detection using ACK and / or NACK protocols to support HARQ operation.

[0064] At least one of the TX processor 368, RX processor 356, and controller / processor 359 can be configured to perform and Figure 1 The various aspects of the combination of 198(1) and 198(2). Similarly, at least one of the TX processor 316, RX processor 370, and controller / processor 375 can be configured to perform with Figure 1 The MDT measurement and processing components 199 combine various aspects. Alternatively, in such Figure 3 In some of the configurations shown, any part or each of the MDT measurement and processing component 199, the MDT data transmission component 198(1), and the MDT measurement component 198(2) may be configured, in part or in whole, as one or more dedicated processors, or in other hardware implementations, such as those described above. Figure 1 Among the hardware implementations described.

[0065] The current implementation of MDT measurements is configured by the base station, executed and recorded by the UE, and transmitted to the base station as a single data file containing measurement report data for all configured measurement types. The UE transmits this single file to the base station when it requests a measurement report.

[0066] This conventional limitation has introduced increasingly intolerable constraints for the corresponding LTE and 5G-NR architectures. Over the past few years, from version 9 of the relevant 3GPP standards up to and including version 15, several new measurement types have been added to the MDT measurement reporting scheme. Because all measurement results for all measurement types are transmitted back to the network by the UE as a single, very large file, the rapid increase in the number of measurements requested by the network naturally results in measurement reports that are much larger than when the initial specification was first issued. When this file is transmitted back to the base station in response to information requests, file transfers deplete the UE's battery life, while also introducing additional network bandwidth consumption and depleting network resources.

[0067] A further drawback of the current approach involves the nature of the Radio Resource Control (RRC) connection, which can currently transmit messages with a maximum size of eight (8) kilobytes. Because a UE's MDT measurement report can range from hundreds of kilobytes to several megabytes or more (depending in part on the number of measurements stored in the file and the amount of data generated by these measurements during a specified interval), a single file must be segmented into several smaller 8KB segments and reconstructed on the receiving side. Other problems include this segmentation leading to undesirable occupancy of network processing resources, with back-to-back RRC signaling overhead accounting for a significant portion of data transmission.

[0068] Additionally, a single file must be filtered by the core network to divide it into multiple files, ensuring that each divided file contains only data related to one measurement type. This filtering is necessary because different clients or other network entities may require different types of measurement information. Only after this filtering process can data be forwarded to the necessary clients.

[0069] to this end, Figure 4 This is a conceptual diagram 400 illustrating an example of UE 402 establishing an RRC connection with a base station (eNB 406) and the base station forwarding measurement data to an operations and management (operation, supervision, and management / maintenance) facility 410. In response to a request from base station 406, UE 402 transmits an MDT measurement report as a large file over the established RRC connection 404. UE 402 may include one or more parameters from UE memory (such as, for example, a trace reference, trace recording session, or trace collection entity (TCE) identifier) ​​in the reported MDT data. Base station 406 (which may be an eNB, gNB, or other types of base stations enumerated above) can receive and reconstruct this file. Base station 406 can then extract one or more parameters to correlate data belonging to the same trace (MDT session) at the TCE. Base station 406 can use the TCE ID to obtain the TCE's IP address, which in turn identifies where the MDT data should be forwarded.

[0070] Still refer to Figure 4 Base station 406 can establish an O&M connection 408 to O&M entity 410, which can be an entity in the core network that performs measurement data filtering by type. The data can ultimately be delivered to the correct network entity, as described above.

[0071] Figure 5This is timing diagram 500, illustrating an example of the recorded MDT reporting procedure between UE 504 and the network, including base station 502 and TCE 506. An RRC connection can be established at 508. Then, at 510, the recorded measurement configuration can be executed, where base station 502 sends one or more messages to UE 504 specifying all types of MDT measurements that UE 504 should perform, the measurement interval for each measurement, and the total duration of the MDT measurement (see, for example, box 530). Thus, via signaling 510, base station 502 can configure UE 504 to perform each MDT measurement required by the network.

[0072] After configuring these MDT measurements, UE 504 can enter an idle state when the RRC connection is released at 512. During the idle state, UE 504 can perform measurements and record the results, as configured by base station 502. For example, UE 504 can perform MDT measurements in each recording interval until the recording duration timer expires, after which UE 504 can perform MDT measurements in another interval. For example, if the recording duration is ten minutes and the recording interval is 320 milliseconds (ms), then an MDT measurement can be performed once during each 320-ms interval, and this interval can be repeated for ten minutes. After all measurements are performed, a large amount of data corresponding to all measurement reports is ready to be sent.

[0073] Next, another RRC connection is established at 516 and completed at 518. During the RRC connection establishment, UE 504 may optionally provide an indication to base station 502 regarding the completion of measurement recording. At 520, base station 502 sends a UE Information Request to UE 504, requesting UE 504 to send an MDT measurement report. Notably, in signal 520, the base station may request the report without specifying the measurement type, as is customary. In response to UE Information Request 520, UE 504 may send a UE Information Response 522, in which a single MDT measurement report is transmitted as a single large file and segmented according to the requirements of each (currently a maximum of 8KB) RRC block. Multiple RRC segmented messages may be sent as discussed above, including all signaling overhead and the associated UE battery depletion, consuming network time until the file transfer is finally completed—only awaiting the next transmission by base station 502 and further filtering steps by the network.

[0074] At 524, base station 502 can obtain the address of the TCE from the TCEID, as described above. After sending the MDT file ready notification 526 to TCE 506, base station 502 can continue to pass the MDT file to TCE 506 at 528, whereby the file can be further forwarded to the network core or its parts as needed to filter the file and provide individual measurement results to the correct entities.

[0075] Figure 6 This is a timing diagram 600 illustrating an example of a recorded MDT report, including the transmission or non-real-time streaming of a requested type of measurement report from UE 602 to a network including base station 604 and TCE 606. As previously described, an RRC connection establishment procedure (608) can be initiated. At 639, the network can issue a UE capability query 639. The UE can respond with a UE capability information message 641, which may include new bits to indicate the UE capability to stream the recorded MDT for the requested MDT measurement type. While non-real-time streaming can be used, this feature is optional and the data can be transmitted over the network as a structured file or otherwise. As described in box 645, the UE capability signal 641 can alternatively be included elsewhere, for example in subsequent RRC connection establishment and setup signal exchanges 616 and 618, and it does not need to be included in the current RRC connection. In some configurations, base station 604 is already aware of the capability and it does not need to be explicitly conveyed by UE 602. Thus, at 643, the RRC connection can be verified and completed. At point 610, the base station communicates with UE 602 and indicates the type of measurement required by the network, as well as the measurement duration and interval, such as... Figure 5 As shown in the image.

[0076] At 612, the RRC connection can be released, and UE 602 can enter an idle state. At 614, UE 602 begins recording, and UE 602 stores and accumulates MDT measurement results related to the measurements configured by base station 604 in 610 within its memory. In various implementations, instead of storing all measurement data in one file, UE 602 can store data corresponding to a single type of measurement result in one corresponding file, and UE 602 can store data corresponding to another type of measurement result in another file, and so on for the remaining measurement intervals within a specified duration.

[0077] At 616, another RRC connection can be established. At 618, UE 602 can indicate that the connection establishment is complete, and in doing so, UE 602 can indicate to base station 604 that the MDT measurement results are ready. In one aspect of this disclosure, base station 604 can perform an MDT measurement type request at 620. Instead of... Figure 5The request for the entire MDT measurement report is as described in request 520. Figure 6 Base station 604 can request only the data corresponding to the measurement type required by the network at the time of the request. MDT measurement type requests may include, in some configurations, an indication that the base station "has data streaming capability," meaning that the base station supports the ability to receive non-real-time measurement type-specific data streams, rather than regular full-packet data file transmissions. As mentioned above, non-real-time streaming is not required, and the data can be transmitted on the control plane, for example, using conventional transmission techniques.

[0078] At 621, UE 602 may optionally send an unready / unavailable indication 621 to base station 604. In this case, the device may revert to legacy technology, or in some configurations, the device may omit MDT exchange entirely. Otherwise, in one implementation, UE 602 responds by sending a non-real-time data stream or by directly sending data 622 that corresponds only to measurement report data for the measurement type requested by base station 604.

[0079] In various configurations, base station 604 may send a request in MDT measurement type request 620 for two or more MDT measurements required by the network at the time of request. Here, UE 602 sequentially sends relevant measurement reports, with data corresponding to one type of measurement at a time. Thus, in this scenario, at 622, UE 602 can respond by sending first data including data corresponding to the requested measurement of the first type, and subsequently sending second data including data corresponding to the requested measurement of the second type, and so on, until data for all types of measurements requested by base station 604 in request 620 has been transmitted.

[0080] In various configurations, base station 604 may request a structured measurement report specific to a particular MDT measurement type in step 620 (as described above), and in response, UE 602 may send data including a report with results regarding that measurement report. At a later time, for example, when the network notifies base station 604 that this information is necessary, base station 604 may make another MDT measurement type request for data corresponding to another type of MDT measurement, and in response, UE 602 may respond at 622 by sending data corresponding to that MDT measurement type. At various stages during the same or different RRC connections at subsequent times, base station 604 may issue additional MDT measurement type requests 620, requesting data corresponding to other measurement types. Thus, these requests in the implementation can be made sequentially according to one or more data types, and data is requested and sent in a structured manner only when the network needs it, rather than being sent arbitrarily as a large measurement report.

[0081] After receiving a measurement report corresponding to the requested measurement type(s), base station 604 can obtain the TCE address (624) from the TCEID sent along with the data. Base station 604 can notify TCE entity 606 of the expected transmission at 626, and then base station 604 can transmit MDT data to TCE 606 at 628, and the data can be forwarded to entities that need the information.

[0082] Figure 6 This technology offers several advantages to both the UE 602 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 network's requirement for filtering data can be avoided or reduced, and instead, data can be sent directly to the network entities that require it. Furthermore, because data can optionally be sent by the UE 602 in non-real-time streams depending on the type of MDT measurement, these streams are typically much smaller and may not exceed the maximum RRC data size, meaning the requirement to segment data into 8KB blocks is reduced or eliminated. This, in turn, minimizes the RRC signaling overhead required by the network, as different data segments do not need to be managed with corresponding RRC control information. Furthermore, bandwidth and network resources are saved because each measurement report for a single type of MDT measurement can correspond to a single non-real-time data stream (or the data can simply be transmitted using conventional techniques). This technology also eliminates the conventional problems associated with UE battery depletion, as the streamed files are significantly smaller, and the UE battery status can be revisited if needed after successfully transmitting a single data stream.

[0083] Although only data for the requested type of measurement is sent, the UE performs and records all measurements configured by the base station as before. Therefore, the UE retains this information for its own use, and this allows the network to be responsible for determining what type of MDT data is needed and when, rather than the UE (which has far more limited processing resources than the network) having to keep track of this information. For example, the network can issue an MDT measurement type request corresponding to the information it needs, and the UE can send that information as a data report formatted to respond to a specific MDT request from the base station. The remaining measurement reports can be stored in the UE unless and until that information is needed.

[0084] Figure 7 This is a flowchart 700 of a wireless communication method. At step 702, the UE (such as...) Figure 1 , 3 UE104, 350, or 602 (or UE104, 350, or 602) can be accessed from base stations (such as respectively) Figure 1 , 3The UE (or base station 102 / 180, 310, or 604) receives configuration information from the base station for multiple different MDT measurement types. This information can specify the measurement interval and duration. These measurement types can typically represent all the different measurement types that the network expects to need data for in subsequent time periods. At step 704, the UE can optionally send a message to the base station regarding the UE's ability to send a non-real-time stream of the measured MDT data for a measurement type. In other configurations, the data can be transmitted directly without using MDT streaming. As mentioned above, this information can be included elsewhere in the process flow, and in some configurations it may already be understood.

[0085] Next, at step 706, the UE can make or execute the corresponding multiple MDT measurements specified by the base station in step 702 during the UE's subsequent idle period. At step 708, which can be executed concurrently with the procedure of step 706, the UE can record these measurements for the corresponding interval period by saving the data obtained from each measurement in a separate file. The UE can perform measurements for all configured measurement types until the total specified measurement duration is reached.

[0086] At step 710, the UE may receive from the base station a request for structured minimized drive test (MDT) data, the requested data corresponding to at least one type of MDT measurement specified by the base station from a plurality of available MDT measurement types that can be performed by the UE. For example, in some embodiments, the UE may receive the request for MDT data from the base station during a time period such as during a subsequent RRC connection, the request specifying a report for at least one type of MDT measurement from a large number of MDT measurement types. In response to step 710, the UE may send to the base station at step 712 data including the results corresponding to the specified at least one type of MDT measurement. For example, in some embodiments, the UE may send to the base station at step 712 a report having the requested measurement type. If the base station requests data corresponding to more than one type of measurement, the UE may sequentially 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.

[0087] The base station may optionally include an indication in the message of step 710 regarding its support for receiving MDT streams. In other configurations, the base station may provide this information at an earlier time.

[0088] If, during some specified period of network operation, for example, no further MDT measurement type request is received from the base station (step 714), the process may end at 719, at least until another such request is made or the UE receives another configuration. However, if at step 714 the UE receives another request for data corresponding to another type (or other type) of MDT measurement required by the network, the UE may again send a non-real-time data stream corresponding to one measurement type, then send another data stream corresponding to the other measurement type (if applicable), and so on, until data is provided to the base station.

[0089] Figure 8 From base stations (such as those described above, for example) Figure 7 , 6 A flowchart of a wireless communication method from the perspective of a base station (identified in 3 or 1). At step 802, the base station may, during an RRC connection, transmit data to the UE (such as those described above). Figure 7 , 6 The base station transmits an MDT measurement configuration for multiple MDT measurements to be performed and recorded by the UE (identified in step 3 or 1). Subsequently, upon receiving notification from the UE that the configured measurements have been recorded, for example, at step 804, the base station may send a request to the UE for structured Minimized Drive Test (MDT) data, the requested MDT data corresponding to at least one type of MDT measurement specified by the base station from multiple available MDT measurement types that can be performed by the UE. For example, in some embodiments, the base station may send a structured MDT measurement type request for a type of MDT measurement data to the UE during another RRC connection. In some configurations, the MDT measurement type request may include data bits or other indications about the base station's support for receiving MDT information in data streams that differ depending on the measurement type.

[0090] In response to request (804), the base station may receive data from the UE at step 806 including results corresponding to at least one type of MDT measurement specified. For example, in some embodiments, the base station may receive non-real-time data streams or other types of transmissions corresponding to the requested type of measurement from the UE. If the base station identifies multiple measurement types at request 804, the base station may receive multiple sequential data streams, each corresponding to a measurement report for a single measurement type identified by the base station. Further at step 806, the base station may receive data from the UE including results corresponding to at least one type of MDT measurement specified. For example, the base station may receive one or more data streams or other transmissions and save data from each of them to a separate file.

[0091] The base station can also identify the TCE address from the data stream or other transmission along with the requested MDT data. Accordingly, at step 808, the base station can forward the requested MDT data to the core network via the Trace Collection Entity (TCE) for distribution to clients. For example, the base station can extract information from each of one or more data streams or other data transmissions to identify the intended TCE recipient, as described above. Using this information, the base station can send received data in the data stream or other transmission type to the TCE for forwarding to the appropriate client or entity that may need the information. In some implementations, the base station can be configured to directly transmit received data to the entity requesting data for that measurement type. If the base station receives multiple data streams corresponding to requests for multiple measurement types in sequence, in an exemplary implementation, the base station can, for example, send each received data stream (e.g., in file form) to the TCE for routing to the intended entity.

[0092] The base station may subsequently determine, or may be notified by the network, that it may require one or more additional measurement reports corresponding to additional data types configured by the base station (810). If so, the base station may return to step 804 to issue a new MDT measurement type request identifying the new data type, and the process resumes from step 804 as described above. If no other MDT data is requested, the process ends (819) until another request is made, or the UE is reconfigured, etc.

[0093] In an optional implementation, a new information element can be added as an information element (IE) that represents the basis for writing code to identify the type of measurement(s) for which it needs to report measurements. In this example implementation, an octet bit string (XXXXXXXX) can be used to enable the base station to identify the type of measurement. Thus, for example, a Bluetooth measurement can be identified by the fourth bit position in the octet (i.e., XXXX). X XXX) can be used to represent WLAN measurements, and the seventh bit position (X) can be used to represent WLAN measurements. X The measurement type is represented by (XXXXXX). The measurement type can be enabled by setting the relevant bits to "1" or "true". In the example where the base station requests MDT information in the MDT information type request for Bluetooth and WLAN MDT tests, the base station can provide the bit string 01001000, for example, which identifies the types to be tested.

[0094] For example, the MDT information type request may optionally include the following IEs for 5G NR networks.

[0095]

[0096]

[0097] In the examples above, the octet can be predefined to have any value from 0 to 7. Specifying 1 enables the flow ID corresponding to the MDT measurement type. In configurations where additional measurement types are required, larger bit strings or multiple bit strings can be used. Code or hardware that implements this IE or similar IE can be used to define the MDT measurement type to be selected in the actual device. MDT flows from the UE can be tagged with flow IDs (e.g., cellular measurements, MDT flows (serving and neighboring), IRAT measurement flows, MBSFN MDT measurement flows, WLAN MDT measurement flows, BT MDT measurement flows, etc.) to distinguish different types of MDT information.

[0098] As mentioned above, the base station can notify the UE that the base station supports selective MDT reporting capabilities. Data bits or other indicators can be added to the base station's MDT measurement type report. Accordingly, IEs indicating non-real-time MDT streaming support can optionally be added as follows:

[0099] }

[0100] UE-NR-Capability-17xy::=sequence{

[0101] Logged MDT-MeasurementType_Support Boolean {True / False} nonCriticalExtension sequence {} (optional)

[0102] }

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

[0104] It should be understood that the IEs described above are merely exemplary, and other IEs or hardware and software implementations may be used in the various configurations described in this disclosure. Therefore, these IEs are not intended to be restrictive, but are purely illustrative in nature.

[0105] Figure 9This is an illustration of an example hardware implementation 900 of example UE 902. UE 902 may include a cellular baseband processor 904 (also referred to as a modem) coupled to a cellular RF transceiver 922 and one or more Subscriber Identity Module (SIM) cards 920, an application processor 906 coupled to a Secure Digital Card (SD) card 908 and a screen 910, a Bluetooth module 912, a Wireless Local Area Network (WLAN) module 914, a Global Positioning System (GPS) module 916, and a power supply 918. The cellular baseband processor 904 can communicate with UE 104 and / or base station 102 / 180 via the cellular RF transceiver 922. The cellular baseband processor 904 may include computer-readable medium / memory. The computer-readable medium / memory may be non-transient. The cellular baseband processor 904 may be responsible for general processing, including the execution of software stored on the computer-readable medium / memory. When executed by the cellular baseband processor 904, the software may cause the cellular baseband processor 904 to perform various functions described herein. Computer-readable media / memory can also be used to store data manipulated by the cellular baseband processor 904 during software execution. The cellular baseband processor 904 may further include a receiving component 930, a communication manager 932, and a transmission component 934. The communication manager 932 may include one or more of the described components. Components within the communication manager 932 may be stored in computer-readable media / memory and / or configured as hardware within the cellular baseband processor 904. The cellular baseband processor 904 may be a component of the UE 350 and may include memory 360 and / or at least one of the following: a TX processor 368, an RX processor 356, and a controller / processor 359. The UE 902 may include a modem chip and the cellular baseband processor 904, and may include the additional modules of the UE 902 discussed above.

[0106] The communication manager 932 may include a measurement type component 940, which may be internal to the UE and may be used, as needed, to store data and codes for assisting in the performance of MDT measurements. The communication manager 932 may further include an MDT measurement component 942, which may optionally receive input in the form of information and codes from component 940 for performing different measurements, and may also optionally receive information (such as MDT configuration from the base station) from receiving component 930. The MDT measurement component 942 may be configured to receive information including, Figure 7 Step 702 and Figure 6 The MDT configuration information for the measurement interval and measurement duration described in signal 610. The MDT measurement component 942 can be configured to perform different types of MDT measurements on the measurement interval and MDT duration provided by base station 180, such as... Figure 7 Step 706 and Figure 6As shown in box 614. The MDT measurement component 942 can also use input from the measurement type component 940 in the form of measurement information that varies from UE to UE. The MDT measurement component 942 is also configured to perform these measurements when the UE 104 is in an idle state. The MDT measurement component 942 can be configured to record measurement data, including storing information corresponding to different types of measurements into different corresponding data files, for example, as in combination Figure 7 Steps 706 and 708 and Figure 6 The boxes 612 and 614 are described.

[0107] Communication manager 932 may further include MDT non-real-time data stream component 944, which can receive input in the form of measurement data from component 942 and can be configured to receive MDT measurement type requests from the base station during RRC connection, for example, as in combination with Figure 7 Steps 710 and Figure 6 The signal 620 describes the MDT non-real-time data stream component 944. It can be configured to receive an indication in a measurement type request regarding base station support for receiving data streams that vary depending on the MDT type, for example, as described in... Figure 7 As shown in step 7. In response to one of these requests, the MDT non-real-time data stream component 944 can be configured to send a non-real-time data stream to the base station 180, the non-real-time data stream including measurement data corresponding to the information requested in the MDT measurement type request, such as... Figure 7 Step 712 and Figure 6 The signal 622 is shown. Component 944 can also be configured to: in cases where the base station identifies more than one type of MDT measurement in the MDT measurement type request, transmit different non-real-time data streams during successive time periods, wherein each data stream corresponds to a data type, for example, such as Figure 7 Steps 710, 712, and 714 and Figure 6 Signal 622 and box 647 are shown.

[0108] The communication manager 932 may further include an RRC component 946, which receives input from the receiving component 930 in the form of an RRC connection / release request and is configured to establish or release an RRC connection. The communication manager 932 may further include a capability reporting component 948, which receives input from components 942 and 944 in the form of a configuration message or an MDT measurement type request and is configured to optionally send an indication to the base station regarding the UE's ability to perform data streaming depending on the MDT measurement type, for example, as in combination with... Figure 7 Step 704 and Figure 6The signal 641 and block 645 are described. The communication manager 932 may further include a ready / not ready component 950 that receives input in the form of an MDT measurement type request from the MDT non-real-time data stream component 944 and is configured to indicate to the base station that it is ready or not ready or unable to send the requested data stream, for example, as... Figure 6 The signal 621 is shown.

[0109] UE can include executing separately Figure 6 and 7 The aforementioned sequence diagrams and flowcharts are additional components of each block of the algorithm. Thus, Figure 6 and 7 Each block in the aforementioned timing diagrams and flowcharts can be executed by a component, and the UE can include one or more of these components. These components can be one or more hardware components specifically configured to execute the process / algorithm, implemented by a processor configured to execute the process / algorithm, stored in a computer-readable medium for implementation by a processor, or some combination thereof.

[0110] In one configuration, UE 902, and particularly cellular baseband processor 904, includes: means for receiving a request for Minimized Drive Test (MDT) data from a base station, the MDT data corresponding to a type of measurement performed by the UE; means for sending a data stream including the requested data to the base station; means for performing a plurality of MDT measurements specified by the base station; and means for storing each of the plurality of measurements in a separate file. The aforementioned means may be one or more of the aforementioned components in UE 902 configured to perform the functions described by the aforementioned means. As described above, UE 902 may include TX processor 368, RX processor 356, and controller / processor 359. Thus, in one configuration, the aforementioned means may be TX processor 368, RX processor 356, and controller / processor 359 configured to perform the functions described by the aforementioned means.

[0111] Figure 10Figure 1000 illustrates an example of the hardware implementation of base station 1002. Base station 1002 includes a baseband unit 1004. Baseband unit 1004 can communicate with UE 104 via a cellular RF transceiver. Baseband unit 1004 may include computer-readable medium / memory. Baseband unit 1004 is responsible for general processing, including the execution of software stored on computer-readable medium / memory. When executed by baseband unit 1004, the software causes baseband unit 1004 to perform the various functions described above. Computer-readable medium / memory may also be used to store data manipulated by baseband unit 1004 during software execution. Baseband unit 1004 further includes a receiving component 1030, a communication manager 1032, and a transmitting component 1034. Communication manager 1032 includes one or more of the illustrated components. Components within communication manager 1032 may be stored in computer-readable medium / memory and / or configured as hardware within baseband unit 1004. The baseband unit 1004 may be a component of the base station 310 and may include a memory 376 and / or at least one of the following: a TX processor 316, an RX processor 370, and a controller / processor 375.

[0112] Communication manager 1032 may include MDT configuration component 1040, which is configured to send MDT configuration messages to the UE to configure multiple different MDT measurement types for the UE to perform, and to provide the UE with specified measurement intervals and MDT measurement durations, for example, as combined with Figure 8 Step 802 and Figure 6 Steps 610 and 630 are described. The communication manager 1032 further includes an MDT data stream component 1042 that receives input from the MDT configuration component 1040 in the form of MDT measurement configuration type, measurement parameters, and measurement intervals and durations, and is configured to send an MDT measurement type message to the UE, for example, in conjunction with... Figure 8 Steps 804 and 810 and Figure 6 The signal 620 is described. The communication manager 1032 further includes an MDT processing component 1044, which is configured to receive input in the form of data streams from component 1042, and is configured to receive these data streams and optionally save them to individual files, for example, as in combination. Figure 8Step 806 is described. The communication manager 1032 may further include an RRC component 1046 that receives input in the form of an RRC connection / release request from the receiving component 1030 and is configured to establish or release an RRC connection. The communication manager 1032 further receives a network component 1048 configured to receive input in the form of a data stream from component 1042 and / or receive a data file from component 1044, and extract TCE information from the data to identify the TCE address used to send the data file to the correct TCE entity, for example, as in combination with... Figure 8 Step 808 and Figure 6 Signals 622, 626, and 628, as well as block 624, are described. Communication manager 1032 further receives legacy enable component 1050, which receives input from receiving component 1030 from the UE in the form of information regarding measurement type data streaming capability or lack thereof.

[0113] Base stations may include those that perform separate operations. Figure 6 and 8 The aforementioned sequence diagrams and flowcharts are additional components of each block of the algorithm. Thus, Figure 6 and 8 Each block in the aforementioned flowchart can be executed by a component, and the base station can include one or more of these components. These components can be one or more hardware components specifically configured to execute the process / algorithm, implemented by a processor configured to execute the process / algorithm, stored in a computer-readable medium for implementation by a processor, or some combination thereof.

[0114] In one configuration, base station 1002, and particularly baseband unit 1004, includes: means for sending a request to a UE for minimized drive test (MDT) data corresponding to a type of measurement performed by the UE; and means for receiving a stream of requested data corresponding to that type of measurement. The aforementioned means may be one or more of the aforementioned components in base station 1002 configured to perform the functions described by the aforementioned means. As described above, base station 1002 may include TX processor 316, RX processor 370, and controller / processor 375. Thus, in one configuration, the aforementioned means may be TX processor 316, RX processor 370, and controller / processor 375 configured to perform the functions described by the aforementioned means.

[0115] As mentioned, one or more aspects of this disclosure can enable a network to selectively identify requested data for MDT measurements associated with it at the time of request, thereby reducing or eliminating network resources spent on filtering data. Data can also be streamed from the UE on a type-dependent basis. As a result, the data stream can be much smaller than a regular data file that includes all measurements, and the possibility of requiring segmentation of the streamed data is reduced or eliminated. This, in turn, reduces or eliminates resource bottlenecks associated with excessive RRC signaling. Additionally, issues related to battery depletion can be mitigated or resolved.

[0116] The following aspects are merely illustrative and may be combined with other embodiments or teachings described herein without limitation.

[0117] Aspect 1 is a method for wireless communication at a user equipment (UE), comprising: receiving from a base station a request for structured minimized drive test (MDT) data, the requested data corresponding to an MDT measurement specified by the base station from at least one type of a plurality of available MDT measurement types that can be performed by the UE; and transmitting to the base station data including the results corresponding to the at least one type of MDT measurement.

[0118] Aspect 2 is the method of aspect 1, wherein sending the data to the base station includes sending a structured report identifying the at least one MDT measurement of a specified type.

[0119] Aspect 3 is a method of either Aspect 1 or 2, further comprising performing a measurement corresponding to at least one type of MDT measurement specified.

[0120] Aspect 4 is a method of any of Aspects 1-3, further comprising sending the data to the base station on the control plane.

[0121] Aspect 5 is a method of any of Aspects 1-4, wherein the requested MDT data includes results of at least one type of MDT measurement specific to the base station.

[0122] Aspect 6 is a method of any of Aspects 1-5, wherein the request for the structured MDT data includes an indication that the base station supports non-real-time streaming of MDT data.

[0123] Aspect 7 is a method of any of Aspects 1-6, further comprising sending to the base station information including capability bits indicating support for selective MDT reporting.

[0124] Aspect 8 is a method of any of Aspects 1-7, further comprising, after transmitting the data, receiving from the base station another request for structured MDT data, the structured MDT data including results corresponding to another type of MDT measurement specified by the base station; and transmitting to the base station the requested data corresponding to the other type of MDT measurement.

[0125] Aspect 9 is a method of any of Aspects 1-8, further comprising: performing a measurement corresponding to the at least one type of MDT measurement specified by the base station; storing the result of the measurement in a separate file; and sending the separate file including the result to the base station.

[0126] Aspect 10 is a method of any of Aspects 1-9, further comprising sending a message to the base station indicating that the UE is not ready to transmit the requested MDT data, wherein when the UE is ready, these results are later sent to the base station.

[0127] Aspect 11 is a method of any of Aspects 1-10, wherein the message includes a UE assistance information message sent in response to a request for the structured MDT data, for notifying the base station that the UE is currently not ready or unable to transmit the requested MDT data.

[0128] Aspect 12 is a method of any of Aspects 1-11, wherein these results are sent using a non-real-time data stream.

[0129] Aspect 13 is a user equipment (UE) device that includes means for performing the functions of any of Aspects 1-12.

[0130] Aspect 14 is a computer-readable medium storing executable code that, when executed by a processor, causes the processor to perform any of aspects 1-12.

[0131] Aspect 15 is a user equipment (UE) including a memory and at least one processor coupled to the memory, and the at least one processor is configured to: receive from a base station a request for structured minimized drive test (MDT) data, the requested data corresponding to an MDT measurement specified by the base station from at least one type of a plurality of available MDT measurement types that can be performed by the UE; and transmit to the base station data including the results corresponding to the at least one type of MDT measurement specified.

[0132] Aspect 16 is the UE of aspect 15, wherein the at least one processor is further configured to send a structured report identifying the at least one MDT measurement of a specified type.

[0133] Aspect 17 is the UE of either Aspect 15 or 16, wherein the at least one processor is further configured to perform a measurement corresponding to at least one type of MDT measurement specified.

[0134] Aspect 18 is a UE of any of Aspects 15-17, wherein the at least one processor is further configured to transmit the data to the base station on the control plane.

[0135] Aspect 19 is a UE of any of Aspects 15-18, wherein the requested MDT data includes the results of at least one type of MDT measurement specific to the base station.

[0136] Aspect 20 is a UE of any of Aspects 15-19, wherein the at least one processor is further configured to: perform a measurement corresponding to the at least one type of MDT measurement specified by the base station; store the result of the measurement in a separate file; and send the separate file including the results to the base station.

[0137] Aspect 21 is a UE of any of Aspects 15-20, wherein the at least one processor is further configured to send a message to the base station indicating that the UE is not ready to transmit the requested MDT data, wherein when the UE is ready, these results are later sent to the base station.

[0138] Aspect 22 is a UE of any of Aspects 15-21, wherein the message includes a UE assistance information message sent in response to a request for the structured MDT data and is configured to notify the base station that the UE is currently not ready or unable to transmit the requested MDT data.

[0139] Aspect 23 is the UE of any of Aspects 15-22, where these results are sent using non-real-time data streaming.

[0140] Aspect 24 is a wireless communication method for a base station, comprising: sending a request to a UE for structured minimized drive test (MDT) data, the requested data corresponding to an MDT measurement specified by the base station from at least one type of available MDT measurement types that can be performed by the UE; and receiving from the UE data including the results of the MDT measurement corresponding to the specified at least one type.

[0141] Aspect 25 is the method of aspect 24, further including forwarding the requested MDT data to the core network via a trace collection entity (TCE) for distribution to clients.

[0142] Aspect 26 is a method of either Aspect 24 or 25, wherein the requested MDT data includes multiple measurement types.

[0143] Aspect 27 is a method of any of Aspects 24-26, wherein the received data includes a structured report identifying at least one type of MDT measurement specified.

[0144] Aspect 28 is a method of any of Aspects 24-27, further comprising, after receiving the requested MDT data, sending to the UE another request for structured MDT data, the structured MDT data including results corresponding to another specified type of MDT measurement; and receiving from the UE data corresponding to the other specified type of MDT measurement.

[0145] Aspect 29 is a method of any of Aspects 24-28, further comprising receiving the data from the UE on the control plane.

[0146] Aspect 30 is a method of any of Aspects 24-29, wherein the requested MDT data includes the results of a measurement specific to a type specified by the base station.

[0147] Aspect 31 is a method of any of Aspects 24-30, further comprising receiving from the UE a message indicating that the UE is not ready to transmit the requested MDT data, wherein the data is later received at the base station.

[0148] Aspect 32 is a device at a base station that includes means for performing the functions of any of aspects 24-30.

[0149] Aspect 33 is a computer-readable medium storing executable code that, when executed by a processor, causes the processor to perform any of aspects 24-30.

[0150] Aspect 34 is a base station including a memory and at least one processor coupled to the memory, and the at least one processor is configured to: send a request to a UE for structured minimized road test (MDT) data, the requested MDT data corresponding to an MDT measurement specified by the base station from at least one type of available MDT measurement types that can be performed by the UE; and receive from the UE data including the results of the MDT measurement corresponding to the specified at least one type.

[0151] Area 35 is a base station of Area 34, wherein the processor is further configured to forward the requested MDT data to the core network via the Trace Collection Entity (TCE) for distribution to clients.

[0152] Aspect 36 is a base station of either Aspect 34 or 35, wherein the requested MDT data includes multiple measurement types.

[0153] Aspect 37 is a base station of any of Aspects 34-36, wherein the received data includes a structured report identifying at least one type of MDT measurement type specified.

[0154] Aspect 38 is a base station of any of Aspects 34-37, wherein the processor is further configured to: after receiving requested MDT data, send another request to the UE for structured MDT data corresponding to another specified type of MDT measurement; and receive data from the UE corresponding to the other specified type of MDT measurement.

[0155] Aspect 39 is a base station of any of Aspects 34-38, wherein the at least one processor is further configured to receive the data from the UE on the control plane.

[0156] Aspect 40 is a base station of any of Aspects 34-39, wherein the requested MDT data includes the results of a measurement specific to a type specified by that base station.

[0157] Aspect 41 is a base station of any of Aspects 34-40, wherein the received data includes a structured report identifying the results of at least one type of MDT measurement specified.

[0158] Aspect 42 is a base station of any of Aspects 34-41, wherein the at least one processor is further configured to receive from the UE a message indicating that the UE is not ready to transmit the requested MDT data.

[0159] Aspect 43 is a user equipment (UE) including a memory and at least one processor coupled to the memory, and the at least one processor is configured to perform any of aspects 1-12.

[0160] It should be understood that the specific order or hierarchy of the boxes in the disclosed process / flowcharts is an explanation of exemplary methods. It should be understood that the specific order or hierarchy of the boxes in these process / flowcharts can be rearranged based on design preferences. Furthermore, some boxes may be combined or omitted. The appended method claims present the elements of the various boxes in an exemplary order and are not intended to be limited to the specific order or hierarchy presented.

[0161] The preceding description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will readily be understood by those skilled in the art, and the universal principles defined herein may be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects shown herein, but are to be granted the full scope consistent with the language of the claims, wherein references to the singular form of an element, unless specifically stated otherwise, are not intended to mean “one and only one,” but rather “one or more.” Terms such as “if,” “when,” and “at the time of,” should be interpreted as meaning “under this condition,” rather than implying a direct temporal relationship or reaction. That is, these phrases (e.g., “when”) do not imply an immediate action in response to the occurrence of an action or during the occurrence of an action, but only imply that an action will occur when a condition is met, without requiring a specific or immediate temporal constraint for the action to occur. The term “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” is not necessarily to be construed as superior to or overriding other aspects. Unless specifically stated otherwise, the term “some / a” refers to one or more. Combinations such as "at least one of A, B, or C", "one or more of A, B, or C", "at least one of A, B, and C", "one or more of A, B, and C", and "A, B, C, or any combination thereof" include any combination of A, B, and / or C, and may include multiple A, multiple B, or multiple C. Specifically, combinations such as "at least one of A, B, or C", "one or more of A, B, or C", "at least one of A, B, and C", "one or more of A, B, and C", and "A, B, C, or any combination thereof" may be only A, only B, only C, A and B, A and C, B and C, or A and B and C, wherein any such combination may include one or more members of A, B, or C. Elements of all aspects described throughout this disclosure that are presently or hereafter known to those skilled in the art are expressly incorporated herein by reference and are intended to be covered by the claims. Furthermore, nothing disclosed herein is intended as a donation to the public, whether or not such disclosure is expressly stated in the claims. The terms “module,” “mechanism,” “element,” and “device” are not necessarily substitutes for the term “apparatus.” Thus, no claim element should be interpreted as an apparatus plus a function unless the element is explicitly stated using the phrase “apparatus for…”.

Claims

1. A wireless communication method for a user equipment (UE), comprising: The network entity receives a request for structured minimized drive test MDT data, the requested data corresponding to at least one type of MDT measurement specified by the network entity from a plurality of available MDT measurement types that can be performed by the UE, wherein the request for the structured MDT data includes an indication that the network entity supports non-real-time streaming MDT data. as well as The data, which includes the results of MDT measurements corresponding to at least one specified type, is sent to the network entity.

2. The method of claim 1, wherein sending the data to the network entity further comprises sending a structured report identifying at least one type of MDT measurement.

3. The method of claim 1, further comprising performing a measurement corresponding to at least one type of MDT measurement specified therefor.

4. The method of claim 1, further comprising sending the data to the network entity on the control plane.

5. The method of claim 1, wherein the requested MDT data includes results of at least one type of MDT measurement specific to the network entity.

6. The method of claim 1, further comprising sending information to the network entity including capability bits indicating support for selective MDT reporting.

7. The method of claim 1, further comprising: After sending the data, another request for structured MDT data is received from the network entity, which includes results corresponding to another type of MDT measurement specified by the network entity; as well as Send the requested data corresponding to the other type of MDT measurement to the network entity.

8. The method of claim 1, further comprising: Perform measurements corresponding to at least one type of MDT measurement specified by the network entity; The results of the measurement are saved in a separate file; as well as Send the separate file containing the results to the network entity.

9. The method of claim 1, further comprising: Send a message to the network entity indicating that the UE is not ready to transmit the requested MDT data. When the UE is ready, the result is later sent to the network entity.

10. The method of claim 9, wherein the message includes a UE assistance information message sent in response to a request for the structured MDT data, for notifying the network entity that the UE is currently not ready or unable to transmit the requested MDT data.

11. The method of claim 1, wherein the result is transmitted using a non-real-time data stream.

12. A user equipment (UE), comprising: Memory; as well as At least one processor coupled to the memory, and the at least one processor is configured to: The network entity receives a request for structured minimized drive test MDT data, the requested data corresponding to at least one type of MDT measurement specified by the network entity from a plurality of available MDT measurement types that can be performed by the UE, wherein the request for the structured MDT data includes an indication that the network entity supports non-real-time streaming MDT data. as well as The data, which includes the results of MDT measurements corresponding to at least one specified type, is sent to the network entity.

13. The UE of claim 12, wherein the at least one processor is further configured to send a structured report of at least one type of MDT measurement identified by the identifier.

14. The UE of claim 12, wherein the at least one processor is further configured to perform a measurement corresponding to at least one type of MDT measurement specified therein.

15. The UE of claim 12, wherein the at least one processor is further configured to transmit the data to the network entity on the control plane.

16. The UE of claim 12, wherein the requested MDT data includes results of at least one type of MDT measurement specific to the network entity.

17. The UE of claim 12, wherein the at least one processor is further configured to: Perform measurements corresponding to at least one type of MDT measurement specified by the network entity; The results of the measurements are saved in a separate file; and Send the separate file containing the results to the network entity.

18. The UE of claim 12, wherein the at least one processor is further configured to send a message to the network entity indicating that the UE is not ready to transmit the requested MDT data. When the UE is ready, the result is later sent to the network entity.

19. The UE of claim 18, wherein the message includes a UE assistance information message sent in response to a request for the structured MDT data and configured to notify the network entity that the UE is currently not ready or unable to transmit the requested MDT data.

20. The UE of claim 12, wherein the result is transmitted using a non-real-time data stream.

21. A wireless communication method for a network entity, comprising: Send a request to the UE for structured minimized drive test MDT data, the requested MDT data corresponding to at least one type of MDT measurement specified by the network entity from a plurality of available MDT measurement types that can be performed by the UE, wherein the request for the structured MDT data includes an indication that the network entity supports non-real-time streaming MDT data. as well as The data received from the UE includes the results of MDT measurements corresponding to at least one specified type.

22. The method of claim 21, further comprising forwarding the requested MDT data to the core network via a trace collection entity (TCE) for distribution to a client.

23. The method of claim 21, wherein the requested MDT data includes multiple measurement types.

24. The method of claim 21, wherein the received data includes a structured report identifying at least one type of MDT measurement specified.

25. The method of claim 21, further comprising: After receiving the requested MDT data, another request for structured MDT data is sent to the UE, which includes the results of an MDT measurement corresponding to another specified type. as well as Receive data from the UE corresponding to the other specified type of MDT measurement.

26. The method of claim 21, further comprising receiving the data from the UE on the control plane.

27. The method of claim 21, wherein the requested MDT data includes the results of a measurement specific to a type specified by the network entity.

28. The method of claim 21, further comprising receiving from the UE a message indicating that the UE is not ready to transmit the requested MDT data. The data mentioned therein is later received at the network entity.

29. A network entity, comprising: Memory; as well as At least one processor coupled to the memory, and the at least one processor is configured to: Send a request to the UE for structured minimized drive test MDT data, the requested MDT data corresponding to at least one type of MDT measurement specified by the network entity from a plurality of available MDT measurement types that can be performed by the UE, wherein the request for the structured MDT data includes an indication that the network entity supports non-real-time streaming MDT data. as well as The data received from the UE includes the results of MDT measurements corresponding to at least one specified type.

30. The network entity of claim 29, wherein the at least one processor is further configured to perform any one of the methods of claims 22-28.

Images