Communication control method, network device, user device, chipset, communication system, and program

Abstract

To provide a network device and a communication control method for applying a minimization of drive tests (MDT) function to a user device to which a coverage extension function is applied.SOLUTION: A communication control method includes a user device transmitting, to a network, a success information stored when the user device succeeds in receiving a predetermined service from a predetermined cell. The success information includes an identifier of the predetermined cell, an identifier of the user device provided from the predetermined cell, and information indicating the number of times of trials for receiving the predetermined service.SELECTED DRAWING: Figure 12

Description

Technical Field

[0001] The present disclosure relates to a communication control method, a network device, a user device, a chipset, a communication system, and a program used in a mobile communication system.

Background Art

[0002] In 3GPP (Third Generation Partnership Project) (registered trademark; the same applies hereinafter), which is a standardization project for cellular communication systems, the function of MDT (Minimization of Drive Tests) has been specified. The MDT function enables a user device to measure the radio environment and report measurement information of the radio environment together with the location information of the user device to the network, so that, for example, coverage holes and the like can be detected, and the optimization of the network can be achieved.

[0003] On the other hand, user devices for MTC (Machine Type Communication) and IoT (Internet of Things) services are known. The transmission and reception bandwidth of such user devices is limited in order to achieve cost reduction, coverage expansion, and low power consumption. In addition, a coverage expansion function including repetition and the like is applied to such user devices so that they can be used even in a poor radio environment.

[0004] When applying the MDT function to a user device to which a coverage expansion function is applied, a new mechanism that is not present in the conventional MDT function is considered necessary.

Summary of the Invention

[0005] A communication control method according to one embodiment is a method performed by a user device. The communication control method includes transmitting a failure report to the network regarding a failure of a procedure related to an RRC connection performed by the user device while in extended coverage of a serving cell. The failure report includes extended status information indicating the coverage extended state of the user device in the extended coverage, and failure count information associated with the extended status information. The failure count information indicates the number of times the user device failed to perform the procedure in the coverage extended state.

[0006] A communication control method according to one embodiment is a method performed by a user device. The communication control method includes saving measured values ​​of the wireless environment of the user device when a procedure related to RRC connection performed by the user device while in a serving cell fails, calculating a single statistical value from the multiple measured values ​​saved in the saving step if the procedure fails multiple times, and transmitting a failure report including the calculated statistical value to the network.

[0007] A communication control method according to one embodiment is a method performed by a user device. The communication control method includes, when the reception of an SC-PTM in which an MBMS service is provided fails, storing wireless environment information relating to the wireless environment of the user device at the time of the failure to receive the SC-PTM, and transmitting a failure report including the stored wireless environment information to the network. The failure report further includes a service identifier indicating the MBMS service. [Brief explanation of the drawing]

[0008] [Figure 1] This figure shows the configuration of a mobile communication system according to one embodiment. [Figure 2] This figure shows the configuration of a user device according to one embodiment. [Figure 3] This figure shows the configuration of a base station according to one embodiment. [Figure 4]This figure shows the configuration of the protocol stack of the user plane's wireless interface according to one embodiment. [Figure 5] This figure shows the configuration of the protocol stack for the wireless interface of a control plane according to one embodiment. [Figure 6A] This figure shows the mapping between the logical channel and the transport channel of the downlink in a mobile communication system according to one embodiment. [Figure 6B] This figure shows the mapping between the transport channel and the physical channel in a mobile communication system according to one embodiment. [Figure 7] This diagram shows the frequency channels handled by eMTC UE and NB-IoT UE. [Figure 8] This figure shows an example of a coverage extension state in a mobile communication system according to one embodiment. [Figure 9] This figure shows an example of SC-PTM receiving operation. [Figure 10] This diagram shows the operation flow of the mobile communication system according to the first embodiment. [Figure 11] This figure shows some details of the operation flow shown in Figure 10. [Figure 12] This diagram shows the operation flow of the mobile communication system according to the second embodiment. [Figure 13] This figure shows some details of the operation flow shown in Figure 12. [Modes for carrying out the invention]

[0009] A mobile communication system according to an embodiment will be described with reference to the drawings. In the drawings, identical or similar parts are denoted by the same or similar reference numerals.

[0010] (Mobile communication system) First, the configuration of a mobile communication system according to one embodiment will be described. The mobile communication system according to one embodiment is a 3GPP 5G system, but LTE may be applied to the mobile communication system at least partially.

[0011] Figure 1 shows the configuration of a mobile communication system according to one embodiment.

[0012] As shown in Figure 1, the mobile communication system includes User Equipment (UE) 100, a 5G Next Generation Radio Access Network (NG-RAN) 10, and a 5G Core Network (5GC) 20.

[0013] UE100 is a mobile device. UE100 can be any device used by a user. For example, UE100 can be a mobile phone terminal (including a smartphone), a tablet terminal, a notebook PC, a communication module (including a communication card or chipset), a sensor or a device attached to a sensor, a vehicle or a device attached to a vehicle (Vehicle UE), or an aircraft or a device attached to an aircraft (Aerial UE).

[0014] NG-RAN10 includes base stations (called "gNBs" in 5G systems) 200. gNB200 is sometimes referred to as an NG-RAN node. gNB200s are interconnected via the Xn interface, which is an inter-base station interface. gNB200 manages one or more cells. gNB200 performs wireless communication with UE100s that have established a connection with its own cell. gNB200 has radio resource management (RRM) functions, user data routing functions (hereinafter simply referred to as "data"), and measurement and control functions for mobility control and scheduling. "Cell" is used as a term indicating the smallest unit of a wireless communication area. "Cell" is also used as a term indicating a function or resource that performs wireless communication with UE100s. One cell belongs to one carrier frequency.

[0015] Note that the gNB may be connected to the EPC (Evolved Packet Core), which is the core network of LTE, or the base station of LTE may be connected to the 5GC. Further, the base station of LTE and the gNB may be connected via an interface between base stations.

[0016] The 5GC 20 includes an AMF (Access and Mobility Management Function) and a UPF (User Plane Function) 300. The AMF performs various mobility controls for the UE 100. The AMF manages information on the area where the UE 100 is located by communicating with the UE 100 using NAS (Non-Access Stratum) signaling. The UPF performs data transfer control. The AMF and the UPF are connected to the gNB 200 via the NG interface, which is an interface between the base station and the core network.

[0017] FIG. 2 is a diagram showing the configuration of the UE 100 (user equipment).

[0018] As shown in FIG. 2, the UE 100 includes a receiving unit 110, a transmitting unit 120, and a control unit 130.

[0019] The receiving unit 110 performs various receptions under the control of the control unit 130. The receiving unit 110 includes an antenna and a receiver. The receiver converts the radio signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 130.

[0020] The transmitting unit 120 performs various transmissions under the control of the control unit 130. The transmitting unit 120 includes an antenna and a transmitter. The transmitter converts the baseband signal (transmitted signal) output by the control unit 130 into a radio signal and transmits it from the antenna.

[0021] The control unit 130 performs various controls on the UE100. The control unit 130 includes at least one processor and at least one memory electrically connected to the processor. The memory stores programs executed by the processor and information used for processing by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in memory and performs various processing.

