WO2016185986A1 - ユーザ端末 - Google Patents

ユーザ端末 Download PDF

Info

Publication number
WO2016185986A1
WO2016185986A1 PCT/JP2016/064073 JP2016064073W WO2016185986A1 WO 2016185986 A1 WO2016185986 A1 WO 2016185986A1 JP 2016064073 W JP2016064073 W JP 2016064073W WO 2016185986 A1 WO2016185986 A1 WO 2016185986A1
Authority
WO
WIPO (PCT)
Prior art keywords
measurement
measurement result
enb
mdt
delay
Prior art date
Application number
PCT/JP2016/064073
Other languages
English (en)
French (fr)
Inventor
憲由 福田
真人 藤代
顕徳 岩渕
優志 長坂
ヘンリー チャン
Original Assignee
京セラ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 京セラ株式会社 filed Critical 京セラ株式会社
Priority to EP16796379.2A priority Critical patent/EP3297318A4/en
Priority to JP2017519156A priority patent/JPWO2016185986A1/ja
Publication of WO2016185986A1 publication Critical patent/WO2016185986A1/ja
Priority to US15/811,924 priority patent/US10390252B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/08—Testing, supervising or monitoring using real traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/10—Scheduling measurement reports ; Arrangements for measurement reports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition

Definitions

  • the present invention relates to a user terminal that reports a measurement result of a radio environment to a radio base station.
  • Non-Patent Document 1 In 3GPP (3rd Generation Partnership Project), a standardization project for mobile communication systems, specifications of MDT (Minimization of Drive Test), a technology that automates measurement and collection of wireless environment by using user terminals owned by users. The formulation is underway (for example, Non-Patent Document 1).
  • 3GPP TS 37.320 V12.2.0 “Radio measurement collection for Minimization of Drive Tests (MDT); Overall description; Stage 2”, 2014-09
  • the user terminal includes a control unit that performs measurement related to data delay in the uplink, and a transmission unit that reports information indicating a result of the measurement to the radio base station.
  • a user terminal generates a result of an MDT measurement including at least location information, a control unit that stores the result of the MDT measurement in the storage unit, and a storage unit that stores the result of the MDT measurement. And a transmitter that reports the result of the MDT measurement to the radio base station.
  • the control unit stores the result of the MDT measurement in the storage unit before detecting in-device interference caused by communication other than cellular communication.
  • 1 is a configuration diagram of an LTE system according to a first embodiment. It is a block diagram of UE100 concerning a first embodiment. It is a block diagram of eNB200 concerning a first embodiment. It is a protocol stack figure of the radio
  • FIG. 10 is a sequence diagram showing Immediate MDT according to Supplementary Note 5.
  • FIG. 10 is a sequence diagram showing Logged MDT in Connected according to Appendix 5.
  • summary of disclosure is the delivery confirmation information of the data transmitted to the said other user terminal via the side link for performing D2D communication which is direct communication with the other user terminal
  • the quality of service via a reception unit for receiving the communication, a control unit for generating a measurement result of the quality of service of the side link based on the delivery confirmation information, and an uplink for performing cellular communication with the radio base station. And a transmitter for reporting the measurement result to the radio base station.
  • the user terminal reports the measurement result of the service quality of the side link for performing D2D communication to the radio base station.
  • appropriate scheduling can be performed using the measurement result of the service quality. For example, the amount of resources allocated to user terminals that do not satisfy service quality can be increased.
  • the user terminal includes a control unit that generates a measurement result of uplink delay time of data in the uplink to the radio base station, and a transmission that reports the measurement result of the uplink delay time to the radio base station. A part.
  • the user terminal reports the measurement result of the uplink delay time of data in the uplink to the radio base station to the radio base station.
  • appropriate scheduling can be performed using the measurement result of the uplink delay time. For example, it is possible to increase the amount of resources allocated to user terminals with a long uplink delay value time.
  • the user terminal generates an MDT measurement result including at least position information, stores the MDT measurement result in a storage unit, and the MDT measurement stored in the storage unit A transmission unit that reports the result to the radio base station, and the control unit stores the MDT measurement result in the storage unit before detecting in-device interference caused by communication other than cellular communication.
  • the user terminal stores the MDT measurement result in the storage unit before detecting in-device interference caused by communication other than cellular communication. That is, since the MDT measurement result after the in-device interference is detected is not stored in the storage unit, the storage of the MDT measurement result adversely affected by the in-device interference in the storage unit is suppressed. Therefore, it is possible to save time and effort for excluding MDT measurement results that are adversely affected by in-device interference by an upper node such as a radio base station while suppressing an increase in load on the user terminal.
  • FIG. 1 is a configuration diagram of an LTE system according to the first embodiment.
  • the LTE system includes a UE (User Equipment) 100, an E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) 10, and an EPC (Evolved Packet Core) 20.
  • UE User Equipment
  • E-UTRAN Evolved-UMTS Terrestrial Radio Access Network
  • EPC Evolved Packet Core
  • the UE 100 corresponds to a user terminal.
  • the UE 100 is a mobile communication device, and performs radio communication with a cell formed by the eNB 200 (or a serving cell when the UE 100 is in an RRC connected state).
  • the configuration of the UE 100 will be described later.
  • the E-UTRAN 10 corresponds to a radio access network.
  • the E-UTRAN 10 includes an eNB 200 (evolved Node-B).
  • the eNB 200 corresponds to a radio base station.
  • the eNB 200 is connected to each other via the X2 interface. The configuration of the eNB 200 will be described later.
  • the eNB 200 forms one or a plurality of cells, and performs radio communication with the UE 100 that has established a connection with the own cell.
  • the eNB 200 has a radio resource management (RRM) function, a user data routing function, a measurement control function for mobility control / scheduling, and the like.
  • RRM radio resource management
  • Cell is used as a term indicating a minimum unit of a radio communication area, and is also used as a term indicating a function of performing radio communication with the UE 100.
  • the EPC 20 corresponds to a core network.
  • the EPC 20 includes an MME (Mobility Management Entity) / S-GW (Serving-Gateway) 300.
  • the MME performs various mobility controls for the UE 100.
  • the S-GW controls user data transfer.
  • the MME / S-GW 300 is connected to the eNB 200 via the S1 interface. Note that the E-UTRAN 10 and the EPC 20 constitute an LTE system network.
  • FIG. 2 is a block diagram of the UE 100.
  • the UE 100 includes a plurality of antennas 101, a radio transceiver 110, a user interface 120, a GNSS (Global Navigation Satellite System) receiver 130, a battery 140, a memory 150, and a processor 160.
  • the memory 150 and the processor 160 constitute a control unit.
  • the wireless transceiver 110 and the processor 160 constitute a transmission unit and a reception unit.
  • the UE 100 may not have the GNSS receiver 130.
  • the memory 150 may be integrated with the processor 160, and this set (that is, a chip set) may be used as the processor.
  • the antenna 101 and the wireless transceiver 110 are used for transmitting and receiving wireless signals.
  • the radio transceiver 110 converts the baseband signal (transmission signal) output from the processor 160 into a radio signal and transmits it from the antenna 101. Further, the radio transceiver 110 converts a radio signal received by the antenna 101 into a baseband signal (received signal) and outputs the baseband signal to the processor 160.
  • the user interface 120 is an interface with a user who owns the UE 100, and includes, for example, a display, a microphone, a speaker, and various buttons.
  • the user interface 120 receives an operation from the user and outputs a signal indicating the content of the received operation to the processor 160.
  • the GNSS receiver 130 receives a GNSS signal and outputs the received signal to the processor 160 in order to obtain location information indicating the geographical location of the UE 100.
  • the battery 140 stores power to be supplied to each block of the UE 100.
  • the memory 150 stores a program executed by the processor 160 and information used for processing by the processor 160.
  • the processor 160 includes a baseband processor that modulates / demodulates and encodes / decodes a baseband signal, and a CPU (Central Processing Unit) that executes programs stored in the memory 150 and performs various processes.
  • the processor 160 may further include a codec that performs encoding / decoding of an audio / video signal.
  • the processor 160 executes various processes and various communication protocols described later.
  • FIG. 3 is a block diagram of the eNB 200.
  • the eNB 200 includes a plurality of antennas 201, a radio transceiver 210, a network interface 220, a memory 230, and a processor 240.
  • the memory 230 and the processor 240 constitute a control unit.
  • the wireless transceiver 210 (and / or the network interface 220) and the processor 240 constitute a transmission unit and a reception unit.
  • the memory 230 may be integrated with the processor 240, and this set (that is, a chip set) may be used as the processor.
  • the antenna 201 and the wireless transceiver 210 are used for transmitting and receiving wireless signals.
  • the radio transceiver 210 converts the baseband signal (transmission signal) output from the processor 240 into a radio signal and transmits it from the antenna 201.
  • the radio transceiver 210 converts a radio signal received by the antenna 201 into a baseband signal (received signal) and outputs the baseband signal to the processor 240.
  • the network interface 220 is connected to the neighboring eNB 200 via the X2 interface and is connected to the MME / S-GW 300 via the S1 interface.
  • the network interface 220 is used for communication performed on the X2 interface and communication performed on the S1 interface.
  • the memory 230 stores a program executed by the processor 240 and information used for processing by the processor 240.
  • the processor 240 includes a baseband processor that performs modulation / demodulation and encoding / decoding of a baseband signal, and a CPU that executes various programs by executing a program stored in the memory 230.
  • the processor 240 executes various processes and various communication protocols described later.
  • FIG. 4 is a protocol stack diagram of a radio interface in the LTE system. As shown in FIG. 4, the radio interface protocol is divided into the first to third layers of the OSI reference model, and the first layer is a physical (PHY) layer.
  • the second layer includes a MAC (Medium Access Control) layer, an RLC (Radio Link Control) layer, and a PDCP (Packet Data Convergence Protocol) layer.
  • the third layer includes an RRC (Radio Resource Control) layer.
  • the physical layer performs encoding / decoding, modulation / demodulation, antenna mapping / demapping, and resource mapping / demapping.
  • User data and control information are transmitted between the physical layer of the UE 100 and the physical layer of the eNB 200 via a physical channel.
  • the MAC layer performs data priority control, retransmission processing by hybrid ARQ (HARQ), random access procedure, and the like.
  • User data and control information are transmitted between the MAC layer of the UE 100 and the MAC layer of the eNB 200 via a transport channel.
  • the MAC layer of the eNB 200 includes a scheduler that determines an uplink / downlink transport format (transport block size, modulation / coding scheme (MCS)) and an allocation resource block to the UE 100.
  • MCS modulation / coding scheme
  • the RLC layer transmits data to the RLC layer on the receiving side using the functions of the MAC layer and the physical layer. Between the RLC layer of the UE 100 and the RLC layer of the eNB 200, user data and control information are transmitted via a logical channel.
  • the PDCP layer performs header compression / decompression and encryption / decryption. It should be noted that a transmission entity for transmitting a data unit (PDCP PDU) or a reception entity for receiving a data unit (PDCP PDU) is formed in the PDCP layer.
  • the RRC layer is defined only in the control plane that handles control information. Control information (RRC message) for various settings is transmitted between the RRC layer of the UE 100 and the RRC layer of the eNB 200.
  • the RRC layer controls the logical channel, the transport channel, and the physical channel according to establishment, re-establishment, and release of the radio bearer.
  • the NAS (Non-Access Stratum) layer located above the RRC layer performs session management and mobility management.
  • FIG. 5 is a configuration diagram of a radio frame used in the LTE system.
  • OFDMA Orthogonal Frequency Division Multiplexing Access
  • SC-FDMA Single Carrier Frequency Multiple Access
  • the radio frame is composed of 10 subframes arranged in the time direction.
  • Each subframe is composed of two slots arranged in the time direction.
  • the length of each subframe is 1 ms, and the length of each slot is 0.5 ms.
  • Each subframe includes a plurality of resource blocks (RB) in the frequency direction and includes a plurality of symbols in the time direction.
  • Each resource block includes a plurality of subcarriers in the frequency direction.
  • One symbol and one subcarrier constitute one resource element (RE).
  • a frequency resource can be specified by a resource block, and a time resource can be specified by a subframe (or slot).
  • FIG. 6 is a diagram for explaining an application scene according to the first embodiment.
  • UE 100 # 1 is at least located in a cell of eNB 200.
  • the UE 100 # 1 and the eNB 200 are performing cellular communication
  • the UE 100 # 1 and the UE 100 # 2 are performing D2D communication that is direct communication between the UEs.
  • UE 100 # 2 may be located in a cell of eNB 200 (In-Coverage). Or UE100 # 2 may not be located in the cell which eNB200 has (Out-of-Coverage).
  • the radio resource used in the D2D communication between the UE 100 # 1 and the UE 100 # 2 is specified by the eNB 200.
  • eNB200 transmits the message (DCI; Downlink Control Information) containing the allocation information of the radio
  • DCI Format 5 Such a message may be referred to as “DCI Format 5”.
  • the UE 100 # 1 (reception unit) receives the delivery confirmation information of the data transmitted to the UE 100 # 2 from the UE 100 # 2 via the side link for performing D2D communication.
  • UE100 # 1 (control part) produces
  • UE100 # 1 (transmission part) reports the measurement result of service quality to eNB200 via the uplink for performing cellular communication with eNB200.
  • the measurement results of the service quality are the amount of data lost in the side link (hereinafter referred to as side link data loss), the throughput of the IP (Internet Protocol) layer in the side link (hereinafter referred to as side link IP throughput), and the UE 100 # 2 successfully received.
  • side link data amount One or more pieces of data selected from the selected data amount (hereinafter referred to as side link data amount).
  • the side link data loss can be calculated by the following formula, for example.
  • M (T, qci) is a value indicating the packet loss for each QCI (QoS Class Identifier) in the side link.
  • the side link IP throughput can be calculated by the following formula, for example.
  • ThpTimeSI is a parameter in which “0” is set when the data amount is a sufficient amount that can be transmitted in one TTI, and “T1-T2” is set in other cases.
  • T1 is a parameter in which the end time of the measurement period is set when data continues at the end of the measurement period. In other cases, T1 is used for data transmission out of the TTI included in the measurement period. This is a parameter in which the end time of the last TTI is set.
  • T2 is a parameter in which the start time of the measurement period is set when data continues at the beginning of the measurement period. In other cases, T2 is used for data transmission out of the TTI included in the measurement period. This is a parameter in which the start time of the first TTI is set.
  • the side link data amount is the number of bits of the SDU in the PDCP layer that the UE 100 # 2 has successfully received in the measurement period.
  • the timing for reporting the measurement result of the service quality to the eNB 200 may be (A) a case of using Immediate MDT and (B) a case of using Logged MDT in Connected.
  • the UE 100 in a connected state receives measurement setting information (RRM Measurement Configuration) from the eNB 200 and stores various measurement setting parameters included in the measurement setting information.
  • the measurement setting parameter includes a report trigger that is a trigger for reporting the measurement result of the service quality.
  • UE100 produces
  • the UE 100 # 1 described above reports the service quality measurement result to the eNB 200 at the timing when the service quality measurement result is generated.
  • the UE 100 # 1 may report the service quality measurement result below the predetermined threshold to the eNB 200 at the timing when the service quality measurement result below the predetermined threshold is generated.
  • the predetermined threshold is included in the measurement setting information.
  • the predetermined threshold value may be a predefined value.
  • the measurement result of the service quality preferably includes the location information of the UE 100.
  • the UE 100 in a connected state receives measurement setting information (Logged Measurement Configuration) from the eNB 200 and stores various MDT setting parameters included in the measurement setting information.
  • the MDT setting parameter includes a generation trigger that is a trigger for generating a measurement result of service quality.
  • UE100 memorize
  • UE100 reports the measurement result of the service quality memorize
  • the UE 100 # 1 described above stores the measurement result of the service quality in the storage unit.
  • UE100 # 1 mentioned above reports the measurement result of the service quality memorize
  • UE100 # 1 reports the measurement result of the service quality below a predetermined threshold to eNB200 among the measurement results of the service quality memorize
  • the UE 100 # 1 may be configured to store only the measurement result of the service quality below a predetermined threshold value in the storage unit.
  • the predetermined threshold is included in the measurement setting information.
  • the predetermined threshold value may be a predefined value.
  • the measurement result of the service quality preferably includes the location information of the UE 100.
  • the UE 100 In the Logged MDT in Connected, the UE 100 notifies the eNB 200 of information (Available Indication) indicating that the measurement result of the service quality is stored in the storage unit when transitioning from the RRC idle state to the RRC connected state. Also good.
  • the UE 100 may transmit information (Available Indication) indicating that the measurement result of the service quality is stored in the storage unit to the target eNB 200. Good.
  • the eNB 200 transmits a service quality measurement result report request to the UE 100 according to information (Available Indication) indicating that the service quality measurement result is stored in the storage unit.
  • the eNB 200 receives from the UE 100 a buffer status report (BSR) indicating the buffer status of the UE 100 used in D2D communication, and determines whether there is data to be transmitted in D2D communication based on the buffer status report. May be. When there is no data to be transmitted by D2D communication, the eNB 200 determines that the D2D communication has ended, and transmits a service quality measurement result report request to the UE 100.
  • BSR buffer status report
  • FIG. 7 and 8 are sequence diagrams showing the mobile communication method according to the first embodiment.
  • a case where the UE 100 # 1 and the eNB 200 are performing cellular communication, and the UE 100 # 1 and the UE 100 # 2 are performing D2D communication is illustrated.
  • a case where data is transmitted from UE 100 # 1 to UE 100 # 2 and delivery confirmation information is transmitted from UE 100 # 2 to UE 100 # 1 will be mainly described.
  • step S10 the eNB 200 transmits a message (DCI Format 5) for designating radio resources used in D2D communication between the UE 100 # 1 and the UE 100 # 2 to the UE 100 # 1.
  • DCI Format 5 a message for designating radio resources used in D2D communication between the UE 100 # 1 and the UE 100 # 2 to the UE 100 # 1.
  • step S11A or step S11B the UE 100 # 1 and the UE 100 # 2 perform D2D communication using the radio resource specified by the eNB 200.
  • the eNB 200 transmits measurement setting information to the UE 100 # 1.
  • Various measurement setting parameters included in the measurement setting information are stored.
  • the measurement setting parameter includes a report trigger that is a trigger for reporting the measurement result of the service quality.
  • the measurement setting information includes information requesting measurement of the service quality of the side link.
  • the measurement setting information may be included in the RRM Measurement Configuration.
  • step S13A or step S13B the UE 100 # 1 measures the service quality of the side link based on the delivery confirmation information received from the UE 100 # 2.
  • step S14A or step S14B the UE 100 # 1 generates a service quality measurement result according to the occurrence of an event corresponding to the report trigger.
  • the UE 100 # 1 may report the service quality measurement result to the eNB 200 at the timing when the service quality measurement result is generated.
  • the UE 100 # 1 may report the service quality measurement result below the predetermined threshold to the eNB 200 at the timing when the service quality measurement result below the predetermined threshold is generated.
  • step S15 the UE 100 # 1 and the UE 100 # 2 end the D2D communication.
  • step S16 the eNB 200 transmits measurement setting information to the UE 100 # 1.
  • the measurement setting information does not include information for requesting measurement and reporting of side link service quality.
  • the measurement setting information may include information for canceling the measurement and reporting of the service quality of the side link.
  • step S20 the eNB 200 transmits a message (DCI Format 5) for designating radio resources used in D2D communication between the UE 100 # 1 and the UE 100 # 2 to the UE 100 # 1.
  • DCI Format 5 a message for designating radio resources used in D2D communication between the UE 100 # 1 and the UE 100 # 2 to the UE 100 # 1.
  • step S21A or step S21B the UE 100 # 1 and the UE 100 # 2 perform D2D communication using the radio resource specified by the eNB 200.
  • the eNB 200 transmits measurement setting information to the UE 100 # 1.
  • Various measurement setting parameters included in the measurement setting information are stored.
  • the measurement setting parameter includes a generation trigger that is a trigger for generating a measurement result of service quality.
  • the measurement setting information includes information for requesting measurement and reporting of side link service quality.
  • the measurement setting information may be included in the RRM Measurement Configuration.
  • step S23A or step S23B the UE 100 # 1 measures the service quality of the side link based on the delivery confirmation information received from the UE 100 # 2.
  • UE100 # 1 memorize
  • the UE 100 # 1 may store only the measurement result of the service quality below a predetermined threshold in the storage unit.
  • step S24 the UE 100 # 1 and the UE 100 # 2 end the D2D communication.
  • step S25 the UE 100 # 1 transitions from the connected state to the idle state.
  • step S26 the UE 100 # 1 transitions from the idle state to the connected state.
  • the eNB 200 transmits a service quality measurement result report request to the UE 100 # 1.
  • the eNB 200 may transmit a service quality measurement result report request to the UE 100 # 1 according to information (available indication) notified from the UE 100 # 1, and the UE 100 # 1 notifies the eNB 200.
  • a service quality measurement result report request may be transmitted to the UE 100 # 1.
  • step S28 the UE 100 # 1 reports the measurement result of the service quality stored in the storage unit to the eNB 200 at the timing when the report request is received from the eNB 200.
  • the UE 100 # 1 may report, to the eNB 200, a service quality measurement result that falls below a predetermined threshold among the service quality measurement results stored in the storage unit at the timing when the report request is received from the eNB 200.
  • the UE 100 # 1 data transmission side / delivery confirmation information reception side
  • the UE 100 # 2 data reception side / delivery confirmation information transmission side
  • the eNB 200 may transmit the measurement setting information to the UE 100 # 2.
  • UE100 reports the measurement result of the service quality of the side link for performing D2D communication to eNB200.
  • appropriate scheduling can be performed using the measurement result of the service quality. For example, the resource amount allocated to the UE 100 that does not satisfy the service quality can be increased.
  • the procedure for reporting the measurement result of service quality in MDT has been described.
  • a procedure for reporting the measurement result of the uplink delay time of the data in the uplink to the eNB 200 in the MDT will be described.
  • the uplink delay time is the delay time from when the data to be transmitted on the uplink is generated by the UE 100 until the data is received on the receiving side (eNB 200), or the data to be transmitted on the uplink is the UE 100
  • the UE 100 (control unit) generates a measurement result of the uplink delay time of data in the uplink to the eNB 200.
  • UE100 (transmission part) reports the measurement result of uplink delay time to eNB200.
  • the timing for reporting the measurement result of the uplink delay time to the eNB 200 the case of using (A) Immediate MDT and the case of using (B) Logged MDT in Connected can be considered as in the first embodiment. .
  • the UE 100 in a connected state receives measurement setting information (RRM Measurement Configuration) from the eNB 200 and stores various measurement setting parameters included in the measurement setting information.
  • the measurement setting parameter includes a report trigger that is a trigger for reporting the measurement result of the uplink delay time.
  • the UE 100 generates the measurement result of the uplink delay time in response to the occurrence of the event corresponding to the report trigger, and reports the measurement result of the uplink delay time to the eNB 200.
  • the UE 100 reports the uplink delay time measurement result to the eNB 200 at the timing when the uplink delay time measurement result is generated.
  • the UE 100 may report the measurement result of the uplink delay time exceeding the predetermined threshold to the eNB 200 at the timing when the measurement result of the uplink delay time exceeding the predetermined threshold is generated.
  • the predetermined threshold is included in the measurement setting information.
  • the predetermined threshold value may be a predefined value.
  • the measurement result of the uplink delay time preferably includes location information of the UE 100.
  • the UE 100 in a connected state receives measurement setting information (Logged Measurement Configuration) from the eNB 200 and stores various MDT setting parameters included in the measurement setting information.
  • the MDT setting parameter includes a generation trigger that is a trigger for generating a measurement result of the uplink delay time.
  • the UE 100 stores (logs) the measurement result of the uplink delay time in the storage unit.
  • UE100 reports the measurement result of the uplink delay time memorize
  • the UE 100 stores the uplink delay time measurement result in the storage unit.
  • UE100 reports the measurement result of the uplink delay time memorize
  • UE100 reports the measurement result of the uplink delay time which exceeded the predetermined threshold among the measurement results of the uplink delay time memorize
  • the UE 100 may be configured to store only the measurement result of the uplink delay time exceeding a predetermined threshold in the storage unit.
  • the predetermined threshold is included in the measurement setting information.
  • the predetermined threshold value may be a predefined value.
  • the measurement result of the uplink delay time preferably includes location information of the UE 100.
  • the UE 100 when the UE 100 transits from the RRC idle state to the RRC connected state, the UE 100 notifies the eNB 200 of information (Available Indication) indicating that the measurement result of the uplink delay time is stored in the storage unit. May be.
  • the UE 100 when the UE 100 performs a handover from the source eNB 200 to the target eNB 200, the UE 100 transmits information (Available Indication) indicating that the measurement result of the uplink delay time is stored in the storage unit to the target eNB 200. Also good. In such a case, the eNB 200 transmits an uplink delay time measurement result report request to the UE 100 in accordance with information (Available Indication) indicating that the uplink delay time measurement result is stored in the storage unit.
  • Mobile communication method (Mobile communication method)
  • a mobile communication method according to the first modification will be described.
  • 9 and 10 are sequence diagrams showing a mobile communication method according to the first modification.
  • step S40 the UE 100 is in the RRC connected state.
  • the eNB 200 transmits measurement setting information to the UE 100.
  • Various measurement setting parameters included in the measurement setting information are stored.
  • the measurement setting parameter includes a report trigger that is a trigger for reporting the measurement result of the uplink delay time.
  • the measurement setting information may be included in the RRM Measurement Configuration.
  • step S42A or step S42B the UE 100 measures the service quality of the uplink delay time.
  • step S43A or step S43B the UE 100 generates a measurement result of the uplink delay time in response to the occurrence of an event corresponding to the report trigger.
  • the UE 100 may report the uplink delay time measurement result to the eNB 200 at the timing when the uplink delay time measurement result is generated.
  • the UE 100 may report the measurement result of the uplink delay time exceeding the predetermined threshold to the eNB 200 at the timing when the measurement result of the uplink delay time exceeding the predetermined threshold is generated.
  • step S50 the UE 100 is in the RRC connected state.
  • the eNB 200 transmits measurement setting information to the UE 100.
  • Various measurement setting parameters included in the measurement setting information are stored.
  • the measurement setting parameter includes a generation trigger that is a trigger for generating a measurement result of the uplink delay time.
  • the measurement setting information may be included in the RRM Measurement Configuration.
  • the UE 100 measures the service quality of the uplink delay time.
  • the UE 100 stores (logs) the measurement result of the uplink delay time in the storage unit in response to the occurrence of the event corresponding to the generation trigger.
  • the UE 100 may store only the measurement result of the uplink delay time exceeding a predetermined threshold in the storage unit.
  • step S53 the UE 100 transitions from the connected state to the idle state.
  • step S54 the UE 100 transitions from the idle state to the connected state.
  • step S55 the eNB 200 transmits a report request for the measurement result of the uplink delay time to the UE 100.
  • the eNB 200 transmits an uplink delay time measurement result report request to the UE 100 in accordance with information (Available Indication) notified from the UE 100.
  • step S56 the UE 100 reports the uplink delay time measurement result stored in the storage unit to the eNB 200 at the timing when the report request is received from the eNB 200.
  • the UE 100 may report, to the eNB 200, the measurement result of the uplink delay time that exceeds a predetermined threshold among the measurement results of the uplink delay time stored in the storage unit at the timing when the report request is received from the eNB 200. .
  • the UE 100 reports information (hereinafter referred to as report information) for estimating the variation in the measurement result of the uplink delay time to the eNB 200.
  • the report information may include an average upstream delay time, a lower 5% upstream delay time, a higher 5% upstream delay time, and the like.
  • the UE 100 reports to the eNB 200 the measurement result of the uplink delay time of data in the uplink to the eNB 200.
  • appropriate scheduling can be performed using the measurement result of the uplink delay time. For example, the amount of resources allocated to the UE 100 having a long uplink delay time can be increased.
  • the procedure for reporting the measurement result of service quality in MDT has been described.
  • a procedure for reporting an MDT measurement result including at least position information in MDT will be described.
  • the MDT measurement result is the same as the content reported by the existing MDT, and it is sufficient that the MDT measurement result includes at least position information indicating the geographical position of the UE 100.
  • the MDT measurement result may include reception quality (RSRP or RSRQ) of a signal received from the eNB 200 through cellular communication.
  • the UE 100 is a dual terminal having a function of performing communication (for example, WiFi or BlueTooth) other than the cellular communication in addition to the function of performing the cellular communication.
  • a function of performing communication for example, WiFi or BlueTooth
  • the MDT measurement result is reported by Logged MDT in Idle.
  • the UE 100 starts communication other than cellular communication (for example, WiFi or BlueTooth). That is, in the UE 100, communication other than cellular communication and cellular communication is performed at the same time (IDC: In Device Coexistence).
  • IDC In Device Coexistence
  • the above-mentioned intra-device interference is interference caused by IDC.
  • the UE 100 detects in-device interference. Specifically, the UE 100 detects that the in-device interference has exceeded a predetermined threshold (Phase 1 start timing shown in FIG. 11).
  • the UE 100 reports an indication indicating that intra-device interference is occurring to the eNB 200 (Phase 2 start timing shown in FIG. 11).
  • the eNB 200 executes a procedure for eliminating intra-device interference.
  • the eNB 200 changes the frequency (FDM Solution), changes the scheduling timing of cellular communication (TDM Solution), and the like (Phase 3 start timing shown in FIG. 11).
  • the UE 100 (control unit) generates an MDT measurement result including at least position information and stores the MDT measurement result in the storage unit.
  • UE100 transmission part
  • the UE 100 (control unit) stores the MDT measurement result in the storage unit before detecting in-device interference caused by communication other than cellular communication. That is, the UE 100 stores the MDT measurement result before Phase 1 illustrated in FIG. 11 in the storage unit. In other words, the UE 100 does not store the MDT measurement result after Phase 1 shown in FIG. 11 in the storage unit.
  • the UE 100 (control unit) discards the MDT measurement result stored in the storage unit after starting communication other than cellular communication. That is, the UE 100 discards the MDT measurement result stored in the storage unit after starting communication other than cellular communication even in the stage before Phase 1 shown in FIG.
  • the UE 100 may stop storing the MDT measurement result in the storage unit in response to the start of communication other than cellular communication.
  • the UE 100 maintains the setting information for storing the MDT measurement result even when the in-device interference is detected, and when the in-device interference is resolved, the MDT is performed according to the setting information. It is preferable to resume storing the measurement results in the storage unit. That is, the UE 100 resumes storing the MDT measurement result in the storage unit after Phase 3 shown in FIG.
  • (Action and effect) UE100 which concerns on the modification 3 stores a MDT measurement result in a memory
  • the UE 100 may report an uplink The measurement result of the PDCP queuing delay (ul-PDCP-DelayResult) may not be created (the creation of the measurement result of the PDCP queuing delay may be limited).
  • the PDCP queuing delay rate is the proportion of PDCP packets whose queuing delay exceeds a threshold among PDCP packets within a unit time.
  • the UE 100 may create a measurement result (ul-PDCP-DelayResult) of the uplink PDCP queuing delay even when the uplink PDCP queuing delay is not detected (excessDelay included in the measurement result is 0). Create as).
  • the UE 100 even when the UE 100 detects the uplink PDCP queuing delay, if the delay rate of the PDCP queuing is less than a threshold (0 or more), the UE 100 reports the uplink to the eNB 200.
  • the measurement result of the PDCP queuing delay (ul-PDCP-DelayResult) may not be created.
  • the UE 100 may not report the measurement result of the uplink PDCP queuing delay to the eNB 200.
  • the measurement result of the service quality includes the SINR of the side link, the BLER of the side link, the SINR of the downlink of the cellular communication, the BLER of the downlink of the cellular communication, and communication other than the cellular communication (for example, WiFi) uplink or downlink SINR, communication other than cellular communication (for example, WiFi) uplink or downlink BLER, delay from transmission of D2D Discovery to actual transmission of D2D Discovery, etc. May be included.
  • the UE 100 that reports the measurement result of the uplink delay time to the eNB 200 may be designated by the eNB 200.
  • the eNB 200 monitors the periodic voice packet received from the UE 100 and estimates the uplink delay time based on the jitter of the periodic voice packet.
  • the eNB 200 designates the UE 100 whose estimated delay time is larger than the threshold as the UE 100 that reports the measurement result of the uplink delay time.
  • the present invention is not limited thereto, and the service quality measurement result may be reported without using MDT.
  • the modification example 1 has been described using the case of using MDT, the present invention is not limited to this, and the measurement result of the uplink delay time may be reported without using MDT.
  • a program for causing a computer to execute each process performed by the UE 100 and the eNB 200 may be provided.
  • the program may be recorded on a computer readable medium. If a computer-readable medium is used, a program can be installed in the computer.
  • the computer-readable medium on which the program is recorded may be a non-transitory recording medium.
  • the non-transitory recording medium is not particularly limited, but may be a recording medium such as a CD-ROM or a DVD-ROM.
  • a chip configured by a memory that stores a program for executing each process performed by the UE 100 and the eNB 200 and a processor that executes the program stored in the memory may be provided.
  • the LTE system has been described as an example of a mobile communication system.
  • the mobile communication system may be a system other than the LTE system.
  • Benefits of such feedback that can be achieved considering the provision of additional feedback that impacts MDT measurement results from provisions from UEs handling various functions (eg, new types of support information such as IDC). Analyzing what is.
  • IDC interference As part of the FeMDT study item, several mechanisms should be studied that accurately reflect channel conditions in MDT measurement results.
  • One typical factor that impacts MDT measurement results is IDC interference.
  • TR for interference avoidance for intra-device coexistence WiFi and Bluetooth can interfere with LTE devices.
  • the measurement result is degraded by IDC interference. Since the eNB / NW cannot detect whether or not the log data is degraded, the UE should log only the measurement results that are not degraded. Therefore, the UE should stop MDT logging as soon as possible when it detects IDC interference. According to section 23.4.2 of TS 36.300, three phases of IDC interference are illustrated in FIG.
  • the UE detects the start of IDC interference, but has not yet started transmitting IDC indications to the eNB.
  • IDLE UE suggests that MDT logging should be stopped when phase 1 of IDC interference state is triggered.
  • Proposal 1 IDLE UE should stop logging when it triggers the start of Phase 1 of IDC interference.
  • the UE simply discards “all log data”, it would be easier. On the other hand, it is always good not to completely discard good log data if it can be avoided without too much UE complexity. In the latter case, if the UE detects an IDC problem, it stops logging but should maintain undegraded log data. For alternative 2, two options for discarding only degraded log data can be considered.
  • Option 1 UE maintains all log data before Phase 1.
  • Option 2 The UE discards the log data collected after starting to use WiFi / Bluetooth.
  • Option 1 is much simpler than option 2. However, it is possible that some of the log data has already been degraded prior to Phase 1. This is because Phase 1 starts with the detection of IDC interference and the details are left to the UE implementation. Thus, “the UE relies on existing LTE measurements and / or UE internal coordination to evaluate interference, and the details are left to the UE implementation”. Also, since detection of IDC interference is left to the UE implementation, the UE may not trigger phase 1 if IDC interference is very small. In other words, the interference is very small (at least from the UE perspective) and the UE never triggers phase 1, but in fact the log data may already be somewhat degraded. In this scenario, “degraded” log data will be reported because IDC interference is not officially detected.
  • the measurement result may be degraded. If option 1 is selected due to uncertainty in the degradation state of the log data, the UE will include in the log that phase 1 has been detected (or log if we use indications) Should be included in the availability indication). If some of the data towards the end of the log is collected or discarded, the eNB / NW will have the option of discarding the entire data (or whether to retrieve the data if indication is used) Can have. Another option would be to allow the UE to add an indication (eg, a time stamp) to the log when the UE starts / stops using WiFi / Bluetooth. Then, the eNB / NW can remove the deteriorated measurement result from the reported log based on these indications.
  • an indication eg, a time stamp
  • Proposal 2 When the UE detects the start of phase 1 of IDC interference, it always discards all log data.
  • Proposal 3 After the IDC problem is resolved, the UE maintains MDT settings and resumes logging.
  • Latency metrics for both UL and DL are desirable for GBR traffic.
  • the UE tags each PDCP PDU with system time information, and the eNB determines the UL queue delay using the provided system time information.
  • the UE determines whether the UL queue delay has exceeded a configured threshold and reports data or delay related parameters.
  • the eNB determines the periodic voice packet (e.g., every 20 milliseconds) to determine whether there is a change (resulting in jitter) when receiving the periodic voice packet. To monitor).
  • This alternative has the advantage that UL latency can be measured without additional complexity on the UE side.
  • QoS related information is measured at the eNB. This is linked with the existing policy for L2 measurement.
  • Alternative 1 can be achieved based on eNB implementation. This means that standardized work is not required. However, since the eNB does not know when traffic arrives in the UE's PDCP buffer, high measurement accuracy cannot be expected.
  • the UE adds a time stamp to the PDCP packet, and the eNB calculates the latency using the time stamp provided in relation to the time when the received PDCP packet was correctly decoded.
  • this alternative allows the eNB to calculate accurate UL latency measurement results. This is because the eNB may be able to use the time stamp added by the UE.
  • this alternative would result in excessive load for both the UE and the eNB because it would require a lot of logging. Therefore, how to mitigate these complexities should be considered.
  • An example of an implementation-based procedure is a combination of Alternative 1 and Alternative 2, where the eNB coarsely estimates the latency using Alternative 1, and for the UE, for example, estimated latency, or If the latency variance (ie, jitter) exceeds the threshold, request to add a time stamp to the PDCP packet for the particular UE.
  • the eNB sets a short measurement duration (eg 5 seconds) where the PDCP packet needs to be time stamped and reported as part of the MDT configuration. This will reduce the number of PDCP packets that the UE needs to measure and log during the duration of MDT. The start time of this short measurement duration should be controlled by the eNB.
  • Alternative 3 all the complexity exists in the UE to determine UL latency. This introduces a significant load on the UE, so it is essential to consider a method to minimize such complexity if Alternative 3 is selected.
  • Alternative 3 is that the eNB estimates the latency using Alternative 1 and, for example, if the estimated latency or latency variance exceeds a threshold, the UL latency is increased for a particular UE. Similar to Alternative 2 in that it requires measurement.
  • the UE may perform some filtering so that only data that exceeds a certain lag threshold can be logged and reported. Alternatively, the UE may report some delay related parameters to the eNB so that the eNB can calculate the latency variance. Possible delay related parameters to be reported include, for example, “number of measured PDCP SDUs” along with average, x%, y% worst / best latency measurements.
  • Proposal 1 RAN2 should incorporate the above three alternatives as candidate solutions with possible enhancements in TR.
  • Proposal 2 RAN2 should study how to minimize the complexity of both the UE and eNB / NW and incorporate them into the TR in case a UE-based solution is introduced is there.
  • UL PDCP queuing delay measurement should be performed for each QCI per UE, and packet delay observed only at the UE's PDCP layer (from packet arrival at PDCT upper SAP until packet begins to be delivered to RLC) Should be reflected.
  • the root cause of UL queuing delay is scheduling. If the reported UL queuing measurement is unacceptable, it is easy to assume that the NW will modify the scheduling algorithm to reduce the delay. Otherwise, the queuing delay will remain. It will be appreciated that if the result of the queuing delay measurement is used only for the eNB, it may not be necessary to report the queuing delay measurement along with the location information.
  • Location information is useful for TCE to detect the root cause of queuing delay. For example, if excessive queuing delays occur under good DL and UL coverage, the TCE can determine that the root cause of the problem is scheduling. Note that the TCE may collect both DL and UL coverage information from existing MDT measurement results. Therefore, we prefer that location information should be reported even for queuing delay measurements.
  • Proposal 1 Location information should be reported along with UL PDCP queuing delay measurement results.
  • Immediate MDT or Logged MDT in Connected Another point to consider is what type of processing, Immediate MDT or Logged MDT in Connected, should be applicable for UL PDCP queuing delay measurements. If RAN2 determines that only UL PDCP queuing delay measurement is sufficient, Immediate MDT is not necessary because the root cause of the problem may be due to scheduling. This means that the queuing delay cannot be improved until the scheduling algorithm is modified. Assuming that the NW does not update the scheduling algorithm frequently, we believe there is no benefit for the NW to obtain queuing delay measurements in real time.
  • Logged MDT in Connected is preferred because it has less signaling overhead and the complexity of both UE and NW can be reduced.
  • the NW may need to stitch together many pieces of reported measurements to assess the extent of the problem.
  • the existing Immediate MDT is designed to allow the eNB to use the reported measurements directly.
  • the eNB may update the radio parameters to adjust to the changing state of the UE.
  • the eNB / NW may be able to estimate the total UL delay based on the UL PDCP queuing delay measurement. If the total UL latency for a particular service exceeds the expected threshold, the eNB / NW should have an option to update the radio parameters as soon as possible, for example, to achieve QoS for the intended service. From this point of view, we prefer that Immediate MDT is applied to the PDCP queuing delay measurement report.
  • Proposal 2 Immediate MDT is applied to the PDCP queuing delay measurement report.
  • Proposal 2 If Proposal 2 is agreed, it should also consider whether the UE should report all measurement results or whether it should report certain measurement results, eg exceeding the delay threshold. According to the results of UL delay measurement studies, the latter is preferred because delay spikes are the main cause of problems for both UE and eNB vendors. Therefore, the UE should start reporting UL PDCP queuing delay measurement results that exceed the configured delay threshold and stop reporting the configured delay threshold after the measurement falls below. If hysteresis needs to be applied due to entry and exit conditions, it is for further study. Regarding the delay threshold, we think it should be configurable by the eNB / NW using, for example, UL PDCP queuing delay measurement configuration.
  • Proposal 3 The UE should start reporting UL PDCP queuing delay measurement results that exceed the configured delay threshold, and stop reporting the configured delay threshold after the UL PDCP queuing delay measurement falls below .
  • Proposal 3 If Proposal 3 is agreed, the NW can only collect UL PDCP queuing delay measurement results that exceed the configured threshold. Therefore, if the UL PDCP delay characteristics need to be corrected by the NW, additional assistance information should be provided by the UE.
  • One of the main objectives for network optimization is understood to be to keep jitter and average latency within limits suitable for the application, especially for GBR type traffic.
  • the NW In order for the NW to estimate the UL PDCP delay characteristics, at least the number of measured UL PDCP SDUs and the average UL PDCP queuing delay are considered necessary. If so, the UE should calculate the average UL PDCP queuing delay and report it later along with the number of measured UL PDCP SDUs. Thus, the eNB should have the option to require the UE to calculate the average UL PDCP queuing delay using the UL PDCP queuing delay measurement configuration. Since the information is already statistical, it is not necessary for the UE to report measurement sample location information.
  • Proposal 4 The eNB should have the option to require the UE to calculate the average UL PDCP queuing delay using the UL PDCP queuing delay measurement configuration.
  • Proposal 5 If requested, the UE should calculate the average UL PDCP queuing delay and report it later along with the number of measured UL PDCP SDUs.
  • the user apparatus reports the location information together with the uplink PDCP queuing delay measurement result measured at the UE to the base station (eNB) or the network.
  • the user apparatus reports the uplink PDCP queuing delay measurement result measured at the UE to the base station (eNB) or the network by ImmediateMDT.
  • the user equipment reports the uplink PDCP queuing delay measurement result exceeding the delay threshold, and stops reporting the uplink PDCP queuing delay measurement result after the measurement result falls within the threshold range.
  • the delay threshold is set by leaving from the eNB or the network to the UE.
  • the user equipment calculates the average uplink PDCP queuing delay measurement result, and the calculation of the average uplink PDCP queuing delay is requested from the eNB or network to the UE in the uplink PDCP queuing delay measurement setting.
  • the user equipment then reports the average uplink PDCP queuing delay measurement result together with the measured number of uplink PDCP SDUs.
  • the UE reports the measurement result according to a request from the eNB or the network.
  • Proposal 1 “ ⁇ Symbol” on the right side of Table 4.2.1.1.1-1 in TS 36.314 should be replaced with “ ⁇ Symbol”.
  • the number or ratio coding reuses the coding principles defined for MBSFN BLER reporting.
  • the UE can only report UL PDCP queuing delay measurement results when an event is detected (ie, a spike is detected by the UE).
  • delay spikes are a major cause of problems for both UEs and eNBs. Therefore, if no spike is detected by the UE within the measurement / reporting period, there is little point in reporting the PDCP queuing delay measurement result. Since the UL PDCP queuing delay measurement report is periodic, if the NW does not receive the measurement results, the NW can understand that there are no spikes during the measurement / report period. Furthermore, if the UE is required to report all measurements regardless of the detection of delayed spikes, there can be an excessive amount of spikeless reporting if no spikes are expected.
  • the trigger for UL PDCP queuing delay measurement report is as follows.
  • One possible way to prevent UL PDCP delay measurement reporting when no excessive delay is detected is to modify the mapping of excess delay ratio as follows.
  • the UE does not detect a UL PDCP delay based on the delay threshold configured by the network and the delay reporting interval, the UE does not report a UL PDCP delay measurement within that period.
  • MDT Configuration Introduce a new IE for UE-based QoS measurement and reuse existing RRM measurement configuration. This can be accomplished by “add-ons” to existing RRM measurement configurations. Reporting method and log available instructions per reporting trigger without available instructions-Logged MDT in Connected Configuration Introduce a new IE for UE-based QoS measurement and reuse existing logged measurement configuration. This can be accomplished by “add-ons” to existing logged measurement configurations.
  • Option 1 IDLE to CONN (and optionally per HO)
  • Option 2 No instruction available (up to eNB implementation) Note: In this case, some other such as logged MDT, number of PDCP SDUs, average QoS measurements, and (optional) 95% worst QoS measurements and (optional) 5% worst QoS measurements result.
  • ENB of throughput of PDCP SDU bits in the side link for data bursts large enough to require the transmission to be split across several TTIs by excluding data transmitted in the last TTI of the data burst Estimated value. Only the data transmission time is taken into account, i.e. when data transmission via the side link has started but not yet finished. Measurement is performed for each D2D UE. For successful reception, the reference point is the MAC upper SAP.
  • This measurement value is obtained by the following formula for the measurement period.
  • (Side link data volume) Data volume for MDT on the side link.
  • the unit is kilobits.
  • FIG. 13 shows a flowchart in this case.
  • the eNB may notice the end of D2D based on the UE's BSR.
  • FIG. 14 shows a flowchart in this case.
  • Option 2 No instruction available (up to eNB implementation) Since the eNB can notice the end of D2D based on the BSR of the UE, the eNB can retrieve the QoS measurement log after the D2D communication is completed.
  • the present invention is useful in the communication field.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

