Communication control method

Abstract

A communication control method in a mobile communication system, comprising: step A, a first radio communication device transmits information on whether to perform early data transmission to a second radio communication device, the early data transmission using a predetermined message to transmit data during a random access procedure; and step B, after the second radio communication device receives the information, the second radio communication device determines whether to perform early data transmission based on the received information. The first radio communication device is one of a radio terminal and a base station, and the second radio communication device is the other of the radio terminal and the base station. Step A is performed before the transmission timing of the predetermined message.

Description

[0001] This application is a divisional application of the Chinese invention patent application "Communication Control Method" with application date of August 6, 2018 and application number 201880051638.4. Technical Field

[0002] The invention relates to a communication control method in a mobile communication system. Background Art

[0003] In recent years, radio terminals that can communicate without human intervention, targeting machine type communication (MTC) and Internet of Things (IoT) services, have attracted much attention. Such radio terminals are required to achieve cost reduction, extended coverage, and low power consumption. Therefore, in the Third Generation Partnership Project (3GPP), a class of new radio terminals is specified, and the transmission / reception bandwidth of such new radio terminals is limited to only a portion of the system transmission / reception bandwidth. Summary of the invention

[0004] A communication control method according to an embodiment is a method in a mobile communication system. The communication control method comprises the following steps: a base station transmits a system information block (SIB), the SIB indicating an allowed data amount allowed to be transmitted in early data transmission, the early data transmission using message 3 to transmit uplink user data during a random access procedure; a radio terminal in RRC idle mode receives the SIB; and the radio terminal determines to perform early data transmission when the amount of data transmitted to the base station is less than or equal to the allowed data amount indicated by the SIB.

[0005] The communication control method may further include the following steps: after determining to perform early data transmission, the radio terminal selects a PRACH resource for transmitting a random access preamble from the PRACH resources used for early data transmission; and the radio terminal transmits the random access preamble to the base station using the selected PRACH resource.

[0006] In the communication control method, a PRACH resource for early data transmission is set for each extended coverage level, and the step of selecting may include the step of selecting a PRACH resource corresponding to the extended coverage level applied to the radio terminal.

[0007] The communication control method may further include the step of: the base station transmitting a random access response including an uplink grant to the radio terminal in response to receiving the random access preamble, wherein the random access response may include information indicating whether the uplink grant is for early data transmission.

[0008] The communication control method may further include the steps of: the radio terminal receiving a random access response from the base station; and the radio terminal terminating the early data transmission when an uplink grant included in the random access response is not for the early data transmission.

[0009] A communication control method according to an embodiment is a communication control method for controlling early data transmission during a random access procedure that performs uplink user data transmission from a base station to a radio terminal. The communication control method includes: step A, the base station transmits to the radio terminal a first timer value for a random access procedure that does not perform early data transmission and a second timer value for a random access procedure that performs early data transmission; step B, the radio terminal selects the second timer value in response to determining that the radio terminal performs early data transmission; step C, the radio terminal starts a timer that sets the second timer value when transmitting uplink data through early data transmission.

[0010] A communication control method according to an embodiment is a communication control method for controlling early data transmission for performing downlink user data transmission from a base station to a radio terminal during a random access procedure. The communication control method includes a step A in which the base station transmits information about a data amount condition in early data transmission to the radio terminal; a step B in which the radio terminal receives information about the data amount condition from the base station; a step C in which the radio terminal estimates an amount of downlink user data to be received from the base station in early data transmission; and a step D in which the radio terminal starts early data transmission when the estimated amount of downlink user data satisfies the data amount condition.

[0011] A communication control method according to an embodiment is a communication control method for controlling early data transmission, wherein during a random access procedure, the amount of user data transmitted or received by a radio terminal is less than or equal to the maximum amount of user data set from a base station. The communication control method comprises the following steps: step A, the radio terminal determines the maximum amount of user data recommended by the radio terminal; and step B, the radio terminal in RRC connection mode transmits information indicating the maximum amount of user data recommended by the radio terminal to the base station. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 is a diagram showing a configuration of an LTE system (mobile communication system) according to an embodiment.

[0013] Figure 2 is a diagram showing a configuration of a UE (Radio Terminal) according to the embodiment.

[0014] Figure 3 is a diagram showing a configuration of an eNB (base station) according to an embodiment.

[0015] Figure 4 is a diagram showing a protocol stack of a radio interface in an LTE system according to an embodiment.

[0016] Figure 5 is a diagram showing a configuration of a radio frame in an LTE system according to an embodiment.

[0017] Figure 6 is a diagram showing frequency bands handled by eMTC UE and NB-IoT UE.

[0018] Figure 7 is a diagram showing a random access procedure for eMTC UE and NB-IoT UE.

[0019] Figure 8 is a diagram showing operation mode 1 according to the first embodiment.

[0020] Fig. 9 is a diagram showing operation mode 2 according to the first embodiment.

[0021] Fig.10 is a diagram showing operation mode 3 according to the first embodiment.

[0022] Fig.11 is a diagram showing operation mode 4 according to the first embodiment.

[0023] Fig.12 It is shown Fig.11 FIG. 1 is a diagram of an example of a modification of a sequence of FIG.

[0024] Fig.13 is a diagram showing a modification example 1 of the first embodiment.

[0025] Fig.14 is a diagram showing a configuration example of PRACH resources according to Modification Example 1 of the first embodiment.

[0026] Fig.15 is a diagram showing a modification example 2 of the first embodiment.

[0027] Fig.16 is a diagram showing an example of a MAC PDU according to Modification Example 8 of the first embodiment.

[0028] Fig.17 : is a diagram showing an example of the operation of Modification Example 14 of the first embodiment.

[0029] Fig.18 is a diagram showing another example of the operation of Modification Example 14 of the first embodiment.

[0030] Fig.19 : is a diagram showing an example of the operation of Modification Example 15 of the first embodiment.

[0031] Fig. 20 : is a diagram showing an example of the operation of Modification Example 17 of the first embodiment.

[0032] Fig.21 : is a diagram showing an example of the operation of Modification Example 18 of the first embodiment.

[0033] Fig. 22 is a diagram showing an example of operation mode 1 of the second embodiment.

[0034] Fig.23 is a diagram showing an example of operation mode 2 of the second embodiment.

[0035] Fig.24 is a diagram showing an example of operation mode 3 of the second embodiment.

[0036] Fig.25 This is a figure related to supplementary explanation.

[0037] Fig.26 This is a figure related to supplementary explanation.

[0038] Fig. 27 This is a figure related to supplementary explanation.

[0039] Fig.28 This is a figure related to supplementary explanation.

[0040] Fig.29 This is a figure related to supplementary explanation.

[0041] Fig.30 This is a figure related to supplementary explanation.

[0042] Fig.31 This is a figure related to supplementary explanation.

[0043] Fig.32 This is a figure related to supplementary explanation. DETAILED DESCRIPTION

[0044] [First embodiment]

[0045] (Overview of First Embodiment)

[0046] Compared with ordinary radio terminals, radio terminals for MTC or IoT have a smaller amount of data to be transmitted and received, and the frequency of data transmission and reception is also smaller. Therefore, in order to enable radio terminals for MTC or IoT to communicate efficiently, early data transmission (early data transmission) that uses a predetermined message to transmit data during a random access procedure has been studied. However, current mobile communication systems do not assume that data is transmitted during a random access procedure, and there is no mechanism that can achieve early data transmission.

[0047] Therefore, an object of the present invention is to provide a communication control method that can realize early data transmission.

[0048] The communication control method according to the first embodiment is a method in a mobile communication system. The communication control method includes the following steps: (A) transmitting information about whether to perform early data transmission, which uses a predetermined message to transmit data during a random access process, from a first radio communication device to a second radio communication device; and (B) after the second radio communication device receives the information, the second radio communication device determines whether to perform early data transmission based on the received information. The first radio communication device is one of a radio terminal and a base station, and the second radio communication device is the other of the radio terminal and the base station. Step A is performed before the transmission timing of the predetermined message.

[0049] (Mobile Communication System)

[0050] Next, the configuration of the mobile communication system according to the first embodiment will be described. Figure 1 1 is a diagram showing a configuration of a Long Term Evolution (LTE) system as a mobile communication system according to a first embodiment. The LTE system is a mobile communication system based on the 3GPP standard.

[0051] The LTE system includes a radio terminal (UE: User Equipment) 100 , a radio access network (E-UTRAN: Evolved UMTS Terrestrial Radio Access Network) 10 , and a core network (EPC: Evolved Packet Core) 20 .

[0052] UE 100 is a mobile communication device and performs radio communication with eNB 200 that manages a cell (serving cell) in which UE 100 is located.

[0053] The E-UTRAN 10 includes a base station (eNB: Evolved Node B) 200. The eNBs 200 are connected to each other via an X2 interface. The eNBs 200 manage one or more cells. The eNBs 200 perform radio communication with the UEs 100, which establish a connection with the cell of the eNBs 200. The eNBs 200 have a radio resource management (RRM) function, a routing function of user data (hereinafter sometimes referred to as "data"), a measurement control function for mobility control and scheduling, and the like. "Cell" is used as a term indicating the minimum unit of a radio communication area. "Cell" may also be used as a term indicating a function or resource for performing radio communication with the UEs 100. One cell belongs to one carrier frequency.

[0054] The EPC 20 includes a mobility management entity (MME) and a serving gateway (S-GW) 300. The MME performs various mobility controls and the like for the UE 100. The MME manages information about a tracking area (TA) in which the UE is located by communicating with the UE 100 using a non-access stratum (NAS) signaling. A tracking area is an area consisting of a plurality of cells. The S-GW performs data transmission control. The MME and the S-GW are connected to the eNB 200 via an S1 interface.

[0055] Figure 2 UE 100 (radio terminal) is a diagram showing a configuration of UE 100. UE 100 includes a receiver 110, a transmitter 120, and a controller 130.

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

[0057] The transmitter 120 performs various transmissions under the control of the controller 130. The transmitter 120 includes an antenna and a transmission device. The transmission device converts a baseband signal (transmission signal) output from the controller 130 into a radio signal and transmits the radio signal from the antenna.

[0058] The controller 130 performs various controls in the UE 100. The controller 130 includes at least one processor and a memory. The memory stores programs executed by the processor and information for processing performed by the processor. The processor may include a baseband processor and a central processing unit (CPU). The baseband processor performs modulation / demodulation, encoding / decoding, etc. of a baseband signal. The CPU performs various processing by executing programs stored in the memory. The processor performs processing to be described later.

[0059] Figure 3 2 is a diagram showing a configuration of an eNB 200 (base station). The eNB 200 includes a transmitter 210, a receiver 220, a controller 230, and a backhaul communicator 240.

[0060] The transmitter 210 performs various transmissions under the control of the controller 230. The transmitter 210 includes an antenna and a transmission device. The transmission device converts a baseband signal (transmission signal) output from the controller 230 into a radio signal and transmits the radio signal from the antenna.

[0061] The receiver 220 performs various receptions under the control of the controller 230. The receiver 220 includes an antenna and a receiving device. The receiving device converts a radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal to the controller 230.

[0062] The controller 230 performs various controls in the eNB 200. The controller 230 includes at least one processor and a memory. The memory stores a program executed by the processor and information for the processing performed by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation, encoding / decoding, etc. of a baseband signal. The CPU performs various processing by executing a program stored in the memory. The processor performs processing to be described later.

[0063] The backhaul communicator 240 is connected to the neighboring eNB via an X2 interface. The backhaul communicator 240 is connected to the MME / S-GW 300 via an S1 interface. The backhaul communicator 240 is used for communication performed on the X2 interface, communication performed on the S1 interface, and the like.

[0064] Figure 4 1 is a diagram showing the configuration of a protocol stack of a radio interface in an LTE system. Figure 4 As shown in , the radio interface protocol is divided into the first layer to the third layer of the OSI reference model. The first layer is the physical (PHY) layer. The second layer includes the media access control (MAC) layer, the radio link control (RLC) layer and the packet data convergence protocol (PDCP) layer. The third layer includes the radio resource control (RRC) layer. The PHY layer, the MAC layer, the RLC layer, the PDCP layer and the RRC layer constitute the access (AS) layer.

[0065] The PHY layer performs encoding / decoding, modulation / demodulation, antenna mapping / demapping, and resource mapping / demapping. Data and control information are transmitted between the PHY layer of the UE 100 and the PHY layer of the eNB 200 via a physical channel.

[0066] The MAC layer performs priority control of data, retransmission processing by hybrid ARQ (HARQ), a random access procedure, etc. 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. The scheduler determines the transmission format (transmission block size, modulation and coding scheme (MCS)) of the uplink and downlink and the resource blocks allocated to the UE 100.

[0067] The RLC layer transmits data to the RLC layer of the receiving side using functions of the MAC layer and the PHY layer. Data and control information are transmitted between the RLC layer of the UE 100 and the RLC layer of the eNB 200 via a logical channel.

[0068] The PDCP layer performs header compression / expansion and encryption / decryption.

[0069] The RRC layer is defined only in the control plane that processes control information. RRC signaling for various configurations is transmitted between the RRC layer of the UE 100 and the RRC layer of the eNB 200. The RRC layer controls logical channels, transport channels, and physical channels in response to establishing, reestablishing, and releasing radio bearers. When there is a connection (RRC connection) between the RRC of the UE 100 and the RRC of the eNB 200, the UE 100 is in the RRC connection mode. When there is no connection (RRC connection) between the RRC of the UE 100 and the RRC of the eNB 200, the UE 100 is in the RRC idle mode.

[0070] The NAS layer located above the RRC layer performs session management, mobility management, etc. NAS signaling is transmitted between the NAS layer of the UE 100 and the NAS layer of the MME 300C. The UE 100 has functions such as an application layer in addition to a radio interface protocol.

[0071] Figure 5 1 is a diagram showing the configuration of a radio frame used in an LTE system. A radio frame consists of 10 subframes on the time axis. Each subframe consists of two time slots on the time axis. The length of each subframe is 1 ms. The length of each time slot is 0.5 ms. Each subframe includes a plurality of resource blocks (RBs) on the frequency axis. Each subframe includes a plurality of symbols on the time axis. Each resource block includes a plurality of subcarriers on the frequency axis. Specifically, 1 RB consists of 12 subcarriers and 1 time slot. A resource element (RE) consists of a symbol and a subcarrier. In the radio resources (time / frequency resources) allocated to UE 100, frequency resources can be specified by resource blocks, and time resources can be specified by subframes (or time slots).

[0072] In the downlink, a portion of the first few symbols of each subframe is a region that can be used as a physical downlink control channel (PDCCH) that mainly transmits downlink control information. The rest of each subframe is a region that can be used as a physical downlink shared channel (PDSCH) for transmitting downlink data.

[0073] In the uplink, the two ends of each subframe in the frequency direction are areas that can be used as a physical uplink control channel (PUCCH) that mainly transmits uplink control information. The rest of each subframe is an area that can be used as a physical uplink shared channel (PUSCH) that mainly transmits uplink data.

[0074] (Overview of eMTC and NB-IoT)

[0075] An overview of eMTC and NB-IoT will be described. In the first embodiment, it is assumed that there is a situation in which a new category of UE 100 for MTC and IoT services exists. The new category of UE 100 is a UE 100 whose transmission / reception bandwidth is limited to only a portion of the system transmission / reception bandwidth (LTE transmission / reception bandwidth). The new category of UE is referred to as, for example, category M1 and category narrowband (NB)-IoT. Category M1 is a category to which enhanced machine type communication (eMTC) UE belongs. Category NB-IoT (category NB1) is a category to which NB-IoT UE belongs. Category M1 limits the transmission / reception bandwidth of UE 100 (eMTC UE) to, for example, 1.08MHz (i.e., a bandwidth of 6 resource blocks). Category NB-IoT (category NB1) further limits the transmission / reception bandwidth of UE 100 (NB-IoT UE) to 180kHz (i.e., a bandwidth of one resource block). By reducing the bandwidth, the cost reduction and power consumption required for eMTC UE and NB-IoT UE can be achieved.

[0076] Figure 6 is a diagram showing frequency bands handled by eMTC UE and NB-IoT UE. Figure 6 As shown in , the bandwidth of the system frequency band of the LTE system can be 10MHz. The system transmission / reception bandwidth is, for example, 50 resource blocks = 9MHz. The bandwidth of the frequency band available to the eMTC UE is within 6 resource blocks = 1.08MHz. The frequency band within 6 resource blocks available to the eMTC UE is called "narrowband (NB)". The frequency band bandwidth available to the NB-IoT UE is 1 resource block = 180kHz. The frequency band of 1 resource block available to the NB-IoT UE is called a "carrier".

[0077] eMTC UE operates within the LTE transmission / reception bandwidth. NB-IoT UE supports the form of operating within the LTE transmission / reception bandwidth, the form of operating in the protection band outside the LTE transmission / reception bandwidth, and the form of operating in the NB-IoT dedicated frequency band.

[0078] In order to achieve coverage extension, eMTC UE and NB-IoT UE support enhanced coverage (EC) functions using repeated transmission, etc. The enhanced coverage function may include repeated transmission of the same signal using multiple subframes. The coverage can be expanded as the number of repetitions increases. The enhanced coverage function may include power boosting, which increases the power density of the transmission signal. For example, the power density is increased by narrowband transmission that narrows the frequency bandwidth of the transmission signal. As the power density of the transmission signal increases, the coverage can be extended. The enhanced coverage function may include lower MCS (lower MCS) transmission, which reduces the MCS used for transmitting the signal. The coverage can be extended by transmitting using an MCS with a low data rate and high fault tolerance.

[0079] (Overview of Random Access Process)

[0080] Figure 7 is a diagram showing a random access procedure for eMTC UE and NB-IoT UE. In the initial state, UE 100 is in RRC idle mode. UE 100 performs a random access procedure to convert to RRC connected mode. This situation is called initial connection (initial access from RRC_IDLE). At the time of initial connection, a contention-based random access procedure will be applied.

[0081] UE 100 selects the cell of eNB 200 as the serving cell. If the first cell selection criterion for normal coverage (first S criterion) is not satisfied and the second cell selection criterion for enhanced coverage (second S criterion) is satisfied, UE 100 may determine that UE 100 is in enhanced coverage. "UE is in enhanced coverage" means that the UE needs to use the enhanced coverage function (enhanced coverage mode) in order to access the cell. Note that the eMTC UE must use the enhanced coverage mode. Here, the description will be made under the assumption that UE 100 is in enhanced coverage.

[0082] In step S1001, the eNB 200 transmits information related to the physical random access channel (PRACH) through broadcast signaling (e.g., SIB). The information related to the PRACH includes various parameters provided for each enhanced coverage level. For example, for the enhanced coverage level, a total of four levels of enhanced coverage levels 0 to 3 are defined. The various parameters include a reference signal received power (RSRP) threshold, PRACH resources, and the maximum number of preamble transmissions. PRACH resources include radio resources (time / frequency resources) and signal sequences (preamble sequences). The UE 100 stores the received information related to the PRACH.

[0083] In step S1002 , UE 100 measures RSRP based on a reference signal transmitted from eNB 200 .

[0084] In step S1003, the UE 100 determines its own enhanced coverage level (CE level) by comparing the measured RSRP with the RSRP threshold for each enhanced coverage level. The enhanced coverage level indicates the degree of enhanced coverage required by the UE 100. The enhanced coverage level is at least related to the number of transmissions in repeated transmissions (i.e., the number of repetitions).

[0085] In step S1004, UE 100 selects a PRACH resource corresponding to its own enhanced coverage level.

[0086] Steps S1005 to S1008 constitute a random access procedure. In step S1005, UE 100 transmits Msg1 (random access preamble) to eNB 200 using the selected PRACH resource. Note that "Msg" is an abbreviation for message. eNB 200 specifies the enhanced coverage level of UE 100 based on the PRACH resource used for the received Msg1.

[0087] In step S1006, the eNB 200 transmits Msg2 (random access response) to the UE 100, the Msg2 including scheduling information indicating the PUSCH resources allocated to the UE 100. The UE 100 may transmit Msg1 multiple times until the UE 100 receives Msg2 normally, and the number of transmissions of Msg1 is at most the maximum number of preamble transmissions corresponding to the enhanced coverage level of the UE 100 itself.

[0088] In step S1007, UE 100 transmits Msg3 to eNB 200 based on the scheduling information. Msg3 may be an RRC connection request message.

[0089] In step S1008, the eNB 200 transmits Msg4 to the UE 100. Msg4 may be an RRC connection establishment message.

[0090] In step S1009, UE 100 switches to RRC connection mode in response to receiving Msg4. At this time, UE 100 may transmit Msg5: RRC connection establishment complete message to eNB 200. Thereafter, eNB 200 controls repeated transmissions to UE 100 based on the specified enhanced coverage level.

[0091] (Operations related to early data transfer)

[0092] The operation related to early data transmission according to the first embodiment will be described.

[0093] Early data transmission is a transmission method for transmitting data (user data) using a predetermined message during a random access procedure. The predetermined message is at least one of Msg1 (random access preamble), Msg2 (random access response), Msg3 (e.g., RRC connection request message), Msg4 (RRC connection establishment message), and Msg5 (RRC connection establishment complete message). Note that "transmitting data using a predetermined message" is at least one of transmitting data by including the data in a predetermined message, transmitting data by adding the data to the predetermined message, and transmitting data by associating the data with the predetermined message.

[0094] Early data transmission can be applied to a UE in an RRC suspended state. The RRC suspended state is a state of the RRC idle mode and is a special state in which the UE context is saved in the network. In the random access procedure for restoring the UE in the RRC suspended state to the RRC connected mode, Msg3 is an RRC connection recovery request message, Msg4 is an RRC connection recovery message, and Msg5 is an RRC connection recovery complete message.

[0095] The communication control method according to the first embodiment includes the following steps: (A) transmitting, by a first radio communication device, to a second radio communication device, information on whether to perform early data transmission, which uses a predetermined message to transmit data during a random access procedure; and (B) after the second radio communication device receives the information, determining, by the second radio communication device, whether to perform early data transmission based on the received information. The first radio communication device is one of UE100 and eNB200, and the second radio communication device is the other of UE100 and eNB200. Step A is performed before the transmission timing of the predetermined message.

[0096] The overview of operation modes 1 to 4 according to the first embodiment will be described. Operation modes 1 to 4 can be combined with the above-mentioned "Overview of random access procedure" (see Figure 7 ) in at least a portion of the operations in .

[0097] In operation mode 1 according to the first embodiment, step A includes the following steps: UE 100 selects resources to be applied to random access preamble transmission based on whether early data transmission is performed; and the random access preamble to which the selected resources are applied is transmitted by UE 100. In step B, eNB 200 determines whether to perform early data transmission based on the resources applied to the random access preamble.

[0098] In the operation mode 2 according to the first embodiment, in step A, when the UE 100 is in the connected mode, the UE 100 transmits a notification indicating the execution of early data transmission to the eNB 200. The operation mode 2 further includes the steps of: after the transmission of the notification, switching the UE 100 from the connected mode to the idle mode, and retaining the notification by the eNB 200 or a higher-level network device when the UE 100 is in the idle mode. In step B, during the random access procedure, the eNB 200 determines whether to perform early data transmission based on the retained notification.

[0099] In operation mode 3 according to the first embodiment, in step A, before starting the random access procedure, the eNB 200 transmits a notification indicating whether to perform early data transmission to the UE 100 through at least one of a paging message, downlink control information (DCI) and / or a physical downlink shared channel (PDSCH). In step B, the UE 100 determines whether to perform early data transmission based on the notification from the eNB 200.

[0100] In operation mode 4 according to the first embodiment, in step A, before starting the random access procedure, the eNB 200 transmits information indicating the amount of data allowed to be transmitted through early data transmission to the UE 100. In step B, the UE 100 determines whether to perform early data transmission based on the amount of data notified from the eNB 200 and the amount of data transmitted from the UE 100 to the eNB 200.

[0101] (1) Operation mode 1

[0102] Figure 8 1 is a diagram showing operation mode 1 according to the first embodiment. The difference from the operation in the above-mentioned "Overview of Random Access Procedure" will be mainly described.

[0103] like Figure 8 As shown in, in step S101, the eNB 200 transmits (broadcasts) PRACH resource information indicating PRACH resources (PRACH resource pool) through system information (SIB), and the PRACH resources are resources that can be used for random access preamble transmission. PRACH resources include radio resources (time / frequency resources) and / or signal sequences (preamble sequences).