[0022] Furthermore, the UE100 may be equipped with position sensors such as a GNSS (Global Navigation Satellite System) receiver.

[0023] Figure 3 shows the configuration of the gNB200 (base station).

[0024] As shown in Figure 3, the gNB200 comprises a transmitting unit 210, a receiving unit 220, a control unit 230, and a backhaul communication unit 240.

[0025] The transmitting unit 210 performs various types of transmissions under the control of the control unit 230. The transmitting unit 210 includes an antenna and a transmitter. The transmitter converts the baseband signal (transmission signal) output by the control unit 230 into a radio signal and transmits it from the antenna.

[0026] The receiving unit 220 performs various types of reception under the control of the control unit 230. The receiving unit 220 includes an antenna and a receiver. The receiver converts the radio signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 230.

[0027] The control unit 230 performs various controls in the gNB200. The control unit 230 includes at least one processor and at least one memory electrically connected to the processor. The memory stores programs executed by the processor and information used for processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in memory and performs various processing.

[0028] The backhaul communication unit 240 is connected to an adjacent base station via an inter-base station interface. The backhaul communication unit 240 is connected to the AMF / UPF300 via a base station-core network interface. The gNB may consist of a CU (Central Unit) and a DU (Distributed Unit) (i.e., functionally separated), and the two units may be connected via an F1 interface.

[0029] Figure 4 shows the configuration of the protocol stack for the user plane's wireless interface that handles data.

[0030] As shown in Figure 4, the user plane radio interface protocol has a physical (PHY) layer, a MAC (Medium Access Control) layer, an RLC (Radio Link Control) layer, a PDCP (Packet Data Convergence Protocol) layer, and an SDAP (Service Data Adaptation Protocol) layer.

[0031] The PHY layer performs encoding / decoding, modulation / demodulation, antenna mapping / demapping, and resource mapping / demapping. Data and control information are transmitted between the UE100's PHY layer and the gNB200's PHY layer via a physical channel.

[0032] The MAC layer performs data priority control, retransmission processing using Hybrid ARQ (HARQ), and random access procedures. Data and control information are transmitted between the MAC layer of the UE100 and the MAC layer of the gNB200 via the transport channel. The MAC layer of the gNB200 includes a scheduler. The scheduler determines the transport format for the up and down links (transport block size, modulation and coding scheme (MCS)) and the resource blocks to be allocated to the UE100.

[0033] The RLC layer transmits data to the receiving RLC layer using the functions of the MAC layer and PHY layer. Data and control information are transmitted between the UE100's RLC layer and the gNB200's RLC layer via a logical channel.

[0034] The PDCP layer performs header compression / decompression, and encryption / decryption.

[0035] The SDAP layer maps IP flows, which are the units under which the core network performs QoS control, to wireless bearers, which are the units under which the AS (Access Stratum) performs QoS control. Note that if the RAN is connected to the EPC, SDAP may not be necessary.

[0036] Figure 5 shows the configuration of the protocol stack of the wireless interface of the control plane that handles signaling (control signals).

[0037] As shown in Figure 5, the protocol stack of the control plane's wireless interface has an RRC (Radio Resource Control) layer and a NAS (Non-Access Stratum) layer instead of the SDAP layer shown in Figure 4.

[0038] RRC signaling for various settings is transmitted between the RRC layer of the UE100 and the RRC layer of the gNB200. The RRC layer controls the logical channel, transport channel, and physical channel in response to the establishment, re-establishment, and release of the radio bearer. If there is a connection (RRC connection) between the RRC of the UE100 and the RRC of the gNB200, the UE100 is in the RRC connected state. If there is no connection (RRC connection) between the RRC of the UE100 and the RRC of the gNB200, the UE100 is in the RRC idle state. Also, if the RRC connection is suspended, the UE100 is in the RRC inactive state.

[0039] The NAS layer, located above the RRC layer, handles session management and mobility management, among other things. NAS signaling is transmitted between the UE100's NAS layer and the AMF300's NAS layer.

[0040] In addition to the wireless interface protocol, the UE100 also has an application layer and other components.

[0041] Figures 6A and 6B show the channel configuration of the downlink of a mobile communication system according to one embodiment. Figure 6A shows the mapping between the Downlink Logical Channel and the Downlink Transport Channel.

[0042] As shown in Figure 6A, the PCCH (Paging Control Channel) is a logical channel for notifying paging information and system information changes. The PCCH is mapped to the transport channel, the PCH (Paging Channel).

[0043] BCCH (Broadcast Control Channel) is a logical channel for system information. BCCH is mapped to the transport channels BCH (Broadcast Channel) and DL-SCH (Downlink Shared Channel).

[0044] The CCCH (Common Control Channel) is a logical channel for transmit control information between the UE100 and the gNB200. The CCCH is used when the UE100 does not have an RRC connection to the network. The CCCH is mapped to the DL-SCH.

[0045] DCCH (Dedicated Control Channel) is a logical channel for transmitting individual control information between the UE100 and the network. DCCH is used when the UE100 has an RRC connection. DCCH is mapped to DL-SCH.

[0046] A DTCH (Dedicated Traffic Channel) is a separate logical channel for data transmission. A DTCH is mapped to a DL-SCH.

[0047] SC-MTCH (Single Cell Multicast Traffic Channel) is a logical channel for SC-PTM. SC-MTCH is a point-to-multipoint downlink channel for multicasting data (MBMS) from the network to the UE100 using SC-PTM. Further details about SC-PTM will be provided later.

[0048] The SC-MCCH (Single Cell Multicast Control Channel) is a logical channel for SC-PTM. The SC-MCCH is a point-to-multipoint downlink channel for multicasting MBMS control information for one or more SC-MTCHs from the network to the UE100. The SC-MCCH is used by UE100s that receive or are interested in receiving MBMS using SC-PTM. Furthermore, only one SC-MCCH exists per cell.

[0049] The MCCH (Multicast Control Channel) is a logical channel for MBSFN. The MCCH is used to transmit MBMS control information for the MTCH from the network to the UE100. The MCCH is mapped to the transport channel, the MCH (Multicast Channel).

[0050] MTCH (Multicast Traffic Channel) is a logical channel for MBSFN. MTCH is mapped to MCH.

[0051] Figure 6B shows the mapping between the transport channel (Downlink Transport Channel) and the physical channel (Downlink Physical Channel).

[0052] As shown in Figure 6B, BCH is mapped to PBCH (Physical Broadcast Channel).

[0053] MCH is mapped to PMCH (Physical Multicast Channel). MCH supports MBSFN with multiple cells.

[0054] PCH and DL-SCH are mapped to PDSCH (Physical Downlink Shared Channel). DL-SCH supports HARQ, link adaptation, and dynamic resource allocation.

[0055] The PDCCH (Physical Downlink Control Channel) carries resource allocation information for the PDSCH (DL-SCH, PCH) and HARQ information related to the DL-SCH. The PDCCH also carries scheduling grants for the uplink.

[0056] (MDT function) Next, an overview of the MDT function will be described. A mobile communication system according to one embodiment supports the MDT function.