ユーザ端末は、上りリンクにおけるデータの遅延に関する測定を行う制御部と、前記測定の結果を示す情報を無線基地局に報告する送信部とを備える。

Description

ユーザ端末
　本発明は、無線環境の測定結果を無線基地局に報告するユーザ端末に関する。
　移動通信システムの標準化プロジェクトである３ＧＰＰ（３ｒｄ　Ｇｅｎｅｒａｔｉｏｎ　Ｐａｒｔｎｅｒｓｈｉｐ　Ｐｒｏｊｅｃｔ）では、ユーザが所持するユーザ端末を利用することによって、無線環境の測定及び収集を自動化する技術であるＭＤＴ（Ｍｉｎｉｍｉｚａｔｉｏｎ　ｏｆ　Ｄｒｉｖｅ　Ｔｅｓｔ）の仕様策定が進められている（例えば、非特許文献１）。
　第１の特徴に係るユーザ端末は、上りリンクにおけるデータの遅延に関する測定を行う制御部と、前記測定の結果を示す情報を無線基地局に報告する送信部とを備える。
　第２の特徴に係るユーザ端末は、記憶部と、少なくとも位置情報を含むＭＤＴ測定の結果を生成するとともに、前記ＭＤＴ測定の結果を前記記憶部に格納する制御部と、前記記憶部に格納された前記ＭＤＴ測定の結果を無線基地局に報告する送信部とを備える。前記制御部は、セルラ通信以外の通信によって生じる装置内干渉が検出される前に、前記ＭＤＴ測定の結果を前記記憶部に格納する。
第一実施形態に係るＬＴＥシステムの構成図である。 第一実施形態に係るＵＥ１００のブロック図である。 第一実施形態に係るｅＮＢ２００のブロック図である。 第一実施形態に係る無線インターフェイスのプロトコルスタック図である。 第一実施形態に係るＬＴＥシステムで使用される無線フレームの構成図である。 第一実施形態に係る適用シーンを説明するための図である。 第一実施形態に係る移動通信方法を示すシーケンス図である。 第一実施形態に係る移動通信方法を示すシーケンス図である。 変更例１に係る移動通信方法を示すシーケンス図である。 変更例１に係る移動通信方法を示すシーケンス図である。 変更例２に係る装置内干渉を説明するための図である。 付記１に係る、ＵＥによるＩＤＣ干渉関連動作の異なるフェーズを示す図である。 付記５に係る、Ｉｍｍｅｉｄａｔｅ　ＭＤＴを示すシーケンス図である。 付記５に係る、Ｌｏｇｇｅｄ　ＭＤＴ　ｉｎ　Ｃｏｎｎｅｃｔｅｄを示すシーケンス図である。
　［開示の概要］
　第１に、開示の概要に係るユーザ端末は、他のユーザ端末との直接的な通信であるＤ２Ｄ通信を行うためのサイドリンクを介して、前記他のユーザ端末に送信したデータの送達確認情報を受信する受信部と、前記送達確認情報に基づいて、前記サイドリンクのサービス品質の測定結果を生成する制御部と、無線基地局とセルラ通信を行うための上りリンクを介して、前記サービス品質の測定結果を前記無線基地局に報告する送信部とを備える。
　開示の概要では、ユーザ端末は、Ｄ２Ｄ通信を行うためのサイドリンクのサービス品質の測定結果を無線基地局に報告する。これによって、サービス品質の測定結果を用いて適切なスケジューリングを行うことができる。例えば、サービス品質を満たしていないユーザ端末に割り当てるリソース量を増大することができる。
　第２に、開示の概要に係るユーザ端末は、無線基地局に対する上りリンクにおけるデータの上り遅延時間の測定結果を生成する制御部と、前記上り遅延時間の測定結果を無線基地局に報告する送信部とを備える。
　開示の概要では、ユーザ端末は、無線基地局に対する上りリンクにおけるデータの上り遅延時間の測定結果を無線基地局に報告する。これによって、上り遅延時間の測定結果を用いて適切なスケジューリングを行うことができる。例えば、上り遅延値時間が大きいユーザ端末に割り当てるリソース量を増大することができる。
　第３に、開示の概要に係るユーザ端末は、少なくとも位置情報を含むＭＤＴ測定結果を生成するとともに、前記ＭＤＴ測定結果を記憶部に格納する制御部と、前記記憶部に記憶された前記ＭＤＴ測定結果を無線基地局に報告する送信部とを備え、前記制御部は、セルラ通信以外の通信によって生じる装置内干渉が検出される前において、前記ＭＤＴ測定結果を前記記憶部に格納する。
　開示の概要では、ユーザ端末は、セルラ通信以外の通信によって生じる装置内干渉が検出される前において、ＭＤＴ測定結果を記憶部に格納する。すなわち、装置内干渉が検出される後におけるＭＤＴ測定結果が記憶部に格納されないため、装置内干渉によって悪影響を受けたＭＤＴ測定結果の記憶部への格納が抑制される。従って、ユーザ端末の負荷増大を抑制しながらも、無線基地局などの上位ノードによって、装置内干渉によって悪影響を受けたＭＤＴ測定結果を除外する手間を省くことができる。
　［第一実施形態］
　以下において、移動通信システムとして、３ＧＰＰ規格に基づいたＬＴＥシステムを例に挙げて、第一実施形態を説明する。
　（システム構成）
　第一実施形態に係るＬＴＥシステムのシステム構成について説明する。図１は、第一実施形態に係るＬＴＥシステムの構成図である。
　図１に示すように、第一実施形態に係るＬＴＥシステムは、ＵＥ（Ｕｓｅｒ　Ｅｑｕｉｐｍｅｎｔ）１００、Ｅ－ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ－ＵＭＴＳ　Ｔｅｒｒｅｓｔｒｉａｌ　Ｒａｄｉｏ　Ａｃｃｅｓｓ　Ｎｅｔｗｏｒｋ）１０、及びＥＰＣ（Ｅｖｏｌｖｅｄ　Ｐａｃｋｅｔ　Ｃｏｒｅ）２０を備える。
　ＵＥ１００は、ユーザ端末に相当する。ＵＥ１００は、移動型の通信装置であり、ｅＮＢ２００によって形成されるセル（ＵＥ１００がＲＲＣコネクティッド状態である場合には、サービングセル）との無線通信を行う。ＵＥ１００の構成については後述する。
　Ｅ－ＵＴＲＡＮ１０は、無線アクセスネットワークに相当する。Ｅ－ＵＴＲＡＮ１０は、ｅＮＢ２００（ｅｖｏｌｖｅｄ　Ｎｏｄｅ－Ｂ）を含む。ｅＮＢ２００は、無線基地局に相当する。ｅＮＢ２００は、Ｘ２インターフェイスを介して相互に接続される。ｅＮＢ２００の構成については後述する。
　ｅＮＢ２００は、１又は複数のセルを形成しており、自セルとの接続を確立したＵＥ１００との無線通信を行う。ｅＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータのルーティング機能、モビリティ制御・スケジューリングのための測定制御機能などを有する。「セル」は、無線通信エリアの最小単位を示す用語として使用される他に、ＵＥ１００との無線通信を行う機能を示す用語としても使用される。
　ＥＰＣ２０は、コアネットワークに相当する。ＥＰＣ２０は、ＭＭＥ（Ｍｏｂｉｌｉｔｙ　Ｍａｎａｇｅｍｅｎｔ　Ｅｎｔｉｔｙ）／Ｓ－ＧＷ（Ｓｅｒｖｉｎｇ－Ｇａｔｅｗａｙ）３００を含む。ＭＭＥは、ＵＥ１００に対する各種モビリティ制御などを行う。Ｓ－ＧＷは、ユーザデータの転送制御を行う。ＭＭＥ／Ｓ－ＧＷ３００は、Ｓ１インターフェイスを介してｅＮＢ２００と接続される。なお、Ｅ－ＵＴＲＡＮ１０及びＥＰＣ２０は、ＬＴＥシステムのネットワークを構成する。
　図２は、ＵＥ１００のブロック図である。図２に示すように、ＵＥ１００は、複数のアンテナ１０１、無線送受信機１１０、ユーザインターフェイス１２０、ＧＮＳＳ（Ｇｌｏｂａｌ　Ｎａｖｉｇａｔｉｏｎ　Ｓａｔｅｌｌｉｔｅ　Ｓｙｓｔｅｍ）受信機１３０、バッテリ１４０、メモリ１５０、及びプロセッサ１６０を備える。メモリ１５０及びプロセッサ１６０は、制御部を構成する。無線送受信機１１０及びプロセッサ１６０は、送信部及び受信部を構成する。ＵＥ１００は、ＧＮＳＳ受信機１３０を有していなくてもよい。また、メモリ１５０をプロセッサ１６０と一体化し、このセット（すなわち、チップセット）をプロセッサとしてもよい。
　アンテナ１０１及び無線送受信機１１０は、無線信号の送受信に用いられる。無線送受信機１１０は、プロセッサ１６０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナ１０１から送信する。また、無線送受信機１１０は、アンテナ１０１が受信する無線信号をベースバンド信号（受信信号）に変換してプロセッサ１６０に出力する。
　ユーザインターフェイス１２０は、ＵＥ１００を所持するユーザとのインターフェイスであり、例えば、ディスプレイ、マイク、スピーカ、及び各種ボタンなどを含む。ユーザインターフェイス１２０は、ユーザからの操作を受け付けて、受け付けた操作の内容を示す信号をプロセッサ１６０に出力する。ＧＮＳＳ受信機１３０は、ＵＥ１００の地理的な位置を示す位置情報を得るために、ＧＮＳＳ信号を受信して、受信した信号をプロセッサ１６０に出力する。バッテリ１４０は、ＵＥ１００の各ブロックに供給すべき電力を蓄える。
　メモリ１５０は、プロセッサ１６０により実行されるプログラム、及びプロセッサ１６０による処理に使用される情報を記憶する。プロセッサ１６０は、ベースバンド信号の変調・復調及び符号化・復号などを行うベースバンドプロセッサと、メモリ１５０に記憶されるプログラムを実行して各種の処理を行うＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）とを含む。プロセッサ１６０は、さらに、音声・映像信号の符号化・復号を行うコーデックを含んでもよい。プロセッサ１６０は、後述する各種の処理及び各種の通信プロトコルを実行する。
　図３は、ｅＮＢ２００のブロック図である。図３に示すように、ｅＮＢ２００は、複数のアンテナ２０１、無線送受信機２１０、ネットワークインターフェイス２２０、メモリ２３０、及びプロセッサ２４０を備える。メモリ２３０及びプロセッサ２４０は、制御部を構成する。無線送受信機２１０（及び／又はネットワークインターフェイス２２０）及びプロセッサ２４０は、送信部及び受信部を構成する。また、メモリ２３０をプロセッサ２４０と一体化し、このセット（すなわち、チップセット）をプロセッサとしてもよい。
　アンテナ２０１及び無線送受信機２１０は、無線信号の送受信に用いられる。無線送受信機２１０は、プロセッサ２４０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナ２０１から送信する。また、無線送受信機２１０は、アンテナ２０１が受信する無線信号をベースバンド信号（受信信号）に変換してプロセッサ２４０に出力する。
　ネットワークインターフェイス２２０は、Ｘ２インターフェイスを介して隣接ｅＮＢ２００と接続され、Ｓ１インターフェイスを介してＭＭＥ／Ｓ－ＧＷ３００と接続される。ネットワークインターフェイス２２０は、Ｘ２インターフェイス上で行う通信及びＳ１インターフェイス上で行う通信に用いられる。
　メモリ２３０は、プロセッサ２４０により実行されるプログラム、及びプロセッサ２４０による処理に使用される情報を記憶する。プロセッサ２４０は、ベースバンド信号の変調・復調及び符号化・復号などを行うベースバンドプロセッサと、メモリ２３０に記憶されるプログラムを実行して各種の処理を行うＣＰＵとを含む。プロセッサ２４０は、後述する各種の処理及び各種の通信プロトコルを実行する。
　図４は、ＬＴＥシステムにおける無線インターフェイスのプロトコルスタック図である。図４に示すように、無線インターフェイスプロトコルは、ＯＳＩ参照モデルの第１層乃至第３層に区分されており、第１層は物理（ＰＨＹ）層である。第２層は、ＭＡＣ（Ｍｅｄｉｕｍ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）層、ＲＬＣ（Ｒａｄｉｏ　Ｌｉｎｋ　Ｃｏｎｔｒｏｌ）層、及びＰＤＣＰ（Ｐａｃｋｅｔ　Ｄａｔａ　Ｃｏｎｖｅｒｇｅｎｃｅ　Ｐｒｏｔｏｃｏｌ）層を含む。第３層は、ＲＲＣ（Ｒａｄｉｏ　Ｒｅｓｏｕｒｃｅ　Ｃｏｎｔｒｏｌ）層を含む。
　物理層は、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００の物理層とｅＮＢ２００の物理層との間では、物理チャネルを介してユーザデータ及び制御情報が伝送される。
　ＭＡＣ層は、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ）による再送処理、及びランダムアクセス手順などを行う。ＵＥ１００のＭＡＣ層とｅＮＢ２００のＭＡＣ層との間では、トランスポートチャネルを介してユーザデータ及び制御情報が伝送される。ｅＮＢ２００のＭＡＣ層は、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））及びＵＥ１００への割当リソースブロックを決定するスケジューラを含む。
　ＲＬＣ層は、ＭＡＣ層及び物理層の機能を利用してデータを受信側のＲＬＣ層に伝送する。ＵＥ１００のＲＬＣ層とｅＮＢ２００のＲＬＣ層との間では、論理チャネルを介してユーザデータ及び制御情報が伝送される。
　ＰＤＣＰ層は、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。また、ＰＤＣＰ層には、データユニット（ＰＤＣＰ　ＰＤＵ）を送信するための送信エンティティ又はデータユニット（ＰＤＣＰ　ＰＤＵ）を受信するための受信エンティティが形成されることに留意すべきである。
　ＲＲＣ層は、制御情報を取り扱う制御プレーンでのみ定義される。ＵＥ１００のＲＲＣ層とｅＮＢ２００のＲＲＣ層との間では、各種設定のための制御情報（ＲＲＣメッセージ）が伝送される。ＲＲＣ層は、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がある場合に、ＵＥ１００はＲＲＣコネクティッド状態であり、ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がない場合に、ＵＥ１００はＲＲＣアイドル状態である。
　ＲＲＣ層の上位に位置するＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）層は、セッション管理及びモビリティ管理などを行う。
　図５は、ＬＴＥシステムで使用される無線フレームの構成図である。ＬＴＥシステムは、下りリンクにはＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ　Ｆｒｅｑｕｅｎｃｙ　Ｄｉｖｉｓｉｏｎ　Ｍｕｌｔｉｐｌｅｘｉｎｇ　Ａｃｃｅｓｓ）、上りリンクにはＳＣ－ＦＤＭＡ（Ｓｉｎｇｌｅ　Ｃａｒｒｉｅｒ　Ｆｒｅｑｕｅｎｃｙ　Ｄｉｖｉｓｉｏｎ　Ｍｕｌｔｉｐｌｅ　Ａｃｃｅｓｓ）がそれぞれ適用される。
　図５に示すように、無線フレームは、時間方向に並ぶ１０個のサブフレームで構成される。各サブフレームは、時間方向に並ぶ２個のスロットで構成される。各サブフレームの長さは１ｍｓであり、各スロットの長さは０．５ｍｓである。各サブフレームは、周波数方向に複数個のリソースブロック（ＲＢ）を含み、時間方向に複数個のシンボルを含む。各リソースブロックは、周波数方向に複数個のサブキャリアを含む。１つのシンボル及び１つのサブキャリアにより１つのリソースエレメント（ＲＥ）が構成される。また、ＵＥ１００に割り当てられる無線リソース（時間・周波数リソース）のうち、周波数リソースはリソースブロックにより特定でき、時間リソースはサブフレーム（又はスロット）により特定できる。
　（適用シーン）
　以下において、適用シーンについて説明する。図６は、第一実施形態に係る適用シーンを説明するための図である。
　図６に示すように、適用シーンでは、ｅＮＢ２００が有するセル内にＵＥ１００＃１が少なくとも在圏しているケースを想定する。このようなケースにおいて、ＵＥ１００＃１及びｅＮＢ２００は、セルラ通信を行っており、ＵＥ１００＃１及びＵＥ１００＃２は、ＵＥ間の直接的な通信であるＤ２Ｄ通信を行っている。
　ＵＥ１００＃２は、ｅＮＢ２００が有するセル内に位置していてもよい（Ｉｎ－Ｃｏｖｅｒａｇｅ）。或いは、ＵＥ１００＃２は、ｅＮＢ２００が有するセル内に位置していなくてもよい（Ｏｕｔ－ｏｆ－Ｃｏｖｅｒａｇｅ）。
　但し、ＵＥ１００＃１とＵＥ１００＃２との間のＤ２Ｄ通信で用いる無線リソースは、ｅＮＢ２００によって指定される。具体的には、ｅＮＢ２００は、ＵＥ１００＃１に対して、Ｄ２Ｄ通信で用いる無線リソースの割り当て情報を含むメッセージ（ＤＣＩ；Ｄｏｗｎｌｉｎｋ　Ｃｏｎｔｒｏｌ　Ｉｎｆｏｒｍａｔｉｏｎ）を送信する。このようなメッセージは、“ＤＣＩ　Ｆｏｒｍａｔ　５”と称されることもある。
　このような前提下において、ＵＥ１００＃１（受信部）は、Ｄ２Ｄ通信を行うためのサイドリンクを介して、ＵＥ１００＃２に送信したデータの送達確認情報をＵＥ１００＃２から受信する。ＵＥ１００＃１（制御部）は、送達確認情報に基づいて、サイドリンクのサービス品質の測定結果を生成する。ＵＥ１００＃１（送信部）は、ｅＮＢ２００とセルラ通信を行うための上りリンクを介して、サービス品質の測定結果をｅＮＢ２００に報告する。
　サービス品質の測定結果は、サイドリンクにおいて消失したデータ量（以下、サイドリンクデータロス）、サイドリンクにおけるＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）層のスループット（以下、サイドリンクＩＰスループット）、ＵＥ１００＃２が受信に成功したデータ量（以下、サイドリンクデータ量）の中から選択された１以上のデータである。
　サイドリンクデータロスは、例えば、以下に示す式によって算出可能である。
Figure JPOXMLDOC01-appb-M000001
　但し、Ｍ（Ｔ，ｑｃｉ）は、サイドリンクにおけるＱＣＩ（ＱｏＳ　Ｃｌａｓｓ　Ｉｄｅｎｔｉｆｉｅｒ）毎のパケットのロスを示す値である。Ｄｌｏｓｓ（Ｔ，ｑｃｉ）は、サイドリンクで消失したＰＤＣＰ（Ｐａｃｋｅｔ　Ｄａｔａ　Ｃｏｎｖｅｒｇｅｎｃｅ　Ｐｒｏｔｏｃｏｌ）パケットの数であり、時間Ｔにおいて上位レイヤに導かれなかったＱＣＩ＝ｑｃｉのＰＤＣＰパケットの数を示している。Ｎｌｏｓｓ（Ｔ，ｑｃｉ）は、サイドリンクで送信されたＰＤＣＰ（Ｐａｃｋｅｔ　Ｄａｔａ　Ｃｏｎｖｅｒｇｅｎｃｅ　Ｐｒｏｔｏｃｏｌ）パケットの総数であり、時間ＴにおけるＱＣＩ＝ｑｃｉのＰＤＣＰパケットの総数を示している。Ｔは、サイドリンクデータロスの測定が行われる期間を示している。
　サイドリンクＩＰスループットは、例えば、以下に示す式によって算出可能である。
Figure JPOXMLDOC01-appb-M000002
　但し、ＴｈｐＴｉｍｅＳＩは、データ量が１つのＴＴＩにおいて十分に送信可能な量である場合に、“０”がセットされるパラメータであり、他の場合には、“Ｔ１－Ｔ２”がセットされるパラメータである。Ｔ１は、測定期間の最後においてデータが継続している場合には、測定期間の終了時間がセットされるパラメータであり、他の場合には、測定期間に含まれるＴＴＩのうち、データ送信に用いられた最後のＴＴＩの終了時間がセットされるパラメータである。Ｔ２は、測定期間の最初においてデータが継続している場合には、測定期間の開始時間がセットされるパラメータであり、他の場合には、測定期間に含まれるＴＴＩのうち、データ送信に用いられた最初のＴＴＩの開始時間がセットされるパラメータである。ＴｈｐＶｏｌＩＰは、サイドリンクで受信されたＰＤＣＰ層のＳＤＵ（単位＝ｋｂｉｔｓ）から、データ送信で用いられた最後のＴＴＩで受信したデータ量を差し引いた値である。
　サイドリンクデータ量は、測定期間においてＵＥ１００＃２が受信に成功したＰＤＣＰ層のＳＤＵのビット数である。
　ここで、サービス品質の測定結果をｅＮＢ２００に報告するタイミングとしては、（Ａ）Ｉｍｍｅｄｉａｔｅ　ＭＤＴを利用するケース及び（Ｂ）Ｌｏｇｇｅｄ　ＭＤＴ　ｉｎ　Ｃｏｎｎｅｃｔｅｄを利用するケースが考えられる。
　（Ａ）Ｉｍｍｅｄｉａｔｅ　ＭＤＴ
　Ｉｍｍｅｄｉａｔｅ　ＭＤＴでは、接続状態にあるＵＥ１００は、ｅＮＢ２００から測定設定情報（ＲＲＭ　Ｍｅａｓｕｒｅｍｅｎｔ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ）を受信し、測定設定情報に含まれる各種の測定設定パラメータを記憶する。測定設定パラメータは、サービス品質の測定結果を報告するトリガである報告トリガを含む。ＵＥ１００は、報告トリガに対応するイベントの発生に応じて、サービス品質の測定結果を生成するとともに、サービス品質の測定結果をｅＮＢ２００に報告する。
　具体的には、上述したＵＥ１００＃１は、サービス品質の測定結果が生成されたタイミングで、サービス品質の測定結果をｅＮＢ２００に報告する。或いは、ＵＥ１００＃１は、所定の閾値を下回ったサービス品質の測定結果が生成されたタイミングで、所定の閾値を下回ったサービス品質の測定結果をｅＮＢ２００に報告してもよい。
　所定の閾値は、測定設定情報に含まれることが好ましい。所定の閾値は、予め定義された値であってもよい。サービス品質の測定結果は、ＵＥ１００の位置情報を含むことが好ましい。
　（Ｂ）Ｌｏｇｇｅｄ　ＭＤＴ　ｉｎ　Ｃｏｎｎｅｃｔｅｄ
　Ｌｏｇｇｅｄ　ＭＤＴ　ｉｎ　Ｃｏｎｎｅｃｔｅｄでは、接続状態にあるＵＥ１００は、ｅＮＢ２００から測定設定情報（Ｌｏｇｇｅｄ　Ｍｅａａｓｕｒｅｍｅｎｔ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ）を受信し、測定設定情報に含まれる各種のＭＤＴ設定パラメータを記憶する。ＭＤＴ設定パラメータは、サービス品質の測定結果を生成するトリガである生成トリガを含む。ＵＥ１００は、生成トリガに対応するイベントの発生に応じて、サービス品質の測定結果を記憶部に記憶（ログ）する。ＵＥ１００は、ｅＮＢ２００から受信する報告要求に応じて、記憶部に記憶されたサービス品質の測定結果をｅＮＢ２００に報告する。
　具体的には、上述したＵＥ１００＃１は、サービス品質の測定結果を記憶部に格納する。上述したＵＥ１００＃１は、ｅＮＢ２００から報告要求を受信したタイミングで、記憶部に記憶されたサービス品質の測定結果をｅＮＢ２００に報告する。或いは、ＵＥ１００＃１は、ｅＮＢ２００から報告要求を受信したタイミングで、記憶部に記憶されたサービス品質の測定結果のうち、所定の閾値を下回るサービス品質の測定結果をｅＮＢ２００に報告する。ここで、ＵＥ１００＃１は、所定の閾値を下回るサービス品質の測定結果のみを記憶部に格納するように構成されていてもよい。
　所定の閾値は、測定設定情報に含まれることが好ましい。所定の閾値は、予め定義された値であってもよい。サービス品質の測定結果は、ＵＥ１００の位置情報を含むことが好ましい。
　Ｌｏｇｇｅｄ　ＭＤＴ　ｉｎ　Ｃｏｎｎｅｃｔｅｄにおいて、ＵＥ１００は、ＲＲＣアイドル状態からＲＲＣコネクティッド状態に遷移する場合に、サービス品質の測定結果が記憶部に格納されている旨を示す情報（Ａｖａｉｌａｂｌｅ　Ｉｎｄｉｃａｔｉｏｎ）をｅＮＢ２００に通知してもよい。或いは、ＵＥ１００は、ソースのｅＮＢ２００からターゲットのｅＮＢ２００へのハンドオーバを行う際に、サービス品質の測定結果が記憶部に格納されている旨を示す情報（Ａｖａｉｌａｂｌｅ　Ｉｎｄｉｃａｔｉｏｎ）をターゲットのｅＮＢ２００に送信してもよい。このようなケースにおいて、ｅＮＢ２００は、サービス品質の測定結果が記憶部に格納されている旨を示す情報（Ａｖａｉｌａｂｌｅ　Ｉｎｄｉｃａｔｉｏｎ）に応じて、サービス品質の測定結果の報告要求をＵＥ１００に送信する。
　或いは、ｅＮＢ２００は、Ｄ２Ｄ通信で用いるＵＥ１００のバッファの状態を示すバッファステータスレポート（ＢＳＲ）をＵＥ１００から受信するとともに、バッファステータスレポートに基づいて、Ｄ２Ｄ通信で送信すべきデータがあるか否かを判定してもよい。ｅＮＢ２００は、Ｄ２Ｄ通信で送信すべきデータがない場合に、Ｄ２Ｄ通信が終了したと判定して、サービス品質の測定結果の報告要求をＵＥ１００に送信する。
　（移動通信方法）
　以下において、第一実施形態に係る移動通信方法について説明する。図７及び図８は、第一実施形態に係る移動通信方法を示すシーケンス図である。ここでは、ＵＥ１００＃１及びｅＮＢ２００がセルラ通信を行っており、ＵＥ１００＃１及びＵＥ１００＃２がＤ２Ｄ通信を行うケースを例示する。ここでは、ＵＥ１００＃１からＵＥ１００＃２に対してデータを送信し、ＵＥ１００＃２からＵＥ１００＃１に対して送達確認情報を送信するケースについて主として説明する。
　第１に、Ｉｍｍｅｄｉａｔｅ　ＭＤＴについて図７を参照しながら説明する。
　図７に示すように、ステップＳ１０において、ｅＮＢ２００は、ＵＥ１００＃１とＵＥ１００＃２との間のＤ２Ｄ通信で用いる無線リソースを指定するメッセージ（ＤＣＩ　Ｆｏｒｍａｔ　５）をＵＥ１００＃１に送信する。
　ステップＳ１１Ａ又はステップＳ１１Ｂにおいて、ＵＥ１００＃１及びＵＥ１００＃２は、ｅＮＢ２００によって指定された無線リソースを用いてＤ２Ｄ通信を行う。
　ステップＳ１２において、ｅＮＢ２００は、測定設定情報をＵＥ１００＃１に送信する。測定設定情報に含まれる各種の測定設定パラメータを記憶する。測定設定パラメータは、サービス品質の測定結果を報告するトリガである報告トリガを含む。ステップＳ１２において、測定設定情報は、サイドリンクのサービス品質の測定を要求する情報を含む。測定設定情報は、ＲＲＭ　Ｍｅａｓｕｒｅｍｅｎｔ　Ｃｏｎｆｉｇｕｒａｔｉｏｎに含まれていてもよい。
　ステップＳ１３Ａ又はステップＳ１３Ｂにおいて、ＵＥ１００＃１は、ＵＥ１００＃２から受信する送達確認情報に基づいて、サイドリンクのサービス品質を測定する。
　ステップＳ１４Ａ又はステップＳ１４Ｂにおいて、ＵＥ１００＃１は、報告トリガに対応するイベントの発生に応じて、サービス品質の測定結果を生成する。ＵＥ１００＃１は、サービス品質の測定結果が生成されたタイミングで、サービス品質の測定結果をｅＮＢ２００に報告してもよい。或いは、ＵＥ１００＃１は、所定の閾値を下回ったサービス品質の測定結果が生成されたタイミングで、所定の閾値を下回ったサービス品質の測定結果をｅＮＢ２００に報告してもよい。
　ステップＳ１５において、ＵＥ１００＃１及びＵＥ１００＃２は、Ｄ２Ｄ通信を終了する。
　ステップＳ１６において、ｅＮＢ２００は、測定設定情報をＵＥ１００＃１に送信する。ステップＳ１６において、測定設定情報は、サイドリンクのサービス品質の測定及び報告を要求する情報を含まない。或いは、測定設定情報は、サイドリンクのサービス品質の測定及び報告を解除する情報を含んでもよい。
　第２に、Ｌｏｇｇｅｄ　ＭＤＴ　ｉｎ　Ｃｏｎｎｅｃｔｅｄについて図８を参照しながら説明する。
　図８に示すように、ステップＳ２０において、ｅＮＢ２００は、ＵＥ１００＃１とＵＥ１００＃２との間のＤ２Ｄ通信で用いる無線リソースを指定するメッセージ（ＤＣＩ　Ｆｏｒｍａｔ　５）をＵＥ１００＃１に送信する。
　ステップＳ２１Ａ又はステップＳ２１Ｂにおいて、ＵＥ１００＃１及びＵＥ１００＃２は、ｅＮＢ２００によって指定された無線リソースを用いてＤ２Ｄ通信を行う。
　ステップＳ２２において、ｅＮＢ２００は、測定設定情報をＵＥ１００＃１に送信する。測定設定情報に含まれる各種の測定設定パラメータを記憶する。測定設定パラメータは、サービス品質の測定結果を生成するトリガである生成トリガを含む。ステップＳ２２において、測定設定情報は、サイドリンクのサービス品質の測定及び報告を要求する情報を含む。測定設定情報は、ＲＲＭ　Ｍｅａｓｕｒｅｍｅｎｔ　Ｃｏｎｆｉｇｕｒａｔｉｏｎに含まれていてもよい。
　ステップＳ２３Ａ又はステップＳ２３Ｂにおいて、ＵＥ１００＃１は、ＵＥ１００＃２から受信する送達確認情報に基づいて、サイドリンクのサービス品質を測定する。ＵＥ１００＃１は、生成トリガに対応するイベントの発生に応じて、サービス品質の測定結果を記憶部に記憶（ログ）する。ここで、ＵＥ１００＃１は、所定の閾値を下回るサービス品質の測定結果のみを記憶部に格納してもよい。
　ステップＳ２４において、ＵＥ１００＃１及びＵＥ１００＃２は、Ｄ２Ｄ通信を終了する。
　ステップＳ２５において、ＵＥ１００＃１は、コネクティッド状態からアイドル状態に遷移する。
　ステップＳ２６において、ＵＥ１００＃１は、アイドル状態からコネクティッド状態に遷移する。
　ステップＳ２７において、ｅＮＢ２００は、サービス品質の測定結果の報告要求をＵＥ１００＃１に送信する。上述したように、ｅＮＢ２００は、ＵＥ１００＃１から通知される情報（Ａｖａｉｌａｂｌｅ　Ｉｎｄｉｃａｔｉｏｎ）に応じて、サービス品質の測定結果の報告要求をＵＥ１００＃１に送信してもよく、ＵＥ１００＃１から通知される情報（Ｄ２Ｄ通信のＢＳＲ）に応じて、サービス品質の測定結果の報告要求をＵＥ１００＃１に送信してもよい。
　ステップＳ２８において、ＵＥ１００＃１は、ｅＮＢ２００から報告要求を受信したタイミングで、記憶部に記憶されたサービス品質の測定結果をｅＮＢ２００に報告する。或いは、ＵＥ１００＃１は、ｅＮＢ２００から報告要求を受信したタイミングで、記憶部に記憶されたサービス品質の測定結果のうち、所定の閾値を下回るサービス品質の測定結果をｅＮＢ２００に報告してもよい。
　上述した第一実施形態では、ＵＥ１００＃１（データの送信側／送達確認情報の受信側）がサービス品質の測定結果をｅＮＢ２００に報告するケースについて主として記載した。しかしながら、ＵＥ１００＃２（データの受信側／送達確認情報の送信側）がサービス品質の測定結果をｅＮＢ２００に報告してもよい。このようなケースでは、ステップＳ１２或いはステップＳ２２において、ｅＮＢ２００は、測定設定情報をＵＥ１００＃２に送信してもよい。
　（作用及び効果）
　第一実施形態では、ＵＥ１００は、Ｄ２Ｄ通信を行うためのサイドリンクのサービス品質の測定結果をｅＮＢ２００に報告する。これによって、サービス品質の測定結果を用いて適切なスケジューリングを行うことができる。例えば、サービス品質を満たしていないＵＥ１００に割り当てるリソース量を増大することができる。
　［変更例１］
　以下において、第一実施形態の変更例１について説明する。以下においては、第一実施形態に対する相違点について主として説明する。
　具体的には、第一実施形態では、ＭＤＴにおいてサービス品質の測定結果を報告する手順について説明した。これに対して、変更例１では、ＭＤＴにおいてｅＮＢ２００に対する上りリンクにおけるデータの上り遅延時間の測定結果を報告する手順について説明する。ここで、上り遅延時間とは、上りリンクで送信すべきデータがＵＥ１００で生成されてから受信側（ｅＮＢ２００）でデータが受信されるまでの遅延時間、或いは、上りリンクで送信すべきデータがＵＥ１００で生成されてから受信側（ｅＮＢ２００）でデータが受信された旨が通知されるまでの遅延時間（ＵＬ　ｑｕｅｕｉｎｇ　ｄｅｌａｙ）である。
　詳細には、ＵＥ１００（制御部）は、ｅＮＢ２００に対する上りリンクにおけるデータの上り遅延時間の測定結果を生成する。ＵＥ１００（送信部）は、上り遅延時間の測定結果をｅＮＢ２００に報告する。
　ここで、上り遅延時間の測定結果をｅＮＢ２００に報告するタイミングとしては、第一実施形態と同様に、（Ａ）Ｉｍｍｅｄｉａｔｅ　ＭＤＴを利用するケース及び（Ｂ）Ｌｏｇｇｅｄ　ＭＤＴ　ｉｎ　Ｃｏｎｎｅｃｔｅｄを利用するケースが考えられる。
　（Ａ）Ｉｍｍｅｄｉａｔｅ　ＭＤＴ
　Ｉｍｍｅｄｉａｔｅ　ＭＤＴでは、接続状態にあるＵＥ１００は、ｅＮＢ２００から測定設定情報（ＲＲＭ　Ｍｅａｓｕｒｅｍｅｎｔ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ）を受信し、測定設定情報に含まれる各種の測定設定パラメータを記憶する。測定設定パラメータは、上り遅延時間の測定結果を報告するトリガである報告トリガを含む。ＵＥ１００は、報告トリガに対応するイベントの発生に応じて、上り遅延時間の測定結果を生成するとともに、上り遅延時間の測定結果をｅＮＢ２００に報告する。
　具体的には、ＵＥ１００は、上り遅延時間の測定結果が生成されたタイミングで、上り遅延時間の測定結果をｅＮＢ２００に報告する。或いは、ＵＥ１００は、所定の閾値を上回った上り遅延時間の測定結果が生成されたタイミングで、所定の閾値を上回った上り遅延時間の測定結果をｅＮＢ２００に報告してもよい。
　所定の閾値は、測定設定情報に含まれることが好ましい。所定の閾値は、予め定義された値であってもよい。上り遅延時間の測定結果は、ＵＥ１００の位置情報を含むことが好ましい。
　（Ｂ）Ｌｏｇｇｅｄ　ＭＤＴ　ｉｎ　Ｃｏｎｎｅｃｔｅｄ
　Ｌｏｇｇｅｄ　ＭＤＴ　ｉｎ　Ｃｏｎｎｅｃｔｅｄでは、接続状態にあるＵＥ１００は、ｅＮＢ２００から測定設定情報（Ｌｏｇｇｅｄ　Ｍｅａａｓｕｒｅｍｅｎｔ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ）を受信し、測定設定情報に含まれる各種のＭＤＴ設定パラメータを記憶する。ＭＤＴ設定パラメータは、上り遅延時間の測定結果を生成するトリガである生成トリガを含む。ＵＥ１００は、生成トリガに対応するイベントが発生した際に、上り遅延時間の測定結果を記憶部に記憶（ログ）する。ＵＥ１００は、ｅＮＢ２００から受信する報告要求に応じて、記憶部に記憶された上り遅延時間の測定結果をｅＮＢ２００に報告する。
　具体的には、ＵＥ１００は、上り遅延時間の測定結果を記憶部に格納する。ＵＥ１００は、ｅＮＢ２００から報告要求を受信したタイミングで、記憶部に記憶された上り遅延時間の測定結果をｅＮＢ２００に報告する。或いは、ＵＥ１００は、ｅＮＢ２００から報告要求を受信したタイミングで、記憶部に記憶された上り遅延時間の測定結果のうち、所定の閾値を上回った上り遅延時間の測定結果をｅＮＢ２００に報告する。ここで、ＵＥ１００は、所定の閾値を上回った上り遅延時間の測定結果のみを記憶部に格納するように構成されていてもよい。
　所定の閾値は、測定設定情報に含まれることが好ましい。所定の閾値は、予め定義された値であってもよい。上り遅延時間の測定結果は、ＵＥ１００の位置情報を含むことが好ましい。
　Ｌｏｇｇｅｄ　ＭＤＴ　ｉｎ　Ｃｏｎｎｅｃｔｅｄにおいて、ＵＥ１００は、ＲＲＣアイドル状態からＲＲＣコネクティッド状態に遷移する場合に、上り遅延時間の測定結果が記憶部に格納されている旨を示す情報（Ａｖａｉｌａｂｌｅ　Ｉｎｄｉｃａｔｉｏｎ）をｅＮＢ２００に通知してもよい。或いは、ＵＥ１００は、ソースのｅＮＢ２００からターゲットのｅＮＢ２００へのハンドオーバを行う際に、上り遅延時間の測定結果が記憶部に格納されている旨を示す情報（Ａｖａｉｌａｂｌｅ　Ｉｎｄｉｃａｔｉｏｎ）をターゲットのｅＮＢ２００に送信してもよい。このようなケースにおいて、ｅＮＢ２００は、上り遅延時間の測定結果が記憶部に格納されている旨を示す情報（Ａｖａｉｌａｂｌｅ　Ｉｎｄｉｃａｔｉｏｎ）に応じて、上り遅延時間の測定結果の報告要求をＵＥ１００に送信する。
　（移動通信方法）
　以下において、変更例１に係る移動通信方法について説明する。図９及び図１０は、変更例１に係る移動通信方法を示すシーケンス図である。
　第１に、Ｉｍｍｅｄｉａｔｅ　ＭＤＴについて図９を参照しながら説明する。
　図９に示すように、ステップＳ４０において、ＵＥ１００は、ＲＲＣコネクティッド状態である。
　ステップＳ４１において、ｅＮＢ２００は、測定設定情報をＵＥ１００に送信する。測定設定情報に含まれる各種の測定設定パラメータを記憶する。測定設定パラメータは、上り遅延時間の測定結果を報告するトリガである報告トリガを含む。測定設定情報は、ＲＲＭ　Ｍｅａｓｕｒｅｍｅｎｔ　Ｃｏｎｆｉｇｕｒａｔｉｏｎに含まれていてもよい。
　ステップＳ４２Ａ又はステップＳ４２Ｂにおいて、ＵＥ１００は、上り遅延時間のサービス品質を測定する。
　ステップＳ４３Ａ又はステップＳ４３Ｂにおいて、ＵＥ１００は、報告トリガに対応するイベントの発生に応じて、上り遅延時間の測定結果を生成する。ＵＥ１００は、上り遅延時間の測定結果が生成されたタイミングで、上り遅延時間の測定結果をｅＮＢ２００に報告してもよい。或いは、ＵＥ１００は、所定の閾値を上回った上り遅延時間の測定結果が生成されたタイミングで、所定の閾値を上回った上り遅延時間の測定結果をｅＮＢ２００に報告してもよい。
　図１０に示すように、ステップＳ５０において、ＵＥ１００は、ＲＲＣコネクティッド状態である。
　ステップＳ５１において、ｅＮＢ２００は、測定設定情報をＵＥ１００に送信する。測定設定情報に含まれる各種の測定設定パラメータを記憶する。測定設定パラメータは、上り遅延時間の測定結果を生成するトリガである生成トリガを含む。測定設定情報は、ＲＲＭ　Ｍｅａｓｕｒｅｍｅｎｔ　Ｃｏｎｆｉｇｕｒａｔｉｏｎに含まれていてもよい。
　ステップＳ５２において、ＵＥ１００は、上り遅延時間のサービス品質を測定する。ＵＥ１００は、生成トリガに対応するイベントの発生に応じて、上り遅延時間の測定結果を記憶部に記憶（ログ）する。ここで、ＵＥ１００は、所定の閾値を上回った上り遅延時間の測定結果のみを記憶部に格納してもよい。
　ステップＳ５３において、ＵＥ１００は、コネクティッド状態からアイドル状態に遷移する。
　ステップＳ５４において、ＵＥ１００は、アイドル状態からコネクティッド状態に遷移する。
　ステップＳ５５において、ｅＮＢ２００は、上り遅延時間の測定結果の報告要求をＵＥ１００に送信する。上述したように、ｅＮＢ２００は、ＵＥ１００から通知される情報（Ａｖａｉｌａｂｌｅ　Ｉｎｄｉｃａｔｉｏｎ）に応じて、上り遅延時間の測定結果の報告要求をＵＥ１００に送信する。
　ステップＳ５６において、ＵＥ１００は、ｅＮＢ２００から報告要求を受信したタイミングで、記憶部に記憶された上り遅延時間の測定結果をｅＮＢ２００に報告する。或いは、ＵＥ１００は、ｅＮＢ２００から報告要求を受信したタイミングで、記憶部に記憶された上り遅延時間の測定結果のうち、所定の閾値を上回った上り遅延時間の測定結果をｅＮＢ２００に報告してもよい。
　上述した変更例１において、ＵＥ１００は、上り遅延時間の測定結果のばらつきを推定するための情報（以下、報告情報）をｅＮＢ２００に報告する。報告情報は、平均上り遅延時間、下位５％の上り遅延時間、上位５％の上り遅延時間等を含んでもよい。
　（作用及び効果）
　変更例１では、ＵＥ１００は、ｅＮＢ２００に対する上りリンクにおけるデータの上り遅延時間の測定結果をｅＮＢ２００に報告する。これによって、上り遅延時間の測定結果を用いて適切なスケジューリングを行うことができる。例えば、上り遅延時間が大きいＵＥ１００に割り当てるリソース量を増大することができる。
　［変更例２］
　以下において、第一実施形態の変更例２について説明する。以下においては、第一実施形態に対する相違点について主として説明する。
　具体的には、第一実施形態では、ＭＤＴにおいてサービス品質の測定結果を報告する手順について説明した。これに対して、変更例２では、ＭＤＴにおいて少なくとも位置情報を含むＭＤＴ測定結果を報告する手順について説明する。ＭＤＴ測定結果は、既存のＭＤＴで報告される内容と同様であり、少なくともＵＥ１００の地理的な位置を示す位置情報を含んでいればよい。ＭＤＴ測定結果は、ｅＮＢ２００からセルラ通信によって受信する信号の受信品質（ＲＳＲＰやＲＳＲＱ）を含んでもよい。
　詳細には、ＵＥ１００は、セルラ通信を行う機能に加えて、セルラ通信以外の通信（例えば、ＷｉＦｉやＢｌｕｅＴｏｏｔｈ）を行う機能を有するデュアル端末である。また、変更例２では、Ｌｏｇｇｅｄ　ＭＤＴ　ｉｎ　ＩｄｌｅによってＭＤＴ測定結果を報告するケースを主として想定している。
　ここで、第０段階として、ＵＥ１００は、セルラ通信に加えて、セルラ通信以外の通信（例えば、ＷｉＦｉやＢｌｕｅＴｏｏｔｈ）を開始する。すなわち、ＵＥ１００内においてセルラ通信及びセルラ通信以外の通信が同時に行われ状態（ＩＤＣ；Ｉｎ　Ｄｅｖｉｃｅ　Ｃｏｅｘｉｓｔｅｎｃｅ）が生じる。上述した装置内干渉とは、ＩＤＣによって生じる干渉である。
　第１段階として、ＵＥ１００は、装置内干渉を検出する。具体的には、ＵＥ１００は、装置内干渉が所定閾値を超えたことを検出する（図１１に示すＰｈａｓｅ１の開始タイミング）。
　第２段階として、ＵＥ１００は、装置内干渉が生じていることを示すインディケーションをｅＮＢ２００に報告する（図１１に示すＰｈａｓｅ２の開始タイミング）。
　第３段階として、ｅＮＢ２００は、装置内干渉を解消するための手順を実行する。例えば、ｅＮＢ２００は、周波数の変更（ＦＤＭ　Ｓｏｌｕｔｉｏｎ）やセルラ通信のスケジューリングタイミングの変更（ＴＤＭ　Ｓｏｌｕｔｉｏｎ）などを行う（図１１に示すＰｈａｓｅ３の開始タイミング）。
　なお、図１１に示すＰｈａｓｅ１～３及び装置内干渉を解消するための手順については、既存の３ＧＰＰ規格書ＴＳ３６．３００　Ｖ．１２．５．０の２３．４．２に記載されていることに留意すべきである。
　このようなケースにおいて、ＵＥ１００（制御部）は、少なくとも位置情報を含むＭＤＴ測定結果を生成するとともに、ＭＤＴ測定結果を記憶部に格納する。ＵＥ１００（送信部）は、記憶部に記憶されたＭＤＴ測定結果をｅＮＢ２００に報告する。このようなケースにおいて、ＵＥ１００（制御部）は、セルラ通信以外の通信によって生じる装置内干渉が検出される前において、ＭＤＴ測定結果を記憶部に格納する。すなわち、ＵＥ１００は、図１１に示すＰｈａｓｅ１よりも前のＭＤＴ測定結果を記憶部に格納する。言い換えると、ＵＥ１００は、図１１に示すＰｈａｓｅ１以降のＭＤＴ測定結果を記憶部に格納しない。
　変更例２において、ＵＥ１００（制御部）は、セルラ通信以外の通信を開始した後に記憶部に格納されたＭＤＴ測定結果を破棄することが好ましい。すなわち、ＵＥ１００は、図１１に示すＰｈａｓｅ１よりも前の段階であっても、セルラ通信以外の通信を開始した後に記憶部に格納されたＭＤＴ測定結果を破棄する。ＵＥ１００は、セルラ通信以外の通信の開始に応じて、ＭＤＴ測定結果の記憶部への格納を停止してもよい。
　或いは、ＵＥ１００（制御部）は、装置内干渉が検出された場合であっても、ＭＤＴ測定結果を格納するための設定情報を維持するとともに、装置内干渉が解消した場合に、設定情報に従ってＭＤＴ測定結果の記憶部への格納を再開することが好ましい。すなわち、ＵＥ１００は、図１１に示すＰｈａｓｅ３以降において、ＭＤＴ測定結果の記憶部への格納を再開する。
　（作用及び効果）
　変更例３に係るＵＥ１００は、セルラ通信以外の通信によって生じる装置内干渉が検出される前において、ＭＤＴ測定結果を記憶部に格納する。すなわち、装置内干渉が検出される後におけるＭＤＴ測定結果が記憶部に格納されないため、装置内干渉によって悪影響を受けたＭＤＴ測定結果の記憶部への格納が抑制される。従って、ＵＥ１００の負荷増大を抑制しながらも、ｅＮＢ２００などの上位ノードによって、装置内干渉によって悪影響を受けたＭＤＴ測定結果を除外する手間を省くことができる。
　［第二実施形態］
　ＵＥ１００（プロセッサ１６０）は、上りリンクのＰＤＣＰのキューイング遅延を検出しない場合（スパイクを検出しない場合又はＰＤＣＰキューイングの遅延率が閾値未満の場合）、ｅＮＢ２００への報告のために、上りリンクのＰＤＣＰキューイング遅延の測定結果（ｕｌ－ＰＤＣＰ－ＤｅｌａｙＲｅｓｕｌｔ）を作成しなくてもよい（ＰＤＣＰキューイング遅延の測定結果の作成を制限してもよい）。なお、スパイクとは、単位時間内のＰＤＣＰパケットのうちの数パケットのキューイング遅延が突発的に閾値を超えてしまう状況である。また、ＰＤＣＰキューイングの遅延率とは、単位時間内のＰＤＣＰパケットのうち、キューイング遅延が閾値を超えたＰＤＣＰパケットの割合である。
　また、ＵＥ１００は、上りリンクのＰＤＣＰのキューイング遅延を検出しない場合でも、上りリンクのＰＤＣＰキューイング遅延の測定結果（ｕｌ－ＰＤＣＰ－ＤｅｌａｙＲｅｓｕｌｔ）を作成してもよい（測定結果に含めるｅｘｃｅｓｓＤｅｌａｙは０として作成する）。
　また、ＵＥ１００は、上りリンクのＰＤＣＰのキューイング遅延を検出した場合であってもＰＤＣＰキューイングの遅延率が閾値（０以上）未満の場合には、ｅＮＢ２００への報告のために、上りリンクのＰＤＣＰキューイング遅延の測定結果（ｕｌ－ＰＤＣＰ－ＤｅｌａｙＲｅｓｕｌｔ）を作成しなくてもよい。
　ＵＥ１００は、上りリンクのＰＤＣＰキューイング遅延の測定結果を作成しなかった場合には、ｅＮＢ２００へ上りリンクのＰＤＣＰキューイング遅延の測定結果を報告しなくてもよい。
　［その他の実施形態］
　本発明は上述した実施形態によって説明したが、この開示の一部をなす論述及び図面は、この発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施形態、実施例及び運用技術が明らかとなろう。
　実施形態では特に触れていないが、サービス品質の測定結果は、サイドリンクのＳＩＮＲ、サイドリンクのＢＬＥＲ、セルラ通信の下りリンクのＳＩＮＲ、セルラ通信の下りリンクのＢＬＥＲ、セルラ通信以外の通信（例えば、Ｗｉｆｉ）の上りリンク又は下りリンクのＳＩＮＲ、セルラ通信以外の通信（例えば、Ｗｉｆｉ）の上りリンク又は下りリンクのＢＬＥＲ、Ｄ２Ｄ　Ｄｉｓｃｏｖｅｒｙの送信をトリガしてから実際にＤ２Ｄ　Ｄｉｓｃｏｖｅｒｙを送信するまでの遅延等を含んでもよい。
　変更例１では特に触れていないが、上り遅延時間の測定結果をｅＮＢ２００に報告するＵＥ１００は、ｅＮＢ２００によって指定されてもよい。例えば、ｅＮＢ２００は、ＵＥ１００から受信する周期的な音声パケットを監視するとともに、周期的な音声パケットのジッタに基づいて上り遅延時間を推定する。ｅＮＢ２００は、推定された遅延時間が閾値よりも大きいＵＥ１００を、上り遅延時間の測定結果を報告するＵＥ１００として指定する。
　実施形態では、ＭＤＴを利用するケースを用いて説明したが、これに限られず、ＭＤＴを利用しないでサービス品質の測定結果を報告してもよい。同様に、変更例１では、ＭＤＴを利用するケースを用いて説明したが、これに限られず、ＭＤＴを利用しないで上り遅延時間の測定結果を報告してもよい。
　実施形態では特に触れていないが、ＵＥ１００及びｅＮＢ２００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。また、プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ等の記録媒体であってもよい。
　或いは、ＵＥ１００及びｅＮＢ２００が行う各処理を実行するためのプログラムを記憶するメモリ及びメモリに記憶されたプログラムを実行するプロセッサによって構成されるチップが提供されてもよい。
　実施形態では、移動通信システムの一例としてＬＴＥシステムを説明した。しかしながら、実施形態はこれに限定されるものではない。移動通信システムは、ＬＴＥシステム以外のシステムであってもよい。
　［付記１］
　（１．はじめに）
　「Ｅ－ＵＴＲＡＮのための駆動試験の最小化のさらなる強化」が合意された。重要な目的のうちの１つは、範囲およびネットワーク最適化のためのチャネル条件を正確に反映するために、ＵＥからのさらなるフィードバックのプロビジョンを研究することである。研究項目はまた、以下の目的を指摘した。
　・強化された範囲最適化使用の場合：
　ＭＤＴ測定結果にインパクトを与える追加のフィードバックの、多様な機能を取り扱うＵＥからのプロビジョン（たとえば、ＩＤＣのような新たなタイプの支援情報等）を考慮し、そのような情報が達成し得る利点が何であるかを分析する。
　本付記では、ＭＤＴ測定結果および潜在的な解決策に対するＩＤＣ干渉のインパクトについて議論される。
　（２．議論）
　ＦｅＭＤＴ研究項目の一部として、チャネル条件をＭＤＴ測定結果へ正確に反映するいくつかのメカニズムを研究するべきである。ＭＤＴ測定結果にインパクトを与える典型的な要因のうちの１つは、ＩＤＣ干渉である。デバイス内共存のための干渉回避のためのＴＲによれば、ＷｉＦｉおよびＢｌｕｅｔｏｏｔｈは、ＬＴＥデバイスに対して干渉し得る。現在の仕様によれば、ＵＥは、自身では解決することができないＩＤＣ問題を経験し、ネットワーク介入が必要される場合、ＩＤＣ問題をｅＮＢへレポートするために、専用のＲＲＣシグナリングを介してＩＤＣインジケーションを送り得る。それは、もしもＵＥがＣＯＮＮモードであれば、ｅＮＢが、ＩｎＤｅｖｉｃｅＣｏｅｘＩｎｄｉｃａｔｉｏｎメッセージに基づいて、ＩＤＣ問題が発生したか否かを検出できることを意味する。したがって、ＲＡＮ２は、迅速なＭＤＴの場合を研究する必要はない。なぜなら、ｅＮＢ／ＮＷは、実施によって、特有の（すなわち、ＩＤＣ共存問題を有する）ＵＥから受信したＭＤＴデータをどのようにして処理するのかを決定でき得るからである。
　観察：ＲＡＮ２は、ＩＤＣ干渉を経験した場合、ＩＤＬＥ　ＵＥがどのようにしてＬｏｇｇｅｄ　ＭＤＴを実行するのかに注目するべきである。
　ＷｉＦｉおよびＢｌｕｅｔｏｏｔｈ　Ｔｘが、ＬＴＥラジオのＲｘに対する干渉を引き起こすのであれば、ＩＤＣ干渉によって、測定結果が劣化される。ｅＮＢ／ＮＷは、ログデータが劣化されたか否かを検出できないので、ＵＥは、劣化されていない測定結果のみをログするべきである。したがって、ＵＥは、ＩＤＣ干渉を検出した場合、可能な限り早急にＭＤＴロギングを停止すべきである。ＴＳ　３６．３００のセクション２３．４．２によれば、ＩＤＣ干渉の３つのフェーズが、図１２に図示されている。
　－フェーズ１：ＵＥは、ＩＤＣ干渉の開始を検出するが、ＩＤＣインジケーションのｅＮＢへの送信をまだ開始しない。
　ＩＤＬＥ　ＵＥは、ＩＤＣ干渉状態のフェーズ１をトリガした場合に、ＭＤＴロギングを停止すべきであると提案する。
　提案１：ＩＤＬＥ　ＵＥは、ＩＤＣ干渉のフェーズ１の開始をトリガした場合、ロギングを停止すべきである。
　問題１：ＵＥは「すべてのログデータ」または「劣化されたデータのみ」を廃棄するべきであるか？
　この質問は、ログデータが廃棄されるか否かである。２つの代替案があると考えられる。
　　代替案１：ＵＥは、ＩＤＣ干渉検出に先立って、すべてのログデータを廃棄する。
　　代替案２：ＵＥは、劣化したログデータのみを検出し廃棄する。
　ＵＥが単に「すべてのログデータ」を廃棄するのであれば、それはより簡単であろう。一方、多過ぎるＵＥの複雑さ無しで回避され得るのであれば、良好なログデータを完全に廃棄しないことが常に良い。後者の場合、ＵＥは、ＩＤＣ問題を検出した場合、ロギングを停止するが、劣化していないログデータを維持するべきである。代替案２の場合、劣化したログデータのみを廃棄するための２つのオプションが考慮され得る。
　　オプション１：ＵＥが、フェーズ１の前に、すべてのログデータを維持する。
　　オプション２：ＵＥは、ＷｉＦｉ／Ｂｌｕｅｔｏｏｔｈを使用することを開始した後に収集されたログデータを廃棄する。
　オプション１は、オプション２よりはるかに単純である。しかしながら、ログデータのいくつかが、フェーズ１の前に既に劣化しているという可能性がある。なぜなら、フェーズ１は、ＩＤＣ干渉の検出から開始し、その詳細はＵＥ実施に委ねられるからである。したがって、「ＵＥは、干渉を評価するために、既存のＬＴＥ測定および／またはＵＥ内部調整に依存し、詳細は、ＵＥ実施に委ねられる」。また、ＩＤＣ干渉の検出は、ＵＥ実施に委ねられているので、ＵＥは、ＩＤＣ干渉が非常に小さいのであれば、フェーズ１をトリガしないことがあり得る。言い換えれば、干渉が（少なくともＵＥの観点から）非常に小さく、ＵＥが決してフェーズ１をトリガしないが、実際、ログデータが既に幾分劣化されていることがあり得る。このシナリオでは、ＩＤＣ干渉は公式には検出されていないので、「劣化された」ログデータがレポートされるであろう。したがって、ＵＥがＷｉＦｉ／Ｂｌｕｅｔｏｏｔｈを使用し始めるや否や、測定結果が劣化され得る。ログデータの劣化状態の不確定性によって、オプション１が選択されたのであれば、ＵＥは、フェーズ１が検出されたことを、ログに含める（または、我々がインジケーションを用いるのであれば、ログ可用性インジケーションに含める）べきである。ログの終わりに向かうデータのいくつかを回収または廃棄した場合、ｅＮＢ／ＮＷは、データ全体を廃棄する（または、インジケーションが使用されるのであれば、データを取得するか否かの）オプションを有し得る。別のオプションは、ＵＥが、ＷｉＦｉ／Ｂｌｕｅｔｏｏｔｈの使用を開始／停止した場合、ログにインジケーション（たとえば、タイム・スタンプ）を追加することをＵＥに許可することであろう。そして、ｅＮＢ／ＮＷは、これらのインジケーションに基づいて、レポートされたログから、劣化した測定結果を除去し得る。
　オプション１とは対照的に、オプション２が適用される場合、ＭＤＴログの精度が高められる。しかしながら、ＵＥの複雑さは増加される。なぜなら、ＵＥは、劣化した結果を完全に除去するためにＷｉＦｉ／Ｂｌｕｅｔｏｏｔｈの使用を開始した時にログしなければならないからである。これは、前述したオプションに対する相補的な解決策であり、すなわち、ＵＥは、ＷｉＦｉ／Ｂｌｕｅｔｏｏｔｈの使用を開始／停止した時にタイムスタンプのようなインジケーションを追加し、これら２つのオプションの主な相違は、ｅＮＢ／ＮＷがフィルタリングを実行している（オプション１）か、またはＵＥがフィルタリングを実行している（オプション２）かであることに注目されたい。
　結論として、劣化していないログデータのみを維持することは困難であると考えられる。したがって、ＵＥが、ＩＤＣ干渉のフェーズ１の開始を検出した場合に、常にすべてのログデータを廃棄する代替案１が優先される。
　提案２：ＵＥは、ＩＤＣ干渉のフェーズ１の開始を検出した場合、すべてのログデータを常に廃棄する。
　問題２：どのＵＥがＭＤＴ設定を廃棄、または、ＩＤＣ問題が解決された場合にロギングを再開するために、ＭＤＴ設定を記憶するのであろうか？
　ＵＥの観点から、提案２が合意された場合に、ＵＥがＭＤＴ設定をも廃棄するのであれば、それはより簡単である。しかしながら、３ＧＰＰは、ｅＮＢが、可能な限り多くＩＳＭ帯域へトラフィックをオフロードすることを可能にするメカニズムを研究している。ＵＥが、ＩＤＣ干渉を検出した場合、または、ＷｉＦｉまたはＢｌｕｅｔｏｏｔｈが使用されている場合、ＵＥが、ＭＤＴ設定を廃棄するのであれば、ＮＷがＩＳＭ帯域近くのＬＴＥ帯域でデータを収集する機会は少なくなるであろう。したがって、ＵＥがＭＤＴ設定を維持しているのであれば、ＩＤＣ問題が解決された後に、ロギングを再開することが好適となるであろう。「ＩＤＣ問題が解決される」という定義は、ＴＳ　３６．３００に記載されている「ＵＥがもはやＩＤＣ問題を被っていない場合」と連携されるべきである。
　ロギングが再開される必要があり、（前述した問題１における決定に依存して）既存のログが存在する場合には、ＵＥに関するいかなる問題もあるはずがない。なぜなら、ＵＥは、既にこの状況を、以下のＵＥ振る舞いを可能にする現在の仕様に基づいて良好に取り扱うことができ得るからである。ＵＥが、ＩＤＬＥ＝＞ＣＯＮＮ＝＞ＩＤＬＥへと移行し、ログ結果が、ＣＯＮＮ中に回収されないのであれば、ＵＥは、ログされたＭＤＴを再開し、１つのログ測定結果を生成する。
　提案３：ＩＤＣ問題が解決された後、ＵＥは、ＭＤＴ設定を維持し、ロギングを再開する。
［付記２］
　（１．はじめに）
　ＦｅＭＤＴ研究項目の一部として、重要な目的のうちの１つは、ビデオトラフィックおよびＭＭＴＥＬのＱｏＳをサポートするために必要とされる強化の研究である。以下について合意できた。
　合意：
　１　ＵＬとＤＬとの両方のためのレイテンシメトリックが、ＧＢＲトラフィックのために望ましい。
　ＦＦＳ：要求された／望ましい／許容可能な精度
　上記の合意に従って、ＵＬ遅れ測定を行うこともまた合意可能である。しかしながら、既存の仕様は、ＵＬ遅れ測定のための何れのＬ２測定をも有しておらず、したがって、本付記において、可能な解決策に関する詳細を議論する。
　（２．議論）
　いくつかの解決策が提案された。これらは、以下のように、３つの代替案に分類され得ると考える。
　代替案１．ｅＮＢは、ＵＥから何ら支援なく、ＵＬキュー遅れを推定する。
　代替案２．ＵＥは、各ＰＤＣＰ　ＰＤＵを、システム時間情報を用いてタグ付けし、ｅＮＢは、提供されたシステム時間情報を用いて、ＵＬキュー遅れを決定する。
　代替案３．ＵＥは、ＵＬ遅れを決定する際にｅＮＢを支援するために、ＵＬキュー遅れが、設定されたしきい値を超えたか否かを判定し、データまたは遅れ関連パラメータをレポートする。
　代替案１に関して、ｅＮＢは、周期的な音声パケットを受信する際に（結果としてジッタになる）変化があるか否かを判定するために、周期的な音声パケットを（たとえば、２０ミリ秒毎に）モニタし得る。この代替案は、ＵＬレイテンシが、ＵＥ側への追加の複雑さ無しで測定され得るという利点を有する。さらに、ＱｏＳ関連情報が、ｅＮＢにおいて測定される。これは、Ｌ２測定のための既存のポリシと連携されている。さらに、代替案１は、ｅＮＢ実施に基づいて達成され得る。これは、標準化された作業が必要とされないことを意味する。しかしながら、ｅＮＢは、トラフィックがＵＥのＰＤＣＰバッファ内にいつ到着するのかを知らないので、高い測定精度が期待されることはできない。
　代替案２に関し、ＵＥは、ＰＤＣＰパケットへタイムスタンプを追加し、ｅＮＢは、受信したＰＤＣＰパケットを正しく復号した時間に関連して提供されたタイムスタンプを用いてレイテンシを計算する。代替案１とは対照的に、この代替案は、ｅＮＢが、正確なＵＬレイテンシ測定結果を計算することを可能にする。なぜなら、ｅＮＢは、ＵＥによって追加されたタイムスタンプを使用でき得るからである。しかしながら、この代替案は、多くのロギングを必要とするであろうから、ＵＥとｅＮＢとの両方のための過度の負荷を結果的にもたらすであろう。したがって、これらの複雑さをどのようにして緩和するのかを考慮するべきである。実施ベースのプロシージャの一例は、代替案１と代替案２との組合せであり、ｅＮＢは、代替案１を用いてレイテンシを粗く推定し、ＵＥに対して、たとえば、推定されたレイテンシ、または、レイテンシの分散（すなわち、ジッタ）がしきい値を超えた場合、特定のＵＥのためのＰＤＣＰパケットへタイムスタンプを追加することを要求する。別の可能性は、ｅＮＢが、ＰＤＣＰパケットが、タイムスタンプされ、ＭＤＴ設定の一部としてレポートされる必要のある短い測定持続時間（たとえば、５秒）を設定することである。これは、ＵＥが、ＭＤＴの持続時間中に測定およびログする必要のあるＰＤＣＰパケットの数を低減するであろう。この短い測定持続時間の開始時間は、ｅＮＢによって制御されるべきである。
　代替案３に関し、ＵＬレイテンシを決定するためにすべての複雑さは、ＵＥに存在する。これは、ＵＥに対する著しい負荷をもたらすので、代替案３が選択されるのであれば、このような複雑さを最小化するための方法を考慮することが不可欠である。代替案３は、ｅＮＢが、代替案１を用いてレイテンシを推定し、たとえば、推定されたレイテンシ、または、レイテンシの分散が、しきい値を超える場合、特定のＵＥに対して、ＵＬレイテンシを測定することを要求するという点において代替案２に類似している。さらに、代替案３では、ＵＥは、ある遅れしきい値を超えるデータのみをログしレポートできるように、いくつかのフィルタリングを実行し得ることがさらに仮定される。あるいは、ｅＮＢがレイテンシの分散を計算できるように、ＵＥが、いくつかの遅れ関連パラメータをｅＮＢへレポートすることも可能である。レポートされるべき可能な遅れ関連パラメータは、たとえば、「測定されたＰＤＣＰ　ＳＤＵの数」を、平均、ｘ％、ｙ％最悪／最良レイテンシ測定結果とともに含む。
　提案１：ＲＡＮ２は、上記３つの代替案を、候補解決策として、ＴＲにおける可能な強化とともに取り込むべきである。
　提案２：ＲＡＮ２は、ＵＥベースの解決策が導入された場合のために、ＵＥとｅＮＢ／ＮＷとの両方の複雑さを最小化し、それらをＴＲの中に取り込むための方法を研究すべきである。
［付記３］
　（導入）
　新しいＷＩ「Ｆｕｒｔｈｅｒ　Ｅｎｈａｎｃｅｍｅｎｔｓ　ｏｆ　Ｍｉｎｉｍｉｚａｔｉｏｎ　ｏｆ　Ｄｒｉｖｅ　Ｔｅｓｔｓ　ｆｏｒ　Ｅ－ＵＴＲＡＮ」が承認された。作業項目は以下の目的を含む。
　　ＱｏＳ検証使用事例の拡張：
　　ＭＭＴＥＬ音声およびビデオトラフィックのためのＱｏＳおよびそれの制限ファクタのより良い理解をサポートするために、ＭＤＴ測定および手順を以下のように指定する：
　１．ＵＬ　ＰＤＣＰキューイング遅延測定
　２．（ＰＤＣＰ　ＳＤＵのＵＬドロッピングを除く）ＵＬおよびＤＬについてのデータ損失測定
　３．トラフィックドロップメトリック収集
　以下の合意が達成された。
　ＵＬ　ＰＤＣＰキューイング遅延測定は、ＵＥごとにＱＣＩごとに実施されるべきであり、（ＰＤＣＴアッパーＳＡＰにおけるパケット到着から、パケットがＲＬＣに配信され始めるまで）ＵＥのＰＤＣＰレイヤのみにおいて観測されるパケット遅延を反映すべきである。
　（議論）
　（ロケーション情報の必要性）
　他の文献によれば、ＵＬキューイング遅延の根本原因はスケジューリングである。報告されたＵＬキューイング測定が許容できない場合、ＮＷは、遅延を低減するようにスケジューリングアルゴリズムを修正するであろうと仮定するのが簡単である。さもなければ、キューイング遅延は残存するであろう。キューイング遅延測定の結果がｅＮＢのみに使用される場合、ロケーション情報とともにキューイング遅延測定を報告することは不要であり得ると理解される。一方、ロケーション情報は、ＴＣＥがキューイング遅延の根本原因を検出するために有用である。例えば、良好なＤＬおよびＵＬカバレージの下で過大なキューイング遅延が生じた場合、ＴＣＥは、問題の根本原因がスケジューリングであると判断することができる。ＴＣＥは、既存のＭＤＴ測定結果からＤＬカバレージ情報とＵＬカバレージ情報の両方を収集し得ることに留意されたい。したがって、キューイング遅延測定のためでさえロケーション情報が報告されるべきであることを選好する。
　提案１：ＵＬ　ＰＤＣＰキューイング遅延測定結果とともにロケーション情報が報告されるべきである。
　（Ｉｍｍｅｄｉａｔｅ　ＭＤＴまたはＬｏｇｇｅｄ　ＭＤＴ　ｉｎ　Ｃｏｎｎｅｃｔｅｄ）
　考慮すべき別のポイントは、どのタイプの処理、Ｉｍｍｅｄｉａｔｅ　ＭＤＴまたはＬｏｇｇｅｄ　ＭＤＴ　ｉｎ　Ｃｏｎｎｅｃｔｅｄが、ＵＬ　ＰＤＣＰキューイング遅延測定に適用可能であるべきかである。ＵＬ　ＰＤＣＰキューイング遅延測定のみで十分であるとＲＡＮ２が判断した場合、問題の根本原因はスケジューリングに起因し得るので、Ｉｍｍｅｄｉａｔｅ　ＭＤＴは不要である。これは、スケジューリングアルゴリズムが修正されるまでキューイング遅延は改善され得ないことを意味する。ＮＷがスケジューリングアルゴリズムを頻繁に更新しないと仮定すると、ＮＷがキューイング遅延測定をリアルタイムで取得する利益はないと考える。そうである場合、Ｒｅｌ－１２においてすでに規格化されている、Ｌｏｇｇｅｄ　ＭＤＴ　ｉｎ　Ｃｏｎｎｅｃｔｅｄは、シグナリングオーバーヘッドがより少なく、ＵＥとＮＷの両方の複雑さが低減され得るので、好ましい。Ｉｍｍｅｄｉａｔｅ　ＭＤＴでは、ＮＷは、問題の程度を評価するために、報告された測定の多くの断片をつなぎ合わせる必要があり得る。
　しかしながら、既存のＩｍｍｅｄｉａｔｅ　ＭＤＴは、ｅＮＢが、報告された測定を直接使用することを可能にするように設計されている。例えば、ｅＮＢは、ＵＥの変化する状態に調整するために無線パラメータを更新することがある。前のセクションで述べたように、ｅＮＢ／ＮＷは、ＵＬ　ＰＤＣＰキューイング遅延測定に基づいて総ＵＬ遅延を推定し得る可能性がある。特定のサービスの総ＵＬレイテンシが予想閾値を超える場合、ｅＮＢ／ＮＷは、意図されたサービスのためのＱｏＳを実現するために、例えば、できるだけ早く無線パラメータを更新するオプションを有するべきである。この観点から、ＰＤＣＰキューイング遅延測定報告にＩｍｍｅｄｉａｔｅ　ＭＤＴが適用されることを選好する。
　提案２：ＰＤＣＰキューイング遅延測定報告にＩｍｍｅｄｉａｔｅ　ＭＤＴが適用される。
　（測定構成および報告メカニズム）
　提案２が合意された場合、ＵＥがすべての測定結果を報告すべきか、または特定の測定結果、例えば、遅延閾値を超えることを報告すべきか、をも考慮すべきである。ＵＬ遅延測定の研究の結果によれば、遅延スパイクがＵＥベンダーとｅＮＢベンダーの両方にとって問題の主因であるので、後者を選好する。したがって、ＵＥは、構成された遅延閾値を超えるＵＬ　ＰＤＣＰキューイング遅延測定結果を報告し始め、構成された遅延閾値を測定値が下回った後に報告するのを止めるべきである。進入条件と離脱条件とのためにヒステリシスが適用される必要がある場合、それは今後の検討課題である。遅延閾値に関して、我々は、それが、例えば、ＵＬ　ＰＤＣＰキューイング遅延測定構成を使用してｅＮＢ／ＮＷによって構成可能であるべきと考える。
　提案３：ＵＥは、構成された遅延閾値を超えるＵＬ　ＰＤＣＰキューイング遅延測定結果を報告し始め、構成された遅延閾値をＵＬ　ＰＤＣＰキューイング遅延測定値が下回った後に報告するのを止めるべきである。
　（ＵＬ　ＰＤＣＰ遅延特性を収集する必要性）
　提案３が合意された場合、ＮＷは、構成された閾値を超えるＵＬ　ＰＤＣＰキューイング遅延測定結果のみを収集することができる。したがって、ＵＬ　ＰＤＣＰ遅延特性がＮＷによって補正される必要がある場合、追加の支援情報がＵＥによって提供されるべきである。ネットワーク最適化のための主要な目的のうちの１つは、適用例に、特にＧＢＲタイプトラフィックに適した制限内にジッタおよび平均レイテンシを保つことであると理解されている。
　ＮＷがＵＬ　ＰＤＣＰ遅延特性を推定するためには、少なくとも測定されたＵＬ　ＰＤＣＰ　ＳＤＵの数と平均ＵＬ　ＰＤＣＰキューイング遅延とが必要であると考える。そうである場合、ＵＥは、平均ＵＬ　ＰＤＣＰキューイング遅延を計算し、測定されたＵＬ　ＰＤＣＰ　ＳＤＵの数とともにそれを後で報告すべきである。したがって、ｅＮＢは、ＵＬ　ＰＤＣＰキューイング遅延測定構成を使用して平均ＵＬ　ＰＤＣＰキューイング遅延を計算することをＵＥに要求するオプションを有するべきである。情報はすでに統計的であるので、ＵＥが測定サンプルのロケーション情報を報告することは不要である。
　提案４：ｅＮＢは、ＵＬ　ＰＤＣＰキューイング遅延測定構成を使用して平均ＵＬ　ＰＤＣＰキューイング遅延を計算することをＵＥに要求するオプションを有するべきである。
　提案５：要求された場合、ＵＥは、平均ＵＬ　ＰＤＣＰキューイング遅延を計算し、測定されたＵＬ　ＰＤＣＰ　ＳＤＵの数とともにそれを後で報告すべきである。
　ユーザ装置（ＵＥ）は、ＵＥにおいて測定された上りリンクＰＤＣＰキューイング遅延測定結果と共に位置情報を基地局（ｅＮＢ）又はネットワークへ報告する。
　ユーザ装置（ＵＥ）は、ＩｍｍｅｄｉａｔｅＭＤＴによって、ＵＥにおいて測定された上りリンクＰＤＣＰキューイング遅延測定結果を基地局（ｅＮＢ）又はネットワークへ報告する。
　ユーザ装置（ＵＥ）は、遅延閾値を超える上りリンクＰＤＣＰキューイング遅延測定結果を報告し、測定結果が閾値の範囲に入った後に、上りリンクＰＤＣＰキューイング遅延測定結果の報告を停止する。
　その場合において、遅延閾値は、ｅＮＢ又はネットワークからＵＥに退位して設定される。
　ユーザ装置（ＵＥ）は、平均上りリンクＰＤＣＰキューイング遅延測定結果を計算し、平均上りリンクＰＤＣＰキューイング遅延の計算はｅＮＢ又はネットワークからＵＥへ上りリンクＰＤＣＰキューイング遅延測定設定で要求される。
　ユーザ装置（ＵＥ）は、その後、測定した上りリンクＰＤＣＰ　ＳＤＵの数と共に平均上りリンクＰＤＣＰキューイング遅延測定結果を報告する。
　その場合において、ＵＥは、ｅＮＢ又はネットワークからの要求によって測定結果を報告する。
［付記４］
　（１．導入）
　ＦｅＭＤＴ作業項目の下で、ＵＬ　ＰＤＣＰキューイング遅延のための測定構成および報告メカニズムが議論された。スパイクが検出されないときのＵＥ挙動が依然として今後の検討課題であると考える。この付記では、この問題と、仕様をどのように修正すべきかの候補とを議論する。
　（２．議論）
　（２．１．過剰遅延比の測定報告マッピング）
　ＵＥが、構成された遅延閾値を超えるＳＤＵと、測定値期間中にＵＥによって受信されたＳＤＵの総数との比として、ＵＬ　ＰＤＣＰ　ＳＤＵキューイング遅延を報告することが合意された。測定された量のマッピングは、以下のようにＴＳ　３６．３１４の表４．２．１．１．１－１に定義されている。
Figure JPOXMLDOC01-appb-T000003
　測定された量の値がちょうどボーダー（例えば、０．０７９）上にある場合、ＵＥは報告される値を検出し得ないので、この表が更新されるべきであると考える。すべてのパケットのレイテンシが構成された閾値を超える事例を考慮に入れるために、右側の「＜記号」は「≦記号」に変更されるべきである。したがって、次のように表を更新することを提案する。
Figure JPOXMLDOC01-appb-T000004
　提案１：ＴＳ　３６．３１４中の表４．２．１．１．１－１の右側の「＜記号」は「≦記号」に置き換えられるべきである。
　（２．２．スパイクが検出されないときのＵＬ　ＰＤＣＰ遅延測定報告）
　測定結果は、構成された閾値を超えるパケット遅延と、測定／報告期間中のパケットの総数との比に変換されることが合意された。
　合意
　　ＰＤＣＰ　ＳＤＵの数および／または検出されたイベントが報告されることになる場合、数または比のコーディングは、ＭＢＳＦＮ　ＢＬＥＲ報告のために定義されたもののコーディング原理を再利用する。
　この合意について、ＵＥは、イベントが検出された（すなわち、ＵＥによってスパイクが検出された）ときのみＵＬ　ＰＤＣＰキューイング遅延測定結果を報告することができると理解される。ＵＬ遅延測定の研究の結果によれば、遅延スパイクは、ＵＥとｅＮＢの両方にとって問題の主因である。したがって、測定／報告期間内にＵＥによってスパイクが検出されない場合、ＰＤＣＰキューイング遅延測定結果の報告にあまり要点はない。ＵＬ　ＰＤＣＰキューイング遅延測定報告は周期的であるので、ＮＷが測定結果を受信しない場合、ＮＷは、測定／報告期間中にスパイクがないことを理解することができる。さらに、ＵＥが、遅延スパイクの検出にかかわらずすべての測定を報告することを要求される場合、スパイクが予想されない場合、過大な量のスパイクなしの報告があり得る。
　ＵＥは、スパイクが検出されないときにＵＬ　ＰＤＣＰキューイング遅延測定結果を報告しない場合、ＲＡＮ２は、どのようにこの合意が仕様に取り込まれるかを議論すべきである。ＴＳ　３６．３３１によれば、ＵＬ　ＰＤＣＰキューイング遅延測定報告のトリガは以下の通りである。
　１＞ｕｌ－ＰＤＣＰ－ＤｅｌａｙＲｅｓｕｌｔが利用可能である場合、
　　２＞ｕｌ－ＰＤＣＰ－ＤｅｌａｙＲｅｓｕｌｔを受信値に設定する。
ｕｌ－ＰＤＣＰ－ＤｅｌａｙＲｅｓｕｌｔは、ｅｘｃｅｓｓＤｅｌａｙおよびｑｃｉ－Ｉｄから構成される。ｅｘｃｅｓｓＤｅｌａｙは、ＴＳ　３６．３１４における上述の表を基準とする。
　過大な遅延が検出ないときにＵＬ　ＰＤＣＰ遅延測定の報告を防ぐための１つの可能性は、以下のように過剰遅延比のマッピングを修正することであると考える。
Figure JPOXMLDOC01-appb-T000005
 は、