[0104] The PRACH resources include: a first resource group (PRACH resource pool) indicating that early data transmission is performed (indication of performing early data transmission) and a second resource group (PRACH resource pool) indicating that early data transmission is not performed. The PRACH resources divided into the first resource group and the second resource group may be radio resources (time / frequency resources). The PRACH resources divided into the first resource group and the second resource group may be signal sequences (preamble sequences).

[0105] The eNB 200 includes information indicating the first resource group and information indicating the second resource group in the SIB. The second resource group may be a PRACH resource similar to a regular resource. The first resource group may be a PRACH resource secured separately from a regular PRACH resource.

[0106] The first resource group may include: a first resource subgroup indicating that uplink data is transmitted through early data transmission; and a second resource subgroup indicating that downlink data is received through early data transmission. In addition, the first resource group may include a third resource subgroup indicating that both transmission of uplink data and reception of downlink data are performed through early data transmission. The eNB 200 may include information indicating at least one of the plurality of resource subgroups (the first resource subgroup, the second resource subgroup, and the third resource subgroup) in the SIB.

[0107] The UE 100 in the RRC idle mode receives the SIB from the eNB 200. The UE 100 in the RRC idle mode determines that an RRC connection needs to be established, and starts preparing for a random access procedure. Here, the UE 100 may determine that an RRC connection needs to be established in order to transmit uplink data in response to generation of uplink data in the UE 100. The UE 100 may determine that an RRC connection needs to be established in order to receive downlink data in response to receiving a paging message addressed to the UE 100 from the eNB 200.

[0108] In step S102, the UE 100 in the RRC idle mode selects resources to be applied to the random access preamble transmission from the PRACH resources notified by the SIB. When performing early data transmission, the UE 100 selects resources in the first resource group. On the other hand, when not performing early data transmission, the UE 100 selects resources in the second resource group. Whether to perform early data transmission is based on at least one of the following criteria 1) to 7). 1) The capability of the UE 100, that is, whether the UE 100 has the ability to perform early data transmission. 2) The priority (e.g., QoS) of the data transmitted or received by the UE 100. 3) The power state of the UE 100 (e.g., the remaining battery power). 4) Whether to reduce data delay (e.g., the necessity of early TCP ACK transmission). 5) User preference (e.g., depending on manual setting). 6) Instructions from the network (e.g., based on functional restrictions or authentication results made by the MME, etc.). 7) Instructions from the eNB (e.g., based on whether the eNB has early data transmission / reception capabilities). Note that "perform early data transmission" may mean whether the UE 100 intends to perform early data transmission, whether early data transmission is allowed, or whether early data transmission is possible.

[0109] The UE 100 may determine whether to perform early data transmission for uplink and downlink, respectively. When transmitting uplink data through early data transmission, the UE 100 may select resources in the first resource subgroup. When receiving downlink data through early data transmission, the UE 100 may select resources in the second resource subgroup.

[0110] In step S103, UE 100 transmits Msg1 (random access preamble) to which the resource selected in step S102 is applied.

[0111] In step S104, the eNB 200 determines whether to perform early data transmission based on the resources applied to the received random access preamble. For example, when the resources in the first resource group are applied to the random access preamble, the eNB 200 determines to perform early data transmission for the UE 100 as the transmission source. In addition, the eNB 200 may determine whether to perform uplink early data transmission or downlink early data transmission based on the resource subgroup. On the other hand, when the resources in the second resource group are applied to the random access preamble, the eNB 200 determines not to perform early data transmission for the UE 100 as the transmission source.

[0112] Note that in operation mode 1, the case of dividing the time / frequency resources and the case of dividing the signal sequence resources have been described, but the time / frequency resources and the signal sequence resources may be divided in combination. For example, the time / frequency resources may be divided into a first resource group and a second resource group, and in the first resource group, the signal sequence resources may be divided into resource subgroups. Alternatively, the signal sequence resources may be divided into a first resource group and a second resource group, and in the first resource group, the time / frequency resources may be divided into resource subgroups.

[0113] In addition, as described later, uplink early data transmission can be used together with downlink early data transmission. For example, UE 100 transmits uplink data in Msg3 through uplink early data transmission, and receives response data (TCP ACK, etc.) corresponding to the data in Msg4 through downlink early data transmission. Therefore, the conditions that enable Msg1 to notify the early data transmission indication include the condition "UE 100 has the capability of uplink early data transmission and downlink early data transmission". That is, UE 100 that does not have at least one of the capabilities of uplink early data transmission and downlink early data transmission can be prohibited from notifying the early data transmission indication through Msg1.

[0114] In addition, the new PRACH resource pool (time / frequency resource) used to notify the early data transmission indication may preferably be defined as a resource pool separate from the conventional PRACH resource pool (time / frequency resource). In this case, the eNB 200 determines whether to set the new PRACH resource pool and the conventional PRACH resource pool to be non-overlapping, or whether to set the new PRACH resource pool and the conventional PRACH resource pool to be at least partially overlapping, and the eNB 200 may notify the UE 100 (e.g., through SIB notification) of each PRACH resource pool.

[0115] (2) Operation Mode 2

[0116] Fig. 9 2 is a diagram showing operation mode 2 according to the first embodiment. The difference from the operation in the above-mentioned "Overview of Random Access Procedure" will be mainly described. In addition, the description repeated with operation mode 1 will be omitted. Operation mode 2 can be applied to uplink early data transmission, or can be applied to downlink early data transmission.

[0117] like Fig. 9As shown in , in step S201, the UE 100 in the RRC connection mode transmits a notification indicating the execution of early data transmission to the eNB 200. For example, the UE 100 notifies the eNB 200 that the early data transmission is to be performed when the next RRC connection is established. The UE 100 stores the content (notification information) notified to the eNB 200. The notification indicating the execution of uplink early data transmission and the notification indicating the execution of downlink early data transmission may be defined separately. The notification may include capability information (about the capability of early data transmission) of the UE 100. The eNB 200 stores the notification from the UE 100. The eNB 200 may transmit the notification to a higher-level device (e.g., the MME 300).

[0118] In step S202, the eNB 200 transmits an RRC connection release message to the UE 100. The RRC connection release message may include information indicating that the UE 100 is set to the RRC suspend state. In addition, the RRC connection release message may include information indicating that the UE 100 can perform (or needs to perform) early data transmission. The RRC connection release message may include information indicating that the UE 100 does not perform early data transmission.

[0119] In step S203, UE 100 releases the RRC connection in response to the RRC connection release message and switches from the RRC connection mode to the RRC idle mode. UE 100 may be in the RRC suspend state. When UE 100 is in the idle mode, UE 100 retains the notification information.

[0120] In step S204, when the UE 100 is in idle mode, the eNB 200 retains the notification information. In other words, the eNB 200 retains information indicating that early data transmission is performed when the next RRC connection is established for the UE 100. In addition to the eNB 200, or instead of the eNB 200, a higher-level device of the eNB 200 (e.g., the MME 300) may retain the notification information. The information retained by the eNB 200 and / or the MME 300 may include capability information of the UE 100 (regarding the capability of early data transmission). When the UE 100 determines not to perform early data transmission (when using a normal PRACH resource in Msg1), the UE 100 and the eNB 200 may cancel (discard) the notification information.

[0121] In step S205, UE 100 transmits Msg1 (Random Access Preamble) to eNB 200. Although described later, UE 100 may transmit the Random Access Preamble by applying a dedicated preamble sequence (Dedicated Preamble) allocated to each UE from eNB 200. eNB 200 receives the Random Access Preamble from UE 100.

[0122] The eNB 200 may receive a paging message addressed to the UE 100 in idle mode from a higher-level device (e.g., the MME 300). The paging message may include a combination of an identifier of the destination UE and notification information stored by the higher-level device. The eNB 200 may use the information included in the paging message to determine whether to perform early data transmission for the UE 100.

[0123] When the dedicated preamble sequence is applied, in step S206, the eNB 200 identifies the UE 100 based on the preamble sequence. The eNB 200 determines whether to perform early data transmission based on the notification information saved in step S204. Specifically, if the notification information corresponding to the identified UE 100 is saved, the eNB 200 determines to perform early data transmission. On the other hand, if the notification information corresponding to the identified UE 100 is not saved, the eNB 200 determines not to perform early data transmission.

[0124] In step S207 , the eNB 200 transmits Msg2 (random access response) to the UE 100 .

[0125] In step S208 , UE 100 transmits Msg3 to eNB 200 .

[0126] When the dedicated preamble sequence is not applied, in step S209, the eNB 200 identifies the UE 100 based on Msg3. The eNB 200 determines whether to perform early data transmission based on the notification information saved in step S204.

[0127] (3) Operation method 3

[0128] Fig.10 : is a diagram showing operation mode 3 according to the first embodiment. The difference from the operation in the above-mentioned "Overview of Random Access Procedure" will be mainly described. In addition, the description repeated with operation modes 1 and 2 will be omitted. Operation mode 3 is applied to downlink early data transmission.

[0129] In operation mode 3, the UE 100 performing the random access procedure is in RRC idle mode or RRC connected mode. The UE 100 in RRC idle mode performs a contention-based random access procedure. On the other hand, the UE 100 in RRC connected mode can perform a non-contention-based random access procedure. In the non-contention-based random access procedure, a dedicated preamble sequence is allocated to each UE from the eNB 200 through downlink control information (DCI) or separate RRC signaling (dedicated signaling). The non-contention-based random access procedure is applied at the time of handover, uplink timing adjustment, etc.

[0130] like Fig.10 As shown in FIG. 1 , in step S301, the eNB 200 transmits a notification indicating whether to perform early data transmission to the UE 100 through at least one of a paging message, a DCI, and a PDSCH before starting a random access procedure.

[0131] When a paging message is used, a contention-based random access procedure may be applied. The eNB 200 transmits a paging message including a combination of an identifier of a destination UE and information indicating whether to perform early data transmission. Such a paging message may be generated by the MME 300 and transmitted from the MME 300 to the UE 100 via the eNB 200.

[0132] When using DCI or PDSCH, UE 100 may be in RRC connected mode. When using DCI or PDSCH, a non-contention based random access procedure may be applied. eNB 200 includes information indicating whether to perform early data transmission in DCI or PDSCH addressed to UE 100. At a paging occasion, i.e., at a timing when UE 100 performing a discontinuous reception (DRX) operation monitors PDCCH, eNB 200 may transmit DCI to UE 100, the DCI including information indicating whether to perform early data transmission.

[0133] When the predetermined message for early data transmission is Msg1 (random access preamble), the eNB 200 may notify the UE 100 of the PRACH resource for early data transmission when notifying the UE 100 whether to perform early data transmission. The notification is performed through at least one of a paging message, a DCI, and a PDSCH. The eNB 200 may pre-broadcast several PRACH resources (and a list including indexes of the PRACH resources) through the SIB. The eNB 200 may notify the index of the PRACH resource through at least one of a paging message, a DCI, and a PDSCH.

[0134] In step S302, the UE 100 determines whether to perform early data transmission based on the notification from the eNB 200 in step S301. The UE 100 may determine to perform early data transmission when notified to perform early data transmission. Alternatively, even when notified to perform early data transmission, the UE 100 may determine not to perform early data transmission. In this case, the UE 100 may notify the eNB 200 of not performing early data transmission through, for example, Msg1 (random access preamble) or Msg3 (e.g., RRC connection request message) during the random access procedure.

[0135] When the random access procedure starts, in step S303, UE 100 transmits Msg1 (random access preamble) to eNB 200. When performing early data transmission, eNB 200 transmits downlink data to UE 100 during the random access procedure, for example, through Msg2 (random access response) or Msg4 (eg, RRC connection establishment message).

[0136] Alternatively, the eNB 200 may notify the UE 100 of performing downlink early data transmission during the random access procedure. For example, the eNB 200 may transmit information indicating that downlink data is transmitted using Msg2 to the UE 100 through Msg4.

[0137] (4) Operation method 4

[0138] Fig.11 : is a diagram showing operation mode 4 according to the first embodiment. The difference from the operation in the above-mentioned "Overview of Random Access Procedure" will be mainly described. In addition, the description repeated with operation modes 1 to 3 will be omitted. Operation mode 4 is applied to uplink early data transmission.

[0139] like Fig.11 As shown in , in step S401, before starting the random access procedure, the eNB 200 transmits information indicating the amount of data allowed to be transmitted through early data transmission (allowed data amount) to the UE 100. The information indicating the allowed data amount of early data transmission may be a threshold indicating the allowed data amount. The eNB 200 may broadcast the information indicating the allowed data amount of early data transmission through the SIB. The eNB 200 may transmit the information indicating the allowed data amount of early data transmission to each UE through a unicast message (e.g., an RRC connection release message). The UE 100 receives the information indicating the allowed data amount of early data transmission. The UE 100 may be in an RRC idle mode.

[0140] The allowed data amount notified by the eNB 200 to the UE 100 may be only one, or may be multiple. When the allowed data amount is multiple, a list may be configured, which includes multiple combinations of the allowed data amount and its index. The eNB 200 may change the content (number of records) of the list based on the load status of the cell. Based on the list, the UE 100 may notify the eNB 200 of the index corresponding to the uplink data amount to be transmitted to the eNB 200 using Msg1, thereby indicating to the eNB 200 the amount of data to be transmitted through early data transmission.

[0141] In step S402, UE 100 determines whether to perform early data transmission based on the allowed data amount notified from eNB 200 and the amount of data transmitted from UE 100 to eNB 200. The amount of data transmitted to eNB 200 may be the amount of uplink data accumulated in an uplink buffer within UE 100.

[0142] The entity that makes such a determination may be the access stratum (AS) of the UE 100 or a higher layer of the UE 100. As described above, the access stratum (AS) is a layer including a PHY layer, a MAC layer, an RLC layer, a PDCP layer, and an RRC layer. The access stratum (AS) is a layer for wireless communication with the eNB 200. A higher layer is a layer including a NAS layer, an application layer, etc., and is located at a higher position than the access stratum. Data to be transmitted to the eNB 200 (i.e., uplink data) is generated in the higher layer.

[0143] When it is determined that the entity is the access stratum (AS) of the UE 100, the higher layer of the UE 100 may notify the access stratum (AS) of the UE 100 of the amount of data to be transmitted to the eNB 200 through uplink early data transmission. The amount of data transmitted to the eNB 200 may be the size of a data packet or the total amount of a plurality of data packets. The data packet may be a PDCP SDU (i.e., an IP packet) or a NAS PDU including a NAS header. For example, the access stratum (AS) of the UE 100 determines whether to perform early data transmission based on the allowed data amount notified from the eNB 200 through the SIB and the size of the data packet notified from the higher layer.

[0144] On the other hand, when it is determined that the entity is a higher layer of UE 100, the access layer notifies the higher layer of the allowed data amount notified from eNB 200. The higher layer determines whether to perform early data transmission based on the allowed data amount notified from the access layer and the size of the data packet to be transmitted to eNB 200.

[0145] When the amount of data to be transmitted to the eNB 200 is equal to or less than the allowed amount of data, the UE 100 may determine to perform early data transmission. In this case, when uplink data transmission is completed by early data transmission during the random access procedure, the UE 100 may end the random access procedure without transitioning to the RRC connected mode. This operation will be described in Modification Example 4 of the first embodiment.

[0146] When the amount of data to be transmitted to the eNB 200 exceeds the allowed amount of data, the UE 100 may determine to perform early data transmission. In this case, the UE 100 may transmit uplink data by early data transmission during the random access procedure, and may transmit the remaining uplink data to the eNB 200 after transitioning to the RRC connected mode.

[0147] When the random access procedure starts, UE 100 transmits Msg1 (random access preamble) to eNB 200 in step S403. When performing early data transmission, UE 100 transmits uplink data to eNB 200 through, for example, Msg1 (random access preamble) or Msg3 (eg, RRC connection request message) during the random access procedure.

[0148] The following examples have been described: Fig.11 In the sequence of , when the amount of data to be transmitted to the eNB 200 (i.e., uplink data) exceeds the allowed data amount, the UE 100 transmits the uplink data by early data transmission, and transmits the remaining uplink data to the eNB 200 after transitioning to the RRC connected mode. However, even if the amount of uplink data is slightly larger than the allowed data amount, since the UE 100 needs to transition to the RRC connected mode, it is inefficient and not preferable in terms of power consumption of the UE 100.

[0149] Therefore, when the amount of data to be transmitted to the eNB 200 is greater than the allowed data amount notified from the eNB 200 through the broadcast information (SIB), the UE 100 can transmit Msg3 multiple times. Each of the multiple transmissions of Msg3 contains data transmission. For example, the UE 100 transmits uplink data until the allowed data amount is reached in the first Msg3 transmission, and transmits the remaining uplink data in the second Msg3 transmission. Therefore, since the uplink data transmission can be completed by the early data transmission, the UE 100 does not have to switch to the RRC connection mode.

[0150] Fig.12 It is shown Fig.11 Here, the following mainly describes the modified example of the sequence of Fig.11 The difference in the sequence.

[0151] like Fig.12 As shown in , in step S411, the eNB 200 transmits broadcast information (SIB) indicating the amount of data allowed to be transmitted through early data transmission (allowed data amount) to the UE 100. The UE 100 determines whether to perform uplink early data transmission based on the allowed data amount notified from the eNB 200 and the amount of data (uplink data) transmitted from the UE 100 to the eNB 200. Here, although the uplink data amount is greater than the allowed data amount, the UE 100 determines that the uplink data transmission can be completed by transmitting Msg3 multiple times, and determines to perform uplink early data transmission.

[0152] When the random access procedure starts, the UE 100 transmits Msg1 (random access preamble) to the eNB 200 in step S412. The UE 100 can notify the eNB 200 of an indication to transmit data larger than the allowed data amount through the random access preamble. For example, the PRACH resources are divided in the same manner as in operation mode 1, and resources for indicating an indication to transmit data larger than the allowed data amount are defined in the PRACH resources. The UE 100 selects resources for indicating an indication to transmit data larger than the allowed data amount, and transmits the random access preamble using the selected resources. The eNB 200 identifies the resources used for preamble transmission, and learns that the UE 100 has an indication to transmit data larger than the allowed data amount.

[0153] In step S413, the eNB 200 transmits Msg2 (random access response) to the UE 100. The eNB 200 may transmit information for multiple transmissions of Msg3 to the UE 100 through Msg2. Such information may be configuration information and / or activation instructions for semi-persistent scheduling (SPS). For example, the eNB 200 transmits configuration information including an SPS period to the UE 100, the SPS period indicating the transmission period of the uplink. In addition, the eNB 200 transmits an uplink grant through Msg2, the uplink grant indicating the uplink resources (time / frequency resources) allocated to the UE 100. The configuration information of the SPS may be notified from the eNB 200 to the UE 100 in step S411. Alternatively, the configuration information of the SPS may be defined in the specification and may be pre-set in the UE 100.

[0154] In step S414, the UE 100 transmits Msg3 together with the data to the eNB 200 using the time / frequency resources indicated by the uplink grant. Here, the UE 100 may transmit uplink data up to the allowed data amount notified from the eNB 200 to the eNB 200. The UE 100 includes the uplink data in an RRC message (e.g., RRC connection request). Alternatively, the UE 100 does not include the uplink data in the RRC message, but multiplexes and transmits the uplink data (DTCH) and the RRC message (CCCH) in the MAC layer.

[0155] In step S415, when the time corresponding to the SPS period has passed from the time of step S414, the UE 100 performs the second Msg3 transmission. The UE 100 transmits the Msg3 together with the data to the eNB 200 using the time / frequency resources indicated by the uplink grant. Here, the Msg3 transmitted here may include uplink data, but not the RRC message.

[0156] UE 100 transmits Msg3 together with data to eNB 200 multiple times according to SPS setting until uplink data transmission is completed. UE 100 may transmit information indicating completion of uplink data transmission (e.g., end marker) in the last Msg3 transmission. UE 100 may use "BSR=0" to indicate completion of uplink data transmission. Details of "BSR=0" will be described in Modification Example 8. eNB 200 recognizes the last Msg3 transmission of UE 100.

[0157] In step S416, the eNB 200 transmits Msg4 to the UE 100. The eNB 200 may terminate the SPS transmission using Msg4. For example, the eNB 200 may transmit a 1-bit indicator indicating to stop the SPS transmission to the UE 100 via Msg4. The UE 100 stops the SPS transmission (and discards the SPS setting) in response to receiving the Msg4. The UE 100 may terminate the random access procedure without switching to the RRC connected mode.

[0158] The eNB 200 may explicitly notify the UE 100 through Msg4 that the random access procedure is terminated without switching to the RRC connection mode. In this case, the Msg4 transmission may include the transmission of an RRC connection release message or an RRC connection rejection message.

[0159] Alternatively, the eNB 200 may explicitly notify the UE 100 of switching to the RRC connection mode through Msg4. In this case, the Msg4 transmission may include the transmission of the RRC connection establishment message or the RRC connection recovery message.

[0160] exist Fig.12 In the sequence of , the following example has been described: an indication that data larger than the allowed data amount is to be transmitted is notified to the eNB 200 through the random access preamble, and the eNB 200 instructs the UE 100 to perform SPS transmission.

[0161] However, in response to receiving the random access preamble, the eNB 200 may transmit an uplink grant enabling transmission of data greater than the allowed data amount to the UE 100 through Msg2. When there is a sufficient amount of uplink resources upon receiving the random access preamble, the eNB 200 may transmit the uplink grant to the UE 100. When an uplink grant enabling transmission of data greater than the allowed data amount is received from the eNB 200, the UE 100 may complete uplink data transmission with one Msg3 transmission.

[0162] Alternatively, when there are not enough uplink resources upon receiving the random access preamble, the eNB 200 does not transmit a random access response (Msg2) to the random access preamble, or may notify the UE 100 of rejection in Msg4.

[0163] (Overview of First Embodiment)

[0164] The communication control method according to the first embodiment includes the following steps: (A) transmitting information on whether to perform early data transmission, which uses a predetermined message to transmit data during a random access procedure, to the second radio communication device by the first radio communication device; and (B) after the second radio communication device receives the information, determining whether to perform early data transmission based on the received information by the second radio communication device. The first radio communication device is one of UE100 and eNB200, and the second radio communication device is the other of UE100 and eNB200. Step A is performed before the transmission timing of the predetermined message. According to this communication control method, the second radio communication device can determine in advance whether to perform early data transmission before the transmission timing of the predetermined message (i.e., the timing that can be used for early data transmission) based on the information received from the first radio communication device. For example, the knowledge on whether to perform early data transmission can be matched between the first radio communication device and the second radio communication device (UE100 and eNB200). Therefore, early data transmission can be achieved.

[0165] (Modified Example 1)

[0166] Fig.13 is a diagram showing Modification Example 1 of the first embodiment. In Modification Example 1 of the first embodiment, UE 100 notifies eNB 200 of the amount of data (uplink data) to be transmitted by early data transmission through a random access preamble. Differences from the operation in the first embodiment will be mainly described.

[0167] like Fig.13 As shown in FIG. 5 , in step S501, the eNB 200 broadcasts at least one of the following information through the SIB: information indicating the correspondence between the data amount and the PRACH resources (eg, the preamble sequence) and information indicating the minimum guaranteed resource amount for early data transmission. A paging message may be used instead of the SIB.

[0168] In step S502, the UE 100 may also select resources to be applied to the random access preamble transmission based on the amount of data (uplink data) transmitted through the early data transmission. For example, the UE 100 selects a preamble sequence corresponding to the amount of data (uplink data) transmitted through the early data transmission based on the correspondence relationship notified from the eNB 200.

[0169] UE 100 may determine whether to notify eNB 200 of the amount of data (uplink data) to be transmitted through early data transmission based on the minimum guaranteed resource amount notified from eNB 200. For example, when the minimum guaranteed resource amount is sufficient, UE 100 may determine not to notify eNB 200 of the amount of data to be transmitted through early data transmission. When the minimum guaranteed resource amount is insufficient, UE 100 may determine to notify eNB 200 of the amount of data to be transmitted through early data transmission.

[0170] In step S503, the UE 100 transmits Msg1 (random access preamble) to the eNB 200. The UE 100 may transmit the random access preamble by applying a PRACH resource (e.g., a preamble sequence) corresponding to the amount of data transmitted through the early data transmission. Alternatively, the UE 100 may transmit the random access preamble by adding information indicating the amount of data transmitted through the early data transmission to the random access preamble.