[0057] In MDT, the gNB200 sends a configuration message to the UE100 to set up MDT measurements. The gNB200 then collects MDT measurement information from the UE100. For example, the gNB200 is connected directly or indirectly to the MDT server. The MDT server obtains the MDT measurement information from the gNB200 and performs network optimization, including coverage optimization, based on the MDT measurement information.

[0058] There are two types of MDT: logged MDT and immediate MDT.

[0059] Logged MDT is a system in which a UE100 in RRC idle, RRC inactive, or RRC connected state performs wireless measurements, records the measurement results along with UE location information and timestamps, and transmits a report including the recorded measurement results, etc., to the network (gNB200) upon request.

[0060] Immediate MDT is a system in which the UE100, in an RRC-connected state, performs wireless measurements and measurements of other parameters, and sends a report containing the measurement results and UE location information to the network (gNB200). The configuration message for setting up Immediate MDT may be a measurement configuration message that includes an information element requesting that UE location information be included in the measurement report.

[0061] In MDT, UE100 stores the failure information described below and sends a failure report containing the failure information.

[0062] (Coverage extension) Next, we will describe the overview of coverage extensions. A mobile communication system according to one embodiment supports coverage extensions.

[0063] UE100s targeting MTC (Machine Type Communications) and IoT services have their transmission and reception bandwidth limited to only a portion of the system's transmission and reception bandwidth. For example, in LTE, such UE100s are categorized as Category M1 and Category NB (Narrow Band)-IoT. Category M1 is the category to which eMTC (enhanced MTC) UEs belong. Category NB-IoT (Category NB1) is the category to which NB-IoT UEs belong.

[0064] Category M1 limits the transmit / receive bandwidth of the UE100 (eMTC UE) to, for example, 1.08 MHz (i.e., the bandwidth of 6 resource blocks). Category NB-IoT (Category NB1) further limits the transmit / receive bandwidth of the UE100 (NB-IoT UE) to 180 kHz (i.e., the bandwidth of 1 resource block). This narrowing of bandwidth enables the cost reduction and lower power consumption required for eMTC UE and NB-IoT UE.

[0065] Figure 7 shows the frequency channels handled by the eMTC UE and NB-IoT UE.

[0066] As shown in Figure 7, the system frequency bandwidth of the mobile communication system can be 10 MHz. The bandwidth of the system transmit / receive band is, for example, 50 resource blocks = 9 MHz. The bandwidth of the frequency channels that the eMTC UE can support is within 6 resource blocks = 1.08 MHz.

[0067] The frequency channels within 6 resource blocks that eMTC UE can support are called "Narrow Band (NB)". The bandwidth of the frequency channels that NB-IoT UE can support is 1 resource block = 180 kHz. The frequency channel of a single resource block that NB-IoT UE can support is called "carrier".

[0068] The Category M1 UE100 cannot receive downlink radio signals transmitted with a bandwidth wider than 6 resource blocks, and therefore cannot receive standard PDCCHs. For this reason, MPDCCH (MTC-PDCCH), a PDCCH designed for MTCs, is introduced. For similar reasons, NPDCCH (NB-PDCCH), a PDCCH designed for NB-IoTs, is introduced.

[0069] The eMTC UE operates within the LTE transmit / receive bandwidth. The NB-IoT UE supports three configurations: operating within the LTE transmit / receive bandwidth, operating in a guard band outside the LTE transmit / receive bandwidth, and operating within a frequency band dedicated to NB-IoT.

[0070] eMTC UE and NB-IoT UE support Enhanced Coverage (EC) functionality, which uses repeated transmissions and other methods to achieve coverage expansion. Enhanced coverage is sometimes also referred to as Coverage Enhancement (CE).

[0071] Coverage extensions may include repetitions, which involve repeatedly transmitting the same signal using multiple subframes. The more repetitions there are, the greater the coverage.

[0072] Coverage extensions may include power boosting, which increases the power density of the transmitted signal. For example, power density can be increased by narrowband transmission, which reduces the frequency bandwidth of the transmitted signal. The higher the power density of the transmitted signal, the greater the coverage. Coverage extensions may also include lower MCS transmission, which reduces the MCS used for the transmitted signal. Coverage can be extended by transmitting with a lower data rate and a more error-tolerant MCS.

[0073] Coverage extensions have multiple coverage extension states, each with a different degree of coverage expansion. The method for determining the coverage extension state will be described later.

[0074] Furthermore, UEs in extended coverage may re-select cells based on a ranking derived from received power (RSRP (Reference Signal Received Power)) during RRC idle or RRC inactive states. For example, the UE calculates the ranking Rs of the current serving cell and the ranking Rn of adjacent cells, and selects a cell with a ranking Rn higher than Rs over a predetermined period (TreselectionRAT) as the new serving cell.

[0075] (Method for determining coverage expansion status) Figure 8 shows an example of a coverage extension state in a mobile communication system according to one embodiment.

[0076] The coverage extension state (hereinafter referred to as the "CE state") may include the coverage extension level (hereinafter referred to as the "CE level") and the coverage extension mode (hereinafter referred to as the "CE mode").

[0077] As shown in Figure 8, CE modes include at least CE mode A and CE mode B. CE mode B is a state with further extended coverage than CE mode A. CE mode B supports a greater number of repeated transmissions than CE mode A. UEs that support extended coverage (e.g., eMTC UEs) support at least CE mode A.

[0078] The CE level includes at least four levels, from level 0 to level 3. A correspondence may be established between CE modes and CE levels. In the example in Figure 8, CE levels 0 and 1 correspond to CE mode A, and CE levels 2 and 3 correspond to CE mode B. A correspondence between CE modes and CE levels is not required.

[0079] UE100, which is in an RRC idle or RRC inactive state, may determine that it is in extended coverage if the first cell selection criterion for normal coverage (first S-criteria) is not met, and the second cell selection criterion for CE mode A (second S-criteria) is met. UE100 may also determine that it is in extended coverage if it supports CE mode B, and the second S-criteria is not met, and the third cell selection criterion for CE mode B (third S-criteria) is met. "UE in extended coverage" may mean a UE that requires the use of coverage extensions to access cells.

[0080] UE100 determines its own CE level after it has determined that it is in extended coverage.

[0081] The UE100 measures the RSRP (Reference Signal Received Power) and determines its own CE level (one of CE levels 0 to 3) by comparing the measured RSRP with the RSRP threshold for each CE level. The RSRP threshold for each CE level may be set by system information broadcast by the UE100's serving cell.

[0082] UE100 may determine its own CE level when performing a random access procedure. When UE100 performs a random access procedure to a serving cell, it sends an RA preamble to the serving cell using a PRACH (Physical Random Access Channel) resource (frequency resource, time resource, preamble, etc.) corresponding to its own CE level. The correspondence between CE levels and PRACH resources may be set by system information. If UE100 does not receive an RA (Random Access) response from the serving cell within a predetermined time, it may resend the RA preamble. If an RA response is not received even after a predetermined number of RA preamble transmissions, UE100 may determine its own CE level to be the next level. For example, if UE100 does not receive an RA response even after a predetermined number of RA preamble transmissions using a PRACH resource corresponding to CE level 0, it determines its own CE level to be CE level 1. Such predetermined numbers may be set by system information. Subsequently, UE100 may send the RA preamble to the serving cell using a PRACH resource corresponding to CE level 1.