Figure JPOXMLDOC01-appb-T000006
のように変更される。
　これは、ＵＥが遅延閾値に基づいてＵＬ　ＰＤＣＰ遅延を検出しない場合、ｕｌ－ＰＤＣＰ－ＤｅｌａｙＲｅｓｕｌｔが作成されないことを意味する。さらに、遅延スパイクが検出されないときにＵＥがＵＬ遅延を報告しないことをステージ２に取り込むのが良いだろうと考える。場合によっては、ＴＳ　３７．３２０のセクション５．２．１．１において測定－－Ｍ６の下に、「ＮＯＴＥ」が以下のように追加され得るだろう。
　ＮＯＴＥ：ＵＥが、ネットワークによって構成された遅延閾値および遅延報告間隔に基づいてＵＬ　ＰＤＣＰ遅延を検出しない場合、ＵＥは、その期間内にＵＬ　ＰＤＣＰ遅延測定を報告しない。
　［付記５］
　（ＵＥベースのＱｏＳ測定）
　－基本的仮定
　　　ＡＣＫ／ＮＡＣＫを用いた１対１のＤ２Ｄ通信が導入される。
　　　サイドリンクＱｏＳ測定にはモード１通信のみが仮定される
　－測定識別情報
　　　サイドリンクデータ損失
　　　サイドリンクスケジュールされたＩＰスループット
　　　サイドリンクデータボリューム
　　　サイドリンクパケット遅延／アップリンクパケット遅延
　　　ダウンリンクＳＩＮＲ／（今後の検討課題）サイドリンクＳＩＮＲ／ＷＬＡＮダウンリンクＳＩＮＲ
　　　ダウンリンクＢＬＥＲ／（今後の検討課題）サイドリンクＢＬＥＲ／ＷＬＡＮダウンリンクＢＬＥＲ
　－可能な報告トリガ
　　　周期的
　　　イベント
　　　　ＰＤＣＰ　ＳＤＵごとに
　　　　ＱｏＳ測定結果が閾値よりも悪い
　－測定構成の可能なＩＥ
　　　測定ターゲット（任意）
　　　　データ損失、スケジュールされたＩＰスループット、データボリューム、パケット遅延など
　　　報告／ロギングトリガ
　　　　周期的、ＰＤＣＰ　ＳＤＵごとに、結果が閾値よりも小さいなど
　（ＵＥベースのＱｏＳ測定のためのＭＤＴ）
　－Ｉｍｍｅｄｉａｔｅ　ＭＤＴ
　　　構成
　　　　ＵＥベースのＱｏＳ測定のための新しいＩＥを導入するとともに既存のＲＲＭ測定構成を再利用する。これは、既存のＲＲＭ測定構成への「アドオン」によって達成され得る。
　　　報告方法およびログ利用可能な指示
　　　　利用可能な指示なしに報告トリガごとに
　－Ｌｏｇｇｅｄ　ＭＤＴ　ｉｎ　Ｃｏｎｎｅｃｔｅｄ
　　　構成
　　　　ＵＥベースのＱｏＳ測定のための新しいＩＥを導入するとともに既存のロギングされた測定構成を再利用する。これは、既存のロギングされた測定構成への「アドオン」によって達成され得る。
　　　報告方法およびログ利用可能な指示
　　　　選択肢１：ＩＤＬＥからＣＯＮＮへ（および随意としてＨＯごとに）
　　　　選択肢２：利用可能な指示なし（ｅＮＢ実装形態まで）
注：この場合、ロギングされたＭＤＴ、ＰＤＣＰ　ＳＤＵの数、平均ＱｏＳ測定結果、ならびに（随意の）９５％ワーストＱｏＳ測定結果および（随意の）５％ワーストＱｏＳ測定結果のようないくつかの他の結果。
　［測定識別情報］
　（サイドリンクデータ損失）
　ＱＣＩごとのサイドリンクにおけるパケット損失レート。この測定値はＤＲＢについてのパケット損失を指す。１つのパケットは１つのＰＤＣＰ　ＳＤＵに対応する。基準点はＰＤＣＰアッパーＳＡＰである。測定はＱＣＩごとに別々に行われる。
詳細な定義：
Figure JPOXMLDOC01-appb-M000007
  