[0171] In step S504, the eNB 200 determines the amount of uplink radio resources (e.g., PUSCH resources) to be allocated to the UE 100 based on the amount of data notified by the random access preamble. The uplink radio resources may be radio resources used for Msg3 transmission. The UE 100 is notified of information about the uplink radio resources allocated to the UE 100 by the eNB 200 through Msg2.

[0172] Note that an example has been described in which the eNB 200 notifies the UE 100 of the minimum guaranteed resource amount. However, instead of such notification, the eNB 200 may set in the UE 100 whether the UE 100 should notify the uplink data amount using the random access preamble. This setting may be performed through the SIB.

[0173] Alternatively, the notification of the indication to perform uplink early data transmission may have an implicit notification meaning of the uplink data amount. The eNB 200 may regard the indication to perform uplink early data transmission as: leaving the UL grant size to the eNB decision, the data amount equal to the reported UL grant size (which may be the maximum allowed UL grant size), or the reported UL grant size needs to have the data amount associated with the early data transmission.

[0174] In the operation mode 1 of the first embodiment, an example of notifying the eNB 200 of an indication of performing early data transmission of the UE 100 using PRACH resources has been described. Such notification may need to be performed for each CE level. In addition, in this modified example, the amount of uplink data is notified to the eNB 200 using PRACH resources. When these operations are used together, it is necessary to increase the number of PRACH resource divisions. In addition, since one resource pool guaranteed for PRACH is limited, as the number of PRACH resource divisions increases, the size of each divided resource group decreases. Therefore, even if the UE 100 randomly selects resources within each resource group, the probability that multiple UEs select the same resource (i.e., the probability of occurrence of resource conflicts) increases.

[0175] Therefore, the UE 100 can perform random access preamble transmission multiple times before the reception timing of the random access response. In each of the multiple random access preamble transmissions, the UE 100 selects resources to be applied to the random access preamble transmission based on the information to be notified to the eNB 200. Thereby, multiple PRACH resource pools can be ensured in the time direction, and the number of available PRACH resources can be increased.

[0176] Fig.14 is a diagram illustrating an example of PRACH resource configuration. Fig.14 In the example shown, UE 100 performs two preamble transmissions within a predetermined time. The predetermined time may be a subframe time or a radio frame time. Two PRACH resource pools #1 and #2 corresponding to the two preamble transmissions are set. PRACH resource pool #1 and PRACH resource pool #2 may be set on the same frequency. Each PRACH resource pool is divided in the frequency direction and is divided into a plurality of resource groups. Each PRACH resource pool may be divided in the time direction.

[0177] UE 100 selects resources from PRACH resource pool #1 in the first preamble transmission. PRACH resource pool #1 is divided into three resource groups corresponding to CE levels #1 to #3. For example, UE 100 having an indication to perform uplink early data transmission determines a resource group corresponding to its own CE level, randomly selects resources from the determined resource group, and transmits a random access preamble using the selected resources. eNB 200 determines a resource group corresponding to the random access preamble received from UE 100, and learns the CE level of UE 100.

[0178] UE 100 selects resources from PRACH resource pool #2 in the second preamble transmission. PRACH resource pool #2 is divided into four resource groups, and the four resource groups correspond to uplink data amounts #1 to #4. Each of data amounts #1 to #4 is an index indicating a range of data amounts. For example, UE 100 having an indication to perform uplink early data transmission determines a resource group corresponding to its uplink data amount, randomly selects a resource from the determined resource group, and transmits a random access preamble using the selected resource. eNB 200 determines a resource group corresponding to the random access preamble received from UE 100, and learns the uplink data amount of UE 100.

[0179] UE 100 may apply the same preamble sequence (signal sequence) in the first preamble transmission and the second preamble transmission. In this case, eNB 200 associates the UE that has performed the first preamble transmission with the UE that has performed the second preamble transmission based on the preamble sequence. Alternatively, resources may be selected from a resource group according to a predetermined pattern (e.g., a frequency hopping pattern) in the first preamble transmission and the second preamble transmission. In this case, eNB 200 associates the UE that has performed the first preamble transmission with the UE that has performed the second preamble transmission based on the resource selection pattern.

[0180] When receiving the random access preamble transmitted by the second preamble transmission from the UE 100, the eNB 200 may transmit a random access response corresponding to the random access preamble transmitted by the first preamble transmission to the UE 100. That is, the eNB 200 does not transmit the random access response corresponding to the random access preamble transmitted by the second preamble transmission. Thus, backward compatibility can be ensured. Alternatively, when receiving the random access preamble transmitted by the second preamble transmission from the UE 100, the eNB 200 may transmit the random access response corresponding to the random access preamble transmitted by the second preamble transmission to the UE 100. That is, the eNB 200 does not transmit the random access response corresponding to the random access preamble transmitted by the first preamble transmission.

[0181] The eNB 200 may notify the UE 100 of information about each PRACH resource pool through the SIB. The information about each PRACH resource pool includes at least one of the type of information associated with each PRACH resource pool and each resource group, information indicating the time / frequency range of resources constituting the PRACH resource pool, and information indicating the time / frequency range of each resource group in the PRACH resource pool. The eNB 200 may notify the UE 100 of such information as a separate information element (e.g., RACH-config) for each PRACH resource pool. Each information element may include the type of corresponding information (CE level or uplink data amount), or the type of corresponding information may be indicated by the information element name.

[0182] Note that Fig.14 In the example of , an example has been described in which the CE level and the uplink data amount are notified to the eNB 200 through the preamble transmission, but information other than the CE level and the uplink data amount (e.g., UE category, timer value of modified example 14 described later) may be notified to the eNB 200 through the preamble transmission. In addition, the number of preamble transmissions performed consecutively is not limited to two times, and may be three times or more. For example, the UE 100 may notify the eNB 200 of the CE level through the first random access preamble transmission, notify the eNB 200 of an indication of performing early data transmission through the second random access preamble transmission, and notify the eNB 200 of the uplink data amount (i.e., the number of uplink grants expected by the UE 100) through the third random access preamble transmission. Alternatively, the PRACH resource pool #1 for the first random access preamble transmission and the PRACH resource pool #2 for the second random access preamble transmission are divided, and the PRACH resource pool #2 is divided into two resource groups. Then, one resource group of the PRACH resource pool #2 may be ensured to be used for notifying the indication of performing early data transmission, and another resource group of the PRACH resource pool #2 may be ensured to be used for notifying the indication of the uplink data amount. In this case, the eNB 200 may regard the UE 100 that has notified the eNB 200 of the uplink data amount using the resources in the resource group for notifying the uplink data amount as a UE having the indication of performing early data transmission. In addition, the notification of the indication of performing early data transmission may be regarded as leaving the UL grant size to the eNB to decide, the data amount being equal to the reported UL grant size (which may be the maximum allowed UL grant size), or the reported UL grant size being required to have the data amount associated with the early data transmission.

[0183] exist Fig.14In the example, an example has been described in which a plurality of PRACH resource pools are set in the time direction, but a plurality of PRACH resource pools may be set in the frequency direction.

[0184] In addition, an example has been described in which the first preamble transmission and the second preamble transmission are associated with each other by applying the same preamble sequence (signal sequence) in the first preamble transmission and the second preamble transmission. However, the association is not limited to the case of using the preamble sequence, and the association can be performed by time / frequency resources. For example, Fig.14 As shown in , each of the PRACH resource pool #1 for the first random access preamble transmission and the PRACH resource pool #2 for the second random access preamble transmission includes a plurality of resource groups, and each resource group is assumed to be defined as a rectangle. In this case, a specific point among the four vertices of the rectangle is determined as a reference point. The UE 100 selects a resource at a predetermined time / frequency position based on the reference point in the resource group for the first random access preamble transmission. The UE 100 selects a resource at the same time / frequency position as the first time based on the reference point in the resource group for the second random access preamble transmission. In this way, by aligning the relative position of the time / frequency resources in each transmission of the first and second random access preamble transmissions, the eNB 200 can perform association of the first preamble transmission with the second preamble transmission.

[0185] In addition, Fig.14 In the example, an example has been described in which the PRACH resource pool is configured by time / frequency resources, but the PRACH resource pool may be composed of preamble sequence (signal sequence) resources.

[0186] Next, a case where the eNB 200 fails to receive a preamble at least once in multiple transmissions of random access preambles will be described. Here, it is assumed that the UE 100 notifies the eNB 200 of the CE level through the first random access preamble transmission, and notifies the eNB 200 of an instruction to perform early data transmission (particularly, an instruction to perform uplink early data transmission) through the second random access preamble transmission. As shown in Table 1, in Cases 1 to 3, at least one of the first random access preamble transmission (first PRACH) and the second random access preamble transmission (second PRACH) fails.

[0187] [Table 1]

[0188]

[0189] Case 1 is a case where both the first random access preamble transmission and the second random access preamble transmission are successful. In case 1, the eNB 200 learns the instruction to perform early data transmission by the UE 100, and allocates more uplink resources to the UE 100 than the normal uplink grant (i.e., regardless of the amount of data to be transmitted by early data transmission), and notifies the allocated uplink resources through Msg2. The UE 100 transmits data through the early data transmission using Msg3.

[0190] Case 2 is a case where the first random access preamble transmission succeeds and the second random access preamble transmission fails. In case 2, the eNB 200 recognizes that a normal random access preamble is received, and notifies the UE 100 of a normal uplink grant through Msg2. The UE 100 determines that no uplink resources available for data transmission are allocated, and transmits Msg3 that does not include data to the eNB 200.

[0191] Case 3 is a case where the first random access preamble transmission fails and the second random access preamble transmission succeeds. In case 3, since the eNB 200 does not receive the first random access preamble, the eNB 200 does not transmit the corresponding Msg2 even if the second random access preamble is received. The UE 100 does not receive the Msg2 from the eNB 200, and thus performs the random access procedure again from the beginning.

[0192] In case 3, the eNB 200 may determine the UE 100 that has transmitted the random access preamble based on the second random access preamble, and may transmit Msg2 to the determined UE 100. For example, the eNB 200 may determine the UE 100 based on the preamble sequence and / or hopping pattern applied to the second random access preamble. However, since the eNB 200 does not receive the first random access preamble, the eNB 200 cannot know the CE level of the UE 100 based on the first random access preamble. In this case, the eNB 200 assumes that the UE 100 is in normal coverage (i.e., not in extended coverage) and does not perform repeated transmission during Msg2 transmission. Alternatively, the eNB 200 may estimate the CE level based on the second random access preamble. Specifically, when repeated transmission is applied during the second preamble transmission, the eNB 200 may count the number of repetitions of the preamble transmission that has been successfully received, and may estimate the CE level based on the count value. The eNB 200 performs repeated transmission when transmitting Msg2 based on the estimated CE level.

[0193] Note that regardless of whether random access preamble transmission is performed multiple times, UE 100 that has notified eNB 200 of the indication to perform uplink early data transmission through preamble transmission may have the following limitation: when no uplink resources that can be used for data transmission are allocated, normal Msg3 (Msg3 without data) should be transmitted to eNB 200.

[0194] Alternatively, when no uplink resource that can be used for data transmission is allocated, the UE 100 that has notified the eNB 200 of an instruction to perform uplink early data transmission through preamble transmission can perform the random access procedure again. When the random access procedure is restarted, the UE 100 performs the preamble transmission again, and notifies the eNB 200 of the instruction to perform uplink early data transmission again through preamble transmission. The UE 100 can perform the random access procedure again only when the eNB 200 allows it. That is, when the eNB 200 does not allow it, the UE 100 is prohibited from performing the random access procedure again. Information indicating such permission can be broadcasted from the eNB 200 through the SIB, or can be configured to the UE 100 from the MME.

[0195] (Modified Example 2)

[0196] Fig.15 2 is a diagram showing a modification example 2 of the first embodiment. The difference from the operation in the first embodiment will be mainly described.

[0197] like Fig.15 As shown in , in step S601, UE 100 transmits data together with Msg1 (random access preamble) to eNB 200 through early data transmission. For example, UE 100 transmits data using a new data channel after the random access preamble. However, a small amount of data may be transmitted together with the random access preamble. UE 100 retains the data transmitted in step S601.

[0198] In step S602, when the eNB 200 receives the data transmitted together with the random access preamble, the eNB 200 returns at least a part of the received data to the UE 100 through Msg2 (random access response). The eNB 200 may return all the received data to the UE 100.

[0199] In step S603, the UE 100 compares the data transmitted in step S601 with the data returned from the eNB 200. As a result of the comparison, if the data transmitted in step S601 is consistent with the data returned from the eNB 200, the UE 100 determines that the transmission is successful (ACK), and if the data transmitted in step S601 is inconsistent with the data returned from the eNB 200, it is determined that the transmission fails (NACK). If it is determined that the transmission fails (NACK), the UE 100 retransmits the data that failed to be transmitted at the next uplink transmission (at the time of PUSCH transmission). In addition, the UE 100 may notify the eNB 200 of the determination result (ACK or NACK) through Msg3. The UE 100 may perform NACK notification to the eNB 200 only when the determination result is NACK.

[0200] (Modified Example 3)

[0201] UE 100 according to Modification Example 3 of the first embodiment transmits data to eNB 200 through early data transmission in RRC idle mode. Thereafter, UE 100 in RRC idle mode monitors a physical channel hybrid ARQ indicator channel (PHICH) to receive ACK or NACK corresponding to the data transmitted through early data transmission from eNB 200.

[0202] Generally, UE 100 monitors PHICH only in RRC connected mode. However, it is assumed that eNB 200 notifies ACK / NACK for uplink early data transmission through PHICH. Therefore, even if UE 100 is in RRC idle mode, UE 100 monitors PHICH to be able to know whether early data transmission is successful.

[0203] (Modified Example 4)

[0204] In Modification Example 4 of the first embodiment, UE 100 or eNB 200 determines whether data transmission is completed by early data transmission. When it is determined that data transmission is completed by early data transmission, UE 100 terminates the random access procedure without switching from RRC idle mode to RRC connected mode. This enables efficient data transmission.

[0205] For example, in the case of uplink early data transmission, when UE 100 receives Msg4 (e.g., RRC connection establishment message) from eNB 200, UE 100 transmits a message indicating failure or rejection (failure message) to eNB 200, and thus the random access procedure can be terminated. The message indicating failure or rejection may include information indicating the cause of the failure or rejection (e.g., early data transmission completion).

[0206] In the case of downlink early data transmission, the eNB 200 notifies the UE 100 of the termination of the random access procedure (ie, not necessarily completed) through Msg4 (eg, RRC connection establishment message), and may terminate the random access procedure. Alternatively, the eNB 200 may transmit an RRC connection release message as Msg4.

[0207] When transmitting downlink early data, the eNB 200 may notify that the downlink early data transmission is a downlink transmission of a small packet (small data amount) by transmitting a special paging message to the UE 100 before the random access procedure. Such a paging message may be generated by the MME 300 and transmitted from the MME 300 to the UE 100 via the eNB 200. The special paging message may include a combination of an identifier of the UE 100 and information indicating small packet transmission. When the UE 100 receives the special paging message, after completing the data transmission through the early data transmission, the UE 100 terminates the random access procedure without switching to the RRC connected mode.

[0208] (Modified Example 5)

[0209] In modification example 5 of the first embodiment, the eNB 200 transmits a preamble index indicating a preamble sequence to be applied to a random access preamble to the UE 100 through a paging message. For example, the paging message may include a combination of an identifier of the UE 100 and the preamble index.

[0210] Prior to this operation, the MME 300 may perform notification of "application of non-contention-based random access procedure" and an identifier (UE ID) of the UE in an S1 paging message transmitted to the eNB 200 via the S1 interface. The MME 300 may perform notification of the UE ID and "application of early data transmission" in the S1 paging message. In addition, the eNB 200 notifies the MME 300 of (multiple) preamble indexes in advance, and the MME 300 notifies the eNB 200 of one index selected from the indexes in the S1 message (if necessary).

[0211] UE 100 (e.g., UE in RRC idle mode) receives a paging message from eNB 200 and transmits a random access preamble to which a preamble sequence indicated by a preamble index is applied to eNB 200. eNB 200 can identify UE 100 as a random access preamble transmission source based on the preamble sequence applied to the random access preamble.

[0212] Therefore, a non-contention-based random access procedure may be performed in a case where a contention-based random access procedure is originally performed (eg, during an initial connection). Therefore, a contention solution for a contention-based random access procedure may not be required.

[0213] (Modified Example 6)

[0214] In Modification Example 6 of the first embodiment, UE 100 or eNB 200 transmits data by early data transmission. For data transmitted by early data transmission, transmission of ACK or NACK corresponding to the data is not applied, but repeated transmission of the data is applied a predetermined number of times. Therefore, even if ACK or NACK is not used, the reliability of data transmission can be improved.

[0215] Even when UE 100 is not in enhanced coverage (i.e., in normal coverage), UE 100 or eNB 200 applies repeated transmission to data transmitted by early data transmission. In general, when UE 100 is in normal coverage, repeated transmission is not applied. On the other hand, in Modification Example 6 of the first embodiment, regardless of whether UE 100 is in enhanced coverage, for data transmitted by early data transmission, transmission of ACK or NACK is not applied, but repeated transmission of the data is applied repeatedly for a predetermined number of times.

[0216] For example, in the case of uplink early data transmission, even if uplink data is received through early data transmission, the eNB 200 does not transmit ACK / NACK to the UE 100. However, the UE 100 performs repeated transmission of the same signal in a lower layer at a number of times predefined in the specification or at a number of times set from the eNB 200.

[0217] In the case of downlink early data transmission, even if downlink data is received through early data transmission, UE 100 does not transmit ACK / NACK to eNB 200. However, eNB 200 performs repeated transmission of the same signal in a lower layer at a number of times predefined in the specification or at a number of times notified to UE 100.

[0218] (Modified Example 7)

[0219] In modified examples 7 to 10 of the first embodiment, it is assumed that the predetermined message for data transmission in early data transmission is Msg3. That is, the early data transmission in modified examples 7 to 10 of the first embodiment is uplink early data transmission. Note that, as described above, Msg3 is a message transmitted from UE 100 to eNB 200, and is a message for requesting that UE 100 be converted from idle mode to connected mode. In early data transmission, data (packets) transmitted by Msg3 may be included in Msg3. For example, UE 100 transmits an RRC connection request message including a data PDU. Alternatively, data (packets) transmitted by Msg3 may be transmitted in combination (continuously) with Msg3 as a message different from Msg3. For example, UE 100 may transmit a MAC PDU that includes a message including data (packets) and Msg3. UE 100 may include a message including data (packets) and Msg3 in a separate MAC PDU, and transmit the separate MAC PDU simultaneously or continuously.

[0220] In the description of the following modification examples 7 to 11, an example in which Msg3 is an RRC connection request message will be described, but Msg3 may be an RRC connection recovery request message.

[0221] In modified example 7, the above-mentioned step A (i.e., the step of transmitting information about whether to perform early data transmission) includes the following steps: indicating the performance of uplink early data transmission through a MAC random access response (MAC RAR), which constitutes a random access response (Msg2) transmitted from the eNB 200 to the UE 100.

[0222] A general random access response is constituted as a MAC RAR and has: a timing advance command determined by the eNB 200 based on the random access preamble; allocation information (UL grant) of uplink resources allocated by the eNB 200 to the UE 100 for RRC connection request message transmission; and a temporary C-RNTI allocated by the eNB 200 to the UE 100.

[0223] In Modification Example 7, the eNB 200 having received the random access preamble from the UE 100 determines whether the UE 100 performs uplink early data transmission (i.e., data transmission using the RRC connection request message) by the method according to the above-described first embodiment or its modification example. When it is determined that the early data transmission is to be performed by the UE 100, the eNB 200 indicates the execution of the uplink early data transmission using the MAC RAR constituting the random access response. For example, when a new field is set in the MAC RAR, the eNB 200 includes a flag (permission bit) indicating that data transmission using the RRC connection request message is to be performed in the new field. When data transmission using the RRC connection request message is not to be performed, the eNB 200 does not include a flag indicating that data transmission using the RRC connection request message is to be performed in the new field (or includes the flag as a zero value).

[0224] Alternatively, the eNB 200 may also notify the UE 100 whether to make the UE 100 perform early data transmission through a MAC CE different from the MAC RAR constituting the random access response. For example, the different MAC CE may be referred to as "early data transmission RAR". In this case, the eNB 200 may include an identifier indicating uplink and / or downlink early data transmission in the early data transmission RAR.

[0225] Note that, as described in Modification Example 1, UE 100 notifies eNB 200 of the amount of data (uplink data) to be transmitted by early data transmission through the random access preamble. eNB 200 determines the amount of uplink radio resources to be allocated to UE 100 based on the amount of uplink data notified from UE 100, and eNB 200 includes information indicating the determined uplink radio resources in a UL grant during a random access response (MAC RAR).

[0226] (Modified Example 8)

[0227] In the above-mentioned modification example 4, an operation has been described in which, when determining that data transmission is completed by early data transmission, the UE 100 terminates the random access procedure without transitioning from the RRC idle mode to the RRC connected mode. Modification example 8 relates to an operation example in the case of downlink early data transmission.

[0228] In Modification Example 8, when data transmission is completed through the RRC Connection Request message, UE 100 transmits an RRC Connection Request message including a flag indicating that UE 100 does not need to switch to the connected mode (ie, does not need to establish an RRC connection) from UE 100 to eNB 200. The flag consists of 1 bit.

[0229] For example, when the amount of data to be transmitted to the eNB 200 is equal to or less than the maximum amount of data that the RRC connection request message can carry, the UE 100 determines that the data transmission is completed by the RRC connection request message. In this case, when the RRC connection request message is used to transmit data, the UE 100 includes a flag indicating that the UE 100 does not need to switch to the connection mode in the RRC connection request message. Therefore, the RRC connection request message includes data transmitted by early data transmission and a flag indicating that the UE 100 does not need to switch to the connection mode. On the other hand, when the amount of data to be transmitted to the eNB 200 exceeds the maximum amount of data that the RRC connection request message can carry, the UE 100 determines that the data transmission is not completed by the RRC connection request message. In this case, when the RRC connection request message is used to transmit data, the UE 100 does not include a flag indicating that the UE 100 does not need to switch to the connection mode in the RRC connection request message (or includes a flag as a zero value).

[0230] The eNB 200 receives the RRC connection request message including the data and the flag from the UE 100. Here, in the eNB 200, a reception error (data decoding failure) of the data included in the RRC connection request message may occur due to a radio state or a collision of the RRC connection request message.

[0231] When the eNB 200 has normally received the data included in the RRC connection request message, the flag included in the RRC connection request message indicates that the RRC connection does not need to be established, and therefore, the eNB 200 does not perform Msg4 transmission to the UE 100, or transmits the RRC connection release message to the UE 100. On the other hand, when a reception error of the data included in the RRC connection request message occurs in the eNB 200, the eNB 200 continues the random access procedure to establish the RRC connection, for example, by transmitting Msg4 to the UE 100. The UE 100 determines whether the data transmission through the RRC connection request message is successful based on the response status of the eNB 200 to the RRC connection request message.

[0232] Here, description will be given of an operation of UE 100 when a reception error of data included in the RRC connection request message occurs in eNB 200. When UE 100 determines that data transmission using the RRC connection request message has failed, UE 100 performs any one of the following operations 0) to 4).

[0233] 0) Restart the random access procedure from the transmission of the random access preamble (Msg1). Specifically, the random access procedure may be restarted from the selection of the preamble sequence. Then, the data may be retransmitted in Msg3.

[0234] 1) Retransmitting the RRC Connection Request message with data In this case, the UE 100 includes a flag in the RRC Connection Request message indicating that the UE 100 does not need to switch to the connected mode.

[0235] 2) Retransmitting the RRC Connection Request message without data. In this case, the UE 100 does not include a flag indicating that the UE 100 does not need to switch to the connected mode in the RRC Connection Request message. The UE 100 transmits (retransmits) data after switching to the connected mode.

[0236] 3) Data is transmitted through Msg5, which is a message transmitted from UE 100 to eNB 200, and is used to notify that the transition to the connected mode has been completed. In this case, UE 100 can be converted to the connected mode. Alternatively, UE 100 can transmit data to eNB 200 instead of transmitting Msg5. eNB 200 can notify UE 100 whether data is successfully received from UE 100 through Msg6.

[0237] 4) Switch to connection mode.