[0083] UE100 may determine its own CE level to be the CE level corresponding to the PRACH resource used when transmitting the RA preamble corresponding to a successfully received RA response.

[0084] UE100 may determine its own CE mode based on the correspondence between CE modes and CE levels. In the example in Figure 8, UE100 determines its own CE mode to be CE mode A when its CE level is level 0 or 1, and determines its own CE mode to be CE mode B when its CE level is level 2 or 3. UE100 may also determine its own CE mode based on other criteria. For example, UE100 may determine its own CE mode to be CE mode A if it determines that it is in extended coverage because the second cell selection criterion for CE mode A has been met.

[0085] The UE100 may set the CE mode from the serving cell when it is in an RRC connected state. Alternatively, the CE mode may be set from the serving cell by dedicated RRC signaling.

[0086] When UE100 receives an RRC signaling indicating CE mode A, it determines its own CE mode to be CE mode A. When UE100 receives an RRC signaling indicating CE mode B, it determines its own CE mode to be CE mode B.

[0087] The CE state may be indicated by one of several received power ranges (RSRP ranges). These RSRP ranges may be set by system information broadcast by the UE100's serving cell. The UE100 measures the RSRP and determines the RSRP range to which the measured RSRP belongs. For example, if RSRP ranges #1 to #3 are set and the measured RSRP belongs to RSRP range #1, the UE100 determines its own CE state to be RSRP range #1.

[0088] When UE100 performs uplink (UL) communication, it applies UL parameters according to its own CE state. UL parameters may be set in UE100 by RRC signaling. UL parameters may also be set in UE100 by system information. UL parameters include UL repetition count, transmit power, etc. UL repetition count may include the number of repetitions to be applied to UL transmission. UL repetition count may also include the maximum number of repetitions to be applied to UL transmission. UL repetition count may be set for each UL channel. For example, UL repetition count may include the number of repetitions for PUCCH (Physical Uplink Control Channel), PUSCH (Physical Uplink Shared Channel), and PRACH. The predetermined number for the number of transmissions in the RA preamble mentioned above may be the maximum number of PRACH repetitions.

[0089] When UE100 performs downlink (DL) communication, it applies DL parameters according to its own CE state. DL parameters may be set in UE100 by RRC signaling. DL parameters may also be set in UE100 by system information. DL parameters include the DL repetition count, etc. The DL repetition count may include the number of repetitions to be applied to DL transmission. The DL repetition count may also include the maximum number of repetitions to be applied to DL transmission. The DL repetition count may be set for each DL channel. For example, the DL repetition count may include the repetition count for PDCCH, the repetition count for PDSCH, etc.

[0090] (Overview of SC-PTM) Next, we will explain the overview of SC-PTM. 3GPP specifies MBMS (Multimedia Broadcast Multicast Service) transmission, which provides multicast / broadcast services to user equipment. There are two MBMS methods: MBSFN (Multicast Broadcast Single Frequency Network) and SC-PTM (Single Cell Point-To-Multipoint). In MBSFN, data is transmitted via PMCH (Physical Multicast Channel) in MBSFN area units consisting of multiple cells. In contrast, in SC-PTM, data is transmitted via PDSCH on a cell-by-cell basis.

[0091] UE100 may receive MBMS services in the RRC connected state, or it may receive MBMS services in the RRC idle state or RRC inactive state.

[0092] Figure 9 shows an example of SC-PTM reception operation. As shown in Figure 9, in step S1, UE100 obtains USD (User Service Description) from 5GC20 via gNB200. USD provides basic information for each MBMS service. For each MBMS service, USD includes the TMGI that identifies the MBMS service, the frequency on which the MBMS service is provided, and the start and end times of the MBMS service.

[0093] In step S2, UE100 receives SIB20 from gNB200 via BCCH (Broadcast Control Channel). SIB20 contains information necessary for acquiring SC-MCCH (scheduling information). SIB20 includes sc-mcch-ModificationPeriod, which indicates the period during which the contents of SC-MCCH may be changed; sc-mcch-RepetitionPeriod, which indicates the transmission (retransmission) period of SC-MCCH in terms of the number of radio frames; sc-mcch-Offset, which indicates the offset of the radio frame in which SC-MCCH is scheduled; and sc-mcch-Subframe, which indicates the subframe in which SC-MCCH is scheduled.

[0094] In step S3, UE100 receives MBMS control information from gNB200 via SC-MCCH based on SIB20. The MBMS control information may also be referred to as SC-PTM Configuration information. At the physical layer, SC-RNTI (Single Cell RNTI) is used to transmit SC-MCCH. The SC-PTM Configuration information includes control information applicable to MBMS services transmitted via SC-MRB (Single Cell MBMS Point to Multipoint Radio Bearer). The SC-PTM Configuration information includes sc-mtch-InfoList, which contains the settings for each SC-MTCH in the cell transmitting the information, and scptmNeighbourCellList, which is a list of neighboring cells providing MBMS services via SC-MRB. sc-mtch-InfoList contains one or more SC-MTCH-Info. Each SC-MTCH-Info includes information about an ongoing MBMS session transmitted via SC-MRB (mbmsSessionInfo), a G-RNTI (Group RNTI) corresponding to that MBMS session, and sc-mtch-schedulingInfo, which is DRX information for the SC-MTCH. mbmsSessionInfo includes the TMGI and session ID (sessionId) that identify the MBMS service. The G-RNTI is an RNTI that identifies a multicast group (specifically, an SC-MTCH destined for a particular group). The G-RNTI is mapped one-to-one with the TMGI. sc-mtch-schedulingInfo includes onDurationTimerSCPTM, drx-InactivityTimerSCPTM, and schedulingPeriodStartOffsetSCPTM. schedulingPeriodStartOffsetSCPTM includes SC-MTCH-SchedulingCycle and SC-MTCH-SchedulingOffset.

[0095] In step S4, UE100 receives MBMS services (MBMS data) corresponding to TMGIs of interest via SC-MTCH, based on SC-MTCH-SchedulingInfo in the SC-PTM configuration information. At the physical layer, gNB200 transmits PDCCH using G-RNTI, and then transmits MBMS data via PDSCH.

[0096] When UE100 performs SC-PTM reception, it may attempt reception by applying the number of repetitions corresponding to each of the above-mentioned channels (BCCH, SC-MCCH, SC-MTCH, etc. that carry SIB20) (for example, the number of repetitions for BCCH, the number of repetitions for SC-MCCH, the number of repetitions for SC-MTCH, etc.). The number of repetitions for BCCH, SC-MCCH, and SC-MTCH may be set for each CE state.

[0097] (First Embodiment) Next, the operation of the mobile communication system according to the first embodiment will be described. Figure 10 is a diagram showing the operation flow of the mobile communication system according to the first embodiment. In this operation flow, for example, the UE100 is executed by an eMTC UE or an NB-IoT UE.

[0098] In step S11, the gNB200 sends the MDT measurement settings to the UE100. At this point, the UE100 is in the RRC connected state. In step S12, the UE100 transitions from the RRC connected state to the RRC idle state or the RRC inactive state.