Figure JPOXMLDOC01-appb-T000008
  
　（サイドリンクＩＰスループット）
　サイドリンクにおけるＭＤＴについてのスケジュールされたＩＰスループット。データバーストの最後のＴＴＩ中で送信されるデータを除外することによる、送信がいくつかのＴＴＩにわたって分割されることを要求するのに十分大きいデータバーストについてのサイドリンクにおけるＰＤＣＰ　ＳＤＵビットのスループットのｅＮＢ推定値。データ送信時間のみ、すなわち、サイドリンクを介したデータ送信が開始したがまだ終了していないときのみが考慮される。測定はＤ２Ｄ　ＵＥごとに実施される。成功した受信について、基準点はＭＡＣアッパーＳＡＰである。
　この測定値は、測定期間のための以下の式によって取得される。
Figure JPOXMLDOC01-appb-M000009
  
Figure JPOXMLDOC01-appb-T000010
  
　（サイドリンクデータボリューム）
　サイドリンクにおけるＭＤＴについてのデータボリューム。測定期間中にサイドリンクにおいて１つのＤ２Ｄ　ＵＥによって正常に受信されるＰＤＣＰ　ＳＤＵビットの量。測定は、Ｄ２Ｄ　ＵＥごとにＱＣＩごとに実施される。単位はキロビットである。
　（サイドリンクパケット遅延／アップリンクパケット遅延）
　ＱＣＩごとのサイドリンク／アップリンクにおけるパケット遅延。この測定値はＤＲＢについてのパケット遅延を指す。パケットの到着について、基準点はＰＤＣＰアッパーＳＡＰである。成功した受信について、基準点はＭＡＣロウアーＳＡＰである。測定はＱＣＩごとに別々に行われる。
　詳細な定義：
Figure JPOXMLDOC01-appb-M000011
  