[0238] In modification example 8, UE 100 may transmit an RRC connection request message having information indicating that UE 100 does not need to switch to connected mode, instead of transmitting an RRC connection request message including a flag indicating that UE 100 does not need to switch to connected mode (i.e., no RRC connection needs to be established). UE 100 may transmit a MAC CE including information indicating that UE 100 does not need to switch to connected mode. For example, MAC CE is a buffer status report (BSR). BSR is a MAC CE indicating the amount of data available for uplink transmission by UE 100 (i.e., the amount of uplink transmission waiting data).

[0239] Fig.16 is a diagram showing an example of a MAC protocol data unit (MAC PDU) generated by the MAC layer. Fig.16 As shown in , MAC PDU includes a MAC service data unit (MAC SDU) provided to the MAC layer from a layer higher than the MAC layer. RRC messages such as an RRC connection request message and an RRC connection recovery request message are generated by the RRC layer and provided to the MAC layer as MAC SDU. Uplink data transmitted by early data transmission is provided to the MAC layer as MAC SDU through the PDCP layer and the RLC layer. Uplink data can be provided to the MAC layer as MAC SDU without passing through the PDCP layer and the RLC layer.

[0240] In addition to the MAC SDU, the MAC PDU also includes a MAC header and a MAC control element (MAC CE) generated by the MAC layer. The MAC PDU also includes padding for filling the free area of ​​the MAC PDU. Fig.16 An example in which a MAC PDU includes two MAC CEs is shown, but the number of MAC CEs may be three or more or one. The MAC CE constituting the BSR includes a buffer size field for storing a value (index) indicating the amount of data available for uplink transmission. The UE 100 includes a value indicating that the amount of data available for uplink transmission is zero in the buffer size field as information indicating that the UE 100 does not need to switch to the connected mode. Such a BSR may be referred to as Release Assistance Information (RAI).

[0241] In the early data transmission, when the data transmission is completed through the RRC connection request message (Msg3), the UE 100 may collect one or more MAC SDUs including uplink data and the RRC connection request message and a MAC CE including information (BSR=0) indicating that the UE 100 does not need to switch to the connection mode through one MAC PDU, and transmit the collected MAC SDU and MAC CE to the eNB 200. Alternatively, the UE 100 may continuously transmit one or more MAC SDUs including uplink data and the RRC connection request message and a MAC CE including information (BSR=0) indicating that the UE 100 does not need to switch to the connection mode through a separate MAC PDU to the eNB 200. The eNB 200 determines that the UE 100 does not need to switch to the connection mode based on "BSR=0" accompanying the RRC connection request message.

[0242] (Modified Example 9)

[0243] In the modified examples 9 to 12 of the first embodiment, it is assumed that the predetermined message for data transmission in the early data transmission is Msg4. That is, the early data transmission in the modified examples 9 to 11 of the first embodiment is downlink early data transmission. Note that, as described above, Msg4 is a message transmitted from the eNB 200 to the UE 100, and is a message for converting the UE 100 from the idle mode to the connected mode.

[0244] In the description of the following modification examples 9 to 12, an example in which Msg4 is an RRC connection establishment message will be described, but Msg4 may be an RRC connection recovery message.

[0245] In Modification Example 9, the UE 100 in the idle mode starts the random access procedure. When the UE 100 is in the idle mode, the eNB 200 may not retain the context information (including the information related to the capability of the UE 100) of the UE 100. In this case, the eNB 200 does not know whether the UE 100 has the capability to process downlink early data transmission, and it is difficult to determine whether to perform downlink early data transmission.

[0246] Therefore, in Modification Example 9, UE 100 notifies eNB 200 whether UE 100 corresponds to (supports) downlink early data transmission by using a random access preamble (Msg1) or an RRC connection request message. For example, UE 100 having the capability to perform downlink early data transmission transmits information (identifier) ​​indicating that UE 100 has the capability to perform downlink early data transmission to eNB 200 through a random access preamble (Msg1) or an RRC connection request message. In the case of using the random access preamble (Msg1), the method of Operation Mode 1 of the above-mentioned first embodiment can be used. Based on the notification from UE 100, eNB 200 determines whether UE 100 corresponds to downlink early data transmission. Here, "UE 100 corresponds to (supports) downlink early data transmission" and "UE 100 has the capability to perform downlink early data transmission" may mean that UE 100 has the capability (function) to "receive" data transmitted from eNB 200 through downlink early data transmission.

[0247] Note that the UE 100 may notify the eNB 200 of the capability of downlink early data transmission through the random access preamble only when a paging message for performing downlink early data transmission is received from the eNB 200 (see operation mode 3 according to the above-mentioned first embodiment). The paging message may include information that explicitly indicates the performance of downlink early data transmission. The paging message may include information that implicitly indicates the performance of downlink early data transmission (e.g., information on PRACH resources used for random access preamble transmission, which indicates that the UE 100 has the capability of downlink early data transmission).

[0248] In addition, UE 100 may notify eNB 200 of the capability of downlink early data transmission through the RRC connection request message only when Msg2 indicating downlink early data transmission (see the above-mentioned modification example 7) is received from eNB 200. Msg2 may include information that explicitly indicates the execution of downlink early data transmission. Msg2 may include information that implicitly indicates the execution of downlink early data transmission.

[0249] (Modified Example 10)

[0250] In Modification Example 9, an example has been described in which UE 100 notifies eNB 200 whether UE 100 corresponds to (supports) downlink early data transmission. However, the mobility management device (MME 300) provided in the core network (EPC 20) may notify eNB 200 whether UE 100 has the capability to perform downlink early data transmission. Prior to this operation, UE 100 notifies MME 300 of information indicating that UE 100 has the capability to perform downlink early data transmission, and MME 300 may retain the UE context including the information for a certain time (for example, while UE 100 is in the EMM registered state).

[0251] MME 300 may notify eNB 200 of the capability through a paging message (S1 paging message) or may notify eNB 200 through an initial context setup message. When MME 300 transmits data to UE 100 through NAS signaling, MME 300 may notify eNB 200 of the capability through NAS signaling or S1 message.

[0252] (Modified Example 11)

[0253] In the above-mentioned modification example 4, an operation has been described in which the UE 100 terminates the random access procedure without transitioning from the RRC idle mode to the RRC connected mode when determining that data transmission is completed by early data transmission. Modification example 8 relates to an operation example in the case of downlink early data transmission.

[0254] In Modification Example 11, the eNB 200 determines the first message or the second message as a message (predetermined message) for data transmission based on the amount of data transmitted to the UE 100 through the downlink early data transmission. The first message is an RRC connection establishment message for converting the UE 100 from the idle mode to the connected mode. The second message is a message for keeping the UE 100 in the idle mode. Although an example using the RRC connection release message as the second message will be described, the second message may be a new message.

[0255] For example, when the amount of data to be transmitted to the UE 100 is equal to or less than the maximum amount of data that can be carried by the RRC connection release message, the eNB 200 determines that the data transmission is completed by the RRC connection release message. In this case, the eNB 200 transmits the RRC connection release message including the data to the UE 100 instead of transmitting the RRC connection establishment message. Therefore, the random access process can be stopped midway, and the UE 100 can be prevented from switching to the connection mode. On the other hand, when the amount of data to be transmitted to the UE 100 exceeds the maximum amount of data that can be carried by the RRC connection release message, the eNB 200 determines that the data transmission is not completed by the RRC connection release message. In this case, the eNB 200 transmits the RRC connection establishment message including the data to the UE 100. This allows the UE 100 to continue the random access process.

[0256] Alternatively, instead of the change message, the termination of the data transmission may be notified to the UE 100 through the RRC connection establishment message. For example, when the amount of data to be transmitted to the UE 100 is equal to or less than the maximum amount of data that the RRC connection establishment message can carry, the eNB 200 determines that the data transmission is completed through the RRC connection establishment message. In this case, the eNB 200 transmits the RRC connection establishment message including the data and the information indicating the termination of the data transmission (the so-called end marker) to the UE 100. Therefore, the random access procedure can be stopped halfway, and the UE 100 can be prevented from switching to the connection mode. On the other hand, when the amount of data to be transmitted to the UE 100 exceeds the maximum amount of data that the RRC connection establishment message can carry, the eNB 200 determines that the data transmission is not completed through the RRC connection establishment message. In this case, the eNB 200 transmits the RRC connection establishment message including the data and not including the end marker to the UE 100. This allows the UE 100 to continue the random access procedure.

[0257] (Modified Example 12)

[0258] In the above-mentioned Modification Example 8, the example of retransmitting the RRC Connection Request message with data when the UE 100 determines that the data transmission through the RRC Connection Request message (Msg3) has failed has been described.

[0259] This retransmission operation can also be applied to downlink early data transmission. In modified example 9, the eNB 200 transmits an RRC connection establishment message (Msg4) with data to the UE 100 through early data transmission, and then determines whether the data transmission through the RRC connection establishment message is successful. The eNB 200 can make a determination based on, for example, HARQ ACK or HARQ NACK in the MAC layer. When the eNB 200 determines that the data transmission using Msg4 has failed, the eNB 200 retransmits Msg4 with data. When downlink early data transmission is set and Msg4 reception fails, the UE 100 determines that the data is also retransmitted in the Msg4 retransmission. The UE 100 (for example, a layer higher than the MAC layer of the UE 100 (RRC layer, etc.)) waits so that both the RRC message (RRC connection reconfiguration) reception and data reception constituting Msg4 can be performed.

[0260] (Modified Example 13)

[0261] Modification Example 13 is an example related to both uplink early data transmission and downlink early data transmission.

[0262] In Modification Example 13, the UE 100 and / or the eNB 200 determine not to perform the early data transmission in the other of the uplink and the downlink for a random access procedure in which early data transmission is performed in one of the uplink and the downlink. Therefore, in one random access procedure performed by one UE 100, only one of uplink early data transmission and downlink early data transmission can be performed.

[0263] If both uplink early data transmission and downlink early data transmission can be implemented in one random access process, the problem is that the control related to early data transmission becomes complicated. In addition, the following problems may occur. For example, after transmitting data through the RRC connection request message (Msg3), the UE 100 should wait for response data (e.g., TCP ACK) corresponding to the data transmitted through the RRC connection establishment message (Msg4). Since such response data is affected by the delay in the network, it is not preferred for the UE 100 to continue waiting for the response data transmitted through the RRC connection establishment message (Msg4). Therefore, in one random access process, this problem can be avoided by enabling only one of the uplink early data transmission and the downlink early data transmission.

[0264] In Modification Example 13, when UE 100 performs data transmission through RRC connection request message (Msg3), UE 100 determines not to perform data reception through RRC connection establishment message (Msg4). In other words, for a random access procedure for performing uplink early data transmission using Msg3, UE 100 determines not to perform downlink early data transmission using Msg4. For example, it is assumed that UE 100 is notified through a paging message to perform downlink early data transmission using Msg4 (see operation mode 3 of the first embodiment), or that downlink early data transmission using Msg4 is performed through a random access response notification (see Modification Example 7). Even in this case, when UE 100 performs data transmission through RRC connection request message (Msg3), UE 100 can also determine not to perform data reception through RRC connection establishment message (Msg4). In addition, when the eNB 200 receives data through the RRC connection request message (Msg3), the eNB 200 may determine not to perform data transmission through the RRC connection establishment message (Msg4).

[0265] In Modification Example 13, when UE 100 performs data reception through the RRC connection establishment message (Msg4), UE 100 determines not to perform data transmission through the RRC connection request message (Msg3). In other words, for the random access process of performing downlink early data transmission using Msg4, UE 100 determines not to perform uplink early data transmission using Msg3. For example, it is assumed that UE 100 is notified through a paging message that downlink early data transmission is performed using Msg4 (see operation mode 3 of the first embodiment), or that downlink early data transmission is performed using Msg4 (see Modification Example 7) is notified through a random access response (Msg2). In this case, even if UE 100 has uplink transmission data, UE 100 determines to perform downlink early data transmission using Msg4, and determines not to perform uplink transmission data using Msg3.

[0266] In Modification Example 13, consider the case where UE 100 having the capability to perform early data transmission transmits a notification (identifier) ​​indicating that UE 100 has the capability to perform early data transmission to eNB 200 through one of a random access preamble (Msg1) and an RRC connection request message (Msg3) (see Modification Example 9).

[0267] In this case, when information indicating the execution of downlink early data transmission is transmitted from the eNB 200 to the UE 100 through the paging message or Msg2, if the eNB 200 receives a notification indicating that the UE 100 has the capability to execute early data transmission from the UE 100, the eNB 200 interprets the notification as an indication of the capability to execute downlink early data transmission. When receiving information indicating the execution of downlink early data transmission from the eNB 200, the UE 100 having the capability and / or indication to execute downlink early data transmission notifies the eNB 200 of the capability and / or indication to execute downlink early data transmission by transmitting to the eNB 200 a notification indicating that the UE 100 has the capability to execute early data transmission.

[0268] On the other hand, when information indicating the execution of downlink early data transmission is not transmitted from the eNB 200 to the UE 100 through the paging message or Msg2, if the eNB 200 receives a notification indicating that the UE 100 has the capability to execute early data transmission from the UE 100, the eNB 200 interprets the notification as an indication of the capability and / or indication to execute uplink early data transmission. When information indicating the execution of downlink early data transmission is not received from the eNB 200, the UE 100 having the capability and / or indication to execute uplink early data transmission notifies the eNB 200 of the capability and / or indication to execute uplink early data transmission by transmitting to the eNB 200 a notification indicating that the UE 100 has the capability to execute early data transmission.

[0269] In this way, the meaning of the notification is made different depending on whether the information indicating that downlink early data transmission is performed is transmitted. Therefore, one type of notification (eg, one information element) can play two roles.

[0270] (Modified Example 14)

[0271] Unlike Modification Example 13, in Modification Example 14, a case where both uplink early data transmission and downlink early data transmission can be realized in one random access procedure is assumed.

[0272] In a general random access procedure, when the UE 100 transmits a Msg3 without data, the UE 100 activates a first timer when transmitting the Msg3 without data, and the first timer defines a waiting time for waiting to receive a Msg4 transmitted from the eNB 200. Such a first timer may be referred to as a contention resolution timer. The first timer is set from the eNB 200 to the UE 100 through the SIB. When the first timer expires without receiving the Msg4, the UE 100 stops the process of receiving the Msg4 (e.g., monitoring of the PDCCH), and restarts the random access procedure from the transmission of the Msg1.

[0273] However, as described above, after data is transmitted through the RRC connection request message (Msg3), when response data (e.g., TCP ACK) corresponding to the data is transmitted through the RRC connection establishment message (Msg4), it is possible that the first timer does not have enough waiting time. Therefore, in Modification Example 14, a second timer for early data transmission is introduced separately from the first timer. The UE 100 provided with both the first timer and the second timer selects the first timer when the Msg3 transmission does not involve data transmission, and selects the second timer when the Msg3 transmission involves data transmission.

[0274] In modification example 14, when UE 100 transmits Msg3 with data by early data transmission, UE 100 activates a second timer that defines a waiting time for waiting to receive Msg4 with data transmitted from eNB 200. The length of the waiting time corresponding to the second timer is different from the length of the waiting time corresponding to the first timer. For example, the waiting time set in the second timer can be made longer than the waiting time set in the first timer. For example, the maximum waiting time that can be set in the second timer is longer than the maximum waiting time that can be set in the first timer. The second timer is set from eNB 200 to UE 100 through SIB. Alternatively, since the context information of UE 100 in RRC suspension state is saved in the network (and UE 100), the second timer is set in UE 100 through a separate RRC message when UE 100 is in connected mode, the setting of the second timer is saved in the network when UE 100 is in connected mode, and the saved setting can be used for the random access procedure. When the second timer expires without receiving Msg4 having data, the UE 100 stops the process of receiving Msg4 (eg, monitoring of PDCCH) and restarts the random access procedure from Msg1 transmission.

[0275] Alternatively, assuming that early data transmission is applied to eMTC UE and NB-IoT UE, priority may be given to energy saving of UE 100. Therefore, the waiting time set in the second timer may be made shorter than the waiting time set in the first timer. Therefore, the process of receiving Msg4 may be terminated earlier.

[0276] Note that each of the first timer and the second timer may be a timer managed in the RRC layer or a timer managed in the MAC layer. The first timer managed in the RRC layer may be referred to as "T300". The first timer managed in the MAC layer may be referred to as a "contention resolution timer".

[0277] The timer value of the second timer (i.e., the waiting time of Msg4) is not limited to the case where the timer value to be set in UE 100 is determined by eNB 200, but may be determined by UE 100. A round trip time, which is the time from when UE 100 transmits uplink data until a higher layer ACK (e.g., TCPACK) returns to UE 100, may be estimated in a higher layer of UE 100. Therefore, a more appropriate timer value may be determined by determining the timer value of the second timer by UE 100. UE 100 may determine the timer value to be set in the second timer, and notify eNB 200 of the determined timer value. Notification of the timer value is performed by Msg3. Notification of the timer value may be performed by Msg1 (preamble transmission).

[0278] Fig.17 is a diagram showing an example of the operation of Modification Example 14. Fig.17 In the embodiment, a server 50 is provided in a network higher than the core network (EPC) (for example, the Internet). Fig.17 In the figure, a network entity (eg, S-GW) between the eNB 200 and the server 50 is not shown.

[0279] like Fig.17 As shown in , in step S701, the UE 100 determines a timer value to be set in the second timer. The UE 100 may determine the timer value of the second timer based on an estimated value of the round trip time.

[0280] In step S702, UE 100 transmits Msg3 with data to eNB 200 through uplink early data transmission. UE 100 notifies eNB 200 of the determined timer value through Msg3. eNB 200 can understand the waiting time of Msg4 in UE 100 through such notification.

[0281] UE 100 may notify eNB 200 that the second timer is used through Msg1 (preamble transmission). Then, UE 100 may use the second timer only when permission to use the second timer is notified from eNB 200 through Msg2, and notify eNB 200 of the timer value through Msg3.

[0282] The eNB 200 may broadcast (eg, transmit via SIB) a list of timer value candidates (including an index for each range of timer values). In this case, the UE 100 may notify the eNB 200 of the index of the timer value via Msg3.

[0283] The eNB 200 may broadcast (e.g., via SIB transmission) a default timer value for the second timer. In this case, the UE 100 basically uses the default timer value. The UE 100 may autonomously determine the timer value only when it is desired to rewrite the default timer value, and notify the eNB 200 of the determined timer value through Msg3. The value of "T300" may be the default timer value, and the value of "Content Resolution Timer" may be the default timer value. In addition, when the UE 100 determines the timer value of the second timer, there may be a restriction that the UE 100 should determine a timer value equal to or greater than the default timer value.

[0284] The eNB 200 may broadcast (e.g., through SIB transmission) a maximum value of the timer value that can be set by the UE 100. The UE 100 determines a timer value that is equal to or less than the maximum value broadcasted from the eNB 200, and notifies the eNB 200 of the determined timer value. However, when the UE 100 determines the maximum value broadcasted from the eNB 200 as the timer value, the UE 100 may not notify the eNB 200 of the determined timer value. When the timer value is not notified from the UE 100, the eNB 200 may assume that the UE 100 has determined the maximum value. Note that when the maximum value is not specified from the eNB 200 through broadcast, the UE 100 may determine a timer value that is equal to or less than the default maximum value using a predefined default maximum value.

[0285] The eNB 200 may broadcast (e.g., through SIB transmission) a minimum value of the timer value that the UE 100 can set. The UE 100 determines a timer value that is equal to or greater than the minimum value broadcasted from the eNB 200, and notifies the eNB 200 of the determined timer value. However, when the UE 100 determines the minimum value broadcasted from the eNB 200 as the timer value, the UE 100 may not notify the eNB 200 of the determined timer value. When the timer value is not notified from the UE 100, the eNB 200 may assume that the UE 100 has determined the minimum value. Note that when the minimum value is not specified from the eNB 200 through broadcast, the UE 100 may determine a timer value that is equal to or greater than the default minimum value using a predefined default minimum value.

[0286] In step S703, when transmitting Msg3, UE 100 activates (initializes) a second timer in which the determined timer value is set.

[0287] In step S704 , the eNB 200 transmits the data received from the UE 100 through the Msg3 to the server 50 .

[0288] In step S705 , the server 50 transmits response data (TCP ACK) to the eNB 200 .

[0289] In step S706, the eNB 200 transmits Msg4 having response data (TCPACK) to the UE 100 through downlink early data transmission.

[0290] exist Fig.17 In the sequence, it is assumed that Msg3 transmission is successful. However, it is also assumed that Msg3 transmission fails, HARQ NACK (retransmission request) is transmitted from eNB 200 to UE 100, and UE 100 performs Msg3 retransmission by HARQ. When Msg3 retransmission is performed by HARQ after activating the second timer, UE 100 can continue the operation of the second timer without restarting (reactivating) the second timer. Therefore, the mismatch between the TCPACK waiting time set by the higher layer based on the round-trip time and the Msg4 waiting time set by the access layer can be avoided. Alternatively, after activating the second timer, UE 100 can restart (reactivate) the second timer when performing Msg3 retransmission by HARQ.

[0291] In the operation of the above modification example 14, it is assumed that the first timer is "T300" or "contention resolution timer", and the second timer is a new timer for early data transmission. That is, it is assumed that the first timer for the random access procedure for performing early data transmission and the second timer for the random access procedure for not performing early data transmission are defined as separate timers.

[0292] Here, "T300" is a timer that defines the maximum waiting time when UE 100 transmits Msg3 and then receives Msg4 (specifically, RRC message) in the random access procedure (or RRC connection establishment procedure), and is managed in the RRC layer. "Content resolution timer" is a timer that defines the maximum waiting time when UE 100 transmits Msg3 and then receives Msg4 (specifically, MAC CE) in the random access procedure, and is managed in the MAC layer.

[0293] However, instead of introducing such a new timer (second timer), two types of timer values ​​are defined as the timer value for setting the first timer ("T300" or "contention resolution timer"), so that an operation similar to that of the above-mentioned modification example 14 can be achieved. Therefore, compared with the case where a new timer is introduced, the influence of the system specification change can be reduced. In addition, instead of setting two timers (first timer and second timer), only one timer (first timer) needs to be set, so the processing load on UE 100 is also reduced.

[0294] In the following Modification Example 14, an operation when two types of timer value definitions are defined as the timer value for setting the first timer will be described. Here, "T300" is exemplified as the first timer, but the first timer may be a "contention resolution timer".

[0295] In this case, the eNB 200 transmits a first timer value for a random access procedure without early data transmission and a second timer value for a random access procedure with early data transmission to the UE 100. The second timer value is a value greater than the first timer value. Alternatively, the second timer value is a value less than the first timer value.

[0296] The eNB 200 transmits the first timer value and the second timer value by broadcasting. For example, the eNB 200 transmits "T300" (the first timer value) as an existing information element in the SIB and "T300-EDT" as a new information element in the SIB through the SIB. The eNB 200 may include the first timer value and the second timer value in the same SIB, or may include the first timer value and the second timer value in different SIBs.

[0297] In response to determining to perform early data transmission, the UE 100 selects a second timer value from among the first timer value and the second timer value, and sets the selected second timer value in the first timer. When transmitting uplink data through early data transmission, the UE 100 starts a timer (first timer) for setting the second timer value. Specifically, transmitting uplink data through early data transmission means that the UE 100 transmits uplink user data when transmitting Msg3.

[0298] Fig.18 is a diagram showing an operation when two types of timer values ​​are defined.

[0299] like Fig.18 As shown in FIG. 1 , the eNB 200 transmits the first timer value and the second timer value by broadcasting in step S751. The eNB 200 transmits the first timer value and the second timer value at a predetermined period.

[0300] In step S752, the UE 100 in the RRC idle mode detects that uplink data to be transmitted to the network is generated, and determines that it is necessary to start a random access procedure.

[0301] In step S753, UE 100 determines whether to perform early data transmission (EDT). For example, when the amount of uplink data to be transmitted is equal to or less than the maximum uplink data amount (transport block size) set by broadcast from eNB 200, UE 100 determines to perform EDT.

[0302] When it is determined not to perform early data transmission but to perform a normal random access procedure (step S753: No), in step S754, UE 100 selects a first timer value and sets the first timer value in a timer (first timer). In step S755, UE 100 starts a normal random access procedure.

[0303] On the other hand, when UE 100 determines to perform early data transmission (step S753: Yes), in step S756, UE 100 selects a second timer value and sets the second timer value in the timer (first timer). In step S757, UE 100 starts a random access procedure with early data transmission.