[0099] The operations in steps S11 to S12 may be omitted. In the following, the operations from step S13 onwards will be described assuming that UE100 is in extended coverage after transitioning to the RRC idle state or RRC inactive state.

[0100] In step S13, UE100 performs a procedure related to the RRC connection. If this procedure fails, in step S14, UE100 saves connection failure information related to the failure of the procedure. Here, the "procedure related to the RRC connection" may be an RRC connection establishment procedure for establishing a new RRC connection, or an RRC connection resume procedure for resuming a suspended RRC connection. Depending on the success of the RRC connection establishment procedure and the RRC connection resume procedure, UE100 transitions to the RRC connected state. The RRC connection establishment procedure and the RRC connection resume procedure may also be referred to as the procedure for transitioning to the RRC connected state.

[0101] Note that UE100 may fail multiple times in the RRC connection procedure when in the RRC idle or RRC inactive state. In this case, UE100 executes steps S13 and S14 multiple times and saves connection failure information for the multiple failures (step S14).

[0102] Steps S13 to S14 will be explained in detail using Figure 11. Figure 11 is a diagram showing the details of steps S13 to S14.

[0103] In step S1301, UE100 determines its own CE state using the coverage extension state determination method described above. For example, UE100 may determine its own CE level according to the measured RSRP. UE100 may also determine its own CE level as the CE level corresponding to the PRACH resource used when sending the RA preamble corresponding to the successfully received RA response. Note that if UE100 is not in extended coverage (i.e., in normal coverage), step S1301 does not need to be performed.

[0104] In step S1302, UE100 initiates a procedure related to the RRC connection and sends an RRC request message corresponding to that procedure to the serving cell (gNB200). UE100 may also send an RRC request message upon receiving an RA response. If the procedure related to the RRC connection is an RRC connection establishment procedure, the RRC request message is an RRCSetupRequest message. If the procedure related to the RRC connection is an RRC connection resume procedure, the RRC request message is an RRCResuemeRequest message.

[0105] In step S1303, UE100 starts a timer in response to the transmission of an RRC request message. The timer value may be set by system information broadcast from the serving cell. The timer value may differ depending on the type of "procedure related to RRC connection" (e.g., RRC connection establishment, RRC connection resume). The timer value may also differ depending on the type of CE mode (e.g., CE mode A, CE mode B). If repeated transmission is applied to the transmission of the RRC request message, UE100 may start the timer in response to the first transmission in the repeated transmission. Alternatively, UE100 may start the timer in response to the last transmission in the repeated transmission. For example, if a maximum number of repeated transmissions in a repeated transmission is set in UE100, UE100 may consider the transmission made immediately before reaching the maximum number of repeated transmissions as the last transmission.

[0106] In steps S1304 to S1305, UE100 attempts to receive an RRC response message in response to the RRC request message before the timer expires.

[0107] If the timer expires (step S1305: YES), UE100 proceeds to step S14. If an RRC response message has not been received before the timer expires, UE100 considers the RRC connection procedure to have failed and stores failure information regarding the failure of the RRC connection procedure.

[0108] On the other hand, if an RRC response message is received before the timer expires (step S1304: YES), in step S1306, UE100 stops the timer and proceeds to step S1307.

[0109] In step S1307, UE100 determines whether the received RRC response message is an affirmative response. If the RRC response message is an affirmative response (step S1307: YES), in step S1308, UE100 successfully completes the procedure related to the RRC connection.

[0110] On the other hand, if the RRC response message is not an affirmative response (step S1307: NO), UE100 may restart the procedure for the RRC connection. UE100 may restart the procedure for the same serving cell, or it may select a new serving cell and restart the procedure for that new serving cell.

[0111] The operation of step S14 will now be described. In step S14, the UE100 stores connection failure information regarding the failure of the RRC connection procedure in a storage area for connection failure information. The storage area for connection failure information is provided, for example, in the memory included in the control unit 130. The connection failure information includes at least one of the following (a) to (d).

[0112] (a) Extended status information UE100 stores extended status information in the connection failure information that indicates its own CE status (CE status determined in step S1301) when the procedure for RRC connection fails. The extended status information may indicate one of the following: CE level, CE mode, and RSRP range, or a combination of two or more of these. For example, the extended status information may indicate CE mode A and CE level 0. The extended status information may also indicate RSRP range #1.

[0113] (b) Failure count information The UE100 stores failure count information, which indicates the number of times the RRC connection procedure has failed (hereinafter referred to as "failure count"), along with the connection failure information. Specifically, the UE100 maintains a counter that counts the number of failures and stores the value of this counter as failure count information. For example, the UE100 increments the value of the counter by 1 and updates the failure count information in response to the expiration of the timer corresponding to the transmitted RRC request message (step S1305: YES).

[0114] UE100 may store failure count information associated with extended state information. In other words, UE100 counts the number of failures for each CE state. Specifically, UE100 maintains the above-mentioned counter for each CE state and counts the number of times the RRC connection procedure performed by UE100 in the same CE state has failed. For example, UE100 maintains a counter corresponding to CE level 0 (counter_CE0), and when its own CE level is CE level 0 (determined as CE level 0 in step S1301), if the timer corresponding to the RRC request message sent expires (step S1305: YES), counter_CE0 is incremented by 1.

[0115] UE100 primarily counts the number of failures for each serving cell, but it may also count the total number of failures for RRC connection procedures performed within a predetermined time period (e.g., 48 hours), regardless of the serving cell. In this case, UE100 may maintain a counter _Total corresponding to the total number of failures.

[0116] (c) Failure cell identification information The UE100 stores the cell identifier of a serving cell that failed the RRC connection procedure as failed cell identification information in the connection failure information. The cell identifier may also be an ECGI (Evolved Cell Global Identifier).

[0117] (d) Measurements of the wireless environment The UE100 stores measurement values ​​of its wireless environment in connection failure information when the RRC connection procedure fails. These measurement values ​​may be RSRP or RSRQ (Reference Signal Received Quality). The UE100 may only store measurement values ​​in connection failure information if it is in extended coverage.

[0118] The UE100 measures the wireless environment and saves the measurements each time the RRC connection procedure fails.

[0119] If the UE100 fails to perform the RRC connection procedure multiple times, it may calculate a single statistic from the multiple measurements stored in the connection failure information. The UE100 may start calculating the statistic when the number of times the RRC connection procedure has failed (e.g., the number indicated in the failure count information) reaches a threshold. The threshold may be set by the gNB200. For example, the threshold may be set by the gNB200 via the MDT measurement setting message described later. The UE100 may store the measurement for each CE state.

[0120] UE100 may calculate an average value as a statistical value based on multiple measurements taken over multiple cycles and the number of times the RRC connection procedure failed. UE100 may use the maximum value among the multiple measurements as the statistical value. UE100 may use the minimum value among the multiple measurements as the statistical value.

[0121] When the UE100 calculates a single statistic from multiple stored measurements, it may store that single statistic as the measurement for the wireless environment instead of the multiple measurements. This reduces the size of the storage area occupied by storing multiple measurements.