Figure JPOXMLDOC01-appb-T000012
　（ＵＥベースのＱｏＳ測定のためのＭＤＴ）
　［フローチャート］
　－Ｉｍｍｅｄｉａｔｅ　ＭＤＴ
　図１３は、この場合のフローチャートを示す。
　注：ｅＮＢは、ＵＥのＢＳＲに基づいてＤ２Ｄ終了に気づき得る。
　－Ｌｏｇｇｅｄ　ＭＤＴ　ｉｎ　Ｃｏｎｎｅｃｔｅｄ
　　　選択肢１：ＩＤＬＥからＣＯＮＮへ（およびオプションとしてＨＯごとに）
　既存のＬｏｇｇｅｄ　ＭＤＴ　ｉｎ　Ｃｏｎｎｅｃｔｅｄの手順を再利用することができる。
　図１４は、この場合のフローチャートを示す。
　　　選択肢２：利用可能な指示なし（ｅＮＢ実装形態まで）
　ｅＮＢはＵＥのＢＳＲに基づいてＤ２Ｄ終了に気づき得るので、ｅＮＢは、Ｄ２Ｄ通信が完了した後にＱｏＳ測定ログを取り出すことができる。
　［相互参照］
　米国仮出願第６２／１６２１６７号（２０１５年５月１５日出願）、米国仮出願第６２／２３２９３４号（２０１５年９月２５日出願）、及び米国仮出願第６２／２７５０４７号（２０１６年１月５日出願）の全内容が参照により本願明細書に組み込まれている。
　本発明は、通信分野において有用である。