[0304] When the random access procedure starts, in step S758, the UE 100 and the eNB 200 transmit and receive Msg1 and Msg2. The UE 100 and the eNB 200 may change the contents of Msg1 and Msg2 depending on whether early data transmission is involved.

[0305] In step S759, the UE 100 transmits Msg3 to the eNB 200. When performing early data transmission, the UE 100 transmits Msg3 having uplink data to the eNB 200. The UE 100 starts a timer (first timer) when transmitting the Msg3.

[0306] In step S760, UE 100 determines whether Msg4 has been received normally from eNB 200. When Msg4 is received normally from eNB 200 (step S760: Yes), in step S761, UE 100 stops the timer (first timer), terminates the random access procedure, or terminates the random access procedure after transmitting an RRC connection completion message. When UE 100 performs a normal random access procedure, UE 100 transitions to RRC connected mode. On the other hand, when performing early data transmission, UE 100 maintains RRC idle mode without transitioning to RRC connected mode. Note that the fact that UE 100 receives Msg4 normally from eNB 200 may mean that UE 100 decodes Msg4 addressed to UE 100 received from eNB 200 and can obtain the content of Msg4.

[0307] On the other hand, when the timer (first timer) has expired without normally receiving Msg4 from eNB 200 (step S760: No, step S762: Yes), in step S763, UE 100 restarts the random access procedure from the beginning or terminates the random access procedure.

[0308] Note that Fig.18 In the process of , the UE 100 determines whether to perform early data transmission before starting the random access procedure (step S753). However, the UE 100 transmits an early data transmission (EDT) indication through Msg1, or transmits an EDT indication using a physical random access channel (PRACH) setting for early data transmission (EDT), and in the case where the UE 100 is allowed to perform early data transmission (EDT) through Msg2, in the case where an EDT grant including resources about early data transmission is received through Msg2, in the case where a DCI for early data transmission (EDT) is received, or in the case where a UL grant including uplink resources sufficient for early data transmission (EDT) is received, when the UE 100 performs uplink early data transmission (UL EDT) through Msg3 (transmitting user data together with Msg3), it can be determined that the UE 100 performs (is performing) early data transmission. In this case, the UE 100 sets a timer value in a timer (first timer) after receiving Msg2, and does not set a timer value in the timer (first timer) before receiving Msg2.

[0309] Note that in any of the above cases, UE 100 may determine to perform early data transmission. That is, in the above cases, in one of the cases where UE 100 transmits Msg1, the case where UE 100 receives Msg2, or the case where UE 100 transmits Msg3, UE 100 determines to perform (is performing) early data transmission.

[0310] (Modified Example 15)

[0311] In the above-mentioned modification example 14, an example has been described in which a higher layer ACK is transmitted from the eNB 200 to the UE 100 through Msg4. In this case, after transmitting Msg3, the UE 100 should continue to monitor the PDCCH for each subframe until the UE 100 receives Msg4 (or until the second timer expires). In particular, when the ACK of the higher layer is delayed, there is a problem of increased power consumption because the UE 100 continuously monitors the PDCCH.

[0312] In Modification Example 15, the eNB 200 transmits Msg4 to the UE 100 without waiting for the arrival of the ACK of the higher layer, so the UE 100 can stop continuously monitoring the PDCCH. In addition, the eNB 200 notifies the UE 100 through Msg4 that the data (ACK of the higher layer) is scheduled to be transmitted to the UE 100 after the transmission of Msg4. The Msg4 transmission may include the transmission of information indicating that the UE 100 remains in the RRC idle mode. Therefore, the UE 100 can wait for the reception of downlink data while maintaining the RRC idle mode. That is, when receiving Msg4, the UE 100 waits for the reception of downlink data (ACK of the higher layer) without converting to the RRC connected mode. While waiting for the downlink data, the UE 100 can monitor the PDCCH intermittently in discontinuous subframes by discontinuous reception (DRX).

[0313] Fig.19 is a diagram showing an example of the operation of Modification Example 15. Fig.19 In the example, a server 50 is provided in a network higher than the core network (EPC) (for example, the Internet). Fig.19 In the figure, a network entity (eg, S-GW) between the eNB 200 and the server 50 is not shown.

[0314] like Fig.19 As shown in FIG. 7 , in step S711 , UE 100 transmits Msg3 having data to eNB 200 through uplink early data transmission.

[0315] In step S712 , the eNB 200 transmits the data received from the UE 100 through the Msg3 to the server 50 .

[0316] In step S713, the eNB 200 transmits Msg4 to the UE 100. The eNB 200 transmits to the UE 100 through Msg4: information indicating that the UE 100 is kept in the RRC idle mode; and a notification indicating that downlink data transmission (i.e., downlink early data transmission) is scheduled to be performed after the transmission of Msg4. The eNB 200 determines whether to perform downlink early data transmission, for example, by any one of the following methods 1) to 3).

[0317] 1) The eNB 200 learns past traffic patterns and the like, and determines whether to perform downlink early data transmission based on the results of the learning.

[0318] 2) The downlink early data transmission indication is notified from the MME to the eNB 200, and the eNB 200 determines whether to perform downlink early data transmission based on the notification from the MME.

[0319] 3) The eNB 200 is notified from the UE 100 through Msg3 that downlink early data transmission may occur (whether there is an ACK of a higher layer), and the eNB 200 determines whether to perform downlink early data transmission based on the notification from the UE 100.

[0320] The notification transmitted from the eNB 200 to the UE 100 through Msg4 may include information indicating the expected timing (eg, after 10 seconds) when downlink early data transmission occurs. The notification may be included in a MAC CE, or may be included in an RRC message.

[0321] In step S714, the UE 100 having received the Msg4 may activate a timer that defines a reception waiting time for downlink data. The timer value (threshold) of the timer may be set to the UE 100 from the eNB 200 through SIB, Msg4 or Msg2. When the timer expires without receiving downlink data, the UE 100 may terminate waiting for downlink data.

[0322] In step S715, UE 100 starts DRX and monitors PDCCH intermittently. Configuration information of DRX may be notified from eNB 200 to UE 100 through SIB or Msg4. DRX operation may be operation according to DRX in RRC connected mode or operation according to DRX in RRC idle mode.

[0323] The case where operation complies with DRX in RRC connected mode will be described. The DRX cycle set from eNB200 to UE 100 in the DRX started in step S715 is preferably longer than the DRX cycle that can be set in DRX in RRC connected mode. Currently, the maximum value of the DRX cycle in RRC connected mode is the time corresponding to 1024 radio frames (i.e., 10.24 seconds). As a method of setting the DRX cycle to be greater than 10.24 seconds, one of the following methods a) and b) can be used by applying an extended DRX (eDRX) mechanism. In eDRX, a superframe is introduced. A superframe is a time unit having a time length of 1024 radio frames. The current superframe number (H-SFN) is broadcast from eNB 200 via the SIB.

[0324] a) UE 100 determines an H-SFN satisfying "H-SFN mod m = 0" as a reception H-SFN. eNB 200 sets the value "m" in the calculation formula in UE 100. UE 100 performs DRX operation in a normal RRC connection mode within the determined reception H-SFN. Specifically, UE 100 wakes up in the set DRX cycle and monitors PDCCH in the awake state. UE 100 can maintain a sleep state (i.e., a state of not monitoring PDCCH) in an H-SFN that does not satisfy "H-SFN mod m = 0".

[0325] b) The UE 100 uses two consecutive superframes as a group, and may correspond to a DRX cycle having a length of 1024 radio frames or longer. One superframe consists of 1024 radio frames having radio frame numbers (SFNs) ranging from 0 to 1023. The UE 100 counts SFNs from 0 to 1023 in the first superframe constituting one group (e.g., the even-numbered superframe), and then counts the first radio frame in the second superframe constituting the one group (e.g., the odd-numbered superframe) as SFN=1024, and counts the second radio frame of the second superframe as SFN=1025. In this way, the UE 100 continues counting by allowing the second superframe to continue the SFN count value in the first superframe. Therefore, the UE 100 can perform a DRX operation using a DRX cycle having a time longer than the time of 1024 radio frames (i.e., 10.24 seconds).

[0326] Next, the case where the operation in RRC idle mode complies with DRX will be described. In order to determine DRX in the conventional RRC idle mode, the DRX cycle and the International Mobile Subscriber Identity (IMSI) of the UE 100 are used. The IMSI is used to allocate paging opportunities (i.e., the timing of PDCCH monitoring) between multiple UEs. However, during the random access procedure, it is assumed that the eNB 200 has not yet acquired the IMSI of the UE 100. On the other hand, since Msg3 includes the SAE Temporary Mobile Subscriber Identity (S-TMSI) or the Recovery ID, the eNB 200 can acquire the S-TMSI or the Recovery ID of the UE 100 during the random access procedure. Therefore, the eNB 200 and the UE 100 use the S-TMSI or the Recovery ID instead of the IMSI to determine the paging opportunity.

[0327] In step S716 , the server 50 transmits response data (TCP ACK) to the eNB 200 .

[0328] In step S717, the eNB 200 transmits response data (TCPACK) to the UE 100 through downlink early data transmission. The UE 100 receives the downlink data.

[0329] Note that, when TCP NACK is received as downlink data, the UE 100 can start a random access procedure and perform uplink early data transmission.

[0330] exist Fig.19 In the operation of the UE 100, from the transmission of Msg3 with data (step S711) to the reception of the downlink data transmission notification (step S713), the UE 100 operates the "T300" timer managed in the RRC layer and / or the "contention resolution timer" managed in the MAC layer, and continuously monitors the PDCCH. Then, the UE 100 activates the timer (step S714) in response to the downlink data transmission notification (step S713), and performs the DRX operation while the timer is operating (step S715).

[0331] Even when data transmission notification is not introduced, the two-stage timer can be used to switch the reception operation.

[0332] Such an operation includes the following steps: during a random access procedure, the UE 100 transmits an RRC message (Msg3) to the eNB 200 and performs early data transmission for transmitting user data; the UE 100 activates a first timer in response to the execution of the early data transmission; the UE 100 performs a first reception operation of continuously monitoring a downlink control channel (PDCCH) during the operation of the first timer; the UE 100 activates a second timer in response to the expiration of the first timer; and the UE 100 performs a second reception operation different from the first reception operation during the operation of the second timer. Compared with the first reception operation, the second reception operation is a reception operation with a lower frequency of monitoring the downlink control channel. For example, the second reception operation is an intermittent reception (DRX) operation of intermittently monitoring the downlink control channel (PDCCH).

[0333] Here, the first timer may be a "T300" timer managed in the RRC layer or a "contention resolution timer" managed in the MAC layer. Typically, when the "T300" timer or the "contention resolution timer" expires without receiving a response (e.g., Msg4) from the eNB 200, the UE 100 determines that the random access procedure has failed (contention resolution failure, etc.), thereby restarting the random access procedure. However, when early data transmission is performed, even if the first timer (the "T300" timer or the "contention resolution timer") expires, the UE 100 continues the random access procedure without determining that the random access procedure has failed.

[0334] Alternatively, the first timer may be a new timer different from the "T300" timer and the "contention resolution timer." When performing early data transmission, the UE 100 activates such a new timer without activating the "T300" timer and the "contention resolution timer" (see Modification Example 14).

[0335] On the other hand, when the notification of downlink data transmission is introduced, the eNB 200 receives the RRC message and user data from the UE 100, and then transmits the notification of downlink data transmission (predetermined message) to the UE 100 (step S713). The UE 100 stops the first timer in response to receiving the predetermined message while the first timer is operating, and stops the first receiving operation. The UE 100 activates the second timer in response to stopping the first timer (stopping the first receiving operation).

[0336] Note that the contention resolution of the MAC layer in Msg4 can be used as a predetermined message. A tag (1-bit identifier) ​​indicating a data transmission notification can be added to the contention resolution. The eNB 200 transmits the RRC connection establishment message of the RRC layer in Msg4 to the UE 100 together with the downlink data when transmitting downlink data (step S717).

[0337] (Modified Example 16)

[0338] Modification Example 16 is a modification example related to Modification Example 14 and Modification Example 15. In Modification Example 16, the difference between Modification Example 14 and Modification Example 15 is mainly described.

[0339] In Modification Example 16, UE 100 performs uplink early data transmission using Msg3. UE 100 activates a timer in response to the execution of early data transmission, the timer defining a waiting time for waiting to receive a response transmitted from eNB 200. The "timer" may be the first timer or the second timer according to Modification Example 14, or may be a timer according to Modification Example 15. The "response transmitted from eNB 200" may be Msg4 with data transmitted from eNB 200, or Msg4 without data transmitted from eNB 200 (see Modification Example 14), and may be data transmitted after Msg4 (notification) is transmitted from eNB 200 (see Modification Example 15).

[0340] Then, UE 100 removes monitoring of PDCCH until the PDCCH monitoring timing determined based on the termination timing of the waiting time corresponding to the timer. For example, UE 100 monitors PDCCH only in the subframe when the timer expires. Therefore, since the receiving device of UE 100 can be turned off when the timer is operating, the power consumption of UE 100 can be reduced.

[0341] The UE 100 may monitor the PDCCH only in a subframe immediately after the timer expires (i.e., the next subframe of the subframe when the timer expires) or in a subframe after a specified time has passed after the timer expires, instead of monitoring the PDCCH in the subframe when the timer expires. Alternatively, the UE 100 may monitor the PDCCH only in a subframe immediately before the timer expires (i.e., the previous subframe of the subframe when the timer expires) or in a subframe before a specified time of the subframe when the timer expires, instead of monitoring the PDCCH in the subframe when the timer expires.

[0342] Alternatively, the UE 100 may monitor the PDCCH only in a plurality of timings (a plurality of subframes) determined based on the time at which the timer expires. For example, the UE 100 may monitor the PDCCH only in the subframe at which the timer expires and in the subframe immediately after the timer expires or in the subframe after a specified time has passed after the timer expires. For example, the UE 100 may monitor the PDCCH only in the subframe at which the timer expires and in the subframe immediately before the timer expires or in the subframe before a specified time of the subframe at which the timer expires.

[0343] Note that the eNB 200 knows the timer value set in the UE 100 and can estimate the PDCCH monitoring timing in the UE 100. When the eNB 200 transmits a response (e.g., Msg4 with data) to the UE 100 at the PDCCH monitoring timing, the UE 100 can receive the response at the PDCCH monitoring timing.

[0344] The UE 100 may perform the operation according to Modification Example 16 only when at least one of the following conditions is satisfied. These conditions may be applied only when the normal timer (T300, contention resolution timer) is used.

[0345] Condition 1: Early data transmission indication (EDT indication) is notified in Msg1

[0346] Condition 2: An uplink grant for early data transmission (larger than a normal uplink grant) is received in Msg2

[0347] Condition 3: Early data transmission is implemented in Msg3 (data transmission)

[0348] (Modified Example 17)

[0349] In the above-described first embodiment, an example has been described in which the eNB 200 sets the maximum value of the amount of data that can be transmitted by the UE 100 in uplink early data transmission in the UE 100. Therefore, the UE 100 determines whether all of its own uplink data can be transmitted through the uplink early data transmission, and if it is determined that all of the uplink data can be transmitted, the UE 100 can start the early data transmission, and if it is determined that all of the uplink data cannot be transmitted, the UE 100 does not start the early data transmission.

[0350] As described above, when downlink early data transmission using Msg4 follows uplink early data transmission using Msg3, early data transmission may be applied only when only one set of uplink (Msg3) and downlink (Msg4) can complete data transmission / reception. Therefore, UE 100 may also determine whether all downlink data of its own can be received through downlink early data transmission, and may start early data transmission only when it is determined that all downlink data can be received.

[0351] In Modification Example 17, an example in which eNB 200 sets the maximum value of the amount of data that UE 100 can receive in downlink early data transmission in UE 100 will be mainly described. In Modification Example 17, it is assumed that uplink early data transmission is performed using Msg3 and downlink early data transmission is performed using Msg4.

[0352] In Modification Example 17, the eNB 200 transmits information related to the data amount condition in the early data transmission to the UE 100 through a broadcast message (SIB). For example, the eNB 200 transmits information indicating the maximum value (maximum transport block size) of the downlink data amount that can be transmitted by the eNB 200 in the early data transmission as the information on the data amount condition. Note that by transmitting the broadcast message (SIB) including the information on the data amount condition by the eNB 200, the UE 100 can receive the broadcast message even if it is in the RRC idle mode.

[0353] UE 100 receives information about data amount conditions from eNB 200. In addition, UE 100 estimates the amount of downlink user data to be received from eNB 200 in early data transmission. For example, UE 100 estimates the amount of downlink user data to be received from eNB 200 based on the type of application executed by UE 100, etc. Specifically, UE 100 estimates the amount of downlink user data based on the protocol configuration of the application that can use early data transmission. For example, in the case of an application using a TCP layer, UE 100 estimates the amount of ACK data of TCP as the amount of downlink user data. In addition, when there is a data reception completion response from a server in the application layer, the amount of response data is added to the amount of downlink user data. The estimation can be performed in the application layer, and the amount of downlink user data can be notified from the application layer to the NAS layer and / or the AS layer. Alternatively, when the estimation is performed in the NAS layer and / or the AS layer, the history of past application layer behaviors is retained, so the amount of downlink user data can be estimated from the past behaviors included in the history.

[0354] When the estimated amount of downlink user data satisfies the condition regarding the amount of data, the UE 100 starts early data transmission. For example, when the estimated amount of downlink user data is equal to or less than the maximum amount of downlink data set from the eNB 200, the UE 100 starts early data transmission. On the other hand, when the estimated amount of downlink user data exceeds the maximum amount of downlink data transmitted and set from the eNB 200, the UE 100 starts a normal random access procedure without starting early data transmission.

[0355] For example, the eNB 200 may transmit information indicating the minimum value (minimum transport block size) of the amount of downlink data that can be transmitted by the eNB 200 in early data transmission as information about the data amount condition. For example, when the estimated amount of downlink user data is equal to or greater than the minimum amount of downlink data set from the eNB 200, the UE 100 starts early data transmission. On the other hand, when the estimated amount of downlink user data exceeds the minimum amount of downlink data set from the eNB 200, the UE 100 starts a normal random access procedure without starting early data transmission. Although the details will be described in the second embodiment, if the amount of data is small, the padding bits increase and the efficiency decreases, and therefore, the eNB 200 allocates the necessary minimum resources to the UE 100 after the transition to the RRC connection mode, thereby suppressing the increase in the padding bits. In addition, if the transition to the RRC connection mode is made, it is possible to perform, for example, an advanced process of multiplexing data of a plurality of UEs into one resource or transport block, or a process of transmitting data together with other signaling in a single UE.

[0356] Alternatively, when the estimated downlink user data amount is less than the minimum downlink data amount set from the eNB 200, the UE 100 may maintain the RRC idle mode without starting the random access procedure.

[0357] Fig. 20 is a diagram illustrating an example of the operation of Modification Example 17.

[0358] like Fig. 20 As shown in FIG. 1 , in step S771 , the eNB 200 transmits information about the maximum downlink data amount by broadcasting, the information indicating the maximum downlink data amount in early data transmission. The UE 100 in the RRC idle mode receives the information about the maximum downlink data amount from the eNB 200 .

[0359] The eNB 200 may also transmit information about the maximum uplink data amount, which indicates the maximum uplink data amount in early data transmission, by broadcasting. The UE 100 in the RRC idle mode receives the information about the maximum uplink data amount from the eNB 200.

[0360] In step S772, the UE 100 detects a start trigger of the random access procedure, such as the generation of uplink data to be transmitted in the UE 100, the reception of a paging message by the UE 100, and the like.

[0361] In step S773, UE 100 estimates the amount of downlink user data to be received in early data transmission from eNB 200. Specifically, UE 100 estimates the amount of downlink user data transmitted to UE 100 when Msg4 is transmitted from eNB 200.

[0362] In step S774, the UE 100 determines whether the estimated amount of downlink user data is equal to or less than the maximum amount of downlink data set from the eNB 200. When the estimated amount of downlink user data is equal to or less than the maximum amount of downlink data (step S774: Yes), in step S775, the UE 100 starts a random access procedure with early data transmission. On the other hand, when the estimated amount of downlink user data exceeds the maximum amount of downlink data (step S774: No), in step S776, the UE 100 starts a random access procedure without early data transmission.

[0363] Note that in step S774, the UE 100 may also determine whether the amount of uplink user data to be transmitted is equal to or less than the maximum uplink data amount set from the eNB 200. When the estimated amount of downlink user data is equal to or less than the maximum downlink data amount, and the estimated amount of uplink user data is equal to or less than the maximum uplink data amount, the UE 100 starts a random access procedure with early data transmission. Otherwise, the UE 100 starts a normal random access procedure without early data transmission.

[0364] Note that when the maximum uplink data amount and the maximum downlink data amount in early data transmission are defined to be the same, the eNB 200 may not notify the UE 100 of the maximum downlink data amount. In this case, when the estimated downlink data amount is equal to or less than the maximum uplink data amount set from the eNB 200, the UE 100 may determine that early data transmission is possible.

[0365] exist Fig. 20 In the example in which the eNB 200 transmits the information about the maximum downlink data amount by broadcast, which indicates the maximum downlink data amount in early data transmission, has been described. However, the eNB 200 may transmit the information about the maximum downlink data amount by unicast. When transmitting such a unicast message, the eNB 200 may set a condition about the data amount for each UE.

[0366] For example, when the UE 100 is in the RRC connection mode, the eNB 200 transmits an RRC connection release message including information about the maximum amount of downlink data to the UE 100. The UE 100 transitions to the RRC idle mode in response to receiving the RRC connection release message, and stores the information about the maximum amount of downlink data. Here, the eNB 200 may transition the UE 100 to a suspended state, which is a sub-state of the RRC idle mode. In the suspended state, the context information of the UE 100 is stored in the eNB 200.

[0367] UE 100 starts a random access procedure in RRC idle mode. When UE 100 is in the suspended state, eNB 200 refers to the context information of UE 100 during the random access procedure and recognizes that the maximum downlink data amount is set in UE 100. On the other hand, when UE 100 is not in the suspended state, since eNB 200 does not have the context information of UE 100, the fact that the maximum downlink data amount has been set and / or the set maximum downlink data amount are notified from UE 100 to eNB 200 during the random access procedure (for example, when Msg3 is transmitted).

[0368] (Modified Example 18)

[0369] As described above, when the eNB 200 sets the maximum data amount (maximum transport block size) in the early data transmission in the UE 100, it is difficult for the eNB 200 to determine the optimal maximum data amount. Specifically, the amount of data (transport block size) transmitted and received by the UE 100 through the early data transmission varies according to the type or situation of the application executed by the UE 100. If the maximum data amount in the early data transmission is set too much, useless resources may be generated. On the other hand, if the maximum data amount in the early data transmission is set too little, the UE 100 that intends to transmit and receive data exceeding the maximum transport block size will not be able to use the early data transmission, and thus the effect of reducing power consumption and delay brought about by the early data transmission is affected.

[0370] In Modification Example 18, UE 100 determines the amount of user data to be transmitted and received in early data transmission. For example, UE 100 determines the amount of uplink data that UE 100 intends to transmit through uplink early data transmission. In addition to or in lieu of such determination, UE 100 may determine the amount of downlink data that UE 100 intends to receive through downlink early data transmission. Then, when UE 100 is in RRC connected mode, UE 100 transmits information indicating the maximum amount of data (maximum transport block size) recommended by UE 100 to eNB 200 based on the determined amount of user data. The recommended maximum amount of data may be a recommended maximum uplink data amount or a recommended maximum downlink data amount.

[0371] The notification of the maximum data amount may be performed only by the UE 100 having the capability to perform early data transmission. In this case, the eNB 200 may save the notification from the UE 100 as UE capability information in the UE context.

[0372] The eNB 200 collects information about the recommended maximum data amount for early data transmission from a large number of UEs 100, and performs statistical processing on the collected information, thereby determining the optimal maximum data amount in the early data transmission. For example, the eNB 200 collects information about the recommended maximum data amount for uplink early data transmission, and determines the optimal maximum data amount for uplink early data transmission based on the collected information. The eNB 200 may collect information about the recommended maximum data amount for downlink early data transmission, and determine the optimal maximum data amount for downlink early data transmission based on the collected information. After determining the optimal maximum data amount, the eNB 200 sets the determined maximum data amount in the UE 100. For example, the eNB 200 sets the maximum data amount in the UE 100 located in the cell of the eNB 200 by broadcasting information indicating the determined maximum data amount.