[0122] In addition to the information described in (a) through (d) above, connection failure information may also include information related to existing MDT measurements, such as location information and timestamps. Location information may indicate the geographical location of UE100 at the time the RRC connection procedure failed. Location information may be obtained from the UE100's GNSS receiver.

[0123] In step S14, the UE100 basically saves connection failure information autonomously, but if step S11 is performed, it may save connection failure information according to the setting message (MDT measurement setting message) from the gNB200. For example, if the CE state is specified by the setting message (MDT measurement setting), the UE100 may save failure count information that is associated only with the specified CE state.

[0124] After step S14, UE100 may return to step S1301 and restart the procedure related to RRC connection.

[0125] Returning to Figure 10, the operation from step S15 onward will be explained. In step S15, UE100 sends a notification message to gNB200 indicating that it has connection failure information. This notification message is sometimes called an availability indicator. This availability indicator may also be a message that notifies that there is connection failure information stored when UE100 is in extended coverage. UE100 may also send a notification message when transitioning from the RRC idle state or RRC inactive state to the RRC connected state, or during a handover, etc.

[0126] Note that the gNB200 that manages the cell where UE100 is located during MDT measurement setup (step S11) may be different from the gNB200 that manages the cell where UE100 is located during notification (step S15).

[0127] In step S16, based on the notification message from UE100, gNB200 sends a report request message to UE100 requesting UE100 to send (report) a connection failure report including connection failure information.

[0128] In step S17, UE100 sends a connection failure report to gNB200 in response to a report request message. The report request message may specify the information to be included in the connection failure report (for example, the information (a) to (d) described above). UE100 may also send a connection failure report that includes only the information specified by the report request message. The connection failure report includes extended status information and failure count information associated with the extended status information. The connection failure report includes statistical values ​​calculated from measurements of the wireless environment.

[0129] If UE100 stores connection failure information across multiple cells, it may send a connection failure report that includes connection failure information for each cell.

[0130] (Summary of the first embodiment) As described above, UE100 sends a failure report to the network regarding any failures in the RRC connection procedure performed by UE100 when it is in extended coverage of the serving cell. The failure report includes extended state information indicating the CE state of UE100 in extended coverage, and failure count information associated with said extended state information. The failure count information indicates the number of times UE100 failed the procedure in the CE state. This allows the network to understand the accessibility for each CE state and appropriately set transmission parameters such as the number of repeated transmissions corresponding to the CE state.

[0131] (Example of modification of the first embodiment 1) In the first embodiment, it is assumed that UE100 is in an RRC idle state or an RRC inactive state, but in Modification Example 1 of the first embodiment, it is assumed that UE100 is in an RRC connected state.

[0132] In the modified example 1 of the first embodiment, the UE100 performs the operations of steps S13 to S14 while in the RRC connected state. When the UE100 is in the RRC connected state, the "procedures related to RRC connection" are RRC connection re-establishment procedures for re-establishing the RRC connection. The RRC connection re-establishment procedure may be performed in response to the UE100 detecting an RLF (Radio Link Failure) for the RRC connected cell.

[0133] In step S1302, UE100 sends an RRCReestablishmentRequest message as an RRC request message. In step S14, UE100 saves extended status information and failure count information corresponding to the RRC connection re-establishment procedure. Without performing the operations in steps S15 and S16, UE100 sends a connection failure report, including extended status information and failure count information corresponding to the RRC connection re-establishment procedure, depending on the success of the connection re-establishment procedure.

[0134] (Example of modification of the first embodiment 2) In the first embodiment, an example was described in which failure cell identification information was included in the connection failure information. However, information of a broader area unit than a cell may also be included in the connection failure information. Examples of such broad area units include the RAN Notification Area (RNA), which is the area unit in which paging is performed during RAN startup; the MBSFN area, which is the area unit in which MBMS is provided; and the tracking area, which is the area unit in which paging is performed during AMF startup. In the following, the RAN Notification Area will be used as an example of such a broad area unit.

[0135] The RAN notification area is also called the RAN-based Notification Area, RAN paging area, or RAN location update area.

[0136] The RAN notification area may consist of one or more cells. The RAN notification area may be set on UE100 by an RRC Release message that causes gNB200 to transition UE100 to an RRC inactive state.

[0137] A UE100 in RRC inactive state does not need to notify (report) the network that it has re-selected a cell even if it moves between cells within the RAN notification area due to cell re-selection. A UE100 in RRC inactive state requests the network to update the RAN notification area if it re-selects a cell outside the RAN notification area.

[0138] The UE100 can execute the RRC connection resume procedure in cells belonging to the RAN notification area configured for it.

[0139] The UE100 stores RAN notification area information, which identifies the RAN notification area, along with connection failure information.

[0140] The UE100 may store information such as failure count information (the extended status information mentioned above, wireless environment measurements, etc.) associated with RAN notification area information. For example, the UE100 counts the number of failures for each RAN notification area. Specifically, the UE100 maintains a counter corresponding to the RAN notification area and counts the number of times the RRC connection resume procedure performed in the same RAN notification area has failed.

[0141] The UE100 transmits a failure report to the network that includes RAN notification area information and information such as the number of failures associated with the RAN notification area information (the extended status information mentioned above, wireless environment measurements, etc.). Therefore, the network can understand the accessibility of each RAN notification area and set a more appropriate RAN notification area for the UE100.

[0142] The UE100 may include and store information of a unit smaller than a cell in its connection failure information. Such a smaller unit could be a beam within a cell. A single cell may contain multiple beams. Each beam broadcasts its own beam identifier.

[0143] The UE100 may store information such as failure count information (extended status information, wireless environment measurements, etc.) associated with a beam identifier that identifies the beam.

[0144] The UE100 transmits a failure report to the network, which includes a beam identifier and information such as the number of failures associated with the beam identifier (extended status information, wireless environment measurements, etc.). This allows the network to understand the accessibility of each beam and perform detailed optimization for each beam.

[0145] (Second Embodiment) Next, the operation of the mobile communication system according to the second embodiment will be described. Figure 12 is a diagram showing the operation flow of the mobile communication system according to the second embodiment.

[0146] The second embodiment is an embodiment relating to the collection of data on the reception status of SC-PTM using the MDT function.

[0147] In step S21, the gNB200 sends an MDT measurement configuration message to the UE100, which is in the RRC connected state, to configure the logged MDT. The UE100 receives the MDT measurement configuration message and stores the various configuration parameters contained in the received MDT measurement configuration message. The configuration parameters may specify the CE state. The measurement parameters may specify a specific MBMS service.

[0148] In step S22, after the UE100 has finished communicating with the gNB200, it transitions from the RRC connected state to the RRC idle state or the RRC inactive state and starts the operation of logged MDT according to the MDT setting parameters.

[0149] Alternatively, the UE100 may perform logged MDT operations according to the MDT setting parameters when in the RRC connected state.

[0150] In step S23, UE100 attempts to receive SC-PTM. In step S24, UE100 saves SC-PTM failure information or SC-PTM success information regarding the reception of SC-PTM.

[0151] Steps S23 and S24 will be explained in detail using Figure 13. Figure 13 is a diagram showing the details of steps S23 and S24.