Claims (10)

  1. 　上りリンクにおけるデータの遅延に関する測定を行う制御部と、
    　前記測定の結果を示す情報を無線基地局に報告する送信部とを備えることを特徴とするユーザ端末。
  2. 　前記送信部は、前記測定の結果が生成されたタイミングで、前記測定の結果を前記無線基地局に報告することを特徴とする請求項１に記載のユーザ端末。
  3. 　前記送信部は、所定の閾値を上回った前記測定の結果が生成されたタイミングで、前記測定の結果を前記無線基地局に報告することを特徴とする請求項２に記載のユーザ端末。
  4. 　前記所定の閾値は、前記無線基地局から個別に受信した前記測定を設定するための情報に含まれることを特徴とする請求項３に記載のユーザ端末。
  5. 　前記送信部は、所定のタイミングで、前記測定の結果を生成すると共に前記測定の結果を前記無線基地局に報告し、
    　前記所定のタイミングを示す情報は、前記無線基地局から個別に受信した測定を設定するための情報に含まれることを特徴とする請求項１に記載のユーザ端末。
  6. 　前記遅延は、キューイング遅延であることを特徴とする請求項１から５のいずれか一項に記載のユーザ端末。
  7. 　記憶部と、
    　少なくとも位置情報を含むＭＤＴ測定の結果を生成するとともに、前記ＭＤＴ測定の結果を前記記憶部に格納する制御部と、
    　前記記憶部に格納された前記ＭＤＴ測定の結果を無線基地局に報告する送信部とを備え、
    　前記制御部は、セルラ通信以外の通信によって生じる装置内干渉が検出される前に、前記ＭＤＴ測定の結果を前記記憶部に格納することを特徴とするユーザ端末。
  8. 　前記制御部は、
    　　前記装置内干渉が検出された場合であっても、前記ＭＤＴ測定の結果を格納するための設定情報を維持するとともに、
    　　前記装置内干渉が解消した場合に、前記設定情報に従って前記ＭＤＴ測定の結果の前記記憶部への格納を再開することを特徴とする請求項７に記載のユーザ端末。
  9. 　前記制御部は、
    　　前記装置内干渉を検出すると、前記ＭＤＴ測定結果の前記記憶部への格納を停止することを特徴とする請求項７又は８に記載のユーザ端末。
  10. 　前記制御部は、
    　　前記装置内干渉を検出すると、前記装置内干渉が生じていることを示すインディケーションを前記無線基地局に報告することを特徴とする請求項７から９のいずれか一項に記載のユーザ端末。