[0373] Fig.21 is a diagram showing an example of the operation of Modification Example 18. Here, an example of notifying the eNB 200 of the recommended maximum uplink data amount in early data transmission using Msg3 from the UE 100 will be described. Note that in the following example, the recommended maximum uplink data amount is described as an example, but the recommended maximum downlink data amount may be applied instead.

[0374] like Fig.21As shown in , in step S781, the eNB 200 transmits information requesting or setting the following operation to the UE 100: transmission of notification of the recommended maximum uplink data amount in early data transmission. The eNB 200 may include the information in: Msg4 (RRC connection establishment message) in the random access procedure, measurement configuration as a unicast message, UE information request message and / or minimization of drive test (MDT) setup message. Alternatively, the eNB 200 may notify the UE 100 of the information allowing or requesting the notification through a broadcast message. However, step S781 is not necessary and may be omitted.

[0375] In step S782, the UE 100 determines the recommended maximum uplink data amount in early data transmission. For example, the UE 100 stores the uplink data amount when performing a random access procedure according to the generation of uplink data, and determines the stored uplink data amount as the recommended maximum uplink data amount.

[0376] In step S783, the UE 100 transmits information indicating the determined recommended maximum uplink data amount to the eNB 200. The UE 100 may include the information in a measurement report, or may include the information in Msg5 (RRC connection establishment complete or RRC connection recovery complete) of the random access procedure or in a UE information response message. Note that the RRC connection establishment complete and the RRC connection recovery complete may be located using a message transmitted from the UE 100 to the eNB 200 immediately after the random access procedure.

[0377] In addition, when the amount of uplink data generated in the UE 100 in the RRC idle mode exceeds the maximum uplink data amount set by the eNB 200, the UE 100 may start a normal random access procedure without early data transmission and store the uplink data amount. After transitioning to the RRC connected mode through the normal random access procedure, the UE 100 may notify the eNB 200 of the stored uplink data amount as the recommended maximum uplink data amount.

[0378] In step S784, the eNB 200 determines the optimal maximum uplink data amount based on the recommended maximum uplink data amount notified from the UE 100. After determining the optimal maximum uplink data amount, the eNB 200 sets the maximum uplink data amount in the UE 100 located in the cell of the eNB 200 by broadcasting the determined maximum uplink data amount.

[0379] Alternatively, the eNB 200 is not limited to the case of setting the maximum data amount (maximum uplink data amount) in the UE 100 by broadcasting, but may set the maximum data amount in the UE 100 by unicast (for example, RRC connection release). In this case, the eNB 200 determines the optimal maximum data amount for the UE 100 based on the recommended maximum data amount notified from the UE 100, and sets the determined maximum data amount in the UE 100 by unicast.

[0380] Note that in this modification example, an example has been described in which the eNB 200 determines the maximum uplink data amount to be set in the UE 100 based on the recommended maximum uplink data amount notified from the UE 100. However, although the details will be described in the second embodiment, a plurality of blind decoding thresholds may be set in the UE 100 within the range of the maximum uplink data amount. Specifically, the UE 100 determines a minimum blind decoding threshold that is larger than the amount of user data transmitted by the UE 100, and fills the insufficient portion with respect to the determined blind decoding threshold with padding data. Therefore, in order to reduce padding data, the eNB 200 may determine the blind decoding threshold to be set in the UE 100 based on the recommended maximum uplink data amount notified from the UE 100.

[0381] [Second embodiment]

[0382] The difference between the second embodiment and the first embodiment will be mainly described. In the second embodiment, it is assumed that uplink early data transmission is performed using Msg3 during the random access procedure. During the random access procedure, in addition to transmitting an RRC message (RRC connection request message or RRC connection recovery request message) to the eNB 200, the UE 100 also performs user data transmission.

[0383] During the random access procedure, the eNB 200 transmits to the UE 100 a Msg2 (Random Access Response) including an uplink grant that allocates uplink radio resources to the UE 100. When the UE 100 transmits user data accompanying the RRC message (Msg3) to the eNB 200, the size of the allocated data corresponding to the uplink radio resources allocated to the UE 100 (i.e., the transport block size) preferably matches the total size of the RRC message and the user data. Note that the transport block size is determined by the amount of uplink radio resources allocated by the uplink grant (e.g., the number of resource blocks) and the MCS. The eNB 200 performs a decoding process based on an assumption of the transport block size allocated to the UE 100.

[0384] However, the transport block size allocated to the UE 100 does not necessarily match the total size of the RRC message and the user data. When the transport block size allocated to the UE 100 is larger than the total size of the RRC message and the user data, the UE 100 needs to transmit padding data within the additionally allocated uplink radio resources so that the eNB 200 can appropriately perform the decoding process. Here, when there is a large amount of additionally allocated uplink radio resources, there is a problem that the UE 100 needs to transmit a large amount of padding data, and in order to transmit the padding data, the power consumption of the UE 100 is increased. The second embodiment is an embodiment for solving such a problem.

[0385] (1) Operation mode 1

[0386] In operation mode 1 of the second embodiment, during the random access procedure, the eNB 200 transmits an uplink grant allocating periodic uplink radio resources to the UE 100. Such resource allocation may be referred to as semi-persistent scheduling (SPS). However, conventional SPS is not applied during the random access procedure.

[0387] In the SPS of the operation mode 1 according to the second embodiment, the configuration information of the SPS (e.g., the uplink transmission period) is included in the SIB transmitted by the eNB 200 to the UE 100. In addition, in the operation mode 1, the uplink grant transmitted to the UE 100 through the Msg2 includes information on the uplink radio resources (resource blocks) allocated to the UE 100, and activates the SPS. That is, the uplink grant allocates periodic uplink radio resources to the UE 100.

[0388] In response to receiving the uplink grant, the UE 100 performs uplink transmission multiple times using periodic uplink radio resources during the random access procedure. Specifically, the UE 100 performs uplink transmission using uplink radio resources allocated by the uplink grant according to the uplink transmission period according to the SPS configuration information.

[0389] In this way, UE 100 can perform uplink transmission multiple times, so that the amount of uplink radio resources used for one uplink transmission becomes smaller. In addition, UE 100 can transmit RRC messages and user data at different timings (different subframes). For example, in performing uplink transmission multiple times, UE 100 transmits at least RRC messages in the first uplink transmission, and transmits at least a portion of user data in the second uplink transmission. Therefore, UE 100 does not need to transmit a large amount of padding data.

[0390] In addition, in the operation mode 1 of the second embodiment, the eNB 200 transmits information for setting the maximum number of uplink transmissions using the periodic uplink radio resource to the UE 100. Therefore, the eNB 200 can appropriately understand the number of times the decoding process is performed on the uplink data. The eNB 200 may transmit the information for setting the maximum number of transmissions through the SIB, or may transmit the information through the uplink grant (Msg2). The UE 100 performs uplink transmission multiple times within a range not exceeding the set maximum number of transmissions.

[0391] Fig. 22 1 is a diagram showing an example of operation mode 1 of the second embodiment. In an initial state, UE 100 is in RRC idle mode.

[0392] like Fig. 22 As shown in FIG. 8 , in step S801, the eNB 200 transmits the configuration information of the SPS through the SIB. The UE 100 receives and stores the configuration information of the SPS. The eNB 200 may transmit the information for setting the maximum number of transmissions through the SIB. Here, it will be described assuming that the maximum number of transmissions is three times.

[0393] In step S802 , UE 100 transmits a random access preamble ( Msg1 ) to eNB 200 .

[0394] In step S803, the eNB 200 transmits a random access response (Msg2) to the UE 100, the random access response (Msg2) including an uplink grant for activating SPS. The uplink grant includes information about uplink radio resources (resource blocks) to be used for one uplink transmission. Here, the one-time resource allocation size (transmission block size) may match the size of the RRC message. The eNB 200 may transmit information for setting the maximum number of transmissions (three times) through Msg2.

[0395] In step S804 (first uplink transmission), UE 100 transmits an RRC message (Msg3) to eNB 200 using the allocated uplink radio resources (resource blocks) in response to receiving the uplink grant.

[0396] In step S805 (second uplink transmission), UE 100 transmits a part of user data to eNB 200 using the allocated uplink radio resources (resource blocks) in the subframe according to the SPS transmission period.

[0397] In step S806 (third uplink transmission), UE 100 transmits the remaining user data to eNB 200 using the allocated uplink radio resources (resource blocks) in the subframe according to the SPS transmission period. Here, since the number of uplink transmissions reaches the maximum number of transmissions, UE 100 deactivates SPS. In addition, UE 100 may discard the configuration information of SPS.

[0398] In addition, when the user data transmission is completed before the maximum number of transmissions is reached (for example, when all user data is transmitted in step S805), the UE 100 may not perform uplink transmission in the subframe according to the SPS transmission period (timing in step S806). Alternatively, the UE 100 may transmit information indicating the termination of data transmission to the eNB 200 at the time of the last uplink transmission (timing in step S806). Such information (end marker) may also be transmitted by the MAC CE.

[0399] In step S807, the eNB 200 transmits Msg4 to the UE 100. The eNB 200 may notify the UE 100 which uplink transmission is successfully received and / or which uplink transmission fails among multiple uplink transmissions through Msg4. For example, the eNB 200 notifies good reception only in the first time, or notifies good reception after the second time.

[0400] Note that in this operation mode, an example has been described in which UE 100 transmits user data after transmitting an RRC message (including a MAC PDU of an RRC connection request), but UE 100 may first transmit user data and then transmit an RRC message after terminating data transmission. In this case, eNB 200 may recognize that user data transmission has been terminated by receiving the RRC message.

[0401] (2) Operation Mode 2

[0402] In operation mode 2 of the second embodiment, during the random access procedure, the eNB 200 transmits an uplink grant allocating uplink radio resources to the UE 100 through Msg2.

[0403] In response to receiving the uplink grant, the UE 100 performs repeated transmission of the RRC message (Msg3) using the uplink radio resources during the random access procedure. Therefore, the possibility of success of the eNB 200 in the reception process (decoding process) of the RRC message can be increased by providing redundancy to the RRC message. Using the uplink radio resources allocated by the uplink grant, in addition to performing repeated transmission of the RRC message, the UE 100 can also perform repeated transmission of user data. Therefore, redundancy can be provided to the user data.

[0404] In the decoding process, the eNB 200 performs software synthesis of the repeatedly transmitted RRC message and software synthesis of the repeatedly transmitted user data. As described above, in the operation mode 2 of the second embodiment, by performing redundant transmission instead of transmission of padding data, uplink radio resources allocated by the uplink grant can be effectively used.

[0405] HARQ redundancy version

[0406] UE 100 can transmit RRC messages with different HARQ redundancy versions (i.e., redundancy configurations) in repeated transmission of RRC messages. In addition, UE 100 can transmit user data with different HARQ redundancy versions in repeated transmission of user data. Thus, the decoding success rate in eNB 200 can be further improved.

[0407] For example, the UE 100 stores multiple RRC messages (or multiple user data) in different MAC PDUs and transmits a group of multiple MAC PDUs with different HARQ redundancy versions. The MAC PDU includes a MAC header, a MAC CE, and a MAC SDU (see Fig.16 ). The RRC message (or user data) corresponds to the MAC SDU.

[0408] Note that as a first example of redundant transmission, only the MAC SDU may be made redundant, and multiple MAC SDUs may be stored in one MAC PDU and transmitted. In this case, only one redundant version may be provided and the gain due to redundancy may be obtained by the following method. Specifically, when generating a bit string before rate matching, the UE 100 generates the bit string according to the bit length (TBS size 1) corresponding to the size of the RRC message and user data. In the rate matching process, when extracting the bit string to be transmitted from the circular buffer, the UE 100 extracts the bit length corresponding to the resource / MCS allocated by the eNB 200. Therefore, although there is only one redundant version, the gain due to redundancy may be obtained compared to the case where the same portion of the circular buffer is repeated. When eNB 200 defines polling scheduling decoding (blind decoding), TBS size 1 (unknown to eNB 200) is determined at a predetermined ratio such as 3 / 4 of TBS size 2, 1 / 2 of TBS size 2, and 1 / 4 of TBS size 2 according to the bit length corresponding to the resources and MCS allocated by eNB 200 (TBS size 2 known to eNB 200), thereby achieving blind decoding.

[0409] As a second example of redundant transmission, the MAC header may also be redundant, and multiple MAC PDUs with different HARQ redundancy versions may be transmitted.

[0410] Transmission power

[0411] When performing repeated transmission (redundant transmission), the UE 100 can reduce the transmission power compared to the case where repeated transmission is not performed. Therefore, the power consumption of the UE 100 can be reduced.

[0412] The UE 100 adjusts the transmission power according to the number of repeated transmissions. The UE 100 may reduce the transmission power as the number of repeated transmissions increases. For example, when three MAC PDUs are redundantly transmitted, the UE 100 may set the transmission power to one third compared to transmitting one MAC PDU. Note that even if the transmission power is reduced, the transmission power may be compensated by software synthesis gain in the eNB 200.

[0413] ·Specific example of software synthesis 1

[0414] When UE 100 performs repeated transmission, UE 100 may notify eNB 200 that repeated transmission is performed (and / or the number of repeated transmissions). Therefore, eNB 200 may perform appropriate software synthesis.

[0415] As a specific example of such notification, the UE 100 may perform notification using a pattern of an uplink demodulation reference signal (DMRS) in Msg 3. The pattern of the DMRS may be a DMRS signal sequence or a resource arrangement pattern of the DMRS (eg, an arrangement pattern of resource elements).

[0416] The UE 100 changes the pattern of the DMRS according to whether to perform repeated transmission. The UE 100 may change the pattern of the DMRS according to the number of repeated transmissions.

[0417] ·Specific example of software synthesis 2

[0418] Instead of transmitting the notification of repeated transmission, the eNB 200 may attempt a reception process (decoding process) the same number of times as the candidate number of repeated transmissions. Here, the candidate number of repeated transmissions includes zero (ie, repeated transmission is not performed).

[0419] In this way, the eNB 200 decodes the repeatedly transmitted RRC message (and repeatedly transmitted user data) by blind decoding using round-robin decoding. Therefore, the eNB 200 can perform appropriate software synthesis even without notification of repeated transmission.

[0420] In order for the eNB 200 to decode the repeatedly transmitted RRC message (and repeatedly transmitted user data) by blind decoding, the following method is applied. Fig.23 (A) and Fig.23(B) is a diagram showing an example of the repeated transmission method of the operation mode 2 according to the second embodiment.

[0421] When the total size of the RRC message (RRC connection request) and the user data (data) is greater than the allocated data size, the UE 100 performs repeated transmission according to a predetermined repeated transmission mode, such as Fig.23 As shown in (A) of FIG. 2 , the eNB 200 performs blind decoding according to a predetermined repetitive transmission mode.

[0422] exist Fig.23 In the example of (A), the data size allocated by the uplink grant (UL grant) is larger than twice the total size of the RRC message (RRC connection request) and the user data (data). In this case, the size of half the allocated data size is set as a unit, and repeated transmission is performed in units of the unit. In addition, for a portion less than half the size of the allocated data size, padding data is arranged. The eNB 200 sets the size of half the allocated data size as a unit, and performs blind decoding in units of the unit.

[0423] Alternatively, when the total size of the RRC message (RRC Connection Request) and user data (Data) is larger than the allocated data size, UE 100 may only repeat the RRC message. Since the data size of the RRC message is already known, eNB 200 performs blind decoding assuming that only the RRC message is repeatedly transmitted.

[0424] On the other hand, when the total size of the RRC message (RRC Connection Request) and the user data (Data) is smaller than the allocated data size, the UE 100 performs repeated transmission according to a predetermined repeated transmission mode, such as Fig.23 As shown in (B) of . For example, when the allocated data size is twice or more the data size of the RRC message, the UE 100 performs repeated transmission of the RRC message. The UE 100 arranges padding data for the remaining part. The eNB 200 performs blind decoding assuming that only the RRC message is repeatedly transmitted.

[0425] When the total size of the RRC message (RRC Connection Request) and user data (Data) is smaller than the allocated data size, the eNB 200 may attempt to perform decoding on three modes of repeatedly transmitting only the RRC message, transmitting only the RRC message, and transmitting user data together with the RRC message.

[0426] Note that UE 100 may notify eNB 200 of information indicating the applied repetitive transmission mode using a MAC header accompanying an RRC message, a MAC CE, or the like.

[0427] (3) Operation method 3

[0428] In operation mode 3 of the second embodiment, the eNB 200 broadcasts information indicating multiple resource pools that can be used for user data transmission in early data transmission, for example, through SIB. The multiple resource pools differ from each other in the amount of available radio resources (ie, available transport block size).

[0429] When UE 100 performs early data transmission in response to receiving an uplink grant from eNB 200, UE 100 transmits user data using a resource pool selected from a plurality of resource pools. Therefore, since it becomes possible to select a resource pool corresponding to the amount (size) of user data that UE 100 intends to transmit, padding data to be transmitted can be eliminated or reduced. Note that eNB 200 attempts to receive (decode) user data in each resource pool, and receives (decodes) user data in any resource pool.

[0430] The UE 100 may use the selected resource pool to jointly transmit user data and RRC messages. Alternatively, the UE 100 may use the uplink radio resources allocated by the uplink grant to transmit RRC messages, and then may also use the selected resource pool to transmit user data.

[0431] UE 100 may select a resource pool for user data transmission from a plurality of resource pools based on the amount of user data. For example, UE 100 compares the amount of user data (data size) to be transmitted to eNB 200 with the transport block size corresponding to each resource pool and selects the best resource pool.

[0432] UE 100 can select a resource pool in consideration of the priority of user data. For example, when uplink radio resources (resource blocks) for transmission can be selected in the selected resource pool, the larger the resource pool, the lower the possibility of interference due to resource conflicts between UEs 100. Therefore, in the case of high priority, UE 100 can select a larger resource pool. Alternatively, eNB 200 can notify the available priority information of each resource pool. Note that in UE 100, the priority can be specified in a higher layer (e.g., application layer), and the priority can be notified to AS (e.g., RRC layer or MAC layer) from the higher layer. The priority can be set in UE 100 in advance by an application server, or can be set in UE 100 after authentication by MME, etc. In addition, a resource pool can be provided for each CE level.

[0433] Fig.24 : is a diagram showing an example of operation mode 3 of the second embodiment. Fig.24 In the embodiment, one partition in the time direction corresponds to one subframe, and the time direction corresponds to the uplink frequency band.

[0434] First, UE 100 learns the resource pool for user data and the resource pool for random access preamble (Msg1) by receiving SIB. Fig.24 As shown in , UE 100 selects one resource pool from multiple resource pools for random access preambles in subframe SFa, and transmits the random access preamble using the selected resource pool. Fig.24 In the example of , resource pool #1 for random access preamble is associated with resource pool #1 for user data (e.g., size of 1000 bits), and resource pool #2 for random access preamble is associated with resource pool #2 for user data (e.g., size of 100 bits). However, there may be only one resource pool for random access preamble, and the resource pool for random access preamble and the resource pool for user data may not be associated with each other.

[0435] Next, the eNB 200 receives the random access preamble in any resource pool, and transmits a random access response (Msg2) to the UE 100 when the use of the resource pool is allowed. Msg2 includes a temporary identifier (temporary C-RNTI) assigned to the UE 100 by the eNB 200. If the UE 100 receives Msg2, it is assumed that early data transmission is allowed. Then, the UE 100 transmits an RRC message (Msg3) to the eNB 200 in a subframe SFb using the uplink radio resources allocated by the uplink grant in the random access response. The UE 100 includes the temporary identifier (temporary C-RNTI) in the RRC message and transmits it.

[0436] Next, the UE 100 transmits the user data to the eNB 200 using the selected resource pool in the subframe SFc. The UE 100 includes a temporary identifier (temporary C-RNTI) in the user data and transmits it.

[0437] (4) Operation method 4

[0438] In operation mode 4 of the second embodiment, the eNB 200 transmits an uplink grant that allocates uplink radio resources to the UE 100 during a random access procedure. When the allocated data size corresponding to the uplink grant is larger than the total size of the RRC message and the user data, the UE 100 determines whether to perform early data transmission using the uplink radio resources or to transmit only the RRC message using the uplink radio resources. The UE 100 makes this determination based on the amount of padding data required to perform early data transmission. The eNB 200 attempts a reception process (decoding process) for both the case where the UE 100 transmits only the RRC message and the case where the UE 100 performs early data transmission.

[0439] When only an RRC message is transmitted, since the eNB 200 can understand the data size of the RRC message, there is no need for the UE 100 to transmit padding data. On the other hand, when early data transmission is performed, that is, when user data is transmitted together with the RRC message, the eNB 200 cannot understand the amount of user data. For this reason, the UE 100 may be required to transmit padding data in order to perform transmission with the allocated data size.

[0440] For example, the UE 100 determines the amount of padding data required to perform early data transmission based on the allocated data size. When the determined amount of padding data is greater than a threshold, the UE 100 considers that the power consumption caused by the transmission of the padding data is large, and only transmits the RRC message without performing early data transmission. Therefore, the increase in power consumption of the UE 100 due to the transmission of the padding data can be avoided.

[0441] [Other embodiments]

[0442] In the modification examples 1 to 15 of the first embodiment, a combination of the second embodiment with the first embodiment and its modification examples may be implemented, or a combination of two or more modification examples may be implemented. In addition, in the modification examples 1 to 15 of the first embodiment, operations according to the modification examples may be performed separately without assuming operations according to the first embodiment.

[0443] In the above-mentioned embodiment and its modification example, the control plane (CP) solution and the user plane (UP) solution are not particularly distinguished, but the operation according to the embodiment and its modification example can be applied to both the CP solution and the UP solution. In the CP solution, in early data transmission, data is included in the RRC message. In the UP solution, in early data transmission, data is not included in the RRC message, and data (DTCH) and RRC message (CCCH) are multiplexed and transmitted in the MAC layer.

[0444] In the UP solution, the RRC message corresponding to Msg3 is an RRC connection recovery request message, and the RRC message corresponding to Msg4 is an RRC connection recovery message. Typically, when receiving an RRC connection recovery, the UE 100 establishes (re-establishes) a PDCP entity. However, when performing early data transmission, it is considered that before receiving the RRC connection recovery, the UE 100 has established (re-established) a PDCP entity in order to perform data transmission. Therefore, the UE 100 can receive an indication (RRC connection recovery) of transitioning from an idle mode to a connected mode from the eNB 200 after establishing (re-establishing) a PDCP entity for performing early data transmission. In this case, the UE 100 can skip the establishment (re-establishment) of the PDCP entity and maintain the established PDCP entity.

[0445] In the above embodiments, examples using radio terminals (eMTC UE and NB-IoT UE) for MTC or IoT have been described. However, the present invention is not limited to eMTC UE and NB-IoT UE. The operations according to the above embodiments can be applied to ordinary UEs.

[0446] In the embodiment, the RRC idle mode, suspended mode and connected mode are mainly used as examples for description, but the embodiment is not limited to this. The present embodiment can be applied to RRC light connection or inactive (INACTIVE) state. RRC light connection is a state of RRC connected mode and is a special state of a part of the process to which the RRC idle mode is applied. It is assumed that inactivity is introduced into the fifth-generation mobile communication system and is an RRC state different from the RRC connected mode and the RRC idle mode. The "RRC idle mode" in the above embodiment can be understood as "inactive mode".

[0447] In the embodiment, the description is made by taking the UE in the enhanced coverage as an example, but the embodiment is not limited thereto. The operation according to the above embodiment can be applied to the UE in the normal coverage. Specifically, it is not necessary to perform CE level determination based on RSRP measurement in the RACH process.

[0448] In the above-described embodiments, the LTE system is exemplified as a mobile communication system. However, the present invention is not limited to the LTE system. The operation according to the above-described embodiments can be applied to mobile communication systems other than the LTE system (eg, a fifth generation mobile communication system).

[0449] A program for causing a computer to execute various processes performed by the UE 100 and the eNB 200 may be provided. In addition, the program may be recorded on a computer-readable medium. If a computer-readable medium is used, the program may be installed in the computer. Here, 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 and may be a recording medium such as a CD-ROM or a DVD-ROM. A chipset may be provided, the chipset including: a memory storing a program for executing various processes performed by the UE 100 and the eNB 200; and a processor executing the program stored in the memory.