[0152] In steps S2301 to S2305, UE100 attempts to receive SC-PTM to receive a specific MBMS service. The specific MBMS service may be an MBMS service of interest to UE100, or it may be an MBMS service specified by the MDT measurement setting message in step S21.

[0153] In step S2301, UE100 attempts to reselect a cell (SC-PTM cell) at a frequency (SC-PTM frequency) that provides a specific MBMS service via SC-PTM. Cell reselection is performed according to the cell reselection procedure defined by 3GPP. If UE100 cannot find an SC-PTM cell that meets the criteria for cell reselection (e.g., R-criteria), it considers the cell reselection to an SC-PTM cell to have failed.

[0154] If cell reselection to the SC-PTM cell fails (step S2301: NO), UE100 determines that SC-PTM reception has failed (step S2306). Then, in step S24, UE100 saves SC-PTM failure information regarding the failure to receive the SC-PTM. Details of the operation in step S24 will be described later.

[0155] On the other hand, if UE100 successfully re-selects the SC-PTM cell (step S2301: YES), it proceeds to S2302.

[0156] In step S2302, UE100 determines its CE status using the method for determining the coverage extension status described above. Note that if UE100 is not in extended coverage (i.e., in normal coverage), step S2302 does not need to be performed.

[0157] In step S2303, UE100 attempts to receive SIB20. If UE100 is in extended coverage, UE100 may attempt to receive SIB20 within the range of the configured maximum number of repetitions (e.g., the maximum number of repetitions for BCCH). If UE100 is unable to receive SIB20 within the applied maximum number of repetitions (specifically, fails to decode SIB20), it may determine that it has failed to receive SIB20. If UE100 attempts to receive SIB20 within a certain period and is unable to receive SIB20, it may determine that it has failed to receive SIB20.

[0158] If UE100 determines that it failed to receive SIB20 (step S2303: NO), it determines that SC-PTM reception failed (step S2306).

[0159] On the other hand, if UE100 successfully receives SIB20 (step S2303: YES), it proceeds to step S2304.

[0160] In step S2304, UE100 attempts to receive SC-MCCH (SC-PTM configuration information). If UE100 is in extended coverage, UE100 may attempt to receive SC-MCCH within the range of the configured maximum number of repetitions (e.g., the number of SC-MCCH repetitions). If UE100 is unable to receive SC-MCCH within the applied maximum number of repetitions, it may determine that it has failed to receive SC-MCCH. UE100 may also attempt to receive SC-MCCH within a certain period of time, and if it is unable to receive SC-MCCH, it may determine that it has failed to receive SC-MCCH.

[0161] If UE100 determines that it has failed to receive SC-MCCH (step S2304: NO), it determines that it has failed to receive SC-PTM (step S2306).

[0162] On the other hand, if UE100 successfully receives SC-MCCH (step S2304: YES), it proceeds to step S2305.

[0163] In step S2305, UE100 attempts to receive SC-MTCH (MBMS data). If UE100 is in extended coverage, UE100 may attempt to receive SC-MTCH within the maximum number of iterations (e.g., the number of SC-MTCH iterations). If UE100 cannot receive SC-MTCH within the applied number of iterations, it may determine that it has failed to receive SC-MTCH. If UE100 attempts to receive SC-MTCH within a certain period and is unable to receive SC-MTCH, it may determine that it has failed to receive SC-MTCH.

[0164] If UE100 determines that it has failed to receive SC-MTCH (step S2305: NO), it determines that it has failed to receive SC-PTM (step S2306).

[0165] On the other hand, if UE100 successfully receives SC-MTCH (step S2305: YES), it determines that it has successfully received SC-PTM (step S2307).

[0166] In step S24, if the UE100 determines that SC-PTM reception has failed, it stores SC-PTM failure information regarding the failure to receive the SC-PTM in a storage area for SC-PTM failure information. The storage area for SC-PTM failure information is provided in the memory included in the control unit 130. The SC-PTM failure information includes at least one of the following pieces of information: (a) to (g).

[0167] (a) Identification information of SC-PTM cells UE100 stores the identification information of the SC-PTM cell in the SC-PTM failure information when SC-PTM fails.

[0168] (i) MBMS service identification information UE100 stores MBMS service identification information in the SC-PTM failure information. MBMS service identification information is identification information related to the MBMS service (the specific MBMS service mentioned above) that UE100 considered when it failed to receive the SC-PTM. MBMS service identification information may include at least one of the following: TMGI, session ID, and G-RNTI.

[0169] (c) Wireless environment information The UE100 stores wireless environment information along with the SC-PTM failure information. This wireless environment information includes the measured wireless environment of the UE100 at the time of the SC-PTM reception failure. The measured values ​​may be RSRP or RSRQ.

[0170] (e) Extended status information The UE100 stores extended status information, which indicates its own CE status when it fails to receive SC-PTM, along with the SC-PTM failure information. The extended status information may indicate one of the following: CE level, CE mode, and RSRP range, or a combination of two or more of these.

[0171] (e) Information on the period during which attempts were made to receive SC-PTM If UE100 is in extended coverage, it stores information about the period during which it attempted to receive SC-PTM (hereinafter referred to as "period information") in the SC-PTM failure information. The period information includes at least one of the following: information about the period during which it attempted to receive SIB20, information about the period during which it attempted to receive SC-MCCH, and information about the period during which it attempted to receive SC-MTCH. UE100 may also store the period information in association with the extended status information.

[0172] (c) Information on the number of repetitions applied to the reception of SC-PTM If UE100 is in extended coverage, it stores the information on the number of repetitions applied to the reception of SC-PTM (hereinafter referred to as "repetition count information") in the SC-PTM failure information. The repetition count information is information on the number of repetitions applied in each of steps S2303, S2304, and S2305. The repetition count information includes at least one of the following: the information on the number of repetitions applied to the reception of SIB20, the information on the number of repetitions applied to the reception of SC-MCCH, and the information on the number of repetitions applied to the reception of SC-MTCH. UE100 may store the repetition count information in association with the extended status information.

[0173] (k) Information on the reason (Cause) for the failure to receive SC-PTM. The UE100 stores the cause information for the failure to receive SC-PTM (hereinafter referred to as "Cause information") in the SC-PTM failure information.

[0174] If UE100 determines that SC-PTM reception failed due to a failure to receive re-selection to an SC-PTM cell, it stores information indicating re-selection to an SC-PTM cell as Cause information.

[0175] If the UE100 determines that SC-PTM reception failed due to a failure to receive SIB20, it stores information indicating the SIB20 reception failure as Cause information.

[0176] If the UE100 determines that SC-PTM reception failed due to a failure in SC-MCCH reception, it stores information indicating the SC-MCCH reception failure as Cause information.

[0177] If the UE100 determines that SC-PTM reception failed due to a failure in SC-MTCH reception, it stores information indicating the SC-MTCH reception failure as Cause information.

[0178] SC-PTM failure information may include, in addition to the information described in (a) through (g) above, information related to existing MDT measurements such as location information and timestamps. SC-PTM failure information may also include information indicating the SC-PTM frequency.

[0179] Next, we will return to Figure 12 and explain the operation from step S25 onward. In step S25, UE100 sends a notification message to gNB200 indicating that it has SC-PTM failure information. UE100 may also send a notification message when transitioning from the RRC idle state or RRC inactive state to the RRC connected state, or during a handover, etc. The notification message may indicate that UE100 has SC-PTM failure information for each MBMS service.