PCT/JP2016/064073 2015-05-15 2016-05-12 ユーザ端末 WO2016185986A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP16796379.2A EP3297318A4 (en) 2015-05-15 2016-05-12 User terminal
JP2017519156A JPWO2016185986A1 (ja) 2015-05-15 2016-05-12 ユーザ端末、通信方法、及びプロセッサ
US15/811,924 US10390252B2 (en) 2015-05-15 2017-11-14 User terminal, communication method and apparatus

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201562162167P 2015-05-15 2015-05-15
US62/162,167 2015-05-15
US201562232934P 2015-09-25 2015-09-25
US62/232,934 2015-09-25
US201662275047P 2016-01-05 2016-01-05
US62/275,047 2016-01-05

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/811,924 Continuation US10390252B2 (en) 2015-05-15 2017-11-14 User terminal, communication method and apparatus

Publications (1)

Publication Number Publication Date
WO2016185986A1 true WO2016185986A1 (ja) 2016-11-24

Family

ID=57319948

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/064073 WO2016185986A1 (ja) 2015-05-15 2016-05-12 ユーザ端末

Country Status (4)

Country Link
US (1) US10390252B2 (ja)
EP (1) EP3297318A4 (ja)
JP (1) JPWO2016185986A1 (ja)
WO (1) WO2016185986A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019124067A1 (ja) * 2017-12-19 2019-06-27 ソニー株式会社 通信装置、通信方法、及び通信システム
WO2020194639A1 (ja) * 2019-03-27 2020-10-01 株式会社Ｎｔｔドコモ 端末
EP3742671A4 (en) * 2018-02-05 2021-03-10 Huawei Technologies Co., Ltd. METHOD AND DEVICE FOR DETERMINING CONNECTION QUALITY
JP2021517421A (ja) * 2018-03-29 2021-07-15 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． サービスのサービス品質を検出するための方法およびシステム、ならびにデバイス
WO2023162214A1 (ja) * 2022-02-28 2023-08-31 日本電信電話株式会社 基地局及び無線端末装置

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107925592B (zh) * 2015-08-11 2021-02-19 Lg 电子株式会社 在无线通信系统中执行上行链路分组延迟测量的方法及其设备
WO2017034274A1 (en) 2015-08-21 2017-03-02 Samsung Electronics Co., Ltd. Method for reporting latency of packet transmission in communication network
EP3360366B1 (en) * 2015-10-05 2020-06-17 LG Electronics Inc. Method for transmitting a queuing delay measurement report in a wireless communication system and a device therefor
WO2017073900A1 (en) * 2015-11-01 2017-05-04 Lg Electronics Inc. Method for transmitting an uplink packet delay measurement report in a wireless communication system and a device therefor
CN109247064B (zh) 2016-06-08 2022-08-05 瑞典爱立信有限公司 无线通信网络中的语音或多媒体会话分析
US10856163B2 (en) * 2017-07-07 2020-12-01 Lg Electronics Inc. Method for performing measurement and device supporting the same
JP7058716B2 (ja) * 2018-02-15 2022-04-22 京セラ株式会社 ユーザ装置
WO2019213924A1 (zh) * 2018-05-10 2019-11-14 华为技术有限公司 通信方法、通信装置和系统
CN110769439B (zh) * 2018-07-27 2022-02-25 维沃移动通信有限公司 测量方法、终端和网络侧设备
CN111565411B (zh) * 2019-02-14 2022-08-09 华为技术有限公司 时延测量方法、网络设备和终端设备
CN111294144B (zh) * 2019-03-28 2021-11-26 北京紫光展锐通信技术有限公司 直接链路的信道质量上报方法及装置、存储介质、用户设备
US11159967B2 (en) * 2019-06-24 2021-10-26 Samsung Electronics Co., Ltd. Apparatus and method for measurement in wireless communication system
US11937114B2 (en) * 2020-08-05 2024-03-19 Qualcomm Incorporated Selective measurement reporting for a user equipment

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014188928A1 (ja) * 2013-05-20 2014-11-27 京セラ株式会社 通信制御方法及びユーザ端末

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7706403B2 (en) * 2003-11-25 2010-04-27 Telefonaktiebolaget Lm Ericsson (Publ) Queuing delay based rate control
ATE549879T1 (de) * 2005-05-02 2012-03-15 Mitsubishi Electric Corp Verfahren und vorrichtung für das handhaben von signalmessungen in einem drahtlosen netz
BRPI0821541A2 (pt) 2007-12-20 2015-06-16 Ntt Docomo Inc Estação móvel, estação base de rádio, método de controle de comunicação, e sistema de comunicação móvel
WO2014084499A1 (en) * 2012-11-29 2014-06-05 Lg Electronics Inc. Method for latency measurement and apparatus therefor
US20140254398A1 (en) * 2013-03-05 2014-09-11 Nokia Corporation Methods And Apparatus for Internetworking
KR102071518B1 (ko) * 2015-09-24 2020-03-02 노키아 솔루션스 앤드 네트웍스 오와이 업링크(UL) 서비스 품질(QoS) 메트릭의 보고
WO2017073900A1 (en) * 2015-11-01 2017-05-04 Lg Electronics Inc. Method for transmitting an uplink packet delay measurement report in a wireless communication system and a device therefor

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014188928A1 (ja) * 2013-05-20 2014-11-27 京セラ株式会社 通信制御方法及びユーザ端末

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
ERICSSON ET AL.: "Definition of delay sensitive QoS experience measurement", 3GPP TSG-RAN WG2#77BIS R2-121601, 20 March 2012 (2012-03-20), XP050606368, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_77bis/Docs/R2-121601.zip> *
INTERDIGITAL COMMUNICATIONS: "On Congestion Detection", 3GPP TSG-SA WG2#95 S 2-130389, 22 January 2013 (2013-01-22), XP050667931, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_95_Prague/Docs/S2-130389.zip> *
NOKIA SIEMENS NETWORKS ET AL.: "IDC Considerations for MDT", 3GPP TSG-RAN WG2#79BIS R2-124423, 12 October 2012 (2012-10-12), XP050666312, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_79bis/Docs/R2-124423.zip> *
See also references of EP3297318A4 *

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019124067A1 (ja) * 2017-12-19 2019-06-27 ソニー株式会社 通信装置、通信方法、及び通信システム
US11576059B2 (en) 2017-12-19 2023-02-07 Sony Corporation Communication device, communication method, and communication system
EP3742671A4 (en) * 2018-02-05 2021-03-10 Huawei Technologies Co., Ltd. METHOD AND DEVICE FOR DETERMINING CONNECTION QUALITY
EP4191962A1 (en) * 2018-02-05 2023-06-07 Huawei Technologies Co., Ltd. Link quality obtaining method and apparatus
US11943662B2 (en) 2018-02-05 2024-03-26 Huawei Technologies Co., Ltd. Link quality obtaining method and apparatus
JP2021517421A (ja) * 2018-03-29 2021-07-15 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． サービスのサービス品質を検出するための方法およびシステム、ならびにデバイス
JP7162678B2 (ja) 2018-03-29 2022-10-28 華為技術有限公司 サービスのサービス品質を検出するための方法およびシステム、ならびにデバイス
WO2020194639A1 (ja) * 2019-03-27 2020-10-01 株式会社Ｎｔｔドコモ 端末
WO2023162214A1 (ja) * 2022-02-28 2023-08-31 日本電信電話株式会社 基地局及び無線端末装置