[0450] [Appendix 1]

[0451] (1. Introduction)

[0452] A new work item on LTE Enhanced MTC (eFeMTC) was approved in RAN#75 and WID identified several goals that RAN2 should consider as the main WG. The goal is to specify the following improvements for machine type communications for BL / CE UEs. […]

[0453] Improved Latency:

[0454] […]

[0455] Support early data transmission [RAN2-led, RAN1, RAN3]

[0456] • Evaluate the power consumption / delay gain on dedicated resources during the random access procedure (after PRACH transmission and before RRC connection establishment is complete) and specify necessary support for DL / UL data transmission, at least in the RRC suspend / resume case.

[0457] In this appendix, considerations for these improvements are discussed.

[0458] (2. Discussion)

[0459] (2.1 Improved latency - early data transfer)

[0460] Although the WID clearly states: "At least in the RRC suspend / resume case, evaluate the power consumption / delay gain on dedicated resources during the random access procedure (after PRACH transmission and before RRC connection establishment is completed) and specify necessary support for DL / UL data transmission." Considering the implementation of various MTC devices, the enhanced delay performance in early data transmission may lead to additional power consumption. In some MTC implementations, where additional power consumption is required, the UE should be allowed to select the traditional RACH procedure (i.e., non-early data transmission mode) to avoid the burden of traditional use cases.

[0461] Proposal 1: The solution for early data transmission should minimize the additional power consumption; for example, the UE should be allowed to select the traditional RACH procedure, i.e., “non-early data transmission mode”.

[0462] WID also mentions that early data transmission should be performed after Msg1 and before Msg5, that is, the enhanced candidates are Msg2, Msg3 and Msg4. On the other hand, it is expected that some control signaling can be transmitted even before Msg2 and after Msg4.

[0463] Proposal 2: Control signaling associated with early data transmission does not need to be sent via Msg 2, Msg 3 or Msg 4.

[0464] The data transmitted earlier without identification in the WID is assumed to be small data packets, large size data and / or both. For example, if only small data is assumed, then the UE is better to switch to RRC IDLE once the data transmission is completed, even in the RACH process, for example. In any case, it can be considered that the solution will be different depending on the size of the data transmitted earlier. Therefore, RAN2 should first discuss and determine the assumption of data size.

[0465] Proposal 3: RAN2 should discuss the data size assumed for early transmissions, i.e. small packets, large packets or both.

[0466] The WID does not explicitly mention whether early data transmission can be initiated only in contention-based RACH procedure, contention-free RACH procedure or both. The assumptions of this solution are different between the two procedures, for example, whether the PDCCH order can be assumed to be different. Therefore, RAN2 should clarify which RACH procedure is assumed for early data transmission.

[0467] Proposal 4: RAN2 should discuss whether early data transmission is applicable to contention-based RACH procedure, contention-free RACH procedure or both.

[0468] Fig.25 A general RACH procedure (contention-based / contention-free) is shown.

[0469] (2.2. Improved power consumption - relaxed monitoring of cell reselection)

[0470] The WID describes the following mechanism: "Enable relaxed UE monitoring for cell (re)selection, e.g. by (re)configuration". Fixed UEs should be allowed to perform relaxed monitoring regardless of whether (re)configuration is required, as cell reselection occurs rarely. When (re)configuration is necessary as per the intent of the WID, some UE assistance information may be necessary, e.g. number of cell reselection reports, fixed UE indication, etc., as the network may not know whether an IDLE mode UE performs cell reselection.

[0471] Proposal 5: Should it be configured to allow fixed UEs to operate under relaxed monitoring of cell reselection?

[0472] [Appendix 2]

[0473] (1. Introduction)

[0474] RAN2#99 started discussions on LTE enhanced MTC (eFeMTC) and reached the following agreement on early data transmission capabilities.

[0475] protocol

[0476] We intend to support early UL data transmission in Msg3 to achieve control plane and user plane CIoT EPS optimization.

[0477] We intend to support early DL data transmission in Msg4 for control plane and user plane CIoT EPS optimization.

[0478] protocol

[0479] When AS security is not established to transfer data using only CP, an early data transfer function is considered.

[0480] When establishing AS security to transfer data using CP and / or UP, consider the early data transfer function.

[0481] In this appendix, the enhancements necessary for early data transmission are discussed in detail.

[0482] (2. Discussion)

[0483] In the following sections, for simplicity, early UL data transmission and early DL data transmission will be discussed separately, and the existing random access procedure will be taken as a benchmark.

[0484] (2.1. Early UL data transmission)

[0485] (2.1.1. Clarifications in email discussion)

[0486] If the UE intends to perform early UL data transmission in Msg3, the SIB provides a specific preamble to be used in Msg1. In other words, if the SIB does not contain an indication with a specific preamble, early UL data transmission is not allowed.

[0487] Msg1 contains the UE's intention in a specific preamble whether or not early UL data transmission is to be carried out in this random access procedure.

[0488] Msg2 indicates whether to accept the UE's intention in addition to the existing random access response.

[0489] Msg3 includes data and an extended RRC connection (resumption) request to inform the eNB whether the data transmission is completed within the random access process, that is, whether the UE needs to switch to an RRC connection.

[0490] Msg4 can be RRC connection establishment / recovery or RRC connection release, i.e. the network responds with Msg4 to confirm that the reception of Msg3 completes the contention resolution and includes NAS PDU (if necessary).

[0491] From the eNB's perspective, the SIB needs to at least indicate whether early UL data transmission is allowed, i.e., SIB indications similar to up-CIoT-EPS-Optimization, etc. [3]. The UE can then include a specific preamble in Msg1 to indicate to the eNB that it intends to use early UL data transmission. However, even if the UE includes a specific preamble in Msgl, the eNB should still have the option to decide whether to accept early UL data transmission, because the eNB may have other reasons to reject early UL data transmission, such as overload. This can be communicated to the UE via Msg2. Therefore, there should be two steps of permission before accepting early UL data transmission.

[0492] Proposal 1 RAN2 should agree that the UE should transmit a specific preamble provided in the SIB in Msg1 to inform the eNB that it intends to perform early data transmission in Msg3, and the eNB can indicate in Msg2 whether early data transmission is acceptable.

[0493] Since one of the main goals of early data transmission is to reduce the power consumption of the UE, the UE should be released to IDLE immediately after the data transmission is completed. A Release Assistance Indication (RAI) [3] [4] can be used for this purpose. On the other hand, if the data packet to be sent is small and can be sent completely within the limited size of Msg3, it is assumed that the UE does not need to transition to an RRC connection. If the UE is allowed to request such a connectionless data transfer, the request needs to be communicated to the eNB using one of the following options.

[0494] Option 1a: Set Alternate 1 in the establishment cause of the RRC connection request and / or the restoration cause of the RRC connection restoration request.

[0495] Option 1b: The Spare IE is located in the RRC Connection Request and / or RRC Connection Resumption Request.

[0496] Option 1c: Specify RAI in Msg3 (ie, BSR=0).

[0497] Option 1d: New RRC message, such as RRC Connectionless Request.

[0498] Options 1a to 1c have less impact on the specification than Option 1d. In terms of signaling overhead, Option 1a is the same as 1b, but is better than Option 1c. Regarding technical implications, Option 1b is more flexible than Option 1a because early UL data transmission is usually not related to establishment / recovery reasons, especially considering potential requirements in future releases. Therefore, Option 1b is preferred.

[0499] Proposal 2: RAN2 should agree to include a 1-bit indication in the RRC Connection (Resumption) Request to inform the eNB whether the UL data transmission is completed in Msg3.

[0500] (2.1.2. Retransmission scheme)

[0501] WID mentions performing early data transfers to dedicated resources.

[0502] Further consideration should be given to whether dedicated resources actually support RAN2's current agreement on early UL data transmission. RAN2 agreed to "early UL data transmission in Msg3", where Msg3 resources are allocated by dedicated UL grants in Msg2. The current Msg3 conveys RRC connection request or RRC connection recovery request on the CCCH logical channel, which is ultimately mapped to PUSCH via UL-SCH, but in the case where early UL data transmission is supported only for UEs in IDLE, i.e., in the contention-based random access procedure, the physical resource contention between UEs has not been resolved.

[0503] Observation 1: On Msg3, the contention-based RACH procedure does not resolve contention.

[0504] In Msg3, more UL interference from multiple UEs can be expected because the contention has not been resolved. In other words, reception errors of early UL data in Msg3 may occur. In the case of failure to successfully receive early UL data transmission, it is still unclear what the UE should do, that is, how to retransmit the UL data that the eNB did not successfully receive.

[0505] Proposal 3: RAN2 should discuss how the UE should retransmit if the eNB does not successfully receive the earlier UL data.

[0506] If Proposal 3 is acceptable, four options for retransmission schemes can be considered.

[0507] Option 2a: The UE restarts the random access procedure from Msg1, i.e. the previous procedure is canceled.

[0508] Option 2b: The UE may retransmit the failed data together with Msg3, i.e. “Early UL data retransmission in Msg3”.

[0509] Option 2c: UE can retransmit failed data in Msg5, i.e. only when the data fails.

[0510] Option 2d: The UE is allowed to retransmit failed data only after being in RRC connection.

[0511] Option 2a is consistent with the current specification, i.e. clearing the Msg3 buffer and restarting from random access resource selection. Even with option 2a, it is unclear whether the old backoff time or the new backoff time is used for early UL data retransmission, and whether the number of retransmissions is limited. Option 2b may follow option 2a, i.e. the UE includes the failed data in the next Msg3 timing. Option 2c is likely to be rare, as it is unlikely that no data was received upon successful reception of the RRC Connection (Resumption) Request, assuming the same MCS is applied. Option 2d is consistent with the current specification, except that retransmission of failed data is allowed.

[0512] Proposal 4: RAN2 should agree that if an early UL data transmission fails, the UE should restart the random access procedure (as it currently does) and be allowed to retransmit the data in the next Msg3.

[0513] In any case, even if the Msg3 buffer is cleared, the UE shall retain the data for earlier transmission until successful reception is confirmed.

[0514] (2.2.DL early data transmission)

[0515] (2.2.1. Notes on Email Discussions)

[0516] The email discussion discussed early DL data transmission and early UL data transmission together, so the DL aspects may not be considered in detail. In the following sections, such details will be discussed.

[0517] (2.2.2. UE support for early DL data transmission)

[0518] RAN2 agrees to "support early DL data transmission in Msg4", where in addition to RRC connection establishment / recovery / release, the UE also needs to receive data at Msg4. However, there is a question whether the eNB always knows whether the UE is capable of early DL data reception, especially for UEs that have been fully released rather than just suspended. Considering a unified solution for optimizing both for CIoT EPS CP / UP, the UE can inform the NW (i.e., eNB or MME) whether it can receive early DL data.

[0519] Proposal 5: RAN2 should agree that the UE should inform the NW whether early DL data reception is supported.

[0520] From the eNB's perspective, there are two options to communicate the UE's capabilities to the NW, either the MME or the UE. If the MME notifies the eNB, then some S1 messages, such as paging or initial context setup request, will obviously need to be enhanced, where RAN2 must consult RAN3. On the other hand, if the UE notifies the eNB, then several options can be considered as follows.

[0521] Option 3a: Added a new IE for Early DL Data Reception in UE Capabilities.

[0522] Option 3b: If the UE supports early DL data reception, an indication is sent in Msg1 or Msg3.

[0523] Option 3a is a direct way to provide the eNB with the UE capabilities, but the eNB needs to retain the context even if the UE is no longer connected or suspended, as it is transferred after Msg4. Option 3b is a "handshake", so the UE needs to know whether early DL data reception is intended before starting (i.e. in paging or Msg2).

[0524] Proposal 6: RAN2 should discuss how to inform the eNB, for example through the UE or MME, whether the UE supports early DL data reception.

[0525] Regardless of Proposal 6, the UE must know whether early DL data reception needs to be established before the early DL data reception occurs.

[0526] Proposal 7: RAN2 should agree that the UE should be informed in paging or Msg2 whether early DL data reception is required.

[0527] (2.2.3. Retransmission scheme)

[0528] It is assumed that early DL data transmission is performed on a dedicated / non-contention resource, i.e., Msg4. However, even with such a resource, reception errors may occur, so the UE's behavior should be clear. Once early DL data transmission is indicated in paging or Msg2 (i.e., Proposal 7), the UE can easily monitor the data to be sent on Msg4. Similar to Proposal 4, a method is also needed to retransmit DL data if the UE does not receive the DL data.

[0529] Proposal 8: RAN2 should agree to perform early DL data retransmission on Msg4 if Msg4 cannot be received.

[0530] (2.2.4. Simultaneous early UL / DL data transmission)

[0531] It is not clear whether early data transmission for both UL and DL should be supported in a single random access procedure. Typically, an UL data transmission may require upper layer acknowledgment on a subsequent DL, and vice versa, such as requiring a TCP ACK. It seems possible that the UE could decide within one random access procedure to transmit an UL data transmission in Msg3, and then acknowledge receipt of the DL data in Msg4. Note that it is clear that DL data cannot be transmitted in Msg4 and then in Msg3 in the same procedure. As upper layer acknowledgment of the UL data transmission must be sent in the next Msg3, which will happen in the next random access procedure, or the UE could also transition to an RRC connected, but this would negate the purpose of sending early DL data.

[0532] However, it is not clear how much delay is required for such upper layer confirmation. If the upper layer round trip is completed in the random access procedure and the upper layer confirmation is delayed, the UE may monitor Msg4 for a long time after Msg3 transmission, which will cause unnecessary power consumption of the UE. Therefore, it is reasonable to support early UL data transmission or early DL data transmission within one random access procedure.

[0533] Proposal 9: RAN2 should agree that one random access procedure supports only one type of early data transmission, namely early UL data transmission or early DL data transmission.

[0534] [Appendix 3]

[0535] (1. Introduction)

[0536] RAN2#99bis has made significant progress in Early Data Transfer (EDT) functionality through many of the following protocols.

[0537] protocol

[0538] PRACH partition is used to indicate the UE's intention to use early data transmission in Msg3. Backward compatibility should be retained. Further consideration is needed: Details about the PRACH pool, e.g., preamble / time / frequency / carrier domain of the PRACH partition.

[0539] For CP during UL EDT procedure, if UE receives a grant that the data does not fit, then UE will not transmit data in Msg3. For UP solution, if the grant is smaller than the UL data size, further consideration needs to be given as to whether the EDT grant can be used for UL data.

[0540] Further consideration is needed as to whether an authorization mechanism needs to be introduced.

[0541] • Broadcast the maximum possible grant size of Msg3 for each CE. It needs to be further considered whether the UE indicates the required grant size of its Msg3 via PRACH partitioning.

[0542] Send the LS to RAN1 with the agreement reached in this meeting and indicate that we assume the legacy TBS table used for PUSCH transmissions for EDT.

[0543] Msg4 determines whether the UE enters RRC connected mode or RRC idle mode. The content of Msg4 of EDT needs to be further considered.

[0544] • The intention to use EDT is for data, ie not for NAS signalling.

[0545] Send LS to RAN3 / SA2 / CT1, including whether any of the following parameters in Msg5 of the legacy procedure should be included in Msg3 of EDT: selectedPLMN-Identity, registeredMME, gummei-Type, attachWithoutPDN-Connectivity, up-CIoT-EPS-Optimisation, cp-CIoT-EPS-Optimisation, dcn-ID.

[0546] RAN2 assumes that S-TMSI for CP, resumeID and shortResumeMAC-I for UP solution are sufficient to identify the UE at MME and eNB respectively. We will provide this assumption in LS to RAN3, SA2, SA3, CT1.

[0547] For the CP solution, NAS PDU for data is encapsulated in an RRC message sent in Msg3 and transmitted as CCCH SDU.

[0548] For the UP solution, SRB0 is used to transmit RRC messages in Msg3.

[0549] For UP solution, CCCH (RRC message) and DTCH (UP data) are multiplexed in MAC in Msg3.

[0550] For UP, AS security is restored before transmitting Msg3, and the data transmitted in Msg3 is protected by AS security.

[0551] For the CP solution, the NAS PDU data in the DL can be encapsulated in the RRC message sent in Msg4 as appropriate and transmitted as CCCH SDU.

[0552] For UP solution, DL data can be multiplexed in MAC as appropriate, i.e. DCCH (RRC message) and DTCH (UP data) in Msg4.

[0553] Further consideration is needed: For UP solution: In case of fixed connection, CCCH (RRC connection recovery request) + DCCH (NAS PDU via fixed connection)

[0554] In this appendix, the remaining issues that complete the basic functionality of EDT are discussed.

[0555] (2. Discussion)

[0556] (2.1. Use Case)

[0557] During the discussion it seemed generally understood that the EDT procedure is started by UL EDT for e.g. sensor data on higher layers and ended by DL EDT for e.g. corresponding higher layer ACK, i.e. the round trip to higher layers is done within the EDT procedure.

[0558] On the other hand, in some cases, a UL-only EDT process and / or a DL-only EDT process is also useful; for example: (For more comparisons, please refer to Fig.26 . Fig.26 Showing the EDT process)

[0559] UDP data transfer type, i.e., no ACK from higher layers.

[0560] The higher layer round trip delay is longer, i.e., the higher layer ACK takes some time to respond.

[0561] • Commands from the application server to the device, i.e., communications are triggered by the DL.

[0562] It can be considered that the UL-only EDT procedure is supported because RAN2 agreed that "For the CP solution, the NAS PDU data in the DL can be encapsulated in the RRC message sent in Msg4 as appropriate and transmitted as CCCH SDU" and "For the UP solution, the DL data can be multiplexed in the MAC as appropriate, i.e., DCCH (RRC message) and DTCH (UP data) in Msg4", i.e., the UE may not receive Msg4 together with the data.

[0563] Observation 1: Currently the protocol supports only the UL EDT process.

[0564] On the other hand, in the current protocol, support for a DL-only EDT procedure is unclear, because from the UE's perspective, the availability of DL EDT transmission is not known until Msg4 is received, and from the eNB's perspective, the reception capability of DL EDT cannot be notified without UL EDT, and so far, it is assumed that a UE supporting UL EDT also supports DL EDT. Therefore, if a DL-only EDT procedure is supported, further discussions should address some enhancements, such as notifications in paging.

[0565] NOTE: It is assumed that a UE with UL EDT capability also has DL EDT capability.

[0566] Proposal 1: RAN2 should discuss whether to support DL-only EDT procedures.

[0567] (2.2. Details of EDT instructions)

[0568] It was agreed in RAN2#99bis that "PRACH partitioning is used to indicate the UE's intention to use early data transmission in Msg3. Backward compatibility should be retained. Further consideration is needed regarding the details of the PRACH pool, e.g., preamble / time / frequency / carrier domain of the PRACH partition" and "the maximum possible grant size for each CE broadcast Msg3. If the UE indicates the required grant size for its Msg3 via PRACH partitioning, it is FFS".

[0569] The email discussion discussed requires further consideration: namely, additional information on Msg1 and PRACH partitioning details. Regarding the additional information on Msg1, it seems that most people think that the EDT indication is configured per CE, but UE category is not required; there is no consensus on the indication of the grant size, which may be a place for future extensions.

[0570] Proposal 2: RAN2 should agree to configure EDT indication on Msg1 according to CE, and the grant size indication on Msg1 should be considered as a future extension.

[0571] For the details of PRACH partitioning, two solutions are proposed, namely soft partitioning (or non-dedicated PRACH resources) and hard partitioning (or dedicated PRACH resources). The question is whether further PRACH fragmentation is acceptable, as it may lead to degraded PRACH performance, especially in resource-limited situations in some deployment scenarios of NB-IoT.

[0572] Even though there are some advantages in sharing PRACH resources with soft partitioning in, for example, non-optimized NWs, the number of partitions is no different from hard partitioning. For example, for hard partitioning, assuming there are 3 legacy CE levels and 3 EDT indications for 3 CE levels, 6 partitions are needed in the PRACH resources. For soft partitioning, 6 PRACH spaces are also needed (3 CE levels x 2 different preambles). This means there is no physical breakthrough, i.e., the difference is in how the UEs are separated by design.

[0573] Note: For hard partitioning, if the eNB configures legacy PRACH resources and EDT indication PRACH resources with overlapping resources, sharing of PRACH resources is possible.

[0574] Therefore, we believe that regardless of the partitioning method (e.g., soft or hard), whether dedicated or non-dedicated resources, the performance of PRACH will eventually reach similarity in the optimized NW.

[0575] Observation 2: The performance of PRACH will ultimately be similar among the solutions proposed in the email discussion.

[0576] As an alternative solution not previously discussed in the email, it should also be considered whether multiple PRACH transmissions from the UE can be defined to distinguish between legacy PRACH and UL-EDT PRACH. For example, the UE sends a first PRACH for legacy purposes (i.e., CE level determination) and still sends a second PRACH for EDT indication (i.e., only UEs requesting EDT send the second PRACH). The eNB can perform blind decoding on both PRACH spaces for each PRACH monitoring (refer to Fig. 27 . Fig. 27 1 shows an EDT indication according to multiple PRACH transmissions). Two PRACHs can be sent on the same subframe. Using this approach, only 4 PRACH resources are needed (3 CE levels for the first PRACH and 1 EDT indication for the second PRACH), and because legacy UEs only send the first PRACH now, it is backward compatible. However, the disadvantage of this solution is obviously that the UE requires additional PRACH transmissions, thereby incurring additional power consumption, but this may be similar to the power consumption caused by PRACH performance degradation (e.g., collisions).

[0577] Proposal 3: RAN2 should consider whether multiple PRACH transmissions in one additional PRACH space are useful for EDT indication.

[0578] Proposal 4: If Proposal 2 and Proposal 3 are acceptable, RAN2 should later consider whether to map the grant size indication to the additional PRACH space.

[0579] (2.3. EDT failure situation)

[0580] (2.3.1.UL approval failed (Msg1 / Msg2))

[0581] RAN2 agrees: "For CP during UL EDT procedure, if UE receives a grant in which data does not fit, then UE shall not send data in Msg3. For UP solution, if EDT grant is available for UL data (if grant is smaller than UL data size), then it is FFS." This means that at least for CP solution, even if UE sent EDT indication on Msg1, eNB may reject EDT procedure with legacy size UL grant on Msg2. This can be considered as failure case from EDT procedure point of view.

[0582] Observation 3: At least for the CP solution, the EDT process fails when the UL grant does not fit the data size.

[0583] The current protocol only specifies the conditions for whether data can be transmitted on Msg3, i.e., it does not mention what the UE should do if the UL grant is less than expected. Therefore, the UE behavior in case of failure should be specified, for example, for testing. The following two options should be considered.

[0584] Option 1: UE transmits legacy Msg3 (ie, not together with data).

[0585] Option 2: The UE may retry the EDT procedure (ie, restart from Msg1).

[0586] Option 1 may be the baseline for impressions during the discussion. Option 2 is somewhat different from the current behavior, i.e., the UE skips PUSCH transmission even if the UE receives a corresponding UL grant. However, since EDT is a new feature, it is still necessary to consider introducing Option 2 on a case-by-case basis, e.g., to minimize unnecessary UE power consumption to transition to an RRC connection only when the eNB allows this feature.

[0587] Proposal 5: At least for the CP solution, if the UL grant size is not enough for UL EDT, RAN2 should agree with the UE to transmit the legacy Msg3.

[0588] Proposal 6: RAN2 should discuss whether to allow the UE to retransmit the EDT indication as appropriate if the UL grant size is not large enough.

[0589] (2.3.2. Reception failed (Msg3 / Msg4))

[0590] How to handle data reception failure during the EDT process has not been discussed.

[0591] So far in the UL EDT discussion, the UE behavior has only assumed the case where the UE does receive Msg4, but it is not clear what happens if the UE does not receive Msg4. Although some options are discussed, it may be simpler if the UE follows the current random access procedure, i.e. restarting from random access resource selection, thereby also retrying UL EDT.

[0592] Proposal 7: RAN2 should agree that the UE restarts the random access procedure (and UL EDT procedure) from random access resource selection if contention resolution is currently deemed unsuccessful.

[0593] There should be discussion about where to store data for retransmission, as currently the HARQ buffer is cleared when contention resolution is considered unsuccessful. From the perspective of the CP solution, service data is encapsulated in the RRC message as a NAS PDU. Service data can be encapsulated in the RRC layer until data transmission is successfully completed. On the other hand, from the perspective of the UP solution, service data on the DTCH is multiplexed in the MAC layer, so the service data cannot be stored in the RRC layer but only in one user plane layer. From the perspective of having common UE behavior for CP and UP, the MAC layer should not clear the HARQ buffer even if contention resolution is considered unsuccessful.

[0594] Observation 4: It is unclear which layer stores the data before the UL EDT is successfully completed in the RED or MAC.

[0595] Proposal 8: RAN2 should agree that the MAC layer handles data retransmission in UL EDT.

[0596] In DL EDT, the reception failure of Msg4 is indicated by HARQ feedback. Therefore, the retransmission of data can simply follow the current HARQ retransmission.

[0597] Proposal 9: RAN2 should agree to perform DL EDT retransmissions via Msg4 HARQ retransmissions as currently done.

[0598] (2.3.3.T300 and contention resolution timer failure (Msg3 / Msg4))

[0599] In the current specification, two timers are running between Msg3 and Msg4, T300 in RRC and mac contention resolution timer in MAC. T300 value is 100ms~2000ms for LTE and 2500ms~60000ms for NB-IoT. Mac-contention resolution timer value is sf8~sf64 for LTE and pp1~pp64 for NB-IoT. When these timers expire, UE considers RRC connection establishment / recovery or contention resolution unsuccessful respectively.

[0600] If UL EDT is used for sensor data transmission and DL EDT is used for TCP ACK (i.e., Fig.26 If the “full EDT process” in the EDT process is used, the Msg4 transmission in the EDT process will be delayed more than the traditional Msg4 because it depends on the round-trip time in the higher layer. Therefore, it is straightforward to define a longer timer value to avoid unnecessary failures.

[0601] Proposal 10: RAN2 should define a longer value for the timer running between UL EDT on Msg3 and DL EDT on Msg4.

[0602] However, this may result in additional UE power consumption due to continuous PDCCH monitoring until Msg4 is received. Therefore, some kind of DRX type reception mode should be introduced during EDT.

[0603] Proposal 11: RAN2 should consider whether discontinuous reception is allowed during EDT (i.e., after Msg3 transmission until Msg4 reception).

[0604] Furthermore, it is questionable how the eNB configures the timer value, since it is unclear when the TCP ACK is returned as a result of a higher layer message. Assuming that there are many UEs implementing various applications in one cell, it seems difficult to set appropriate timer values ​​for all UEs.

[0605] One possibility is dedicated configuration on Msg2, but it is still difficult to determine the timer value without application layer knowledge. On the other hand, the UE may help set a suitable timer value based on its timeout settings at higher layers. For example, the UE can inform the eNB of the self-configured timer value on Msg3.

[0606] Proposal 12: RAN2 should consider whether to allow the UE to notify the eNB of its configured timer value in Msg3.

[0607] If one of Proposals 10 to 12 is acceptable, the concept of timer for EDT is different from the traditional timer. In addition, due to, for example, larger packet transmission, a UE with EDT function may still initiate a traditional RRC connection establishment / recovery, so in this case, the traditional timer will apply. Therefore, it is necessary to discuss whether the timer for EDT reuses the traditional timer or defines a new timer.

[0608] Proposal 13: RAN2 should discuss whether the timer for EDT should reuse the traditional timer or define a new timer.

[0609] Fig.28 The delay due to the round trip time in higher layers is shown.

[0610] (2.4. Authorization mechanism)

[0611] The board note noted that “further consideration is required as to whether a delegation mechanism should be introduced” which was beyond the scope of the email discussion.

[0612] According to our understanding, EDT is an AS function and is not expensive from the perspective of NW and UE (unlike CE). In addition, NW can always disable EDT function, for example by removing PRACH partitioning parameters and / or maximum possible grant size from SIB. Therefore, there is no technical reason to introduce authorization mechanism.

[0613] Proposal 14: RAN2 should agree that no EDT authorization mechanism is required.

[0614] [Appendix 4]

[0615] (1. Introduction)

[0616] RAN2#100 discussed the details of the Early Data Transfer (EDT) indication on Msg1 and reached the following agreement.

[0617] protocol

[0618] When the size of Msg3 including user data that the UE intends to transmit is equal to or smaller than the maximum possible TBS size of Msg3 broadcast for each CE, the UE starts EDT in Msg1.

[0619] ·Configure the PRACH partitions for EDT indication according to the enhanced coverage level.

[0620] Working hypothesis: Segment support for this situation is not a priority.

[0621] • Working assumption: PRACH resource partitioning is not supported to indicate the expected data size, other than the legacy or maximum TBS broadcasted for each CE.

[0622] How to solve the padding problem in Msg3.

[0623] UE category is not indicated in Msgl.

[0624] For EDT indication, PRACH resources can be configured in terms of physical layer resources, preamble / subcarrier in traditional eMTC or NB-IoT.

[0625] The PRACH resource pool (ie, physical layer resources, preamble / subcarrier) used for EDT indication is separate from the PRACH resource pool used for the traditional RACH process.

[0626] Regarding how to solve the padding issue, it is identified as FFS; this problem occurs when the UL grant for UL EDT does not match the size of data that the UE intends to transmit. The details of the issue will be described in the corresponding email discussion.

[0627] In this appendix, additional notes on the email discussions are provided.

[0628] (2. Discussion)

[0629] In an email discussion, a solution to the padding problem was proposed and summarized as follows.

[0630] The following solutions to the padding problem are described above.

[0631] 1. (N)PRACH partitioning, where the UE uses Msg1 to indicate the expected data size / TBS of EDT Msg3.

[0632] 2. The network provides multiple combinations of transport block sizes and UL grant information, such as RU, PRB, and repetition number, in the RAR message for the UE to choose from considering the expected data transmission in Msg3.

[0633] 3. The network provides dual (or more) permission for Msg3 transmission.

[0634] 4. Combination of data size expression in Msg1 and flexible permissions in RAR.

[0635] 5. Repeat the MAC SDU or PDU in the padding area (the details of this solution are not clear and it would be better to explain it in detail for better understanding).

[0636] 6. Implicit allocation, e.g., multiple common UL resource pools for Msg3 transmission associated with multiple "maximum TBS broadcast per CE" (the details of this solution are not clear, it is better to explain it in detail for better understanding).

[0637] 7. For UP only: Segmentation to avoid padding for legacy Msg3 transmission.

[0638] (2.1. Solution 5 (MAC PDU duplication))

[0639] This solution uses the padding region as a redundancy opportunity. In other words, the existing repetition scheme on the subframe is done within the transmission. Fig.29 and Fig.30 An example is shown in . Fig.29 A case where the UL grant is larger than the expected data size is shown. Fig.30 A case where the UL grant is smaller than the expected data size is shown.

[0640] Further consideration needs to be given to which entity in the layer should perform the additional redundancy process, and one possibility exists in the physical layer. For example, the UE generates a bit string based on the MAC PDU, stores it in a circular buffer, and transmits bits based on the UL grant size.

[0641] The expected pros and cons are as follows:

[0642] Advantage: Possibility that Rx soft synthesized gain and / or Tx power is reduced to compensate for repetitions compared to transmission of filler bits.

[0643] Disadvantage: If duplication is handled in the physical layer, it may affect RAN1.

[0644] (2.2. Solution 6 (Universal UL Resource Pool))

[0645] The solution provides a common UL resource pool for EDT, whereby the resource pool is similar to a Mode 2 / Type 1 sidelink transmission, i.e., a common resource used by multiple UEs. It can be assumed that the legacy Msg3 resources are always provided by the UL grant (as is currently the case), but the UE is allowed to use the common resource pool to transmit the data part and use the same temporary C-RNTI transmission as used in the legacy Msg3. The configuration of the common resource pool is provided in the SIB. This solution can be seen as a "semi-static" version of the multiple UL grant solution, where the second grant resource intended for data can be shared by multiple UEs.

[0646] Fig.31 A common resource pool for UL transmission is shown.

[0647] Consider the pros and cons as follows.

[0648] Advantages: No need to change Msg2. Assuming a sidelink-like transmission, the UE can transmit data without padding (unless the size exceeds the common resources). If we consider EDT as an IDLE mode procedure, it is also reasonable to use common resources, which is similar to the case of Mode 2 / Type 1 resources. This means that resources can be allocated without dedicated signaling, which again reinforces the idea that Msg2 does not need to be modified.

[0649] Disadvantages: Conflicts may occur when using common resources.

[0650] [Appendix 5]

[0651] (1. Introduction)

[0652] RAN2#100 aims to lay an important foundation for the Early Data Transfer (EDT) function. However, many further considerations are still needed for the details, one of which is as follows.

[0653] protocol

[0654] Solutions for CP

[0655] […]

[0656] Further consideration is needed as to whether the T300 and MAC contention resolution timers need to be changed.

[0657] In this appendix, further considerations on timers are discussed.

[0658] (2. Discussion)

[0659] (2.1. Assumptions)

[0660] During the discussion, it seemed to be generally understood that the EDT process is initiated by UL EDT, e.g. sensor data on higher layers, and ends with DL EDT, e.g. corresponding higher layer ACK, i.e. the higher layer round trip is completed within the EDT process (i.e., reference Fig.26 "Complete EDT Process" in the documentation).

[0661] Observation 1: A typical EDT procedure includes UL EDT and DL EDT (within the random access procedure).

[0662] On the other hand, the UL-only EDT process and / or the DL-only EDT process are also useful in the following cases (for more comparison, please refer to Fig.26 ).

[0663] UDP type for data transmission, i.e., no ACK from higher layers.

[0664] The higher layer round trip delay is longer, that is, the higher layer ACK takes some time to respond.

[0665] Commands from the application server to the device, i.e., communications are triggered by DL.

[0666] DL data in Msg4 is transmitted independently of CP / UP as appropriate, i.e., "For CP solution, NAS PDU data in DL can be encapsulated in RRC message transmitted in Msg4 as appropriate and transmitted as CCCH SDU" and "For UP solution, DL data can be multiplexed in MAC as appropriate, i.e., DCCH (RRC message) and DTCH (UP data) in Msg4."

[0667] Observation 2: Based on the current protocol, only UL EDT process is supported.

[0668] On the other hand, based on the current protocol, support for DL-only EDT procedures is unclear because the UE does not know whether DL EDT transmission will occur until it receives Msg4, and the eNB does not know the UE's DL EDT reception capability until it receives UL EDT from the UE.

[0669] Proposal 1: RAN2 should discuss whether to support DL-only EDT procedures.

[0670] (2.2.T300 and Contention Resolution Timer)

[0671] (2.2.1.Msg4 delay issue)

[0672] In the current specification, two timers are running between Msg3 and Msg4, T300 in RRC and mac contention resolution timer in MAC. The value of T300 varies between 100ms~2000ms for LTE and 2500ms~60000ms for NB-IoT. The mac contention resolution timer value varies between sf8~sf64 for LTE and pp1~pp64 for NB-IoT. When these timers expire, the UE considers that the RRC connection establishment / recovery or contention resolution is unsuccessful, respectively. Although it is not clear what the UE's behavior should be if these existing timers expire under EDT, the current random access procedure is indeed the benchmark for the EDT procedure. Therefore, timers need to be further considered.

[0673] If the sensor data is transmitted via UL EDT and the corresponding TCP ACK is transmitted via DL EDT (i.e., refer to Fig.26 If the "full EDT process" in the EDT process is used, the Msg4 transmission in the EDT process will be delayed more than the traditional Msg4 because it depends on the round-trip time from the higher layer (such as Figure 2 ).

[0674] Observation 3: Due to the round-trip time from higher layers, the duration between Msg3 and Msg4 in EDT becomes longer than the conventional one.

[0675] Therefore, it is straightforward to define a longer timer value to avoid unnecessary failures caused by T300 expiration.

[0676] Proposal 2: RAN2 should define a longer value for the timer running between UL EDT on Msg3 and DL EDT on Msg4 to prevent unnecessary failures due to expiration of the full EDT procedure.

[0677] (2.2.2.: DRX for Msg4 reception)

[0678] If Proposal 2 is acceptable, then the existing T300 and mac contention resolution timer values ​​can be directly extended. However, this may result in additional UE power consumption due to continuous PDCCH monitoring until Msg4 is received, whereby Msg4 may be delayed in EDT as discussed in the previous section. To avoid this unnecessary power consumption, some kind of DRX type reception mode should be introduced during the EDT process.

[0679] For example, as a simple solution, the UE can monitor PDCCH only in the subframe before the timer expires, i.e. "single" monitoring. In some MTC / NB-IoT use cases (such as high latency communication), it is better than continuous monitoring.

[0680] Proposal 3: RAN2 should consider whether discontinuous reception is allowed in the EDT process (ie, after Msg3 transmission until Msg4 reception).

[0681] (2.2.3. Configuration of timer value)

[0682] In addition, it is questionable how the eNB configures the timer value, because the eNB does not yet know when the TCP ACK will arrive from the higher layer message. Assuming that there are many UEs implementing various applications in a cell, it will be difficult for the eNB to set appropriate timer values ​​for all UEs.

[0683] Observation 4: Considering that different UEs may use different applications, it is difficult to configure appropriate timer values.

[0684] One possibility is to use dedicated signaling for Msg2 to configure the timer, but it is still difficult to determine the timer value without application layer knowledge of the eNB. On the other hand, the UE can help set a suitable timer value based on its timeout settings in higher layers. For example, the UE can inform the eNB of the self-configured timer value on Msg3.

[0685] Proposal 4: RAN2 should consider whether to allow UE to notify eNB of self-configured timer value in Msg3.

[0686] (2.2.4. Definition of timer)

[0687] If one or more of the above proposals (Proposal 2 to Proposal 4) are acceptable, the concept of timers for EDT will be different from the traditional timers. Due to, for example, larger packet transmission, a UE with EDT function may still initiate a traditional RRC connection establishment / recovery, so in this case, the traditional timers will apply. In this sense, it will be simpler to keep the existing timers as is and define new timers for EDT rather than extending the existing timers.

[0688] Proposal 5 RAN2 should agree to define a new timer running between UL EDT (via Msg3) and DL EDT (via Msg4) instead of the legacy timer.

[0689] [Appendix 6]

[0690] (1. Introduction)

[0691] RAN2#100 aims to lay an important foundation for the Early Data Transfer (EDT) function. However, many further considerations are still needed for the details, one of which is as follows.

[0692] protocol

[0693] Solutions for CP

[0694] […]

[0695] Further consideration is needed as to whether the T300 and MAC contention resolution timers need to be changed.

[0696] In this appendix, further considerations on timers are discussed.

[0697] (2. Discussion)

[0698] (2.1. Assumptions)

[0699] Proposal 1: RAN2 should discuss whether to support DL-only EDT procedures.

[0700] (2.2.T300 and Contention Resolution Timer)

[0701] (2.2.1.Msg4 delay issue)

[0702] Observation 1: The duration between Msg3 and Msg4 in EDT is longer than before due to the round trip time of higher layers.

[0703] For the mac contention resolution timer, early contention resolution can be used to prevent the timer from expiring. In the case of NB-IoT UE, it is agreed that Rel-14 and later versions support early contention resolution, but whether it is optional requires further consideration.

[0704] Proposal 2: If NB-IoT UE supporting EDT supports early contention resolution, RAN2 should agree that no changes to mac-contention resolution are required.

[0705] T300 is directly affected by the upper layer round trip time. It has been proposed to extend the timer value to take into account retransmissions and repeated transmissions of CE Mode B.

[0706] Therefore, it is easy to define a longer timer value to prevent unnecessary failures due to T300 expiration.

[0707] Proposal 3: RAN2 should define a longer value for the timer running between UL EDT on Msg3 and DL EDT on Msg4 to prevent unnecessary failures due to T300 expiration.

[0708] (2.2.2.: DRX for Msg4 reception)

[0709] If Proposal 3 is acceptable, it will be straightforward to extend the existing T300 timer value. However, this may result in additional UE power consumption due to continuous PDCCH monitoring until Msg4 is received, whereby Msg4 may be delayed in the EDT as discussed in the previous section. To avoid this unnecessary power consumption, some kind of DRX-type reception mode should be introduced during the EDT.

[0710] For example, as a simple solution, the UE can monitor PDCCH only in the subframe before the timer expires, i.e. "single" monitoring. In some MTC / NB-IoT use cases (such as high latency communication), it is better than continuous monitoring.

[0711] Proposal 4: RAN2 should consider whether discontinuous reception is allowed during the EDT process (i.e., after Msg3 transmission until Msg4 reception).

[0712] (2.2.3. Configuration of timer value)

[0713] In addition, it is questionable how the eNB configures the timer value, because the eNB does not yet know when the TCP ACK will arrive from the higher layer message. Assuming that there are many UEs implementing various applications in a cell, it will be difficult for the eNB to set appropriate timer values ​​for all UEs.

[0714] Observation 4: Considering that different UEs may use different applications, it is difficult to configure appropriate timer values.

[0715] One possibility is to use dedicated signaling for Msg2 to configure the timer, but it is still difficult to determine the timer value without application layer knowledge of the eNB. On the other hand, the UE can help set a suitable timer value based on its timeout settings in higher layers. For example, the UE can inform the eNB of the self-configured timer value on Msg3.

[0716] Proposal 5: RAN2 should consider whether to allow UE to notify eNB of self-configured timer value in Msg3.

[0717] (2.2.4. Definition of timer)

[0718] If one or more of the above proposals (Proposal 3 to Proposal 5) are acceptable, the concept of timers for EDT will be different from the legacy timers. Due to, for example, larger packet transmissions, a UE with EDT capability may still initiate a legacy RRC connection establishment / recovery, so in this case the legacy timers will apply. In this sense, it would be simpler to keep the existing timers as is and define new timers for EDT rather than extending the existing timers.

[0719] Proposal 6 RAN2 should agree to define a new timer running between UL EDT (via Msg3) and DL EDT (via Msg4) instead of the legacy timer.

[0720] [Appendix 7]

[0721] (1. Introduction)

[0722] RAN2#101 agrees that the solution to the padding problem in UL EDT is as follows.

[0723] protocol

[0724] Unless the UL grant provided is for legacy Msg3, the EDT UL grant shall always allow the maximum TB size broadcasted in the system information.

[0725] The EDT UL grant shall allow the UE to select an appropriate TB size, MCS, repetition count and RU (for NB-IoT) from a set of TB sizes provided based on the UL data. How the FFS provides this set of possible TB sizes, MCS, repetition count and RU (for NB-IoT) is e.g. hardcoded in the specification. This is pending RAN1 confirmation.

[0726] RAN2 assumes that there are 8 possible candidate values ​​for the maximum TB size broadcasted in the system information. RAN2 assumes that for each maximum TB size broadcasted, at most 4 possible TB sizes, i.e. blind decoding options, are allowed.

[0727] For eMTC, the reserved bits in the MAC RAR can be used for the EDT function in eMTC only when necessary.

[0728] Send an LS reply to RAN1 to obtain the above agreement, including the agreement on the maximum and minimum possible TB size, and request confirmation from RAN1.

[0729] In this appendix, further considerations on how this solution works are discussed.

[0730] (2. Discussion)

[0731] like Fig.32 As shown in , the association of TBS in the solution under the current assumptions can be described. Fig.32 The UL grant size and actual UL transmission of EDT are shown.

[0732] From the UE's perspective, an UL grant for EDT with 4 blind decoding options allows the UE to select a TBS that minimizes the required padding bits. However, if the granted UL data size for EDT does not "fit" (at least for the CP solution), the UE may start the legacy procedure and transition to an RRC connection. Therefore, from the UE's perspective, the maximum TBS and the number of blind coding options should be set as high as possible.

[0733] Observation 1: The UE may start EDT when the maximum TBS and / or blind decoding options “fit” well with its UL data size.

[0734] On the contrary, from the perspective of the NW, the maximum TBS should be set to the lowest practical value to minimize resource waste. Therefore, in some implementations, the configuration of the maximum TBS value will tend to be more conservative. However, this configuration will directly affect how many UEs use EDT, i.e., whether the NW supports low-power operation of UEs. Since the NW may not know the UL data size required by UEs with various MTC applications, it is not clear whether the NW implementation has appropriate methods for optimizing the maximum TBS and blind decoding options.

[0735] Observation 2: The effectiveness of EDT will depend on the optimal maximum TBS configuration.

[0736] Observation 3: The configuration of maximum TBS and blind decoding options should be based on the UL data size requirement of the MTC application.

[0737] In view of the above observations, whether the UE should provide feedback about its expected applications, especially regarding the UL data size, should be considered as part of NW optimization.

[0738] Before the UE transitions back to RRC idle (eg, sends RAI), the UE may have the opportunity to inform the eNB of its preferred TBS for EDT as auxiliary information. The auxiliary information is meaningful in the following cases.

[0739] Case 1: Similar to BSR, this information can be used as the expected data size of the next EDT, so it will become one of the reference conditions for changing the configuration in the SIB.

[0740] • Case 2: Similar to UE capabilities, this information can be used to determine whether NCC should be provided to the UE for the next EDT possibility.

[0741] Case 3: Similar to MDT, this information may be used for statistical analysis and NW optimization.

[0742] Therefore, auxiliary information associated with the EDT operation should be introduced.

[0743] Proposal 1: RAN2 should agree to allow the UE to send assistance information for TBS configuration optimization, such as its preferred TBS.

[0744] In addition, there may be a case where the UE itself falls back to legacy, i.e., due to, for example, additional UL data generated by the application, the UE sends a legacy Msg3 even after sending an EDT indication in Msg1 and receiving an UL grant for EDT. If this case is taken into account, in addition to the agreed 4 options, the EDT UL grant should always allow the blind decoding option for the legacy Msg3 size.

[0745] Proposal 2: In addition to the 4 options agreed, RAN2 should discuss whether the EDT UL grant should always allow the blind decoding option for the legacy Msg3 size.

[0746] [Cross reference]

[0747] This application claims the benefit of priority to U.S. Provisional Application No. 62 / 543,469 (filed on August 10, 2017), U.S. Provisional Application No. 62 / 560,775 (filed on September 20, 2017), U.S. Provisional Application No. 62 / 564,430 (filed on September 28, 2017), U.S. Provisional Application No. 62 / 586,981 (filed on November 16, 2017), U.S. Provisional Application No. 62 / 627,313 (filed on February 7, 2018), U.S. Provisional Application No. 62 / 630,915 (filed on February 15, 2018), and U.S. Provisional Application No. 62 / 652,436 (filed on April 4, 2018), the entire disclosures of which are incorporated herein by reference.

Claims

1. A communication control method for controlling user data transmission of uplink user data during a random access procedure, the communication control method comprising the following steps: The base station sends a first timer value and a second timer value to the user equipment, where the first timer value is used to not perform a random access procedure for the user data transmission, and the second timer value is used to perform a random access procedure for the user data transmission, and the second timer value is different from the first timer value; In response to determining to perform the user data transmission, the user equipment selects the second timer value; and The user equipment starts a timer with the second timer value set when sending uplink data through the user data transmission.

2. The communication control method according to claim 1, wherein: The timer is a timer that defines the maximum waiting time of the user equipment from sending Msg3 to receiving Msg4 during the random access process. In the user data transmission, the user equipment sends the uplink user data when sending the Msg3.

3. A user equipment, comprising: a receiving unit, receiving a first timer value and a second timer value from a base station, wherein the first timer value is used for not performing a random access procedure for user data transmission, and the second timer value is used for performing a random access procedure for the user data transmission, wherein the user data transmission sends uplink user data during the random access procedure, and the second timer value is different from the first timer value; as well as The control unit selects the second timer value in response to determining to perform the user data transmission, wherein: The control unit starts the timer having the second timer value set when sending uplink data through the user data transmission.

4. A processor for controlling a user equipment, the processor performing the following processing: receiving, from a base station, a first timer value and a second timer value, the first timer value being used for not performing a random access procedure for user data transmission, the second timer value being used for performing a random access procedure for the user data transmission, wherein the user data transmission transmits uplink user data during the random access procedure, the second timer value being different from the first timer value; In response to determining to perform the user data transmission, selecting the second timer value; as well as When uplink data is sent through the user data transmission, a timer with the second timer value set is started.

5. A base station, comprising: A control unit, the control unit performs the following processing: sending a first timer value and a second timer value, the first timer value is used for not performing a random access procedure for user data transmission, the second timer value is used for performing a random access procedure for the user data transmission, wherein the user data transmission sends uplink user data during the random access procedure, and the second timer value is different from the first timer value.

Images