[0180] In step S26, based on the notification message from UE100, gNB200 sends a report request message to UE100 requesting UE100 to send (report) an SC-PTM failure report containing SC-PTM failure information.

[0181] In step S27, UE100 sends an SC-PTM failure report to gNB200 in response to a report request message. The report request message may specify the information to be included in the SC-PTM failure report (for example, the information (a) to (g) described above). The report request message may also request that the report include SC-PTM failure information corresponding to a predetermined frequency. The report request message may also request that the report include SC-PTM failure information corresponding to a predetermined cell. The report request message may also request that the report include SC-PTM failure information corresponding to a predetermined MBMS identifier (TMGI).

[0182] UE100 may send an SC-PTM failure report containing only the information specified by the report request message. The SC-PTM failure report includes radio environment information and MBMS service identification information. The SC-PTM failure report also includes extended status information.

[0183] (Summary of the second embodiment) As explained above, when UE100 fails to receive an SC-PTM for an MBMS service, it stores radio environment information about the UE100's radio environment at the time of the SC-PTM reception failure. UE100 then transmits an SC-PTM failure report, including the stored radio environment information, to the network. The SC-PTM failure report further includes a service identifier indicating the MBMS service. This allows the network to understand the SC-PTM reception status for a specific MBMS service and to appropriately configure the SC-PTM settings (frequency, MCS, repetition count, etc.) for that specific MBMS service.

[0184] (Example of modification of the second embodiment) This example of modification explains the information (SC-PTM success information) that is saved when SC-PTM is successfully received.

[0185] As shown in Figure 13, if UE100 determines that it has successfully received the SC-PTM (step S2307), it saves the SC-PTM success information in step S24. The SC-PTM success information includes (a) the SC-PTM cell identification information, (b) the MBMS service identification information, and (d) the extended status information described above.

[0186] UE100 may save SC-PTM success information only if it successfully receives an SC-PTM with repeated transmission applied while in extended coverage.

[0187] As described above, an SC-PTM to which repeated transmission is applied includes at least one of the following: an SIB20 to which repeated transmission is applied, an SC-MCCH to which repeated transmission is applied, and an SC-MTCH to which repeated transmission is applied.

[0188] Furthermore, the UE100 also stores count information in the SC-PTM success information, indicating how many times an SC-PTM (SIB20, SC-MCCH, SC-MTCH, etc.) was transmitted before successful reception.

[0189] The UE100 sends an SC-PTM success report to the network, which includes SC-PTM cell identification information, MBMS service identification information, extended status information, and count information corresponding to the MBMS service identification information. This allows the network to understand the SC-PTM count information for a specific MBMS service and appropriately configure the SC-PTM settings (such as the number of repetitions) for that specific MBMS service. For example, if the number of SC-MTCH repetitions set by the network (the number of repeated transmissions of SC-MTCH) is much larger than the SC-MTCH count information included in the SC-PTM success report (the number of reception attempts the UE made before successfully receiving SC-MTCH), the network can set a smaller number of SC-MTCH repetitions, thereby effectively utilizing the SC-PTM transmission resources.

[0190] (Other embodiments) In the embodiments described above, an example of applying a logged MDT as the MDT was mainly explained, but an immediate MDT may also be applied.

[0191] Furthermore, although the above-described embodiments mainly focused on 5G systems (NR), the operation according to the embodiments may also be applied to LTE.

[0192] A program may be provided that causes a computer to perform each of the processes that UE100 or gNB200 performs. The program may be recorded on a computer-readable medium. Using a computer-readable medium, it is possible to install the program on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, but may be a recording medium such as a CD-ROM or DVD-ROM.

[0193] Alternatively, the circuits that perform each process carried out by the UE100 or gNB200 may be integrated, and at least a portion of the UE100 or gNB200 may be configured as a semiconductor integrated circuit (chipset, SoC).

[0194] Although one embodiment has been described in detail above with reference to the drawings, the specific configuration is not limited to that described above, and various design changes can be made without departing from the gist of the invention.

[0195] This application claims priority to U.S. Provisional Application No. 62 / 884275 (filed August 8, 2019), the entirety of which is incorporated into the specification of this application.

Claims

1. A communication control method, The user device transmits to the network success information stored when the user device successfully receives a predetermined service from a predetermined cell. The aforementioned success information is, The identifier of the predetermined cell, The identifier of the user device provided from the predetermined cell, Includes information indicating the number of times an attempt was made to receive the aforementioned predetermined service. Communication control method.

2. A communication control method, The network device has the ability to receive from the user device success information stored when the user device successfully receives a predetermined service from a predetermined cell. The aforementioned success information is, The identifier of the predetermined cell, The identifier of the user device provided from the predetermined cell, Includes information indicating the number of times an attempt was made to receive the aforementioned predetermined service. Communication control method.

3. Network device, The system includes a receiving unit that receives success information stored when the user device successfully receives a predetermined service from a predetermined cell, The aforementioned success information is, The identifier of the predetermined cell, The identifier of the user device provided from the predetermined cell, Includes information indicating the number of times an attempt was made to receive the aforementioned predetermined service. Network device.

4. User device, It includes a transmission unit that transmits stored success information when it successfully receives a predetermined service from a predetermined cell, The aforementioned success information is, The identifier of the predetermined cell, The identifier of the user device provided from the predetermined cell, Includes information indicating the number of times an attempt was made to receive the aforementioned predetermined service. User device.

5. A chipset for controlling a network device, The system receives the success information stored when the user device successfully receives a predetermined service from a predetermined cell from the user device. The aforementioned success information is, The identifier of the predetermined cell, The identifier of the user device provided from the predetermined cell, Includes information indicating the number of times an attempt was made to receive the aforementioned predetermined service. Chipset.

6. A chipset for controlling a user device, The user device transmits the stored success information to the network when it successfully receives a predetermined service from a predetermined cell. The aforementioned success information is, The identifier of the predetermined cell, The identifier of the user device provided from the predetermined cell, Includes information indicating the number of times an attempt was made to receive the aforementioned predetermined service. Chipset.

7. A communication system including network equipment and user equipment, The user device transmits the stored success information to the network device when it successfully receives a predetermined service from a predetermined cell. The network device receives the success information from the user device. The aforementioned success information is, The identifier of the predetermined cell, The identifier of the user device provided from the predetermined cell, Includes information indicating the number of times an attempt was made to receive the aforementioned predetermined service. Communication system.

8. A program that causes a network device to receive from a user device the success information stored when the user device successfully receives a predetermined service from a predetermined cell, The aforementioned success information is, The identifier of the predetermined cell, The identifier of the user device provided from the predetermined cell, Includes information indicating the number of times an attempt was made to receive the aforementioned predetermined service. program.

9. A program that causes a user device to transmit stored success information to a network device when the user device successfully receives a predetermined service from a predetermined cell, The aforementioned success information is, The identifier of the predetermined cell, The identifier of the user device provided from the predetermined cell, Includes information indicating the number of times an attempt was made to receive the aforementioned predetermined service. program.

Images