Also Published As

Publication number Publication date
US20180084451A1 (en) 2018-03-22
JPWO2016185986A1 (ja) 2018-03-15
EP3297318A4 (en) 2018-10-24
EP3297318A1 (en) 2018-03-21
US10390252B2 (en) 2019-08-20

Similar Documents

Publication Publication Date Title
WO2016185986A1 (ja) ユーザ端末
US20220191962A1 (en) Rlm and rlf procedures for nr v2x
US20210297889A1 (en) Method, System and Device for Providing Flow Control in a Split Bearer Environment
US9264928B2 (en) Methods, apparatus and systems for minimization of drive tests (MDT) based on QoS verifications
EP3140958B1 (en) Communication system
JP5670518B2 (ja) 無線通信システムにおけるパケット性能を測定する方法及び装置
US20170149514A1 (en) WTRU Measurements Handling to Mitigate In-Device Interference
US11159974B2 (en) Base station and user terminal for performing measurement and communication in unlicensed frequency bands
US20180351665A1 (en) Radio terminal and processor
JP6741966B2 (ja) 通信装置
US20160323762A1 (en) Measurement control method
WO2016207688A1 (en) Method and system for improving video quality during call handover
WO2014135748A1 (en) Methods and apparatus for internetworking
US20190268814A1 (en) Network Node and Methods Therein for User Plane Switching
US10326569B2 (en) Inter-site carrier aggregation with physical uplink control channel monitoring
US11943799B2 (en) Evaluation of DL IP scheduled throughput for inter eNB carrier aggregation
JP2019062542A (ja) ユーザ端末、通信方法及び通信システム
US20160157079A1 (en) User terminal, network apparatus, and processor
JP6804452B2 (ja) 基地局及び無線端末
WO2016163475A1 (ja) ユーザ端末及び基地局

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16796379

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017519156

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE