Communication control method

Abstract

To provide an early data transmission method and a system that transmit data using a predetermined message during a random access procedure for wireless terminals targeted for machine type communication (MTC) and Internet of things (IoT) to perform efficient communication.SOLUTION: A communication control method comprises a step in which a base station eNB transmits to user equipment UE 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, a step in which the user equipment selects the second timer value in response to determining that early data transmission will be performed, and a step in which the user equipment starts a timer set to the second timer value when transmitting uplink data by early data transmission.SELECTED DRAWING: Figure 18

Description

[Technical field]

[0001] The present invention relates to a communication control method in a mobile communication system. [Background technology]

[0002] In recent years, wireless terminals for MTC (Machine Type Communication) and IoT (Internet of Things) services that communicate without human intervention have been attracting attention. Such wireless terminals are required to achieve low cost, extended coverage, and low power consumption. For this reason, 3GPP (3rd Generation Partnership Project) (registered trademark; the same applies below) has specified a new category of wireless terminals that limit the transmission and reception bandwidth to only a part of the system transmission and reception bandwidth. Summary of the Invention

[0003] A communication control method according to one embodiment is a method in a mobile communication system, the communication control method including the steps of: a base station transmitting a system information block (SIB) indicating an allowable data amount permitted to be transmitted in an early data transmission for transmitting uplink user data using a message 3 during a random access procedure; a radio terminal in an RRC idle mode receiving the SIB; and, when an amount of data to be transmitted to the base station is equal to or less than the allowable data amount indicated by the SIB, determining by the radio terminal to perform the early data transmission.

[0004] The communication control method may further include a step in which, after determining to perform the early data transmission, the wireless terminal selects a PRACH resource to be used for transmitting a random access preamble from among the PRACH resources for the early data transmission, and a step in which the wireless terminal transmits the random access preamble to the base station using the selected PRACH resource.

[0005] In the communication control method, the PRACH resource for early data transmission may be provided for each extended coverage level, and the selecting step may include a step of selecting a PRACH resource corresponding to the extended coverage level applied to the wireless terminal.

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

[0007] The communication control method may further include a step of the wireless terminal receiving the random access response from the base station, and a step of the wireless terminal canceling the early data transmission if the uplink grant included in the random access response is not for the early data transmission.

[0008] A communication control method according to one embodiment is a communication control method for controlling early data transmission for transmitting uplink user data 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 to the radio terminal a first timer value for the random access procedure without the early data transmission and a second timer value for the random access procedure with the early data transmission, a step B in which the radio terminal selects the second timer value in response to the determination by the radio terminal to perform the early data transmission, and a step C in which the radio terminal starts a timer set to the second timer value when transmitting the uplink data by the early data transmission.

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

[0010] A communication control method according to one embodiment is a communication control method for controlling early data transmission in which a radio terminal transmits or receives user data in an amount equal to or less than a maximum user data amount set by a base station during a random access procedure. The communication control method includes a step A in which the radio terminal determines the maximum user data amount recommended by the radio terminal, and a step B in which the radio terminal in an RRC connected mode transmits information indicating the maximum user data amount recommended by the radio terminal to the base station. [Brief description of the drawings]

[0011] [Figure 1] 1 is a diagram showing a configuration of an LTE system (mobile communication system) according to an embodiment. [Diagram 2] FIG. 2 is a diagram illustrating a configuration of a UE (wireless terminal) according to the embodiment. [Diagram 3] FIG. 2 is a diagram illustrating a configuration of an eNB (base station) according to an embodiment. [Figure 4] FIG. 2 is a diagram showing a protocol stack of a radio interface in an LTE system according to an embodiment. [Diagram 5] 1 is a diagram showing a configuration of a radio frame of an LTE system according to an embodiment. [Figure 6]A diagram showing frequency channels handled by eMTC UE and NB-IoT UE. [Figure 7] A diagram showing a random access procedure for eMTC UE and NB-IoT UE. [Figure 8] FIG. 2 is a diagram showing an operation pattern 1 according to the first embodiment. [Figure 9] FIG. 4 is a diagram showing an operation pattern 2 according to the first embodiment. [Figure 10] FIG. 4 is a diagram showing an operation pattern 3 according to the first embodiment. [Figure 11] FIG. 11 is a diagram showing an operation pattern 4 according to the first embodiment. [Figure 12] FIG. 12 is a diagram showing a modification of the sequence of FIG. [Figure 13] FIG. 11 is a diagram showing a first modified example of the first embodiment. [Figure 14] FIG. 11 is a diagram illustrating an example of a PRACH resource configuration according to a first modification of the first embodiment. [Figure 15] FIG. 11 is a diagram showing a second modification of the first embodiment. [Figure 16] FIG. 13 is a diagram showing an example of a MAC PDU according to an eighth modification of the first embodiment. [Figure 17] FIG. 23 is a diagram illustrating an example of the operation of the fourteenth modification of the first embodiment. [Figure 18] FIG. 23 is a diagram illustrating another example of the operation of the fourteenth modification of the first embodiment. [Figure 19] FIG. 23 is a diagram illustrating an example of the operation of the fifteenth modification of the first embodiment. [Figure 20] FIG. 23 is a diagram illustrating an example of the operation of the seventeenth modification of the first embodiment. [Figure 21] FIG. 23 is a diagram illustrating an example of the operation of the eighteenth modification of the first embodiment. [Figure 22] FIG. 11 is a diagram showing an example of an operation pattern 1 according to the second embodiment. [Figure 23] FIG. 11 is a diagram showing an example of an operation pattern 2 according to the second embodiment. [Figure 24] FIG. 11 is a diagram showing an example of an operation pattern 3 according to the second embodiment. [Diagram 25] FIG. [Figure 26] FIG. [Figure 27] FIG. [Figure 28] FIG. [Figure 29] FIG. [Diagram 30] FIG. [Diagram 31] FIG. [Diagram 32] FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] [First embodiment] (Overview of the first embodiment) A wireless terminal for MTC or IoT has a smaller amount of data to be transmitted and received, and transmits and receives data less frequently, compared to a general wireless terminal. Therefore, in order for wireless terminals for MTC or IoT to communicate efficiently, early data transmission, which transmits data using a predetermined message during a random access procedure, is being considered. However, the current mobile communication system does not assume that data will be transmitted during a random access procedure, and there is no mechanism that enables early data transmission.

[0013] Therefore, an object of the present disclosure is to provide a communication control method that enables early data transmission.

[0014] A communication control method according to a first embodiment is a method in a mobile communication system. The communication control method includes a step A in which a first wireless communication device transmits information regarding whether or not to perform early data transmission, which transmits data using a predetermined message during a random access procedure, to a second wireless communication device, and a step B in which, after the second wireless communication device receives the information, the second wireless communication device determines whether or not to perform the early data transmission based on the received information. The first wireless communication device is one of a wireless terminal and a base station, and the second wireless communication device is the other of the wireless terminal and the base station. The step A is performed before a timing of transmitting the predetermined message.

[0015] (Mobile communication system) The configuration of a mobile communication system according to the first embodiment will be described. Fig. 1 is a diagram showing the configuration of an LTE (Long Term Evolution) system, which is a mobile communication system according to the first embodiment. The LTE system is a mobile communication system based on the 3GPP standard.

[0016] 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.

[0017] The UE 100 is a mobile communication device that performs wireless communication with the eNB 200 that manages a cell (a serving cell) in which the UE 100 is located.

[0018] E-UTRAN 10 includes base stations (eNB: evolved Node-B) 200. eNBs 200 are connected to each other via an X2 interface. eNB 200 manages one or more cells. eNB 200 performs wireless communication with UE 100 that has established a connection with its own cell. eNB 200 has a radio resource management (RRM) function, a routing function for user data (hereinafter simply referred to as "data"), a measurement control function for mobility control and scheduling, and the like. "Cell" is used as a term indicating the smallest unit of a wireless communication area. "Cell" is also used as a term indicating a function or resource for performing wireless communication with UE 100. One cell belongs to one carrier frequency.

[0019] The EPC 20 includes a mobility management entity (MME) and a serving gateway (S-GW) 300. The MME performs various mobility controls for the UE 100. The MME manages information on a tracking area (TA) in which the UE 100 is located by communicating with the UE 100 using NAS (Non-Access Stratum) signaling. A tracking area is an area consisting of multiple cells. The S-GW controls data forwarding. The MME and S-GW are connected to the eNB 200 via an S1 interface.

[0020] 2 is a diagram showing a configuration of the UE 100 (wireless terminal). The UE 100 includes a receiving unit 110, a transmitting unit 120, and a control unit .

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

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

[0023] The control unit 130 performs various controls in the UE 100. The control unit 130 includes at least one processor and a memory. The memory stores programs executed by the processor and information used in the processing by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation / demodulation and encoding / decoding of a baseband signal. The CPU executes programs stored in the memory to perform various processing. The processor executes the processing described below.

[0024] 3 is a diagram showing a configuration of the eNB 200 (base station). The eNB 200 includes a transmitter 210, a receiver 220, a controller 230, and a backhaul communication unit 240.

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

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

[0027] The control unit 230 performs various controls in the eNB 200. The control unit 230 includes at least one processor and a memory. The memory stores programs executed by the processor and information used in the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of a baseband signal. The CPU executes programs stored in the memory to perform various processing. The processor executes the processing described below.

[0028] The backhaul communication unit 240 is connected to a neighboring eNB via an X2 interface. The backhaul communication unit 240 is connected to the MME / S-GW 300 via an S1 interface. The backhaul communication unit 240 is used for communication over the X2 interface and communication over the S1 interface.

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

[0030] 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.

[0031] The MAC layer performs data priority control, retransmission processing using hybrid ARQ (HARQ), random access procedures, 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 uplink and downlink transport format (transport block size, modulation and coding scheme (MCS)) and the resource blocks to be assigned to the UE 100.

[0032] The RLC layer transmits data to the RLC layer on the receiving side by utilizing the 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 logical channels.

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

[0034] The RRC layer is defined only in the control plane that handles control information. RRC signaling for various settings is transmitted between the RRC layer of the UE 100 and the RRC layer of the eNB 200. The RRC layer controls logical channels, transport channels, and physical channels in response to establishment, re-establishment, and release of 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 RRC connected 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 RRC idle mode.

[0035] The NAS layer, which is 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 a function of an application layer and the like in addition to a protocol of a radio interface.

[0036] FIG. 5 is a diagram showing a configuration of a radio frame used in an LTE system. A radio frame is composed of 10 subframes on a time axis. Each subframe is composed of two slots on a time axis. The length of each subframe is 1 ms. The length of each slot is 0.5 ms. Each subframe includes multiple resource blocks (RBs) on a frequency axis. Each subframe includes multiple symbols on a time axis. Each resource block includes multiple subcarriers on a frequency axis. Specifically, one RB is composed of 12 subcarriers and one slot. One resource element (RE) is composed of one symbol and one subcarrier. Of 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 slots).

[0037] In the downlink, the section of the first few symbols of each subframe is an area used mainly as a physical downlink control channel (PDCCH) for transmitting downlink control information, and the remaining part of each subframe is an area used mainly as a physical downlink shared channel (PDSCH) for transmitting downlink data.

[0038] In the uplink, both ends of each subframe in the frequency direction are regions that are mainly used as a Physical Uplink Control Channel (PUCCH) for transmitting uplink control information, and the remaining part of each subframe is a region that is mainly used as a Physical Uplink Shared Channel (PUSCH) for transmitting uplink data.

[0039] (Overview of eMTC and NB-IoT) An overview of eMTC and NB-IoT will be described. In the first embodiment, a scenario is assumed in which a new category of UE 100 exists that targets MTC and IoT services. The new category of UE 100 is a UE 100 whose transmission and reception bandwidth is limited to only a part of the system transmission and reception bandwidth (LTE transmission and reception bandwidth). The new UE categories are called, for example, category M1 and category NB (Narrow Band)-IoT. Category M1 is a category to which eMTC (enhanced Machine Type Communications) UEs belong. Category NB-IoT (category NB1) is a category to which NB-IoT UEs belong. Category M1 is a category to which UE 100 (eMTC Category NB-IoT (category NB1) limits the transmission and reception bandwidth of UE 100 (NB-IoT UE) to, for example, 1.08 MHz (i.e., a bandwidth of six resource blocks). Category NB-IoT (category NB1) further limits the transmission and reception bandwidth of UE 100 (NB-IoT UE) to 180 kHz (i.e., a bandwidth of one resource block). Such narrowbanding makes it possible to achieve the low cost and low power consumption required for eMTC UE and NB-IoT UE.

[0040] FIG. 6 is a diagram showing frequency channels handled by eMTC UE and NB-IoT UE. As shown in FIG. 6, the frequency bandwidth of the system frequency band of the LTE system may be 10 MHz. The bandwidth of the system transmission and reception band is, for example, 50 resource blocks = 9 MHz. The bandwidth of the frequency channel that the eMTC UE can support is within 6 resource blocks = 1.08 MHz. A frequency channel of 6 resource blocks or less that the eMTC UE can support is called a "narrow band (NB: Narrow Band)". The bandwidth of the frequency channel that the NB-IoT UE can support is 1 resource block = 180 kHz. A frequency channel of 1 resource block that the NB-IoT UE can support is called a "carrier".

[0041] The eMTC UE operates within the LTE transmission / reception bandwidth. The NB-IoT UE supports a mode in which it operates within the LTE transmission / reception bandwidth, a mode in which it operates in a guard band outside the LTE transmission / reception bandwidth, and a mode in which it operates within a frequency band dedicated to NB-IoT.

[0042] In order to realize coverage extension, eMTC UE and NB-IoT UE support an Enhanced Coverage (EC) function using repeated transmission, etc. The enhanced coverage function may include repetition, which repeatedly transmits the same signal using multiple subframes. The more the number of repeated transmissions, the more the coverage can be extended. The enhanced coverage function may include power boosting, which increases the power density of a transmission signal. As an example, the power density is increased by narrowband transmission, which narrows the frequency bandwidth of a transmission signal. The more the power density of a transmission signal is increased, the more the coverage can be extended. The enhanced coverage function may include lower MCS transmission, which lowers the MCS used for a transmission signal. The coverage can be extended by transmitting using an MCS with a low data rate and high error tolerance.

[0043] (Overview of Random Access Procedures) FIG. 7 is a diagram showing a random access procedure for eMTC UE and NB-IoT UE. In an initial state, the UE 100 is in an RRC idle mode. The UE 100 executes a random access procedure to transition to an RRC connected mode. Such a case is called an initial access from RRC_IDLE. At the time of the initial access, a contention based random access procedure is applied.

[0044] The UE 100 selects the cell of the eNB 200 as a serving cell. The UE 100 may determine that it is in the enhanced coverage when the first cell selection criterion (first S-criteria) for normal coverage is not satisfied and the second cell selection criterion (second S-criteria) for enhanced coverage is satisfied. The term "UE in the enhanced coverage" refers to a UE that is required to use an enhanced coverage function (enhanced coverage mode) to access a cell. Note that it is mandatory for eMTC UEs to use the enhanced coverage mode. Here, the following description will be given on the assumption that the UE 100 is in the enhanced coverage.

[0045] In step S1001, eNB200 transmits PRACH (Physical Random Access Channel) related information by broadcast signaling (e.g., SIB). The PRACH related information includes various parameters provided for each enhanced coverage level. As an example, a total of four enhanced coverage levels, enhanced coverage levels 0 to 3, are defined. The various parameters include an RSRP (Reference Signal Received Power) threshold, a PRACH resource, and a maximum number of preamble transmissions. The PRACH resource includes a radio resource (time-frequency resource) and a signal sequence (preamble sequence). UE100 stores the received PRACH related information.

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

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

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

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

[0050] In step S1006, eNB 200 transmits Msg2 (random access response) including scheduling information indicating the PUSCH resource allocated to UE 100 to UE 100. UE 100 may transmit Msg1 multiple times up to the maximum preamble transmission number corresponding to its own enhanced coverage level until it successfully receives Msg2.

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

[0052] In step S1008, the eNB 200 transmits Msg4 to the UE 100. Msg4 may be an RRC Connection Setup message.

[0053] In step S1009, in response to receiving Msg 4, UE 100 transitions to the RRC connected mode. At that time, UE 100 may transmit an Msg 5: RRC Connection Setup Complete message to eNB 200. After that, eNB 200 controls repeated transmission to UE 100, etc., based on the identified enhanced coverage level.

[0054] (Operations related to early data transmission) An operation relating to early data transmission according to the first embodiment will be described.

[0055] 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., an RRC connection request message), Msg4 (RRC connection establishment message), and Msg5 (RRC connection establishment completion message). Note that "transmitting data using a predetermined message" means at least one of transmitting data by including it in the predetermined message, transmitting data by adding it to the predetermined message, and transmitting data in association with the predetermined message.

[0056] The early data transmission may be applied to a UE in an RRC suspended state. The RRC suspended state is a special state of the RRC idle mode in which the UE context is retained in the network. In a random access procedure for a UE in an RRC suspended state to recover to an RRC connected mode, Msg 3 is an RRC connection resume request message, Msg 4 is an RRC connection resume message, and Msg 5 is an RRC connection recovery completion message.

[0057] The communication control method according to the first embodiment includes step A in which a first wireless communication device transmits information regarding whether or not to perform early data transmission, which transmits data using a predetermined message during a random access procedure, to a second wireless communication device, and step B in which, after the second wireless communication device receives the information, the second wireless communication device determines whether or not to perform early data transmission based on the received information. The first wireless communication device is one of the UE 100 and the eNB 200, and the second wireless communication device is the other of the UE 100 and the eNB 200. Step A is performed before the transmission timing of the predetermined message.

[0058] An overview of operation patterns 1 to 4 according to the first embodiment will be described below. Operation patterns 1 to 4 can be combined with at least a part of the operations in the above-mentioned "Outline of the Random Access Procedure" (see FIG. 7).

[0059] In the operation pattern 1 according to the first embodiment, step A includes a step in which the UE 100 selects a resource to be applied to transmission of a random access preamble based on whether or not early data transmission is performed, and a step in which the UE 100 transmits the random access preamble to which the selected resource is applied. In step B, the eNB 200 determines whether or not early data transmission is performed based on the resource applied to the random access preamble.

[0060] In operation pattern 2 according to the first embodiment, in step A, UE 100 transmits a notification indicating that early data transmission will be performed to eNB 200 while UE 100 is in connected mode. Operation pattern 2 further includes a step of UE 100 transitioning from connected mode to idle mode after transmitting the notification, and a step of eNB 200 or an upper network device retaining the notification while UE 100 is in idle mode. In step B, eNB 200 determines whether or not to perform early data transmission based on the retained notification during a random access procedure.

[0061] In operation pattern 3 according to the first embodiment, in step A, eNB200 transmits a notification indicating whether or not to perform early data transmission to UE100 by at least one of a paging message, DCI (Downlink Control Information), and PDSCH (Physical Downlink Shared Channel) before a random access procedure is started. In step B, UE100 determines whether or not to perform early data transmission based on the notification from eNB200.

[0062] In operation pattern 4 according to the first embodiment, in step A, eNB200 transmits information indicating the amount of data permitted to be transmitted by early data transmission to UE100 before starting a random access procedure. In step B, UE100 determines whether to perform early data transmission based on the amount of data notified by eNB200 and the amount of data that UE100 transmits to eNB200.

[0063] (1) Operation pattern 1 8 is a diagram showing operation pattern 1 according to the first embodiment. Differences from the operation in the above-mentioned "Outline of the random access procedure" will be mainly explained.

[0064] 8, in step S101, the eNB 200 transmits (broadcasts) PRACH resource information indicating PRACH resources (PRACH resource pool), which are resources available for transmitting a random access preamble, by system information (SIB). The PRACH resources include radio resources (time-frequency resources) and / or signal sequences (preamble sequences).

[0065] The PRACH resources include a first resource group (PRACH resource pool) indicating that early data transmission is to be performed (intent to perform early data transmission) and a second resource group (PRACH resource pool) indicating that early data transmission is not to be 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).

[0066] 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 the conventional PRACH resource. The first resource group may be a PRACH resource secured separately from the conventional PRACH resource.

[0067] The first resource group may include a first resource subgroup indicating that uplink data is transmitted by early data transmission and a second resource subgroup indicating that downlink data is received by early data transmission. Furthermore, the first resource group may include a third resource subgroup indicating that both uplink data is transmitted and downlink data is received by early data transmission. The eNB200 may include information indicating at least one of a plurality of resource subgroups (the first resource subgroup, the second resource subgroup, and the third resource subgroup) in the SIB.

[0068] The UE 100 in the RRC idle mode receives an SIB from the eNB 200. The UE 100 in the RRC idle mode determines that it is necessary to establish an RRC connection, and starts preparation for a random access procedure. Here, the UE 100 may determine that it is necessary to establish an RRC connection in order to transmit uplink data in response to the occurrence of uplink data in the UE 100. The UE 100 may determine that it is necessary to establish an RRC connection in order to receive downlink data in response to the reception of a paging message addressed to the UE 100 from the eNB 200.

[0069] In step S102, UE 100 in RRC idle mode selects resources to be applied to the transmission of a random access preamble from among the PRACH resources notified in the SIB. If UE 100 performs early data transmission, it selects resources in the first resource group. On the other hand, if UE 100 does not perform early data transmission, it selects resources in the second resource group. Whether or not to perform early data transmission is based on at least one of the following criteria 1) to 7): 1) Capability of UE 100, i.e., whether UE 100 has the capability to perform early data transmission; 2) Priority of data to be transmitted or received by UE 100 (e.g., QoS); 3) Power state of UE 100 (e.g., remaining battery power); 4) Necessity of reducing data delay (e.g., necessity of early TCP ACK transmission, ), 5) User preference (e.g., manual setting), 6) Instruction from the network (e.g., based on functional restrictions by MME or the like or authentication results), 7) Instruction from the eNB (e.g., based on whether the eNB has early data transmission capability). Note that "performing early data transmission" may mean that UE 100 wants to perform early data transmission, or may mean whether early data transmission is permitted, or may mean whether early data transmission is possible.

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

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

[0072] In step S104, the eNB200 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 eNB200 determines to perform early data transmission for the source UE100. Furthermore, the eNB200 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 eNB200 determines not to perform early data transmission for the source UE100.

[0073] In the operation pattern 1, the case where the time-frequency resource is divided and the case where the signal sequence resource is divided have been described, but the time-frequency resource and the signal sequence resource may be combined and divided. For example, the time-frequency resource may be divided into a first resource group and a second resource group, and the signal sequence resource may be divided into resource subgroups in the first resource group. Alternatively, the signal sequence resource may be divided into a first resource group and a second resource group, and the time-frequency resource may be divided into resource subgroups in the first resource group.

[0074] Also, as described later, uplink early data transmission may be used in combination with downlink early data transmission. For example, UE 100 transmits uplink data by uplink early data transmission in Msg3, and receives response data (such as TCP ACK) to the data by downlink early data transmission in Msg4. Therefore, the condition that enables the UE 100 to notify the intention of early data transmission by Msg1 may include the condition that "UE 100 has the capability of both uplink early data transmission and downlink early data transmission." In other words, UE 100 that does not have the capability of at least one of uplink early data transmission and downlink early data transmission may be prohibited from notifying the intention of early data transmission by Msg1.

[0075] Furthermore, it is preferable that the new PRACH resource pool (time-frequency resource) used for notifying the intention of early data transmission is specified as a resource pool separate from the conventional PRACH resource pool (time-frequency resource). In this case, the eNB 200 may determine whether to configure the new PRACH resource pool and the conventional PRACH resource pool so as not to overlap each other or to configure the new PRACH resource pool and the conventional PRACH resource pool so as to overlap each other at least partially, and notify the UE 100 of each PRACH resource pool (for example, by SIB).

[0076] (2) Operation pattern 2 9 is a diagram showing operation pattern 2 according to the first embodiment. Differences from the operation in the above-mentioned "Outline of Random Access Procedure" will be mainly described. Also, descriptions overlapping with operation pattern 1 will be omitted. Operation pattern 2 may be applied to uplink early data transmission, or may be applied to downlink early data transmission.

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

[0078] 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 an RRC suspended state. The RRC connection release message may also include information indicating that the UE 100 may (or must) perform early data transmission. The RRC connection release message may also include information indicating that the UE 100 may not perform early data transmission.

[0079] In step S203, the UE 100 releases the RRC connection in response to the RRC connection release message, and transitions from the RRC connected mode to the RRC idle mode. The UE 100 may be in an RRC suspended state. The UE 100 holds notification information while the UE 100 is in the idle mode.

[0080] In step S204, the eNB200 holds the notification information while the UE100 is in the idle mode. In other words, the eNB200 holds information indicating that early data transmission will be performed for the UE100 when the next RRC connection is established. In addition to the eNB200, or instead of the eNB200, a higher-level device of the eNB200 (e.g., the MME300) may hold the notification information. The information held by the eNB200 and / or the MME300 may include capability information of the UE100 (capability regarding early data transmission). The UE100 and the eNB200 may cancel (discard) the notification information when the UE100 decides not to perform early data transmission (when the conventional PRACH resource is used in Msg1).

[0081] In step S205, the UE 100 transmits Msg1 (random access preamble) to the eNB 200. Although details will be described later, the UE 100 may transmit the random access preamble by applying a dedicated preamble sequence (dedicated preamble) assigned individually to the UE by the eNB 200. The eNB 200 receives the random access preamble from the UE 100.

[0082] The eNB 200 may receive a paging message addressed to the UE 100 in the 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 held by the higher-level device. The eNB 200 may use the information included in the paging message to determine whether or not to perform early data transmission for the UE 100.

[0083] When a dedicated preamble sequence is applied, in step S206, eNB200 identifies UE100 based on the preamble sequence. Then, eNB200 determines whether to perform early data transmission based on the notification information stored in step S204. Specifically, eNB200 determines to perform early data transmission if notification information corresponding to identified UE100 is stored. On the other hand, eNB200 determines not to perform early data transmission if notification information corresponding to identified UE100 is not stored.

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

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

[0086] If a dedicated preamble sequence is not applied, in step S209, the eNB 200 identifies the UE 100 based on the Msg 3. Then, the eNB 200 determines whether to perform early data transmission based on the notification information held in step S204.

[0087] (3) Operation pattern 3 Fig. 10 is a diagram showing operation pattern 3 according to the first embodiment. Differences from the operation in the above-mentioned "Outline of Random Access Procedure" will be mainly described. Also, descriptions overlapping with operation patterns 1 and 2 will be omitted. Operation pattern 3 is applied to downlink early data transmission.

[0088] In the operation pattern 3, the UE 100 performing the random access procedure is in the RRC idle mode or the RRC connected mode. The UE 100 in the RRC idle mode performs the contention-based random access procedure. On the other hand, the UE 100 in the RRC connected mode can perform the non-contention based random access procedure. In the non-contention based random access procedure, a dedicated preamble sequence is assigned to each UE from the eNB 200 by DCI (Downlink Control Information) or dedicated RRC signaling. The non-contention based random access procedure is applied at the time of handover, uplink timing adjustment, etc.

[0089] As shown in FIG. 10, in step S301, before the random access procedure is started, the eNB 200 transmits a notification indicating whether or not to perform early data transmission to the UE 100 by at least one of a paging message, a DCI, and a PDSCH.

[0090] When the paging message is used, a contention-based random access procedure may be applied. The eNB 200 transmits a paging message including a combination of a destination UE identifier and information indicating whether or not 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.

[0091] When DCI or PDSCH is used, UE 100 may be in an RRC connected mode. When DCI or PDSCH is used, a non-contention based random access procedure may be applied. eNB 200 includes information indicating whether or not early data transmission is performed in DCI or PDSCH addressed to UE 100. eNB 200 may transmit DCI including information indicating whether or not early data transmission is performed to UE 100 in a paging occasion that is a timing at which UE 100 performing discontinuous reception (DRX) operation monitors a PDCCH.

[0092] When the predetermined message used for early data transmission is Msg1 (random access preamble), the eNB200 may notify the UE100 of the PRACH resource for early data transmission when notifying the UE100 of whether or not to perform early data transmission. The notification is performed by at least one of a paging message, DCI, and PDSCH. The eNB200 may broadcast some PRACH resources (and a list including their indexes) in advance by SIB. The eNB200 may notify the index of the PRACH resource by at least one of a paging message, DCI, and PDSCH.

[0093] In step S302, UE 100 determines whether or not to perform early data transmission based on the notification from eNB 200 in step S301. If it has been notified that early data transmission will be performed, UE 100 may determine to perform early data transmission. Alternatively, even if it has been notified that early data transmission will be performed, UE 100 may determine not to perform early data transmission. In this case, UE 100 may notify eNB 200 that early data transmission will not be performed, for example, by Msg1 (random access preamble) or Msg3 (for example, an RRC connection request message) during the random access procedure.

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

[0095] Alternatively, the eNB 200 may notify the UE 100 of the intention to perform downlink early data transmission during the random access procedure. For example, the eNB 200 may transmit, to the UE 100, information indicating that downlink data is to be transmitted by Msg4, by Msg2.

[0096] (4) Operation pattern 4 FIG. 11 is a diagram showing operation pattern 4 according to the first embodiment. Differences from the operation in the above-mentioned "Outline of Random Access Procedure" will be mainly described. Also, descriptions overlapping with operation patterns 1 to 3 will be omitted. Operation pattern 4 is applied to uplink early data transmission.

[0097] As shown in FIG. 11, in step S401, eNB200 transmits, to UE100, information indicating an amount of data (allowable data amount) allowed to be transmitted by early data transmission before starting a random access procedure. The information indicating the allowable data amount of early data transmission may be a threshold indicating the allowable data amount. eNB200 may broadcast the information indicating the allowable data amount of early data transmission by SIB. eNB200 may transmit the information indicating the allowable data amount of early data transmission to each UE individually by a unicast message (e.g., an RRC Connection Release message). UE100 receives the information indicating the allowable data amount of early data transmission. UE100 may be in an RRC idle mode.

[0098] The allowable data amount notified by the eNB200 to the UE100 may be only one or may be multiple. In the case of multiple allowable data amounts, a list consisting of multiple combinations of the allowable data amounts and their indexes may be configured. The eNB200 may change the contents of the list (the number of records) based on the load status of the cell, etc. The UE100 may indicate to the eNB200 the amount of data to be transmitted by early data transmission by notifying the eNB200 of an index corresponding to the amount of uplink data to be transmitted to the eNB200 by Msg1 based on the list.

[0099] In step S402, the UE 100 determines whether to perform early data transmission based on the allowable data amount notified by the eNB 200 and the amount of data that the UE 100 transmits to the eNB 200. The amount of data that the UE 100 transmits to the eNB 200 may be the amount of uplink data stored in an uplink buffer in the UE 100.

[0100] The subject making such a determination may be the access layer (AS) of the UE 100 or an upper layer of the UE 100. As described above, the access layer (AS) is a layer consisting of a PHY layer, a MAC layer, an RLC layer, a PDCP layer, and an RRC layer. The access layer (AS) is a layer for performing wireless communication with the eNB 200. The upper layer is a layer consisting of a NAS layer, an application layer, etc., and is positioned higher than the access layer. Data to be transmitted to the eNB 200 (i.e., uplink data) is generated in the upper layer.

[0101] When the decision subject is the access layer (AS) of the UE 100, the upper layer of the UE 100 may notify the access layer (AS) of the UE 100 of the amount of data to be transmitted to the eNB 200 by uplink early data transmission. The amount of data to be 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 layer (AS) of the UE 100 determines whether to perform early data transmission based on the allowable data amount notified by the eNB 200 through the SIB and the size of the data packet notified by the upper layer.

[0102] On the other hand, when the decision subject is the upper layer of the UE 100, the access layer notifies the upper layer of the allowable data amount notified by the eNB 200. The upper layer determines whether to perform early data transmission based on the allowable data amount notified by the access layer and the size of a data packet to be transmitted to the eNB 200.

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

[0104] The UE 100 may determine to perform early data transmission even when the amount of data to be transmitted to the eNB 200 exceeds the allowable data amount. 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.

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

[0106] 11, an example has been described in which, when the amount of data (i.e., uplink data) to be transmitted to eNB200 exceeds the allowable data amount, UE100 transmits the uplink data by early data transmission, transitions to the RRC connected mode, and then transmits the remaining uplink data to eNB200. However, since it is necessary to transition to the RRC connected mode even when the amount of uplink data exceeds the allowable data amount only slightly, this is inefficient and undesirable in terms of power consumption of UE100.

[0107] Therefore, when the amount of data to be transmitted to the eNB 200 is greater than the allowable data amount notified by the eNB 200 through the broadcast information (SIB), the UE 100 may transmit the Msg3 multiple times. Each of the multiple Msg3 transmissions involves data transmission. For example, the UE 100 transmits uplink data up to the allowable data amount in the first Msg3 transmission, and transmits the remaining uplink data in the second Msg3 transmission. This makes it possible to complete the transmission of the uplink data through the early data transmission, and therefore the UE 100 does not need to transition to the RRC connected mode.

[0108] Fig. 12 is a diagram showing a modified example of the sequence of Fig. 11. Here, differences from the sequence of Fig. 11 will be mainly described.

[0109] As shown in Fig. 12, in step S411, eNB200 transmits broadcast information (SIB) indicating the amount of data permitted to be transmitted by early data transmission (allowable data amount) to UE100. UE100 determines whether to perform uplink early data transmission based on the allowable data amount notified by eNB200 and the amount of data (uplink data) that UE100 transmits to eNB200. Here, UE100 determines that although the amount of uplink data is greater than the allowable data amount, it is possible to complete the transmission of uplink data by transmitting Msg3 multiple times, and determines to perform uplink early data transmission.

[0110] When the random access procedure is started, in step S412, UE 100 transmits Msg1 (random access preamble) to eNB 200. UE 100 may notify eNB 200 of its intention to transmit more data than the allowable data amount by using the random access preamble. For example, similar to operation pattern 1, the PRACH resource is divided, and a resource for indicating an intention to transmit more data than the allowable data amount is defined in the PRACH resource. UE 100 selects a resource for indicating an intention to transmit more data than the allowable data amount, and transmits a random access preamble using the selected resource. eNB 200 recognizes the resource used for preamble transmission, and understands that UE 100 has an intention to transmit more data than the allowable data amount.

[0111] In step S413, the eNB200 transmits Msg2 (random access response) to the UE100. The eNB200 may transmit information for transmitting Msg3 multiple times to the UE100 by Msg2. Such information may be semi-persistent scheduling (SPS) setting information and / or an activation instruction. For example, the eNB200 transmits setting information including an SPS period indicating an uplink transmission period to the UE100. The eNB200 also transmits an uplink grant indicating uplink resources (time-frequency resources) allocated to the UE100 by Msg2. The SPS setting information may be notified to the UE100 from the eNB200 in step S411. Alternatively, the SPS setting information may be defined in a specification and set in advance in the UE100.

[0112] In step S414, UE 100 transmits Msg3 with data to eNB 200 using the time-frequency resource indicated in the uplink grant. Here, UE 100 may transmit uplink data to eNB 200 up to the allowable data amount notified by eNB 200. UE 100 includes the uplink data in an RRC message (e.g., RRC Connection Request). Alternatively, UE 100 multiplexes the uplink data (DTCH) and the RRC message (CCCH) in the MAC layer and transmits them without including the uplink data in the RRC message.

[0113] In step S415, the UE 100 transmits the second Msg3 when a time period equivalent to an SPS cycle has elapsed since the timing of step S414. The UE 100 transmits the Msg3 including data to the eNB 200 using the time-frequency resource indicated by the uplink grant. The Msg3 transmitted here may include uplink data without including an RRC message.

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

[0115] In step S416, the eNB200 transmits Msg4 to the UE100. The eNB200 may use Msg4 to terminate the SPS transmission. For example, the eNB200 may transmit a 1-bit indicator indicating the stop of the SPS transmission to the UE100 by Msg4. The UE100 may stop the SPS transmission (and discard the SPS setting) in response to receiving the Msg4. Then, the UE100 may terminate the random access procedure without transitioning to the RRC connected mode.

[0116] The eNB 200 may explicitly notify the UE 100 of the termination of the random access procedure without transitioning to the RRC connected mode by Msg4. In this case, the transmission of Msg4 may include the transmission of an RRC Connection Release message or an RRC Connection Reject message.

[0117] Alternatively, the eNB 200 may explicitly notify the UE 100 of the transition to the RRC connected mode by Msg 4. In this case, the transmission of the Msg 4 may include the transmission of an RRC Connection Setup message or an RRC Connection Resume message.

[0118] The sequence of FIG. 12 has described an example in which an intention to transmit more data than the allowable data amount is notified to eNB 200 by a random access preamble, and eNB 200 instructs UE 100 to transmit SPS.

[0119] However, in response to receiving the random access preamble, the eNB200 may transmit an uplink grant enabling transmission of a larger amount of data than the allowable data amount to the UE100 by using Msg2. The eNB200 may transmit the uplink grant to the UE100 when there is a margin in the uplink resource at the time of receiving the random access preamble. When the UE100 receives from the eNB200 an uplink grant enabling transmission of a larger amount of data than the allowable data amount, the transmission of the uplink data may be completed by transmitting Msg3 once.

[0120] Alternatively, when there is no spare uplink resource when receiving the random access preamble, the eNB 200 may not transmit a random access response (Msg2) in response to the random access preamble, or may notify the UE 100 of Reject in Msg4.

[0121] (Summary of the first embodiment) The communication control method according to the first embodiment includes step A in which a first wireless communication device transmits information regarding whether or not to perform early data transmission, which transmits data using a predetermined message during a random access procedure, to a second wireless communication device, and step B in which, after the second wireless communication device receives the information, the second wireless communication device determines whether or not to perform early data transmission based on the received information. The first wireless communication device is one of the UE 100 and the eNB 200, and the second wireless communication device is the other of the UE 100 and the eNB 200. Step A is performed before the transmission timing of the predetermined message. According to such a communication control method, the second wireless communication device can determine in advance whether or not to perform early data transmission before the transmission timing of the predetermined message (i.e., a timing available for early data transmission) based on the information received from the first wireless communication device. For example, the first wireless communication device and the second wireless communication device can determine in advance whether or not to perform early data transmission. This allows the UE 100 and the eNB 200 to match each other. Therefore, early data transmission can be realized.

[0122] (Change example 1) 13 is a diagram showing a first modification of the first embodiment. In the first modification of the first embodiment, the UE 100 notifies the eNB 200 of the amount of data (uplink data) to be transmitted by early data transmission by a random access preamble. The following mainly describes the differences from the operation in the first embodiment described above.

[0123] 13, in step S501, the eNB 200 broadcasts, by SIB, at least one of information indicating a correspondence relationship between data amounts and PRACH resources (e.g., preamble sequences) and information indicating a minimum guaranteed resource amount for early data transmission. Instead of the SIB, a paging message may be used.

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

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

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

[0127] In step S504, the eNB200 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 transmitting Msg3. Information on the uplink radio resources to be allocated to the UE 100 by the eNB200 is notified to the UE 100 by Msg2.

[0128] In the above description, an example has been described in which the eNB 200 notifies the UE 100 of the minimum guaranteed resource amount. However, instead of such a notification, the eNB 200 may set to the UE 100 whether or not the UE 100 should notify the amount of uplink data by a random access preamble. The setting may be performed by the SIB.

[0129] Alternatively, the notification of the intention to perform uplink early data transmission may have a meaning of implicit notification of the amount of uplink data. eNB200 may interpret the notification of the intention to perform uplink early data transmission as meaning that the UL grant size is left to the discretion of the eNB, or that the amount of data is equal to the broadcasted UL grant size (which may be the maximum allowable UL grant size), or that the amount of data related to the early data transmission requires the broadcasted UL grant size.

[0130] In the operation pattern 1 of the first embodiment, an example has been described in which the UE 100 notifies the eNB 200 of its intention to perform early data transmission using the PRACH resource. 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 the PRACH resource. When these operations are used in combination, it is necessary to increase the number of divisions of the PRACH resource. In addition, since one resource pool reserved for the PRACH is finite, increasing the number of divisions of the PRACH resource reduces the size of each divided resource group. As a result, even if the UE 100 randomly selects resources in each resource group, the probability that multiple UEs select the same resource, that is, the probability that resource collision occurs, increases.

[0131] Therefore, the UE 100 may transmit the random access preamble multiple times before the reception timing of the random access response. In each of the multiple random access preamble transmissions, the UE 100 selects a resource to be applied to the transmission of the random access preamble based on information to be notified to the eNB 200. This allows multiple PRACH resource pools to be secured in the time direction, and the amount of available PRACH resources to be increased.

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

[0133] In the first preamble transmission, UE 100 selects resources from PRACH resource pool #1. PRACH resource pool #1 is divided into three resource groups, and the three resource groups correspond to CE levels #1 to #3. For example, UE 100 intending to perform uplink early data transmission identifies a resource group corresponding to its own CE level, randomly selects resources from the identified resource group, and transmits a random access preamble using the selected resources. eNB 200 identifies a resource group corresponding to the random access preamble received from UE 100, and grasps the CE level of UE 100.

[0134] In the second preamble transmission, the UE 100 selects resources from the PRACH resource pool #2. The 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 the data amounts #1 to #4 is an index indicating a range of the data amount. For example, The UE 100 intending to perform uplink early data transmission identifies a resource group corresponding to its own uplink data volume, randomly selects a resource from the identified resource group, and transmits a random access preamble using the selected resource. The eNB 200 identifies a resource group corresponding to the random access preamble received from the UE 100, and grasps the uplink data volume of the UE 100.

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

[0136] When the eNB200 receives the random access preamble transmitted by the second preamble transmission from the UE100, the eNB200 may transmit to the UE100 a random access response corresponding to the random access preamble transmitted by the first preamble transmission. That is, the eNB200 does not transmit a random access response corresponding to the random access preamble transmitted by the second preamble transmission. This makes it possible to ensure backward compatibility. Alternatively, when the eNB200 receives the random access preamble transmitted by the second preamble transmission from the UE100, the eNB200 may transmit to the UE100 a random access response corresponding to the random access preamble transmitted by the second preamble transmission. That is, the eNB200 does not transmit a random access response corresponding to the random access preamble transmitted by the first preamble transmission.

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

[0138] In the example of FIG. 14, an example in which the CE level and the amount of uplink data are notified to the eNB200 by transmitting a preamble has been described, but information other than the CE level and the amount of uplink data (for example, a UE category, a timer value in Modification Example 14 described later) may be notified to the eNB200 by transmitting a preamble. The number of consecutive preamble transmissions is not limited to two, and may be three or more. For example, the UE100 may notify the eNB200 of the CE level by transmitting a first random access preamble, notify the eNB200 of an intention to perform early data transmission by transmitting a second random access preamble, and notify the eNB200 of the amount of uplink data (i.e., the amount of uplink grant desired by the UE100) by transmitting a third random access preamble. Alternatively, the PRACH resource pool for the first random access preamble transmission may be notified to the eNB200 by transmitting a second random access preamble. 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 may be separated, and the PRACH resource pool #2 may be divided into two resource groups. Then, one resource group of the PRACH resource pool #2 may be reserved for notification of an intention to perform early data transmission, and the other resource group of the PRACH resource pool #2 may be reserved for notification of an uplink data amount. In this case, the eNB 200 may consider the UE 100 that has notified the eNB 200 of the uplink data amount by using a resource in a resource group for notifying the uplink data amount as a UE that has an intention to perform early data transmission. Furthermore, the notification of the intention to perform early data transmission may be considered as leaving the UL grant size to the eNB, or as being equal to the broadcasted UL grant size (which may be the maximum allowable UL grant size), or as being necessary for the data amount related to the early data transmission.

[0139] In the example of FIG. 14, an example in which a plurality of PRACH resource pools are provided in the time direction has been described, but a plurality of PRACH resource pools may be provided in the frequency direction.

[0140] Also, an example has been described in which the first preamble transmission and the second preamble transmission are linked by applying the same preamble sequence (signal sequence) to the first preamble transmission and the second preamble transmission. However, the linking is not limited to the case of linking by the preamble sequence, and the linking may be performed by the time-frequency resource. For example, as shown in FIG. 14, it is assumed that a PRACH resource pool #1 for the first random access preamble transmission and a PRACH resource pool #2 for the second random access preamble transmission each include a plurality of resource groups, and each resource group is defined in a rectangular shape. In this case, a specific point among the four vertices of the rectangle is determined as a reference point. In the resource group for the first random access preamble transmission, the UE 100 selects a resource at a predetermined time-frequency position based on the reference point. Then, in the resource group for the second 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 this manner, by aligning the relative positions of the time-frequency resources in each of the first and second random access preamble transmissions, eNB200 is able to link the first preamble transmission with the second preamble transmission.

[0141] Furthermore, in the example of FIG. 14, an example has been described in which the PRACH resource pool is configured with time-frequency resources, but the PRACH resource pool may be configured with preamble sequence (signal sequence) resources.

[0142] Next, a case where the eNB200 fails to receive a preamble at least once among a plurality of random access preamble transmissions will be described. Here, it is assumed that the UE100 notifies the eNB200 of its CE level by transmitting a first random access preamble, and notifies the eNB200 of its intention to perform early data transmission (particularly, its intention to perform uplink early data transmission) by transmitting a second random access preamble. As shown in Table 1, there are cases 1 to 3 as cases where at least one of the first random access preamble transmission (First PRACH) and the second random access preamble transmission (Second PRACH) fails to be transmitted.

[0143] [Table 1]

[0144] 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, eNB200 grasps UE100's intention of early data transmission, allocates to UE100 an amount of uplink resources that is greater than a normal uplink grant (i.e., an uplink grant that does not take into account the amount of data transmitted by early data transmission), and notifies UE100 of the amount by Msg2. UE100 transmits data by early data transmission by Msg3.

[0145] Case 2 is a case where the first random access preamble transmission is successful and the second random access preamble transmission is unsuccessful. In case 2, eNB200 recognizes that it has received a normal random access preamble and notifies UE100 of a normal uplink grant by Msg2. UE100 determines that an uplink resource usable for data transmission has not been allocated and transmits Msg3 containing no data to eNB200.

[0146] Case 3 is a case where the first random access preamble transmission fails and the second random access preamble transmission succeeds. In case 3, the eNB 200 does not receive the first random access preamble, and therefore does not transmit the corresponding Msg2 even if the eNB 200 receives the second random access preamble. Since the UE 100 does not receive the Msg2 from the eNB 200, the UE 100 starts the random access procedure again from the beginning.

[0147] In case 3, the eNB200 may identify the UE100 that transmitted the second random access preamble based on the second random access preamble, and transmit Msg2 to the identified UE100. For example, the eNB200 may identify the UE100 based on the preamble sequence and / or hopping pattern applied to the second random access preamble. However, since the eNB200 has not received the first random access preamble, the eNB200 cannot grasp the CE level of the UE100 based on the first random access preamble. In this case, the eNB200 considers that the UE100 is in the normal coverage (i.e., not in the extended coverage), and does not perform repeated transmission when transmitting Msg2. Alternatively, the eNB200 may estimate the CE level based on the second random access preamble. Specifically, when the repeat transmission is applied at the time of the second preamble transmission, the eNB 200 can count the number of times the preamble transmission is successfully received and estimate the CE level from the count value. The eNB 200 performs the repeat transmission at the time of transmitting Msg2 based on the estimated CE level.

[0148] In addition, regardless of whether or not a random access preamble is transmitted multiple times, a UE 100 that has notified eNB 200 of its intention to perform uplink early data transmission by transmitting a preamble may be restricted to transmit a normal Msg3 (Msg3 not including data) to eNB 200 if uplink resources that can be used for data transmission are not allocated.

[0149] Alternatively, the UE 100, which has notified the eNB 200 of its intention to perform uplink early data transmission by transmitting a preamble, may redo the random access procedure if an uplink resource usable for data transmission is not allocated. When redoing the random access procedure, the UE 100 transmits a preamble again and notifies the eNB 200 of its intention to perform uplink early data transmission again by transmitting a preamble. The UE 100 may redo such random access procedure only when permitted by the eNB 200. In other words, the UE 100 is prohibited from redoing the random access procedure when not permitted by the eNB 200. Information indicating such permission may be broadcast by the eNB 200 via a SIB, or may be set in the UE 100 from the MME.

[0150] (Change example 2) 15 is a diagram showing a second modification of the first embodiment. Differences in operation from the first embodiment described above will be mainly described.

[0151] As shown in FIG. 15, in step S601, UE 100 transmits data together with Msg1 (random access preamble) to eNB 200 by early data transmission. For example, UE 100 transmits data using a new data channel following the random access preamble. However, the amount of data transmitted together with the random access preamble may be small. UE 100 holds the data transmitted in step S601.

[0152] 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 by Msg2 (random access response) to the UE 100. The eNB 200 may return the entire received data to the UE 100.

[0153] In step S603, UE 100 compares the data transmitted in step S601 with the data returned from eNB 200. UE 100 determines that the transmission is successful (ACK) if the comparison result shows a match, and determines that the transmission is unsuccessful (NACK) if the comparison result shows a mismatch. If it determines that the transmission is unsuccessful (NACK), UE 100 retransmits the data that was unsuccessfully transmitted at the next uplink transmission (PUSCH transmission). UE 100 may also notify eNB 200 of the determination result (ACK or NACK) by Msg3. UE 100 may notify eNB 200 of the NACK only when the determination result is NACK.

[0154] (Change example 3) The UE 100 according to the third modification of the first embodiment transmits data to the eNB 200 by early data transmission in the RRC idle mode. After that, the UE 100 in the RRC idle mode receives an ACK or NACK corresponding to the data transmitted by the early data transmission from the eNB 200 by monitoring a PHICH (Physical channel Hybrid ARQ Indicator Channel).

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

[0156] (Change example 4) In the fourth modification of the first embodiment, the UE 100 or the eNB 200 judges whether or not data transmission is completed by the early data transmission. If it is judged that data transmission is completed by the early data transmission, the UE 100 ends the random access procedure without transitioning from the RRC idle mode to the RRC connected mode. This enables efficient data transmission.

[0157] For example, in the case of uplink early data transmission, when the UE 100 receives Msg4 (e.g., an RRC Connection Setup message) from the eNB 200, the UE 100 can terminate the random access procedure by transmitting a message indicating failure or refusal (failure message) to the eNB 200. The message indicating failure or refusal may include information indicating the reason for the failure or refusal (e.g., early data transmission completed).

[0158] In the case of downlink early data transmission, the eNB 200 can notify the UE 100 by Msg4 (e.g., an RRC Connection Setup message) that the random access procedure is to be terminated (i.e., there is no need to complete the procedure), and can terminate the random access procedure. Alternatively, the eNB 200 may transmit an RRC Connection Release message as Msg4.

[0159] In the case of downlink early data transmission, eNB200 may notify UE100 of the fact that it is downlink transmission of a small packet (a small amount of data) by transmitting a special paging message to UE100 before the random access procedure. The special paging message may be generated by MME300 and transmitted from MME300 to UE100 via eNB200. The special paging message may include a combination of an identifier of UE100 and information indicating small packet transmission. When UE100 receives the special paging message, UE100 ends the random access procedure without transitioning to the RRC connected mode after data transmission is completed by early data transmission.

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

[0161] Prior to this operation, MME300 may notify eNB200 of "non-contention based random access procedure application" together with the UE identifier (UE ID) in an S1 paging message transmitted to eNB200 via the S1 interface. MME300 may notify eNB200 of "early data transmission application" together with the UE ID in an S1 paging message. Alternatively, eNB200 may notify MME300 of (multiple) preamble indexes in advance, and MME300 may notify eNB200 of an index selected (as necessary) from these indexes in an S1 message.

[0162] The UE 100 (for example, a UE in an RRC idle mode) receives a paging message from the eNB 200 and transmits a random access preamble to which the preamble sequence indicated by the preamble index is applied to the eNB 200. The eNB 200 can identify the UE 100 that is the transmission source of the random access preamble based on the preamble sequence applied to the random access preamble.

[0163] This allows a non-contention-based random access procedure to be performed in a situation where a contention-based random access procedure would normally be performed (e.g., at the time of initial connection), thereby making it possible to eliminate the need for contention resolution used in the contention-based random access procedure.

[0164] (Change Example 6) In the sixth modification of the first embodiment, the UE 100 or the eNB 200 transmits data by early data transmission. The data transmitted by early data transmission does not include an ACK or NACK transmission corresponding to the data, and applies a repeat transmission in which the data is repeatedly transmitted a predetermined number of times. This can improve the reliability of data transmission even when an ACK or NACK is not used.

[0165] UE100 or eNB200 applies repeated transmission to data transmitted by early data transmission even when UE100 is not in enhanced coverage (i.e., when UE100 is in normal coverage). In general, repeated transmission is not applied when UE100 is in normal coverage. On the other hand, in the sixth modification of the first embodiment, regardless of whether UE100 is in enhanced coverage or not, the transmission of ACK or NACK is not applied to data transmitted by early data transmission, and repeated transmission is applied to repeatedly transmit the data a predetermined number of times.

[0166] For example, in the case of uplink early data transmission, even if the eNB 200 receives uplink data by early data transmission, the eNB 200 does not transmit an ACK / NACK to the UE 100. However, the UE 100 repeatedly transmits the same signal in a lower layer a number of times that is predetermined in the specifications or a number of times that is set by the eNB 200.

[0167] In the case of downlink early data transmission, even if the UE 100 receives downlink data by early data transmission, the UE 100 does not transmit an ACK / NACK to the eNB 200. However, the eNB 200 repeatedly transmits the same signal in a lower layer a number of times that is determined in advance by the specifications or a number of times that is notified to the UE 100.

[0168] (Change Example 7) In the seventh to tenth modifications of the first embodiment, a scenario is assumed in which the predetermined message used for data transmission in the early data transmission is Msg3. That is, the early data transmission in the seventh to tenth modifications of the first embodiment is early data transmission in the uplink. As described above, Msg3 is a message transmitted from the UE 100 to the eNB 200, and is a message used to request the UE 100 to transition from the idle mode to the connected mode. In the early data transmission, the data (packet) transmitted by Msg3 may be included in Msg3. For example, the UE 100 transmits an RRC connection request message including a data PDU. Alternatively, the data (packet) transmitted by Msg3 may be transmitted (continuously) in combination with Msg3 as a message different from Msg3. For example, the UE 100 may transmit one MAC PDU including a message including the data (packet) and Msg3. The UE 100 may include the message including the data (packet) and the Msg3 in separate MAC PDUs, and transmit the separate MAC PDUs simultaneously or consecutively.

[0169] In the following description of Modifications 7 to 11, an example will be described in which Msg3 is an RRC connection request message, but Msg3 may be an RRC connection restoration request message.

[0170] In modification example 7, the above-mentioned step A (i.e., the step of transmitting information regarding whether or not to perform early data transmission) includes a step of instructing the execution of early data transmission in the uplink by a MAC RAR (MAC Random Access Response) constituting a random access response (Msg2) transmitted from eNB200 to UE100.

[0171] A typical random access response is configured as a MAC RAR, and includes a timing advance (Timing Advance Command) determined by eNB200 based on the random access preamble, allocation information (UL grant) regarding uplink resources allocated by eNB200 to UE100 for transmitting an RRC connection request message, and a temporary C-RNTI (Temporary C-RNTI) allocated by eNB200 to UE100.

[0172] In the seventh modification, the eNB200 that has received the random access preamble from the UE100 determines whether or not to cause the UE100 to perform early data transmission in uplink (i.e., data transmission using an RRC connection request message) by the method according to the first embodiment or its modification described above. When determining to cause the UE100 to perform early data transmission, the eNB200 instructs the UE100 to perform early data transmission in uplink by using the MAC RAR constituting the random access response. For example, when a new field is provided in the MAC RAR, the eNB200 includes in the new field a flag (permission bit) indicating that data transmission using an RRC connection request message is to be performed. When data transmission using an RRC connection request message is not to be performed, the eNB200 does not include in the new field a flag indicating that data transmission using an RRC connection request message is to be performed (or includes the flag as a zero value).

[0173] Alternatively, the eNB 200 may notify the UE 100 of whether or not to cause the UE 100 to perform early data transmission by a MAC CE different from the MAC RAR constituting the random access response. The different MAC CE may be referred to as, for example, an "Early Data Transmission RAR." In this case, the eNB 200 may include an identifier indicating early data transmission in the uplink and / or downlink in the Early Data Transmission RAR.

[0174] As described in the first modification, the UE 100 may notify the eNB 200 of the amount of data (uplink data) to be transmitted by early data transmission by using a random access preamble. The eNB 200 determines the amount of uplink radio resources to be assigned to the UE 100 based on the amount of uplink data notified from the UE 100, and includes information indicating the determined uplink radio resources in a UL grant in a random access response (MAC RAR).

[0175] (Change Example 8) In the above-described modification example 4, when it is determined that data transmission is completed by early data transmission, the UE 100 ends the random access procedure without transitioning from the RRC idle mode to the RRC connected mode. Modification example 8 relates to an example of operation in the case of early data transmission in downlink.

[0176] In the eighth modification, when data transmission is completed by the RRC connection request message, the UE 100 transmits an RRC connection request message including a flag indicating that it is not necessary to transition to the connected mode (i.e., it is not necessary to establish an RRC connection) from the UE 100 to the eNB 200. The flag is configured of 1 bit.

[0177] For example, when the amount of data to be transmitted to eNB200 is equal to or less than the maximum amount of data that can be carried by the RRC connection request message, UE100 determines that data transmission is completed by the RRC connection request message. In this case, UE100 includes a flag indicating that it is not necessary to transition to the connected mode in the RRC connection request message when transmitting data by the RRC connection request message. As a result, the RRC connection request message includes data to be transmitted by early data transmission and a flag indicating that it is not necessary to transition to the connected mode. On the other hand, when the amount of data to be transmitted to eNB200 exceeds the maximum amount of data that can be carried by the RRC connection request message, UE100 determines that data transmission is not completed by the RRC connection request message. In this case, UE100 does not include a flag indicating that it is not necessary to transition to the connected mode in the RRC connection request message when transmitting data by the RRC connection request message (or includes the flag as a zero value).

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

[0179] When the eNB200 has successfully received the data included in the RRC connection request message, the eNB200 does not transmit Msg4 to the UE100 or transmits an RRC connection release message to the UE100, since the flag included in the RRC connection request message indicates that it is not necessary to establish an RRC connection. On the other hand, when a reception error occurs in the eNB200 for the data included in the RRC connection request message, the eNB200 continues the random access procedure to establish an RRC connection, for example, by transmitting Msg4 to the UE100. The UE100 determines whether the transmission of the data by the RRC connection request message has been successful, based on the status of the response from the eNB200 to the RRC connection request message.

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

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

[0182] 1) Retransmitting the RRC connection request message including the data In this case, the UE 100 includes a flag indicating that it is not necessary to transition to the connected mode in the RRC connection request message.

[0183] 2) Retransmit the RRC connection request message without the data. In this case, the UE 100 does not include a flag indicating that it is not necessary to transition to the connected mode in the RRC connection request message. The UE 100 transmits (retransmits) the data after transitioning to the connected mode.

[0184] 3) The data is transmitted by Msg5, which is a message transmitted from UE 100 to eNB 200 and is used to notify completion of transition to the connected mode. In this case, UE 100 may transition to the connected mode. Alternatively, UE 100 may transmit data to eNB 200 instead of transmitting Msg5. eNB 200 may notify UE 100 of whether or not data reception from UE 100 has been successful by Msg6.

[0185] 4) Transition to connected mode.

[0186] In the eighth modification, the UE 100 may transmit an RRC connection request message with information indicating that it is not necessary to transition to the connected mode, instead of the RRC connection request message including a flag indicating that it is not necessary to transition to the connected mode (i.e., it is not necessary to establish an RRC connection). The UE 100 may transmit a MAC CE including information indicating that it is not necessary to transition to the connected mode. For example, the MAC CE is a buffer status report (BSR). The BSR is a MAC CE indicating the amount of data that the UE 100 has available for uplink transmission (i.e., the amount of data waiting to be transmitted on the uplink).

[0187] FIG. 16 is a diagram showing an example of a MAC PDU (MAC Protocol Data Unit) generated by a MAC layer. As shown in FIG. 16, the MAC PDU includes a MAC SDU (MAC Service Data Unit) 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 a MAC SDU. Uplink data transmitted by early data transmission is provided to the MAC layer as a MAC SDU through the PDCP layer and the RLC layer. The uplink data may be provided to the MAC layer as a MAC SDU without passing through the PDCP layer and the RLC layer.

[0188] The MAC PDU includes a MAC header and a MAC CE (MAC Control Element) generated by a MAC layer in addition to the MAC SDU. The MAC PDU may further include padding for filling an empty area of ​​the MAC PDU. Although an example in which the MAC PDU includes two MAC CEs is illustrated in FIG. 16, the number of MAC CEs may be three or more or one. The MAC CE constituting the BSR includes a buffer size field that stores 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 it is not necessary to transition to the connected mode. Such a BSR may be referred to as RAI (Release Assistance Information).

[0189] In the early data transmission, when data transmission is completed by the RRC connection request message (Msg3), the UE 100 may transmit one or more MAC SDUs including the uplink data and the RRC connection request message, and a MAC CE including information indicating that it is not necessary to transition to the connected mode (BSR=0) to the eNB 200 together in one MAC PDU. Alternatively, the UE 100 may transmit one or more MAC SDUs including the uplink data and the RRC connection request message, and a MAC CE including information indicating that it is not necessary to transition to the connected mode (BSR=0) to the eNB 200 continuously in separate MAC PDUs. The eNB 200 determines that it is not necessary to transition the UE 100 to the connected mode based on "BSR=0" accompanying the RRC connection request message.

[0190] (Change Example 9) Modifications 9 to 12 of the first embodiment assume a scenario in which the predetermined message used for data transmission in early data transmission is Msg4. That is, the early data transmission in modifications 9 to 11 of the first embodiment is early data transmission in downlink. Note that, as described above, Msg4 is a message transmitted from eNB200 to UE100, and is a message used to transition UE100 from idle mode to connected mode.

[0191] In the following description of Modifications 9 to 12, an example will be described in which Msg4 is an RRC connection establishment message, but Msg4 may be an RRC connection restoration message.

[0192] In the ninth modification, the UE 100 in the idle mode starts a random access procedure. While the UE 100 is in the idle mode, the eNB 200 may not hold the context information of the UE 100 (including information on the capability of the UE 100). In this case, the eNB 200 does not know whether the UE 100 has the capability to handle the early data transmission in the downlink, and it is difficult to determine whether to perform the early data transmission in the downlink.

[0193] Therefore, in the ninth modification, the UE 100 notifies the eNB 200 whether or not it supports early data transmission in downlink by using either a random access preamble (Msg1) or an RRC connection request message. For example, the UE 100 capable of performing early data transmission in downlink transmits information (identifier) ​​indicating that it has the capability of performing early data transmission in downlink to the eNB 200 by using either a random access preamble (Msg1) or an RRC connection request message. In the case where the random access preamble (Msg1) is used, the method of the operation pattern 1 of the first embodiment described above can be used. The eNB 200 determines whether or not the UE 100 supports early data transmission in downlink based on the notification from the UE 100. Here, "UE100 supports early data transmission in the downlink" and "UE100 has the capability to perform early data transmission in the downlink" may mean that UE100 has the capability (function) to "receive" data transmitted from eNB200 by early data transmission in the downlink.

[0194] Note that, only when UE 100 receives a paging message (see operation pattern 3 according to the first embodiment described above) indicating that early data transmission in downlink will be performed from eNB 200, UE 100 may notify eNB 200 of the capability of early data transmission in downlink by using a random access preamble. The paging message may include information explicitly indicating that early data transmission in downlink will be performed. The paging message may include information implicitly indicating that early data transmission in downlink will be performed (for example, information on a PRACH resource used to transmit a random access preamble indicating that early data transmission in downlink is possible).

[0195] Furthermore, only when UE 100 has received Msg2 (see the above-mentioned modification 7) indicating an instruction for early data transmission in downlink from eNB 200, UE 100 may notify eNB 200 of its capability for early data transmission in downlink by an RRC connection request message. The Msg2 may include information explicitly indicating that early data transmission in downlink will be performed. The Msg2 may include information implicitly indicating that early data transmission in downlink will be performed.

[0196] (Change Example 10) In the ninth modification, an example has been described in which the UE 100 notifies the eNB 200 of whether the UE 100 supports early data transmission in downlink. However, a mobility management device (MME 300) provided in a core network (EPC 20) may notify the eNB 200 of whether the UE 100 has the capability of performing early data transmission in downlink. Prior to this operation, the UE 100 may notify the MME 300 of information indicating that the UE 100 has the capability of performing early data transmission in downlink, and the MME 300 may hold a UE context including the information for a certain period (for example, while the UE 100 is in an EMM Registered state).

[0197] The MME 300 may notify the eNB 200 of the capability by a paging message (S1 paging message) or may notify the eNB 200 by an INITIAL CONTEXT SETUP message. When transmitting data to the UE 100 by NAS signaling, the MME 300 may notify the eNB 200 of the capability by NAS signaling or an S1 message.

[0198] (Change Example 11) In the above-described modification example 4, when it is determined that data transmission is completed by early data transmission, the UE 100 ends the random access procedure without transitioning from the RRC idle mode to the RRC connected mode. Modification example 8 relates to an example of operation in the case of early data transmission in downlink.

[0199] In the eleventh modification, the eNB200 determines, based on the amount of data to be transmitted to the UE100 by early data transmission in the downlink, either a first message or a second message as a message (predetermined message) to be used for transmitting the data. The first message is an RRC connection establishment message to be used for transitioning the UE100 from the idle mode to the connected mode. The second message is a message to be used for maintaining the UE100 in the idle mode. Although an example in which an RRC connection release message is used as the second message will be described, the second message may be a new message.

[0200] 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 an RRC connection release message including data to the UE 100 instead of transmitting an RRC connection establishment message. This allows the random access procedure to be stopped midway and the UE 100 to not transition to the connected 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 an RRC connection establishment message including data to the UE 100. This allows the UE 100 to continue the random access procedure.

[0201] Alternatively, instead of using different messages, the eNB200 may notify the UE100 of the end of data transmission by an RRC connection establishment message. For example, when the amount of data to be transmitted to the UE100 is equal to or less than the maximum amount of data that can be carried by the RRC connection establishment message, the eNB200 determines that the data transmission is completed by the RRC connection establishment message. In this case, the eNB200 transmits to the UE100 an RRC connection establishment message including data and information indicating the end of the data transmission (a so-called end marker). This allows the random access procedure to be stopped midway and prevents the UE100 from transitioning to the connected mode. On the other hand, when the amount of data to be transmitted to the UE100 exceeds the maximum amount of data that can be carried by the RRC connection establishment message, the eNB200 determines that the data transmission is not completed by the RRC connection establishment message. In this case, the eNB200 transmits to the UE100 an RRC connection establishment message including data and not including an end marker. This allows the UE100 to continue the random access procedure.

[0202] (Change Example 12) In the above-described eighth modification, an example has been described in which, when the UE 100 determines that the transmission of data by the RRC connection request message (Msg3) has failed, the UE 100 retransmits the RRC connection request message including the data.

[0203] Such a retransmission operation is also applicable to early data transmission in downlink. In the ninth modification, the eNB200 transmits an RRC connection establishment message (Msg4) with data to the UE100 by early data transmission, and then judges whether or not the transmission of the data by the RRC connection establishment message has been successful. The eNB200 may make such a judgment based on, for example, HARQ ACK or HARQ NACK in the MAC layer. Then, when the eNB200 judges that the transmission of the data by Msg4 has failed, it retransmits Msg4 with the data. When the early data transmission in downlink is set and the UE100 fails to receive Msg4, it judges that the data is also retransmitted in the retransmission of Msg4. Then, the UE100 (for example, a layer (such as an RRC layer) higher than the MAC layer of the UE100) waits to receive both the RRC message (RRC Connection Reconfiguration) constituting the Msg4 and the data.

[0204] (Change Example 13) Modification 13 is an embodiment related to both early data transmission in the uplink and early data transmission in the downlink.

[0205] In the thirteenth modification, the UE 100 and / or the eNB 200 determines not to transmit early data in either the uplink or the downlink for a random access procedure in which early data transmission is performed in either the uplink or the downlink, so that only one of the early data transmission in the uplink and the early data transmission in the downlink can be performed in one random access procedure performed by one UE 100.

[0206] If both the early data transmission in the uplink and the early data transmission in the downlink are made possible in one random access procedure, there is a concern that the control regarding the early data transmission becomes complicated. In addition, the following problem may occur. For example, after transmitting data by an RRC connection request message (Msg3), the UE 100 must wait for response data (e.g., TCP ACK) corresponding to the data to be transmitted by an RRC connection establishment message (Msg4). Since such response data is affected by delays in the network, it is not preferable for the UE 100 to continue waiting for the response data to be transmitted by the RRC connection establishment message (Msg4). Therefore, by making it possible to perform only one of the early data transmission in the uplink and the early data transmission in the downlink in one random access procedure, such a problem can be avoided.

[0207] In the thirteenth modification, when data transmission is performed by the RRC connection request message (Msg3), the UE 100 determines not to perform data reception by the RRC connection establishment message (Msg4). In other words, the UE 100 determines not to perform downlink early data transmission using Msg4 for a random access procedure in which uplink early data transmission using Msg3 is performed. For example, assume that the UE 100 is notified by a paging message that downlink early data transmission using Msg4 will be performed (see the operation pattern 3 of the first embodiment), or is notified by a random access response that downlink early data transmission using Msg4 will be performed (see the seventh modification). Even in such a case, the UE 100 may determine that it is not necessary to perform data reception by the RRC connection establishment message (Msg4) when data transmission is performed by the RRC connection request message (Msg3). Furthermore, when data reception is performed in response to the RRC connection request message (Msg3), the eNB 200 may determine not to transmit data in response to the RRC connection establishment message (Msg4).

[0208] In the thirteenth modification, when the UE 100 receives data by the RRC connection establishment message (Msg4), the UE 100 determines not to transmit data by the RRC connection request message (Msg3). In other words, the UE 100 determines not to transmit uplink early data using Msg3 for a random access procedure in which downlink early data transmission using Msg4 is performed. For example, assume that the UE 100 is notified by a paging message that downlink early data transmission using Msg4 is to be performed (see the operation pattern 3 of the first embodiment), or is notified by a random access response (Msg2) that downlink early data transmission using Msg4 is to be performed (see the seventh modification). In such a case, even if the UE 100 has uplink transmission data, the UE 100 may determine to transmit downlink early data using Msg4 and not to transmit uplink data using Msg3.

[0209] In modification example 13, a scenario is assumed in which UE100 capable of performing early data transmission transmits a notification (identifier) ​​indicating that it has the capability of performing early data transmission to eNB200 via either a random access preamble (Msg1) or an RRC connection request message (Msg3) (see modification example 9).

[0210] In such a scenario, when information indicating that early data transmission in downlink is to be performed is transmitted from eNB200 to UE100 by a paging message or Msg2, when eNB200 receives a notification indicating that it has the capability of performing early data transmission from UE100, it interprets the notification as indicating the capability of performing early data transmission in downlink. When UE100 has the capability and / or intention of performing early data transmission in downlink and receives information indicating that it will perform early data transmission in downlink from eNB200, UE100 notifies eNB200 of its capability and / or intention of performing early data transmission in downlink by transmitting a notification to eNB200 indicating that it has the capability of performing early data transmission.

[0211] On the other hand, when information indicating that early data transmission in downlink is to be performed is not transmitted from eNB200 to UE100 by the paging message or Msg2, when eNB200 receives a notification indicating that it has the capability of performing early data transmission from UE100, it interprets the notification as indicating the capability and / or intention of performing early data transmission in uplink. When UE100 has the capability and / or intention of performing early data transmission in uplink, when UE100 has not received information indicating that it will perform early data transmission in downlink from eNB200, UE100 notifies eNB200 of the capability and / or intention of performing early data transmission in uplink by transmitting a notification to eNB200 indicating that it has the capability of performing early data transmission.

[0212] In this way, the meaning of the notification is changed depending on whether or not information indicating that early data transmission in downlink is to be performed is transmitted, allowing one type of notification (for example, one information element) to play two different roles.

[0213] (Change Example 14) Modification 14 is different from Modification 13 in that a scenario is assumed in which both uplink early data transmission and downlink early data transmission can be performed in one random access procedure.

[0214] In a general random access procedure, when UE 100 transmits Msg3 without data, the UE 100 starts a first timer that determines a waiting time for receiving Msg4 transmitted from eNB 200 at the time of transmitting Msg3. Such a first timer may be called a Contention Resolution Timer. The first timer is set in UE 100 by SIB from eNB 200. When the first timer expires without receiving Msg4, UE 100 stops processing for receiving Msg4 (e.g., monitoring PDCCH) and resumes the random access procedure from transmitting Msg1.

[0215] However, as described above, when response data (e.g., TCP ACK) corresponding to data is transmitted by an RRC connection establishment message (Msg4) after data is transmitted by an RRC connection request message (Msg3), the first timer may not have enough waiting time. Therefore, in the fourteenth modification, a second timer for early data transmission is introduced in addition to the first timer. The UE 100 in which both the first timer and the second timer are set 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.

[0216] In the fourteenth modification, when the UE 100 transmits Msg3 with data by early data transmission, the UE 100 starts a second timer that determines a waiting time for receiving Msg4 transmitted from the eNB 200 with data. 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 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 in the UE 100 by the SIB from the eNB 200. Alternatively, since context information for UE 100 in an RRC suspended state is held in the network (and UE 100), the second timer may be set in UE 100 by a dedicated RRC message while UE 100 is in connected mode, the setting of the second timer may be held in the network while UE 100 is in connected mode, and the held setting may be used during the random access procedure. When the second timer expires without receiving Msg4 with data, UE 100 stops processing for receiving Msg4 (e.g., monitoring PDCCH) and resumes the random access procedure from the transmission of Msg1.

[0217] Alternatively, assuming that early data transmission is applied to eMTC UE and NB-IoT UE, power saving of the UE 100 may be prioritized. Therefore, the waiting time set in the second timer may be shorter than the waiting time set in the first timer. This allows the process for receiving Msg4 to be terminated early.

[0218] 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 "Contention Resolution timer".

[0219] The timer value of the second timer (i.e., the waiting time of Msg4) may be determined by UE 100, not necessarily by eNB 200 and set in UE 100. A round trip time, which is a time from when UE 100 transmits uplink data until an ACK (e.g., TCP ACK) of a higher layer returns to UE 100, can be estimated in a higher layer of UE 100. Thus, by UE 100 determining the timer value of the second timer, a more appropriate timer value can be determined. UE 100 may determine a timer value to be set in the second timer, and notify eNB 200 of the determined timer value. The timer value is notified by Msg3. The timer value may be notified by Msg1 (preamble transmission).

[0220] Fig. 17 is a diagram showing an example of the operation of Modification 14. In Fig. 17, the server 50 is provided in a network (e.g., the Internet) higher than the core network (EPC). Also, in Fig. 17, a network entity (e.g., S-GW) between the eNB 200 and the server 50 is omitted from illustration.

[0221] 17, 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.

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

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

[0224] The eNB 200 may broadcast (for example, transmit by SIB) timer value candidates (a list 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 in the Msg3.

[0225] The eNB200 may broadcast (for example, transmit by SIB) a default timer value of the second timer. In this case, the UE100 basically uses the default timer value. The UE100 may autonomously determine the timer value only when it wants to overwrite the default timer value, and may notify the eNB200 of the determined timer value by Msg3. The value of "T300" may be the default timer value, or the value of "Contention Resolution timer" may be the default timer value. In addition, when the UE100 determines the timer value of the second timer, the UE100 may be restricted to determine a timer value equal to or greater than the default timer value.

[0226] eNB200 may broadcast (for example, transmit by SIB) the maximum timer value that UE100 can set. UE100 determines a timer value equal to or less than the maximum value broadcast from eNB200, and notifies eNB200 of the determined timer value. However, when UE100 determines the maximum value broadcast from eNB200 as the timer value, UE100 may not notify eNB200 of the determined timer value. When a timer value is not notified from UE100, eNB200 may assume that UE100 has determined the maximum value. Note that, when a maximum value is not specified by eNB200 by broadcast, UE100 may use a predefined default maximum value to determine a timer value equal to or less than the default maximum value.

[0227] eNB200 may broadcast (for example, transmit by SIB) the minimum value of the timer value that UE100 can set. UE100 determines a timer value equal to or greater than the minimum value broadcast from eNB200, and notifies eNB200 of the determined timer value. However, when UE100 determines the minimum value broadcast from eNB200 as the timer value, it is not necessary to notify eNB200 of the determined timer value. When the timer value is not notified from UE100, eNB200 may assume that UE100 has determined the minimum value. Note that, when the minimum value is not specified by eNB200 by broadcast, UE100 may use a predefined default minimum value to determine a timer value equal to or greater than the default minimum value.

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

[0229] In step S704, the eNB 200 transfers the data received from the UE 100 by Msg3 to the server 50.

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

[0231] In step S706, the eNB 200 transmits the Msg4 including the response data (TCP ACK) to the UE 100 by downlink early data transmission.

[0232] In the sequence of FIG. 17, it is assumed that the Msg3 transmission is successful. However, it is also assumed that the Msg3 transmission fails, a HARQ NACK (retransmission request) is transmitted from the eNB 200 to the UE 100, and the UE 100 retransmits the Msg3 by HARQ. After starting the second timer, the UE 100 may continue to operate the second timer without restarting (restarting) the second timer when retransmitting the Msg3 by HARQ. This can avoid inconsistency between the TCP ACK waiting time set by the upper layer based on the round trip time and the Msg4 waiting time set by the access layer. Alternatively, the UE 100 may restart (restart) the second timer when retransmitting the Msg3 by HARQ after starting the second timer.

[0233] In the operation of the above modification 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 with early data transmission and the second timer for the random access procedure without early data transmission are specified as separate timers.

[0234] Here, "T300" is a timer that specifies the maximum waiting time from when UE 100 transmits Msg3 in the random access procedure (or RRC Connection Establishment Procedure) until it receives Msg4 (specifically, an RRC message) and is managed in the RRC layer. "Contention Resolution timer" is a timer that specifies the maximum waiting time from when UE 100 transmits Msg3 in the random access procedure until it receives Msg4 (specifically, a MAC CE) and is managed in the MAC layer.

[0235] However, instead of introducing such a new timer (second timer), it is possible to implement an operation similar to that of the above-mentioned modification example 14 by specifying two types of timer values ​​as the timer value to be set in the first timer ("T300" or "Contention Resolution timer"). This makes it possible to reduce the impact of a change in the system specifications compared to the case where a new timer is introduced. Also, instead of setting two timers (first timer and second timer), it is only necessary to set one timer (first timer), and therefore the processing load of the UE 100 is also reduced.

[0236] In the following modified example 14, an operation in the case where two types of timer values ​​are defined as timer values ​​to be set in the first timer will be described. Here, "T300" is exemplified as the first timer, but the first timer may be a "Contention Resolution timer."

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

[0238] The eNB200 transmits the first timer value and the second timer value by broadcast. For example, the eNB200 transmits, by the SIB, "T300" (first timer value), which is an existing information element in the SIB, and "T300-EDT", which is a new information element in the SIB. The eNB200 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.

[0239] In response to the determination to perform early data transmission, the UE 100 selects the second timer value from the first timer value and the second timer value and sets the second timer value in the first timer. Then, when transmitting uplink data by early data transmission, the UE 100 starts a timer (first timer) to which the second timer value is set. To transmit uplink data by early data transmission, specifically, the UE 100 transmits uplink user data when transmitting Msg3.

[0240] FIG. 18 is a diagram showing the operation when two types of timer values ​​are defined.

[0241] 18, in step S751, the eNB 200 broadcasts the first timer value and the second timer value. The eNB 200 transmits the first timer value and the second timer value at a predetermined cycle.

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

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

[0244] When it is determined that the normal random access procedure is to be performed without performing the early data transmission (step S753: NO), in step S754, the UE 100 selects a first timer value and sets the first timer value in a timer (first timer). Then, in step S755, the UE 100 starts the normal random access procedure.

[0245] On the other hand, when it is determined that early data transmission is to be performed (step S753: YES), in step S756, UE 100 selects a second timer value and sets the second timer value in the timer (first timer). Then, in step S757, UE 100 starts a random access procedure involving early data transmission.

[0246] When the random access procedure is started, in step S758, the UE 100 and the eNB 200 transmit and receive Msg1 and Msg2. Note that the UE 100 and the eNB 200 may change the contents of Msg1 and Msg2 depending on whether or not early data transmission is involved.

[0247] In step S759, the UE 100 transmits Msg3 to the eNB 200. When performing early data transmission, the UE 100 transmits uplink data to the eNB 200 in conjunction with the transmission of Msg3. The UE 100 starts a timer (first timer) at the time of transmitting Msg3.

[0248] In step S760, UE 100 judges whether or not Msg4 has been normally received from eNB 200. If Msg4 has been normally received from eNB 200 (step S760: YES), in step S761, UE 100 stops the timer (first timer) and ends the random access procedure or ends the random access procedure after transmitting an RRC Connection Complete message. If UE 100 has performed a normal random access procedure, UE 100 transitions to the RRC connected mode. On the other hand, if early data transmission has been performed, UE 100 maintains the RRC idle mode without transitioning to the RRC connected mode. Note that UE 100 successfully receiving Msg4 from eNB 200 may mean that UE 100 has decoded Msg4 addressed to UE 100 received from eNB 200 and has acquired the contents of Msg4.

[0249] On the other hand, if the timer (first timer) expires without successfully receiving Msg4 from eNB200 (step S760: NO, step S762: YES), in step S763, UE100 restarts (restarts) the random access procedure from the beginning or terminates the random access procedure.

[0250] In the flow of Fig. 18, UE 100 determines whether to perform early data transmission (step S753) before starting the random access procedure. However, UE 100 may determine that early data transmission is to be performed (or is being performed) when uplink early data transmission (UL EDT) is performed in Msg3 (user data is transmitted together with Msg3) in the following cases: EDT (Early Data Transmission) Indication is transmitted in Msg1 or transmitted using a PRACH (Physical Random Access Channel) setting for early data transmission (EDT), and early data transmission (EDT) is permitted in Msg2, an EDT Grant including resources related to early data transmission is received in Msg2, DCI for early data transmission (EDT) is received, or a UL Grant including sufficient uplink resources for performing early data transmission (EDT) is received. In this case, the UE 100 does not set a timer value in the timer (first timer) until receiving Msg2, and sets a timer value in the timer (first timer) after receiving Msg2.

[0251] In addition, UE 100 may determine to perform early data transmission in any of the above cases. That is, UE 100 may determine to perform (or to perform) early data transmission when UE 100 transmits Msg1, receives Msg2, or transmits Msg3 in the above cases.

[0252] (Change Example 15) In the above-described modification 14, an example has been described in which the ACK of the higher layer is transmitted from the eNB 200 to the UE 100 by the Msg4. In this case, after transmitting the Msg3, the UE 100 must continue to monitor the PDCCH for each subframe until it receives the Msg4 (or until the second timer expires). In particular, when the ACK of the higher layer is delayed, there is a concern that power consumption will increase if the UE 100 continues to monitor the PDCCH.

[0253] In the fifteenth modification, the eNB200 transmits Msg4 to the UE100 without waiting for the arrival of an ACK of the higher layer, thereby enabling the UE100 to discontinue continuous monitoring of the PDCCH. Furthermore, the eNB200 notifies the UE100 by Msg4 that it plans to transmit data (ACK of the higher layer) to the UE100 after transmitting Msg4. This transmission of Msg4 may include transmission of information indicating that the UE100 is to be maintained in the RRC idle mode. This allows the UE100 to wait for reception of downlink data while maintaining the RRC idle mode. That is, when the UE100 receives Msg4, it waits for downlink data (ACK of the higher layer) without transitioning to the RRC connected mode. During the wait for downlink data, the UE100 may intermittently monitor the PDCCH in discontinuous subframes by DRX (Discontinues Reception).

[0254] Fig. 19 is a diagram showing an example of the operation of Modification 15. In Fig. 19, the server 50 is provided in a network (e.g., the Internet) higher than the core network (EPC). Also, in Fig. 19, a network entity (e.g., S-GW) between the eNB 200 and the server 50 is omitted from illustration.

[0255] As shown in FIG. 19, in step S711, the UE 100 transmits the Msg3 with data to the eNB 200 by uplink early data transmission.

[0256] In step S712, the eNB 200 transfers the data received from the UE 100 by Msg3 to the server 50.

[0257] In step S713, eNB200 transmits Msg4 to UE 100. eNB200 transmits, to UE 100, information to the effect that UE 100 is to be maintained in the RRC idle mode and a prior notice to the effect that downlink data transmission (i.e., downlink early data transmission) is to be performed after transmission of Msg4, by Msg4. eNB200 determines whether or not to perform downlink early data transmission, for example, by any one of the following methods 1) to 3).

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

[0259] 2) The MME notifies the eNB 200 of an intention to transmit downlink early data, and the eNB 200 determines whether to transmit downlink early data based on the notification from the MME.

[0260] 3) In Msg3, UE 100 notifies eNB 200 of the possibility of downlink early data transmission (presence or absence of higher layer ACK), and eNB 200 determines whether to perform downlink early data transmission based on the notification from UE 100.

[0261] The advance notification transmitted from eNB 200 to UE 100 by Msg4 may include information indicating an expected occurrence timing of downlink early data transmission (for example, 10 seconds later). The advance notification may be included in a MAC CE or an RRC message.

[0262] In step S714, the UE 100 that has received the Msg4 may start a timer that specifies a waiting time for receiving downlink data. A timer value (threshold value) of the timer may be set by the eNB 200 to the UE 100 through the SIB, the Msg4, or the Msg2. When the timer expires without receiving the downlink data, the UE 100 may end the waiting for the downlink data.

[0263] In step S715, the UE 100 starts DRX and intermittently monitors the PDCCH. The setting information of the DRX may be notified from the eNB 200 to the UE 100 by the SIB or Msg4. Such a DRX operation may be an operation based on the DRX in the RRC connected mode or an operation based on the DRX in the RRC idle mode.

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

[0265] a) UE 100 determines an H-SFN that satisfies "H-SFN mod m = 0" as a reception H-SFN. eNB 200 sets the value of "m" in this calculation formula to UE 100. UE 100 performs a conventional RRC connected mode DRX operation in the determined reception H-SFN. Specifically, UE 100 wakes up at the set DRX cycle and monitors the PDCCH in the wake-up state. UE 100 can maintain a sleep state (i.e., a state in which the PDCCH is not monitored) in an H-SFN that does not satisfy "H-SFN mod m = 0".

[0266] b) The UE 100 can handle a DRX cycle longer than 1024 radio frames by using two consecutive hyperframes as one set. One hyperframe consists of 1024 radio frames having radio frame numbers (SFNs) from 0 to 1023. The UE 100 counts the SFN from 0 to 1023 in a first hyperframe (e.g., an even-numbered hyperframe) constituting one set, and then counts the first radio frame of a second hyperframe (e.g., an odd-numbered hyperframe) constituting the set as SFN=1024, and counts the second radio frame of the second hyperframe as SFN=1025. In this way, the UE 100 continues counting by taking over the count value of the SFN in the first hyperframe in the second hyperframe. This allows the UE 100 to perform a DRX operation using a DRX cycle longer than the time for 1024 radio frames (i.e., 10.24 seconds).

[0267] Next, a case where an operation conforming to DRX in RRC idle mode is described. In conventional RRC idle mode DRX determination, a DRX cycle and an International Mobile Subscriber Identity (IMSI) of the UE 100 are used. The IMSI is used to distribute paging occasions (i.e., timing of PDCCH monitoring) among multiple UEs. However, it is assumed that the eNB 200 has not yet acquired the IMSI of the UE 100 during the random access procedure. Meanwhile, since Msg3 includes an SAE Temporary Mobile Subscriber Identity (S-TMSI) or a Resume ID, the eNB 200 can acquire the S-TMSI or Resume ID of the UE 100 during the random access procedure. Therefore, the eNB 200 and the UE 100 determine a paging occasion using the S-TMSI or Resume ID instead of the IMSI.

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

[0269] In step S717, the eNB 200 transmits response data (TCP ACK) to the UE 100 by downlink early data transmission. The UE 100 receives the downlink data.

[0270] When UE 100 receives TCP NACK as downlink data, UE 100 may start a random access procedure and perform uplink early data transmission.

[0271] In the operation of Fig. 19, from when UE 100 transmits Msg3 with data (step S711) until it receives a notice of downlink data transmission (step S713), it operates a "T300" timer managed in the RRC layer and / or a "Contention Resolution timer" managed in the MAC layer, and continuously monitors the PDCCH. Then, UE 100 starts a timer in response to reception of the notice of downlink data transmission (step S713) (step S714), and performs DRX operation while this timer is operating (step S715).

[0272] Even if no advance notice of data transmission is introduced, it is possible to switch the reception operation using such a two-stage timer.

[0273] The operation includes a step in which the UE 100 performs early data transmission for transmitting an RRC message (Msg3) to the eNB 200 and transmitting user data during a random access procedure, a step in which the UE 100 starts a first timer in response to the execution of the early data transmission, a step in which the UE 100 performs a first reception operation for continuously monitoring a downlink control channel (PDCCH) while the first timer is operating, a step in which the UE 100 starts a second timer in response to expiration of the first timer, and a step in which the UE 100 performs a second reception operation different from the first reception operation while the second timer is operating. The second reception operation is a reception operation that monitors the downlink control channel less frequently than the first reception operation. For example, the second reception operation is a discontinuous reception (DRX) operation that discontinuously monitors the downlink control channel (PDCCH).

[0274] Here, the first timer may be a "T300" timer managed in the RRC layer or a "Contention Resolution timer" managed in the MAC layer. Normally, 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 (such as a contention resolution failure) and restarts the random access procedure. However, when performing early data transmission, the UE 100 continues the random access procedure even if the first timer (the "T300" timer or the "Contention Resolution timer") expires, without determining that the random access procedure has failed.

[0275] 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 starts the new timer without starting the "T300" timer and the "Contention Resolution timer" (see Modification 14).

[0276] On the other hand, when a notice of downlink data transmission is introduced, after receiving an RRC message and user data from the UE 100, the eNB 200 transmits a notice of downlink data transmission (a predetermined message) to the UE 100 (step S713). In response to receiving the predetermined message while the first timer is operating, the UE 100 stops the first timer and stops the first reception operation. In response to stopping the first timer (stopping the first reception operation), the UE 100 starts the second timer.

[0277] As the predetermined message, a Contention Resolution of the MAC layer in Msg4 may be used. A flag (one-bit identifier) ​​indicating a notice of data transmission may be added to the Contention Resolution. Then, when transmitting downlink data (step S717), the eNB 200 transmits an RRC Connection Setup of the RRC layer in Msg4 to the UE 100 together with the downlink data.

[0278] (Change Example 16) Modified Example 16 is a modified example related to Modified Examples 14 and 15. Modified Example 16 will be described mainly focusing on the differences between Modified Examples 14 and 15.

[0279] In Modification 16, UE 100 performs uplink early data transmission using Msg3. In response to the execution of early data transmission, UE 100 starts a timer that determines a waiting time for receiving a response transmitted from eNB200. The "timer" may be the first timer or the second timer according to Modification 14, or may be the timer according to Modification 15. The "response transmitted from eNB200" may be Msg4 transmitted from eNB200 with data or Msg4 transmitted from eNB200 without data (see Modification 14), or may be data transmitted from eNB200 after transmitting Msg4 (announcement) (see Modification 15).

[0280] Then, the UE 100 omits monitoring the PDCCH until the PDCCH monitoring timing determined based on the end timing of the waiting time corresponding to the timer. For example, the UE 100 monitors the PDCCH only in the subframe at the time when the timer expires. This allows the receiver of the UE 100 to be turned off while the timer is operating, thereby reducing the power consumption of the UE 100.

[0281] Instead of the subframe at which the timer expires, the UE 100 may monitor the PDCCH only in the subframe immediately after the timer expires (i.e., the subframe next to the subframe at which the timer expires) or in the subframe after a specified time has elapsed since the timer expires. Alternatively, instead of the subframe at which the timer expires, the UE 100 may monitor the PDCCH only in the subframe immediately before the timer expires (i.e., the subframe one subframe before the subframe at which the timer expires) or in the subframe a specified time before the subframe at which the timer expires.

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

[0283] 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.

[0284] The UE 100 may execute the operation according to the modification 16 only when at least one of the following conditions is satisfied. Such a condition may be applied only when a conventional timer (T300, Contention resolution timer) is used.

[0285] Condition 1: Msg1 indicates intent to transmit early data (EDT Indication). Condition 2: An uplink grant for early data transmission (larger in size than a general uplink grant) is received in Msg2. Condition 3: Early data transmission (data transmission) was performed using Msg3

[0286] (Change Example 17) In the above-described first embodiment, an example has been described in which the eNB 200 sets the maximum amount of data that the UE 100 can transmit in uplink early data transmission to the UE 100. This allows the UE 100 to determine whether or not all of its own uplink data can be transmitted by uplink early data transmission, and to start early data transmission if it is determined that transmission is possible, and not to start early data transmission if it is not determined that transmission is possible.

[0287] As described above, when uplink early data transmission using Msg3 is followed by downlink early data transmission using Msg4, the early data transmission may be applied only when data transmission and reception can be completed with only one set of uplink (Msg3) and downlink (Msg4). Therefore, UE 100 may also determine whether or not all of its own downlink data can be received by downlink early data transmission, and may start early data transmission only when it is determined that the data can be received.

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

[0289] In the seventeenth modification, the eNB 200 transmits information on the data amount condition in the early data transmission to the UE 100 by a broadcast message (SIB). For example, the eNB 200 transmits, as the information on the data amount condition, a maximum value of the amount of downlink data that the eNB 200 can transmit in the early data transmission (maximum transport block size Note that, by the eNB 200 transmitting a broadcast message (SIB) including information regarding the data amount condition, even the UE 100 in the RRC idle mode can receive the broadcast message.

[0290] The UE 100 receives information on the data amount condition from the eNB 200. The UE 100 also estimates the amount of downlink user data to be received from the eNB 200 in the early data transmission. For example, the UE 100 estimates the amount of downlink user data to be received from the eNB 200 based on the type of application executed by the UE 100. Specifically, the UE 100 estimates the amount of downlink user data based on the protocol configuration of the application that can use the early data transmission. For example, the UE 100 estimates the amount of ACK data of TCP as the amount of downlink user data when the application uses a TCP layer. In addition, when there is a response of data reception completion from the server in the application layer, the amount of response data is added to the amount of downlink user data. Such estimation may be performed in the application layer, and the amount of downlink user data may 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, it is also possible to estimate the amount of downlink user data from the past behavior included in the history by retaining the history of the behavior of the past application layer.

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

[0292] The eNB 200 may transmit a minimum amount of downlink data (minimum transport block size) in early data transmission as information regarding the data amount condition. ) may be transmitted. The UE 100 starts early data transmission when the estimated amount of downlink user data is equal to or larger than the minimum downlink data amount set by the eNB 200. On the other hand, the UE 100 starts a normal random access procedure without starting early data transmission when the estimated amount of downlink user data is smaller than the minimum downlink data amount set by the eNB 200. Details will be described in the second embodiment. Since a small amount of data increases padding bits and is inefficient, the eNB 200 allocates the minimum necessary resources to the UE 100 after transitioning to the RRC connected mode, thereby suppressing an increase in padding bits. In addition, by transitioning to the RRC connected mode, for example, advanced processing such as multiplexing data of multiple UEs into one resource or transport block, and processing such as transmitting data together with other signaling in a single UE are also possible.

[0293] Alternatively, when the estimated amount of downlink user data is below the minimum amount of downlink data set by the eNB 200, the UE 100 may maintain the RRC idle mode without initiating the random access procedure.

[0294] FIG. 20 is a diagram showing an example of the operation of the seventeenth modification.

[0295] 20, in step S771, the eNB 200 broadcasts maximum downlink data amount information indicating the maximum downlink data amount in early data transmission. The UE 100 in the RRC idle mode receives the maximum downlink data amount information from the eNB 200.

[0296] The eNB 200 may further transmit, by broadcast, maximum uplink data amount information indicating the maximum uplink data amount in the early data transmission. The UE 100 in the RRC idle mode receives the maximum uplink data amount information from the eNB 200.

[0297] In step S772, the UE 100 detects a start trigger of the random access procedure. The start trigger is, for example, occurrence of uplink data to be transmitted in the UE 100, or receipt of a paging message by the UE 100.

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

[0299] In step S774, the UE 100 determines whether the estimated downlink user data amount is equal to or less than the maximum downlink data amount set by the eNB 200. If the estimated downlink user data amount is equal to or less than the maximum downlink data amount (step S774: YES), the UE 100 starts a random access procedure with early data transmission in step S775. On the other hand, if the estimated downlink user data amount exceeds the maximum downlink data amount (step S774: NO), the UE 100 starts a normal random access procedure without early data transmission in step S776.

[0300] In step S774, the UE 100 may further determine whether or not the amount of uplink user data to be transmitted is equal to or less than the maximum uplink data amount set by the eNB 200. The UE 100 starts the random access procedure with early data transmission when the estimated downlink user data amount is equal to or less than the maximum downlink data amount and the estimated uplink user data amount is equal to or less than the maximum uplink data amount. If not, the UE 100 starts a normal random access procedure without early data transmission.

[0301] In addition, when it is specified that the maximum uplink data amount and the maximum downlink data amount in the early data transmission are the same, the eNB 200 may not notify the maximum downlink data amount to the UE 100. In this case, the UE 100 may determine that the early data transmission is possible when the estimated downlink data amount is equal to or less than the maximum uplink data amount set by the eNB 200.

[0302] In addition, in FIG. 20, an example has been described in which the eNB 200 transmits the maximum downlink data amount information indicating the maximum downlink data amount in early data transmission by broadcast. However, the eNB 200 may transmit the maximum downlink data amount information by unicast. When transmitting such a unicast message, the eNB 200 can set the data amount condition for each UE.

[0303] For example, when the UE 100 is in the RRC connected mode, the eNB 200 transmits an RRC Connection Release message including maximum downlink data amount information to the UE 100. In response to receiving the RRC Connection Release message, the UE 100 transitions to the RRC idle mode and stores the maximum downlink data amount information. 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 maintained in the eNB 200.

[0304] Then, UE 100 starts a random access procedure in RRC idle mode. When UE 100 is in a 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 for this UE 100. On the other hand, when UE 100 is not in a suspended state, eNB 200 does not have the context information of UE 100, and therefore, UE 100 notifies eNB 200 that the maximum downlink data amount is set and / or the set maximum downlink data amount during the random access procedure (for example, when transmitting Msg3).

[0305] (Change Example 18) As described above, when eNB200 sets the maximum data amount (maximum transport block size) in early data transmission to UE100, it is difficult for eNB200 to determine the optimal maximum data amount. Specifically, the amount of data (transport block size) that UE100 transmits and receives by early data transmission varies depending on the type and situation of the application executed by UE100. If the maximum data amount in early data transmission is set too large, resources may be wasted. On the other hand, if the maximum data amount in early data transmission is set too small, UE100 that wants to transmit and receive data exceeding this maximum transport block size cannot use early data transmission, and the effect of reducing power consumption and delay by early data transmission is lost.

[0306] In the eighteenth modification, the UE 100 determines the amount of user data to be transmitted and received in the early data transmission. For example, the UE 100 determines the amount of uplink data that the UE 100 wishes to transmit by the uplink early data transmission. In addition to or instead of such a determination, the UE 100 may determine the amount of downlink data that the UE 100 wishes to receive by the downlink early data transmission. Then, when the UE 100 is in the RRC connected mode, the UE 100 transmits, to the eNB 200, information indicating a maximum data amount (maximum transport block size) recommended by the UE 100 based on the determined amount of user data. Such a recommended maximum data amount may be a recommended maximum data amount for the uplink or a recommended maximum data amount for the downlink.

[0307] Such notification of the maximum data amount may be performed only by the UE 100 having the capability of performing early data transmission. In this case, the eNB 200 may store the notification from the UE 100 in the UE context as UE capability information.

[0308] The eNB200 collects information on the recommended maximum data amount for early data transmission from a large number of UEs 100, and performs statistical processing on the collected information to determine an optimal maximum data amount for early data transmission. For example, the eNB200 collects information on the recommended maximum data amount for uplink early data transmission, and determines an optimal maximum data amount for uplink early data transmission based on the collected information. The eNB200 may collect information on the recommended maximum data amount for downlink early data transmission, and determine an optimal maximum data amount for downlink early data transmission based on the collected information. After determining the optimal maximum data amount, the eNB200 sets the determined maximum data amount to the UEs 100. For example, the eNB200 broadcasts information indicating the determined maximum data amount to set the maximum data amount to the UEs 100 in the cell of the eNB200.

[0309] 21 is a diagram showing an example of the operation of Modification Example 18. Here, an example will be described in which the UE 100 notifies the eNB 200 of the recommended maximum uplink data amount in early data transmission using Msg3. Note that, although the following example is described using the recommended maximum uplink data amount as an example, it can also be applied by replacing it with the recommended maximum downlink data amount.

[0310] As shown in FIG. 21, in step S781, the eNB200 transmits to the UE100 information requesting or setting transmission of a notification of the recommended maximum uplink data amount in early data transmission. The eNB200 may include such information in an Msg4 (RRC Connection Setup message) in a random access procedure, a Measurement Configuration (Measurement Configuration) which is a unicast message, a UE Information Request message, and / or a Minimization of Drive Test (MDT) setting message. Alternatively, the eNB200 may notify the UE100 of information permitting or requesting the notification by a broadcast message. However, step S781 is not essential and may be omitted.

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

[0312] 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 such information in a measurement report, or may include such information in Msg5 (RRC Connection Setup Complete or RRC Connection Resume Complete) of the random access procedure or in a UE Information Response message. Note that the RRC Connection Setup Complete and the RRC Connection Resume Complete may be positioned as messages transmitted from the UE 100 to the eNB 200 immediately after the random access procedure.

[0313] 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 not involving early data transmission and may store the amount of uplink data. Then, after transitioning to the RRC connected mode by the normal random access procedure, the UE 100 may notify the eNB 200 of the amount of uplink data stored as a recommended maximum uplink data amount.

[0314] In step S784, the eNB 200 determines an optimal maximum uplink data amount based on the recommended maximum uplink data amount notified by the UE 100. After determining the optimal maximum uplink data amount, the eNB 200 broadcasts the determined maximum uplink data amount, thereby setting the maximum uplink data amount to the UE 100 in the cell of the eNB 200.

[0315] Alternatively, eNB200 may set the maximum data amount (maximum uplink data amount) to UE 100 by unicast (e.g., RRC Connection Release) instead of broadcasting the maximum data amount to UE 100. In this case, eNB200 determines the optimal maximum data amount for UE 100 based on the recommended maximum data amount notified from UE 100, and sets the determined maximum data amount to UE 100 by unicast.

[0316] In this modification, an example has been described in which the eNB200 determines the maximum uplink data amount to be set in the UE100 based on the recommended maximum uplink data amount notified by the UE100. However, as will be described in detail in a second embodiment, a plurality of blind decoding thresholds may be set in the UE100 within the range of the maximum uplink data amount. Specifically, the UE100 identifies a minimum blind decoding threshold that is greater than the amount of user data to be transmitted by the UE100, and fills in a shortage with the identified blind decoding threshold with padding data. Therefore, in order to reduce padding data, the eNB200 may determine a blind decoding threshold to be set in the UE100 based on the recommended maximum uplink data amount notified by the UE100.

[0317] [Second embodiment] The second embodiment will be described mainly with respect to differences from the first embodiment. In the second embodiment, it is assumed that uplink early data transmission is performed using Msg3 during a random access procedure. During the random access procedure, the UE 100 transmits user data in addition to an RRC message (an RRC Connection Request message or an RRC Connection Resume Request message) to the eNB 200.

[0318] During the random access procedure, the eNB200 transmits Msg2 (random access response) including an uplink grant for allocating uplink radio resources to the UE100. When the UE100 transmits user data associated with an RRC message (Msg3) to the eNB200, it is desirable that the allocation data size (i.e., transport block size) corresponding to the uplink radio resources allocated to the UE100 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 eNB200 performs a decoding process assuming the transport block size allocated to the UE100.

[0319] 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 in the extra uplink radio resources so that the eNB 200 can appropriately perform the decoding process. Here, when the extra uplink radio resources are allocated in large numbers, the UE 100 needs to transmit a large amount of padding data, which causes a problem of increasing the power consumption of the UE 100 to transmit the padding data. The second embodiment is an embodiment for solving such a problem.

[0320] (1) Operation pattern 1 In the operation pattern 1 of the second embodiment, the eNB 200 transmits an uplink grant for allocating periodic uplink radio resources to the UE 100 during a random access procedure. Such resource allocation is sometimes called semi-persistent scheduling (SPS). However, conventional SPS is not applied during the random access procedure.

[0321] In the SPS according to the operation pattern 1 of the second embodiment, the setting information of the SPS (for example, an uplink transmission period) is included in the SIB transmitted to the UE 100 by the eNB 200. In addition, in the operation pattern 1, the uplink grant transmitted to the UE 100 by the Msg2 includes information of the uplink radio resource (resource block) to be assigned to the UE 100, and activates the SPS. That is, the uplink grant assigns a periodic uplink radio resource to the UE 100.

[0322] 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 the uplink radio resources allocated by the uplink grant at an uplink transmission period according to the SPS configuration information.

[0323] In this way, the UE 100 performs multiple uplink transmissions, thereby making it possible to reduce the amount of uplink radio resources used in one uplink transmission. Also, the UE 100 can transmit an RRC message and user data at different timings (different subframes). For example, in multiple uplink transmissions, the UE 100 transmits at least an RRC message in the first uplink transmission, and transmits at least a part of the user data in the second uplink transmission. Therefore, the UE 100 does not need to transmit a lot of padding data.

[0324] In the operation pattern 1 of the second embodiment, the eNB 200 transmits information for setting the maximum number of times of uplink transmission using periodic uplink radio resources to the UE 100. This allows the eNB 200 to properly grasp the number of times to perform decoding processing of the uplink data. The eNB 200 may transmit the information for setting the maximum number of times of transmission by an SIB or by an uplink grant (Msg2). The UE 100 performs uplink transmission multiple times within a range not exceeding the set maximum number of times of transmission.

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

[0326] As shown in FIG. 22, in step S801, the eNB 200 transmits SPS setting information by SIB. The UE 100 receives and stores the SPS setting information. The eNB 200 may transmit information for setting the maximum number of transmissions by SIB. Here, the description will be given assuming that the maximum number of transmissions is three.

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

[0328] In step S803, the eNB200 transmits a random access response (Msg2) including an uplink grant for activating the SPS to the UE100. The uplink grant includes information on uplink radio resources (resource blocks) to be used for one uplink transmission. Here, the resource allocation size (transport block size) for one transmission may be matched with the size of the RRC message. The eNB200 may transmit information for setting the maximum number of transmissions (three times) by Msg2.

[0329] In step S804 (first uplink transmission), in response to the reception of the uplink grant, the UE 100 transmits an RRC message (Msg3) to the eNB 200 by using the allocated uplink radio resource (resource block).

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

[0331] In step S806 (third uplink transmission), the UE 100 transmits remaining user data to the eNB 200 using the allocated uplink radio resource (resource block) in the subframe according to the SPS transmission cycle. Here, since the number of uplink transmissions has reached the maximum number of transmissions, the UE 100 deactivates the SPS. The UE 100 may also discard the SPS setting information.

[0332] If the transmission of user data ends before the maximum transmission count is reached (for example, if all user data is transmitted in step S805), the UE 100 may not perform uplink transmission in a subframe (timing of step S806) according to the SPS transmission cycle. Alternatively, the UE 100 may transmit information indicating the end of data transmission to the eNB 200 at the time of the final uplink transmission (timing of step S806). Such information (end marker) may be transmitted by the MAC CE.

[0333] In step S807, the eNB 200 transmits Msg4 to the UE 100. The eNB 200 may notify the UE 100 of which uplink transmission has been successfully received and / or which uplink transmission has failed to be received among multiple uplink transmissions by using Msg4. For example, the eNB 200 may notify the UE 100 that reception was OK only the first time, or may notify the UE 100 that reception was OK from the second time onwards.

[0334] In this operation pattern, an example in which the UE 100 transmits the user data after transmitting the RRC message (MAC PDU containing an RRC Connection Request) has been described, but the UE 100 may transmit the user data first and transmit the RRC message after the data transmission is completed. In this case, the eNB 200 can recognize that the transmission of the user data is completed by receiving this RRC message.

[0335] (2) Operation pattern 2 In the operation pattern 2 of the second embodiment, the eNB 200 transmits an uplink grant for allocating an uplink radio resource to the UE 100 by using Msg2 during a random access procedure.

[0336] In response to receiving the uplink grant, the UE 100 repeatedly transmits an RRC message (Msg3) using uplink radio resources during the random access procedure. This provides redundancy to the RRC message, thereby increasing the probability that the eNB 200 will succeed in receiving (decoding) the RRC message. The UE 100 may repeatedly transmit user data in addition to repeatedly transmitting the RRC message, using the uplink radio resources allocated by the uplink grant. This allows the user data to also have redundancy.

[0337] In the decoding process, the eNB 200 performs soft combining of the repeatedly transmitted RRC messages and soft combining of the repeatedly transmitted user data. In this way, in the operation pattern 2 of the second embodiment, by performing redundant transmission instead of transmitting padding data, it is possible to effectively utilize the uplink radio resources allocated by the uplink grant.

[0338] -HARQ redundancy version In the repeated transmission of the RRC message, the UE 100 may transmit an RRC message having a different HARQ redundancy version (i.e., a redundancy configuration). In addition, the UE 100 may transmit user data having a different HARQ redundancy version in the repeated transmission of the user data. This can further increase the decoding success rate in the eNB 200.

[0339] For example, the UE 100 stores multiple RRC messages (or multiple user data) in different MAC PDUs and transmits a set 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.

[0340] As a first example of redundant transmission, only the MAC SDU may be made redundant, and multiple MAC SDUs may be stored and transmitted in one MAC PDU. In this case, while there is only one redundancy version, a gain due to redundancy can be obtained by the following method. Specifically, when generating a bit string before rate matching, the UE 100 generates it from a bit length (TBS size 1) corresponding to the size of the RRC message and user data. Then, when the UE 100 extracts a bit string to be transmitted from a circular buffer during rate matching processing, the UE 100 extracts a bit length according to the resource and MCS allocated by the eNB 200. As a result, although there is only one redundancy version, a gain due to redundancy can be obtained compared to the case where the same part of the circular buffer is repeated. When performing brute force decoding (blind decoding), eNB200 defines TBS size 1 (unknown to eNB200) in a predetermined ratio, such as 3 / 4 of TBS size 2, 1 / 2 of TBS size 2, or 1 / 4 of TBS size 2, depending on the bit length corresponding to the resources and MCS allocated by eNB200 (TBS size 2, known to eNB200), enabling blind decoding.

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

[0342] Transmission power When performing the repeated transmission (redundant transmission), the UE 100 may reduce the transmission power compared to when the repeated transmission is not performed. This allows the power consumption of the UE 100 to be reduced.

[0343] 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 the UE 100 redundantly transmits three MAC PDUs, the transmission power may be one-third that when transmitting one MAC PDU. Note that even if the transmission power is reduced, it is possible to compensate for this by using a soft combining gain in the eNB 200.

[0344] -Soft Blending Example 1 When performing the repetitive transmission, the UE 100 may notify the eNB 200 of the repetitive transmission (and / or the number of repetitive transmissions), which enables the eNB 200 to perform appropriate soft combining.

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

[0346] The UE 100 makes the DMRS pattern different depending on whether or not the repetitive transmission is performed. The UE 100 may make the DMRS pattern different depending on the number of times of the repetitive transmission.

[0347] -Soft Blending Example 2 Instead of transmitting a notification of the repeated transmission, the eNB 200 may try the reception process (decoding process) for the number of candidates for the number of repeated transmissions, where the candidates for the number of repeated transmissions include zero (i.e., no repeated transmission is performed).

[0348] In this way, the eNB 200 decodes the repeatedly transmitted RRC message (and the repeatedly transmitted user data) in a round-robin manner by blind decoding. This allows the eNB 200 to perform appropriate soft combining even without notification of the repeated transmission.

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

[0350] When the total size of an RRC message (RRC Connection Request) and user data (Data) is larger than the allocated data size, the UE 100 performs repeated transmission according to a predefined repeated transmission pattern as shown in Fig. 23A. The eNB 200 performs blind decoding according to the predefined repeated transmission pattern.

[0351] In the example of FIG. 23A, the allocation data size allocated by the uplink grant (UL grant) is larger than twice the total size of the RRC message (RRC Connection Request) and user data (Data). In this case, half the size of the allocation data size is set as one unit, and transmission is performed repeatedly for each unit. In addition, padding data is placed in the portion that is less than half the size of the allocation data size. The eNB 200 performs blind decoding for each unit that is half the size of the allocation data size.

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

[0353] On the other hand, when the total size of the RRC message (RRC Connection Request) and user data (Data) is smaller than the allocated data size, the UE 100 performs repeated transmission according to a predefined repeated transmission pattern as shown in FIG. 23B. 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 in the remaining portion. The eNB 200 performs blind decoding, assuming that only the RRC message is repeatedly transmitted.

[0354] When the total size of the RRC message (RRC Connection Request) and user data (Data) is smaller than the allocated data size, eNB200 may attempt decoding for each of three patterns: a case where only the RRC message is repeatedly transmitted, a case where only the RRC message is transmitted, and a case where user data is transmitted together with the RRC message.

[0355] In addition, the UE 100 may notify the eNB 200 of information indicating which repetitive transmission pattern to apply, by using a MAC header or a MAC CE accompanying the RRC message.

[0356] (3) Operation pattern 3 In the operation pattern 3 of the second embodiment, the eNB 200 broadcasts, for example, by an SIB, information indicating multiple resource pools available for transmitting user data in early data transmission. The multiple resource pools have different amounts of available radio resources (i.e., available transport block sizes).

[0357] When performing early data transmission in response to receiving an uplink grant from eNB200, UE100 transmits user data using a resource pool selected from among multiple resource pools. This makes it possible to select a resource pool appropriate for the amount (size) of user data that UE100 wishes to transmit, thereby eliminating or reducing padding data to be transmitted. Note that eNB200 attempts to receive (decode) user data in each resource pool, and receives (decodes) the user data in one of the resource pools.

[0358] The UE 100 may transmit the user data and the RRC message together using the selected resource pool. Alternatively, the UE 100 may transmit the RRC message using the uplink radio resource allocated by the uplink grant, and then transmit the user data using the selected resource pool.

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

[0360] The UE 100 may select a resource pool in consideration of the priority of user data. For example, when an uplink radio resource (resource block) to be used for transmission can be selected from the selected resource pool, the larger the resource pool, the lower the possibility of interference caused by resource collision between the UEs 100. Therefore, the UE 100 may select a larger resource pool when the priority is high. Alternatively, the eNB 200 may notify the available priority information for each resource pool. Note that in the UE 100, the priority may be specified in a higher layer (e.g., an application layer) and notified from the higher layer to an AS (e.g., an RRC layer, a MAC layer). The priority may be set in advance in the UE 100 by an application server, or may be authenticated by an MME or the like and set in the UE 100. Also, the resource pool may be provided for each CE level.

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

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

[0363] Next, eNB200 receives a random access preamble in any one of the resource pools, and transmits a random access response (Msg2) to UE100 if the use of this resource pool is permitted. Msg2 includes a temporary identifier (Temporary C-RNTI) that eNB200 has assigned to UE100. When UE100 receives Msg2, UE100 considers that early data transmission is permitted. Then, in subframe SFb, UE100 transmits an RRC message (Msg3) to eNB200 using uplink radio resources assigned by the uplink grant in the random access response. UE100 transmits the RRC message including the temporary identifier (Temporary C-RNTI).

[0364] Next, in the subframe SFc, the UE 100 transmits user data to the eNB 200 by using the selected resource pool. The UE 100 transmits the user data by including a temporary identifier (Temporary C-RNTI).

[0365] (4) Operation pattern 4 In the operation pattern 4 of the second embodiment, the eNB200 transmits an uplink grant for allocating an uplink radio resource to the UE100 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 UE100 determines whether to perform early data transmission using the uplink radio resource or to transmit only the RRC message using the uplink radio resource. The UE100 makes such a determination based on the amount of padding data required for early data transmission. The eNB200 attempts reception processing (decoding processing) for both the case where the UE100 transmits only the RRC message and the case where the UE100 performs early data transmission.

[0366] When only the RRC message is transmitted, the eNB 200 can grasp the data size of the RRC message, and therefore the UE 100 does not need 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 does not grasp the amount of user data. For this reason, the UE 100 may need to transmit padding data in order to transmit at the assigned data size.

[0367] For example, the UE 100 determines the amount of padding data required for early data transmission based on the allocated data size. If the determined amount of padding data is greater than a threshold, the UE 100 assumes that the power consumption caused by the transmission of the padding data is large, and transmits only an RRC message without performing early data transmission. This makes it possible to avoid an increase in the power consumption of the UE 100 caused by the transmission of the padding data.

[0368] [Other embodiments] The second embodiment may be implemented in combination with the first embodiment and its modified examples, or two or more modified examples of the first embodiment to the modified examples 1 to 15 may be implemented in combination. In addition, the modified examples 1 to 15 of the first embodiment may be implemented independently of the operation according to the modified example without being based on the operation according to the first embodiment.

[0369] In the above-described embodiment and its modified example, no particular distinction is made between a CP (Control Plane) solution and a UP (User Plane) solution, but the operation according to the embodiment and its modified example can be applied to both the CP solution and the UP solution. In the CP solution, data is included in an RRC message in early data transmission. In the UP solution, data is not included in an RRC message in early data transmission, but data (DTCH) and an RRC message (CCCH) are multiplexed and transmitted in the MAC layer.

[0370] In the UP solution, the RRC message corresponding to Msg3 is an RRC Connection Resume Request message, and the RRC message corresponding to Msg4 is an RRC Connection Resume message. Usually, when UE 100 receives RRC Connection Resume, it establishes (re-establishes) a PDCP entity. However, when performing early data transmission, it is considered that UE 100 has already established (re-established) a PDCP entity for data transmission before receiving RRC Connection Resume. Therefore, UE 100 may receive a transition instruction (RRC Connection Resume) from idle mode to connected mode from eNB 200 after establishing (re-establishing) a PDCP entity for performing early data transmission. In this case, UE 100 may skip the establishment (re-establishment) of the PDCP entity and maintain the established PDCP entity.

[0371] In the above-described embodiment, an example using radio terminals (eMTC UE and NB-IoT UE) for MTC and IoT has been described. However, the present disclosure is not limited to eMTC UE and NB-IoT UE. The operation according to the above-described embodiment may be applied to a general UE.

[0372] In the embodiment, the RRC idle, suspended, and connected are mainly described as examples, but the present invention is not limited to these. The present invention may be applied to the RRC light connection and INACTIVE states. The RRC light connection is one state of the RRC connected mode, and is a special state to which a part of the RRC idle mode procedure is applied. The INACTIVE state is expected to be introduced in 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-mentioned embodiment may be read as "INACTIVE mode".

[0373] In the embodiment, the UE in the enhanced coverage is taken as an example, but the present invention is not limited thereto. The operation according to the above-mentioned embodiment may be applied to the UE in the normal coverage. Specifically, in the RACH procedure, the CE level determination based on the RSRP measurement may not be performed.

[0374] In the above-described embodiment, the LTE system is exemplified as a mobile communication system. However, the present disclosure is not limited to the LTE system. The operation according to the above-described embodiment may be applied to a mobile communication system other than the LTE system (for example, a fifth generation mobile communication system).

[0375] A program may be provided that causes a computer to execute each process performed by the UE 100 and the eNB 200. The program may be recorded in a computer-readable medium. Using the computer-readable medium, it is possible to install the program in the computer. Here, the computer-readable medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM. A chipset may be provided that is configured by a memory that stores a program for executing each process performed by the UE 100 and the eNB 200 and a processor that executes the program stored in the memory.

[0376] [Appendix 1] (1. Introduction) A new work item on further enhanced MTC for LTE (eFeMTC) has been approved in RAN#75 and WID has identified several goals for RAN2 to consider as the lead WG. The objective is to specify the following improvements for machine type communication for BL / CE UE: [...] Improved latency: [...] Supports early data transmission [RAN2 led, RAN1, RAN3] · Evaluation of power consumption / latency gains on dedicated resources and specification of required support for DL / UL data transmission during the random access procedure (after PRACH transmission and before RRC connection setup is completed) at least for RRC suspend / resume.

[0377] This appendix discusses considerations for these improvements.

[0378] (2. Consideration) (2.1. Improved Latency - Early Data Transmission) The WID clearly states that "Evaluate the power consumption / latency gain on dedicated resources during random access procedures (after PRACH transmission and before RRC connection setup is completed) at least in the RRC suspend / resume case and specify the required support for DL / UL data transmission." The latency performance improvement due to early data transmission may lead to additional power consumption, taking into account various MTC device implementations. If additional power consumption is required for some MTC implementations, the UE should be allowed to select legacy RACH procedures, i.e. non-early data transmission modes, to avoid burdening legacy use cases.

[0379] Proposal 1: The solution for early data transmission should minimize additional power consumption, e.g., the UE should be allowed to select the legacy RACH procedure, i.e. the "non-early data transmission mode".

[0380] The WID also states that early data transmission should be performed after Msg1 and before Msg5, i.e. candidates for extension are Msg2, Msg3 and Msg4, whereas it is expected that some control signaling could be sent before Msg2 and even after Msg4.

[0381] Proposal 2: It is not necessary that control signaling related to early data transmission be required to be sent in message 2, message 3, and message 4.

[0382] It is not identified in the WID whether the data for early transmission is assumed as small packets, large size data and / or both. For example, if only small data is assumed, it may be better for the UE to transition to RRC IDLE as soon as data transmission is completed, even within the RACH procedure. It is considered that the solution differs depending on the data size for early transmission. Therefore, RAN2 should first consider and decide on the assumption of the data size.

[0383] Proposal 3: RAN2 should consider the data size assumed for early transmission (i.e., small packets, large packets, or both).

[0384] The WID does not explicitly state whether early data transmission can be initiated only in the contention-based RACH procedure, the contention-free RACH procedure, or both. The solution assumptions differ between the two procedures, for example, whether a PDCCH command can be assumed. Therefore, RAN2 should clarify which RACH procedures are assumptions for early data transmission.

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

[0386] FIG. 25 shows a typical RACH procedure (contention-based / free).

[0387] (2.2. Improving Power Consumption - Relaxed Monitoring for Cell Reselection) WID states that "(re)configuration enables relaxed UE monitoring for cell (re)selection." Regardless of the need for (re)configuration, stationary UEs should be allowed to perform relaxed monitoring since cell reselection is rare. If (re)configuration is required as intended in WID, some UE assistant information may be required, such as the number of cell reselection reports and stationary UE indication, since the network cannot know whether IDLE mode UEs perform cell reselection or not.

[0388] Proposal 5: It should be configurable whether a stationary UE is allowed to operate under loose monitoring for cell reselection.

[0389] [Appendix 2] (1. Introduction) RAN2#99 has started work on more advanced MTC for LTE (eFeMTC) and agreement on early data transmission capabilities has been achieved as follows:

[0390] Agreement Supports early UL data transmission in Msg3 for control plane and user plane CIoTEPS optimization.

[0391] Supports early DL data transmission in Msg4 for control plane and user plane CIoTEPS optimization.

[0392] Agreement The early data transmission feature is taken into consideration when AS security is not established to only transmit data using the CP.

[0393] The early data transfer function is considered when AS security is established to transmit data using CP and / or UP.

[0394] This appendix provides details of the extensions required for early data transmission.

[0395] (2. Consideration) In the following sections, for simplicity, early UL data transmission and early DL data transmission are described separately, and the existing random access procedure is taken as the baseline.

[0396] (2.1. Early UL data transmission) (2.1.1. Clarification of Email Discussion) If the UE wishes to perform an early UL data transmission in Msg3, the SIB provides the specific preamble to be used in Msg1. In other words, if the SIB does not contain such an indication with a specific preamble, then the early UL data transmission is not allowed.

[0397] · Msg1 contains the UE's intention with a specific preamble whether or not there is an early UL data transmission in this random access procedure.

[0398] Msg2 indicates whether the UE's intention is accepted in addition to the existing random access response.

[0399] Msg3 contains data and an enhanced RRC connection (resume) request to inform the eNB whether data transmission is completed within this random access procedure, i.e. whether the UE needs to transition to RRC Connected.

[0400] Msg4 can be either RRC Connection Setup / Resume or RRC Connection Release, i.e. the network responds with Msg4 and ensures that receipt of Msg3 completes contention resolution and includes a NAS PDU if required.

[0401] From the eNB's point of view, it is necessary for the SIB to indicate whether Early UL data transmission is allowed or not, i.e. SIB indications such as Up-CIoT-EPS-Optimized etc. are minimal. The UE can then include a specific preamble in Msg1 to indicate to the eNB its intention to use Early UL data transmission. However, even if the UE includes a specific preamble in Msg1, the eNB should still have the option to decide whether to accept the Early UL data transmission, since there may be other reasons why it needs to reject the Early UL data transmission. This may be conveyed to the UE via Msg2. Thus, two stages of authorization are required before the Early UL data transmission is authorized.

[0402] Proposal 1: It should be agreed that RAN2 will send a specific preamble provided in the SIB in Msg1 to inform the eNB of its intention to perform early data transmission in Msg3, and the eNB will indicate in Msg2 whether early data transmission is acceptable or not.

[0403] Since one of the main purposes of early data transmission is to reduce the UE power consumption, the UE should be released to IDLE as soon as the data transmission is completed. The Release Assistance Indication (RAI) can be reused for this purpose. On the other hand, if the data packet to be transmitted is small and can be transmitted 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 transmission, the request should be conveyed to the eNB using one of the following options:

[0404] Option 1a: Set spare1 to the Establishment Cause of the RRC Connection Request and / or Resume Cause of the RRC Connection Resume Request.

[0405] Option 1b: There is a spare IE in the RRC Connection Request and / or the RRC Connection Reestablishment Request.

[0406] Option 1c: Specify RAI (i.e., BSR=0) in Msg3.

[0407] Option 1d: A new RRC message, e.g., RRC Connection-less Request.

[0408] Options 1a-1c have less impact on the specification than option 1d. From the point of view of signaling overhead, options 1a and 1b are the same as option 1c, but are better than option 1. In terms of technical implications, option 1b is more flexible than option 1a, especially considering potential needs in future releases, since early UL data transmission is generally not related to establishment / resumption causes. Therefore, option 1b is preferred.

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

[0410] (2.1.2.Retransmission method) WID says early data transmission will be carried out on dedicated resources.

[0411] It should be further considered whether the current agreement of RAN2 for early UL data transmission is actually supported with dedicated resources. RAN2 agreed to "Early UL data transmission in Msg3" where Msg3 resources are allocated by dedicated UL grant in Msg2. Current Msg3 carries either RRC connection request or RRC connection recovery request via CCCH logical channel which is ultimately mapped to PUSCH via UL-SCH, but the contention for physical resources between UEs is unresolved. Early UL data transmission is supported only for IDLE UEs, i.e. with contention based random access procedure.

[0412] Observation 1: In Msg3, the conflict is not resolved based on the RACH procedure.

[0413] In Msg3, more UL interference from multiple UEs is expected since contention is not resolved. In other words, reception errors of early UL data in Msg3 may occur. If the early UL data transmission is not successfully received, it is still unclear what the UE should do, i.e., how to retransmit the UL data that was not successfully received by the eNB.

[0414] Proposal 3: RAN2 should consider how the UE should retransmit early UL data if the data is not successfully received by the eNB.

[0415] If proposal 3 is acceptable, four options for the retransmission scheme are considered:

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

[0417] Option 2b: The UE may retransmit the failed data, ie, Msg3 with "Early UL Data Retransmission in Msg3".

[0418] Option 2c: The UE can retransmit the failed data in Msg5, i.e., only the data failed.

[0419] Option 2d: The UE is allowed to retransmit failed data only after an RRC connection.

[0420] Option 2a is adapted from the current specification, i.e. flushing the Msg3 buffer and resuming from random access resource selection. With option 2a, it is unclear whether to apply the legacy backoff time or the new backoff time for early UL data retransmission and whether there is a limit on the number of retransmissions. Option 2b can follow option 2a, i.e. the UE includes the failed data in the next Msg3 timing. Option 2c is a rare case, since it is unlikely that no data was received during a successful RRC connection (resume) request, assuming the same MCS is applied. Option 2d is consistent with the current specification, except that retransmission of failed data is allowed.

[0421] Proposal 4: RAN2 should agree that if an Early UL data transmission fails, the UE should be allowed to restart the random access procedure (as it is now) and retransmit the data for the next Msg3.

[0422] In any case, the UE should maintain the data for early transmission until confirmation of successful reception, even if the Msg3 buffer is flushed.

[0423] (2.2. DL Early Data Transmission) (2.2.1. Consideration of email discussions) In the email discussion, we jointly considered both early DL and early UL data transmissions, so DL aspects may not have been considered in detail. The next section provides such details.

[0424] (2.2.2. UE Support for Early DL Data Transmission) It has been agreed that RAN2 supports Early DL data transmission in Msg4, which requires receiving data in Msg4 in addition to RRC Connection Setup / Resume / Release. However, it is questionable how the eNB can always know whether the UE is capable of Early DL data reception, especially for UEs that are not only suspended but also not suspended. Considering a unified solution for both CIoTE PSCP / UP optimization, the UE can inform the NW, i.e., eNB or MME, whether it is capable of receiving Early DL data.

[0425] Proposal 5: RAN2 should agree that the UE should inform the NW whether it supports early DL data reception or not.

[0426] From the eNB's point of view, there are two options to convey the UE's capabilities to the NW, i.e. MME or UE. If the MME informs the eNB, it is obvious that some S1 messages need to be enhanced, such as PAGING or INITIAL CONTEXT SETUP REQUEST, and RAN2 should discuss with RAN3. On the other hand, if the UE informs the eNB, several options are considered as follows:

[0427] Option 3a: A new IE is added for UE capability of early DL data reception.

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

[0429] Option 3a is a simple way to provide the UE capability to the eNB, but the eNB needs to keep the context even if the UE is no longer connected or suspended since it is forwarded after Msg4. Option 3b is a kind of "handshake", so the UE needs to know if early DL data reception is intended before DL data reception starts, i.e. in paging or Msg2.

[0430] Proposal 6: RAN2 should consider whether the UE supports early DL data reception, i.e. how the eNB is informed by the UE or MME.

[0431] Regardless of Proposal 6, the UE needs to know if it needs to set up early DL data reception before that happens.

[0432] Proposal 7: RAN2 should agree that the UE should be informed by paging or Msg2 if early DL data reception is required.

[0433] (2.2.3.Retransmission method) We assume that the early DL data transmission is performed on a dedicated / non-contention resource, i.e. Msg4. However, reception errors occur even on such resources, so the UE behavior needs to be clarified. Once the early DL data transmission is indicated by paging or Msg2, i.e. proposal 7, it is straightforward for the UE to monitor the data transmitted on Msg4. As in proposal 4, a means of retransmission of DL data is needed in case the DL data is not received by the UE.

[0434] Proposal 8: RAN2 should agree that if Msg4 is not received, an early DL data retransmission is performed for Msg4.

[0435] (2.2.4. Simultaneous early UL / DL data transmission) It remains unclear whether early data transmission should be supported simultaneously on both UL and DL within a single random access procedure. In general, UL data transmission requires higher layer acknowledgment for the next DL and vice versa, e.g. TCP ACK. After the UE decides to send a UL data transmission in Msg3, it may be possible to send an acknowledgment as DL data reception in Msg4 within one random access procedure. The DL data transmission in Msg4 cannot be followed by Msg3 in the same procedure. The higher layer acknowledgment as UL data transmission must be sent in the next Msg3 occurring in the next random access procedure, or the UE could transition to an RRC connection, which would negate the purpose of sending early DL data.

[0436] However, it is unclear how much delay is required for such higher layer acknowledgment. If a higher layer round trip occurs within the random access procedure and the higher layer acknowledgment is delayed, the UE may continue to monitor Msg4 for a long time after transmitting Msg3, which will cause unnecessary power consumption in the UE. Therefore, it is reasonable to support early UL data transmission or early DL data transmission in a single random access procedure.

[0437] Proposal 9: RAN2 should agree that one random access procedure supports only one early data transmission, i.e., either early UL data transmission or early DL data transmission.

[0438] [Appendix 3] (1. Introduction) RAN2#99bis has achieved significant progress in Early Data Transmission (EDT) capabilities with many agreements, including:

[0439] Agreement PRACH partitioning is used to indicate UE intent to use early data transmission in Msg3. Backward compatibility is preserved. Further study required: Details regarding PRACH pool, e.g. preamble / time / frequency / carrier domain for PRACH partitioning.

[0440] For CP during UL EDT procedure, if the UE receives a grant for which the data does not fit, the UE will not send data in Msg3. For UP solution, if the grant is smaller than the UL data size, it needs further consideration whether the EDT grant can be used for UL data.

[0441] Further consideration is needed as to whether it is necessary to introduce an authentication mechanism.

[0442] The maximum grant size for Msg3 is broadcast per CE. Whether the UE indicates the required grant size for Msg3 via PRACH partitioning needs further study.

[0443] ·LS to RAN1, indicating that it is assumed that the conventional TBS table for PUSCH transmission is used for EDT.

[0444] Msg4 determines whether the UE transitions to RRC connected mode or RRC idle mode. The content of Msg4 in EDT needs further study.

[0445] The intention of using EDT is not for data, i.e. NAS signaling.

[0446] Whether any of the following parameters included in Msg5 of the legacy procedure should be included in Msg3 for EDT LS sent to RAN3 / SA2 / CT1: selected PLMN-Identity, registered MME, gummei-Type, attach Without PDN-Connectivity, up-CIoT-EPS-optimized, cp-CIoT-EPS-optimized, dcn-ID.

[0447] RAN2 assumes that S-TMSI for CP, resumeID and shortResumeMAC-1 for UP solution are sufficient to identify the UE at MME and eNB respectively. We apply this assumption for LS.toRAN3, SA2, SA3, CT1.

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

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

[0450] In the UP solution, CCCH (RRC message) and DTCH (UP data) are multiplexed onto the MAC of Msg3.

[0451] In the UP case, AS security is resumed before sending Msg3, and the data sent in Msg3 is protected by AS security.

[0452] For the CP solution, the NASPDU data in DL is encapsulated in an RRC message sent in Msg4 and transmitted as CCCHSDU.

[0453] · For UP solutions, DL data can be arbitrarily multiplexed onto the MAC in Msg4, i.e. DCCH (RRC messages) and DTCH (UP data).

[0454] Further consideration is needed: For UP solution: For fixed connection, i.e. CCCH (RRC Connection Resume Req) + DCCH (NAS PDU with fixed connection)

[0455] This appendix discusses the remaining tasks to complete the basic functionality of EDT.

[0456] (2. Consideration) (2.1. Use Cases) During the discussion, there appears to be a common understanding that the EDT procedure is initiated by, for example, a UL EDT for upper layer sensor data and terminated by a DL EDT for the corresponding upper layer ACK, i.e., the upper layer round trip is performed within the EDT procedure.

[0457] On the other hand, UL-only EDT procedures and / or DL-only EDT procedures may also be useful in some cases. (See FIG. 26 for more comparisons. FIG. 26 shows the EDT procedures.)

[0458] UDP type data transmission, i.e., no higher layer ACK.

[0459] The upper layer round trip delay is long, i.e. the upper layer ACK requires some time before it responds.

[0460] · Commands from the application server to the device, i.e. communication, are triggered by DL.

[0461] It is agreed that "For the CP solution, NAS PDU data in DL can be encapsulated in an RRC message sent in Msg4 and transmitted as CCCH SDU," and "For the UP solution, DL data can be optionally multiplexed into MAC, i.e. DCCH (RRC message) and DTCH (UP data) in Msg4, i.e. the UE can receive Msg4 without data." Therefore, it is considered that the UL only EDT procedure is supported.

[0462] Observation 1: The current agreement supports UL-only EDT procedures.

[0463] Meanwhile, support for DL-only EDT procedures is still unclear in the current agreements. The availability of DL-EDT transmission cannot be known from the UE's point of view until Msg4 is received, and the ability of DL EDT reception was not possible, so that it would be signaled without UL EDT from the eNB's point of view if the assumed UL EDT-capable UE also supports DLE DT. Therefore, further studies should address some extensions, e.g. notification in paging, if DL-only EDT procedures are supported.

[0464] NOTE: It is assumed that a UE capable of UL EDT functionality is also capable of DL EDT functionality.

[0465] Proposal 1: RAN2 should consider whether DL-only EDT procedures are supported.

[0466] (2.2. Details of EDT Indication) In RAN2#99bis, it was agreed that "PRACH partitioning is used to indicate the UE's intention to use early data transmission in Msg3. Backward compatibility is preserved. Further study required: details on PRACH pool such as preamble / time / frequency / carrier domain for PRACH partitioning" and "The maximum possible grant size for Msg3 is broadcast per CE. If the UE indicates the required grant size for Msg3 via PRACH partitioning, it needs further study."

[0467] The email discussion explained that further consideration is needed, namely additional information on Msg1 and PRACH partitioning details. Regarding additional information on Msg1, the majority of opinions seem to be that EDT indication is set per CE, but UE category is not necessary. There is no agreement on EDT indication, but this may be a future extension.

[0468] Proposal 2: RAN2 should agree that the EDT indication in Msg1 should be set per CE and that the grant size indication in Msg1 should be considered as a future extension.

[0469] Regarding the details of PRACH partitioning, two directions have been suggested: soft partitioning (or non-dedicated PRACH resources) and hard partitioning (or dedicated PRACH resources). In particular, the question is whether PRACH fragmentation is acceptable, since it may cause PRACH performance degradation in the case of limited resources in some NB-IoT deployment scenarios.

[0470] For example, sharing PRACH resources with soft partitioning in a non-optimized NW has some advantages, but the number of partitions is the same as with hard partitioning. For example, with hard partitioning, 6 partitions are needed for PRACH resources for 3 legacy CE levels, 3EDT 3CE levels. With soft partitioning, 6 PRACH spaces (3 CE levels x 2 different preambles) are also needed. This means that there is no physical overstepping, i.e., the difference is in how you separate the UEs.

[0471] NOTE: In hard partitioning, shared PRACH resources are possible if the eNB configures legacy PRACH resources and EDT Indication PRACH resources with overlapping resources.

[0472] Therefore, in our view, regardless of the partitioning method (eg, soft or hard), and regardless of dedicated or non-dedicated resources, the PRACH performance is ultimately similar in an optimized NW.

[0473] Observation 2: The performance of PRACH is ultimately similar among the solutions proposed in the email discussion.

[0474] As an alternative solution not previously considered in the email, it is also necessary to consider whether multiple PRACH transmissions from the UE can be defined to distinguish between legacy and UL-EDT PRACHs. For example, the UE transmits a first PRACH for legacy purposes (i.e., CE level determination) and a second PRACH for EDT indication (i.e., only UEs that request EDT transmit the second one). The eNB can perform blind decoding on the two PRACH spaces of each PRACH shot (see Figure 27, which shows EDT indication with multiple PRACH transmissions). The two PRACHs can be transmitted on the same subframe. With this approach, four PRACH resources (three CE levels for the first PRACH, one EDT indication for the second one) are needed since legacy UEs transmit only the first PRACH as they do now. However, the drawback of this solution is that it obviously requires the UE to transmit an additional PRACH, which incurs additional power consumption, which may be similar to the power consumption due to PRACH performance degradation (eg, collisions).

[0475] Proposal 3: RAN2 should consider whether multiple PRACH transmissions with one additional PRACH space would be useful for EDT indication.

[0476] Proposal 4: Once Proposal 2 and Proposal 3 are agreed upon, RAN2 should consider later whether the grant size indication can be mapped to additional PRACH space.

[0477] (2.3. Examples of EDT failures) (2.3.1.UL Grant Failure (Msg1 / Msg2)) RAN2 agreed that "For CP during ULEDT procedure, if the UE receives a grant that does not fit the data, the UE shall not transmit data in Msg3. For UP solution, if the grant is smaller than the UL data size, further consideration is required if EDT grant can be used for UL data." At least for CP solution, eNB may reject EDT procedure with legacy size UL grant on Msg2 even if UE sends EDT indication on Msg1. It can be considered as a failure case from EDT procedure point of view.

[0478] Observation 3: At least for the CP solution, the EDT procedure fails if the UL grant does not fit the data size.

[0479] The current agreement only states whether data can be transmitted on Msg3 or not, i.e. does not mention what the UE should do if the UL grant is smaller than expected. Therefore, the UE behavior in case of failure should be specified, for example for testing. Some options should be considered:

[0480] Option 1: The UE sends legacy Msg3 (ie, no data).

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

[0482] Option 1 may be the baseline from our impressions during the study. Option 2 differs somewhat from the current behavior, i.e. the UE skips PUSCH transmission even if it receives a corresponding UL grant. However, since EDT is a new feature, it is worth considering introducing option 2 in the options only if the eNB allows this feature, for example, to minimize unnecessary UE power consumption to transition to RRC connection.

[0483] Proposal 5: RAN2 should agree that, at least for the CP solution, the UE should send legacy Msg3 if the UL grant size is not enough for the UL EDT.

[0484] Proposal 6: RAN2 should consider whether the UE is optionally allowed to retransmit the EDT indication if the UL grant size is not large enough.

[0485] (2.3.2. Reception failure (Msg3 / Msg4)) There is no discussion on how to handle failure to receive data in the EDT procedure.

[0486] In the previous discussion of UL EDT, the UE behavior was assumed only when the UE receives Msg4, but it is not yet clear what happens if the UE does not receive Msg4. Several options were considered, but it may be easier for the UE to follow the current random access procedure, i.e., to restart from random access resource selection, so that the UL EDT is also retried.

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

[0488] Since currently the HARQ buffer is flushed when contention resolution is deemed unsuccessful, consideration should be given to where the data for retransmission is stored. From the CP solution point of view, the traffic data is encapsulated as NAS PDUs in RRC messages. It is possible to encapsulate the traffic data in the RRC layer until the data transmission is successfully completed. On the other hand, from the UP solution point of view, since the traffic data on the DTCH is multiplexed in the MAC layer, the traffic data is not stored in the RRC layer but in one of the user plane layers. Even if contention resolution is deemed unsuccessful, from the point of view of having a common UE behavior for CP and UP, the MAC layer should not flush the HARQ buffer.

[0489] Observation 4: In the RRT or MAC, it is unknown in which layer the data is stored until the UL EDT is successfully completed.

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

[0491] In DL EDT, the failure to receive Msg4 is indicated by the HARQ feedback, so the data retransmission can simply follow the current HARQ retransmission.

[0492] Proposal 9: RAN2 should agree that DL EDT retransmissions are performed via Msg4 HARQ retransmissions, as is the case today.

[0493] (2.3.3.T300 and Contention Resolution Timer Fault (Msg3 / Msg4) In the current specification, there are two timers between RRC Msg3 and Msg4: T300 and MAC mac-Contention Resolution Timer. The value of T300 is between 100ms and 2000ms for LTE and between 2500ms and 60000ms for NB-IoT. The value of mac-Contention Resolution Timer is between sf8 and sf64 for LTE and between pp1 and pp64 for NB-IoT. When these timers expire, the UE assumes that the RRC connection establishment / resumption or contention resolution, respectively, was not successful.

[0494] If the UL EDT is for sensor data transmission and the DL EDT is for TCP ACK ("Full EDT procedure" in Figure 26), the Msg4 transmission in the EDT procedure depends on the round trip time at the upper layer and is likely to be delayed more than the conventional Msg4. Therefore, it is easy to define a longer timer value to prevent unnecessary errors.

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

[0496] However, it may cause additional UE power consumption due to continuous PDCCH monitoring until reception of Msg4. Therefore, a DRT-like receiving mode needs to be introduced into the EDT procedure.

[0497] Proposal 11: RAN2 should consider whether discontinuous reception is permitted in the EDT procedure (i.e., between the transmission of Msg3 and the reception of Msg4).

[0498] Moreover, it is questionable how the eNB sets the timer value, since it does not know when the TCP ACK will come back for the higher layer message. Since it is assumed that there are many UEs implementing various applications in the cell, it seems difficult to set the appropriate timer value for all UEs.

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

[0500] Proposal 12: RAN2 should consider whether the UE is allowed to inform the eNB of the self-configuration timer value on Msg3.

[0501] If any of proposals 10 to 12 are preferred, the timer concept for EDT is different from the legacy timers. It is also possible that an EDT-capable UE initiates a legacy RRC connection establishment / resumption, e.g. for larger packet transmissions, so the legacy timers are applicable in this case. Therefore, it is worth considering whether the timers for EDT should reuse the legacy timers or define new timers.

[0502] Proposal 13: RAN2 should consider whether the timer for EDT should reuse a legacy timer or define a new timer.

[0503] FIG. 28 shows the delay due to the round trip time of the upper layer.

[0504] (2.4. Approval Mechanism) The chair's memo stated that "further consideration is required as to whether an approval mechanism should be put in place." Such an approval mechanism was out of scope for the email discussions.

[0505] In our understanding, EDT is an AS functionality and does not incur any cost from the perspective of the NW or UE (unlike CE). Furthermore, the NW can always disable the EDT functionality by removing the PRACH splitting parameters and / or the maximum possible grant size from the SIB. Therefore, there is no technical reason to introduce an authentication mechanism.

[0506] Proposal 14: RAN2 should agree that authentication mechanisms for EDT are not required.

[0507] [Appendix 4] (1. Introduction) RAN2#100 reviewed the details of the Early Data Transmission (EDT) indication on Msg1 and reached the following agreement:

[0508] Agreement ·The UE starts EDT on Msg1 if the size of Msg3 containing user data that the UE intends to transmit is equal to or smaller than the maximum possible TBS size of Msg3 broadcast per CE.

[0509] For each extended coverage level, a PRACH partitioning for EDT indication is set.

[0510] Working assumptions: Support for segmentation in this case is not a priority.

[0511] · Operational assumption: PRACH resource partitioning is not supported to indicate intended data size other than legacy or maximum TBS broadcast per CE.

[0512] How to fix padding issues in Msg3

[0513] · UE category is not indicated in Msg1.

[0514] For EDT indication, PRACH resources can be configured like legacy eMTC or NB-IoT in terms of physical layer resources, preamble / subcarriers.

[0515] · The PRACH resource pool for EDACH indications, i.e. physical layer resources, preambles / subcarriers, is separate from the PRACH resource pool for legacy RACH procedures.

[0516] It was recognized that further work was needed on how to address the padding issue, which occurs when the UL grant for ULEDT is mismatched with the data size that the UE is trying to send. The details of the issue are detailed in the corresponding email discussion.

[0517] This appendix provides additional clarification on the email discussion.

[0518] (2. Consideration) A solution to the padding problem was proposed and summarized in an email discussion as follows:

[0519] The following solutions to the above padding problem were presented:

[0520] 1. (N)PRACH partitioning, where the UE indicates the intended data size / TBS for EDT Msg3 using Msg1.

[0521] 2. The network provides multiple transport block sizes and combinations of UL grant information: RU, PRB, and repetition count in the RAR message for the UE to select considering the intended data transmission in Msg3.

[0522] 3. The network provides double (or more) grant for sending Msg3.

[0523] 4. Combination of data size expression with Msg1 and RAR flexible grant.

[0524] 5. Repetition of MAC SDUs or PDUs in padding areas (the details of this solution are unclear, but will be explained in detail for better understanding)

[0525] 6. Implicit allocation such as multiple common UL resource pools for Msg3 transmissions related to multiple "Maximum TBS broadcasts per CE" (details of this solution are unclear but will be explained in detail for better understanding).

[0526] 7.UP only: Segmentation to avoid padding for legacy Msg3 transmissions.

[0527] (2.1. Solution 5 (MAC PDU Repetition)) This solution uses padding areas as redundancy opportunities. In other words, the existing repetition scheme on the subframe is done within the transmission. Examples are shown in Figures 29 and 30. Figure 29 shows the case where the UL grant is larger than the intended data size. Figure 30 shows the case where the UL grant is smaller than the intended data size.

[0528] One possibility is the physical layer, but which entity in that layer performs the additional redundancy process needs further study. For example, the UE may generate a bit string from the MACPDU, store it in a circular buffer, and transmit the bits according to the UL grant size.

[0529] The pros and cons are expected to be:

[0530] Advantages: Possibility of Rx soft combining gain and / or Tx power reduction to compensate for repetitions compared to transmitting padding bits.

[0531] Disadvantages: There may be RAN1 effects if repetition is handled at the physical layer.

[0532] (2.2. Solution 6 (Common UL Resource Pool)) This solution provides a common UL resource pool for EDT, so that the resource pool is similar to the Mode 2 / Type 1 sidelink transmission, i.e. the common resources used by multiple UEs. The legacy Msg3 resources (as they are now) are ) can be assumed to always be provided by the UL grant, but the UE can transmit the data part using a common resource pool with the same temporary C-RNTI 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, whereby the second grant resource intended for data is shared by multiple UEs.

[0533] FIG. 31 shows a common resource pool for UL transmission.

[0534] The advantages and disadvantages can be considered as follows:

[0535] Pros: No changes to Msg2 are needed. The UE can transmit data without padding (as long as the size does not exceed the common resources), assuming a sidelink-like transmission. Considering that EDT is an IDLE mode procedure, the use of common resources is also reasonable, as is the case for Mode2 / Type1 resources. This means that resources can be allocated without dedicated signaling, which again emphasizes the idea that Msg2 does not need to be changed.

[0536] Cons: Using common resources creates conflicts.

[0537] [Appendix 5] (1. Introduction) RAN2#100 has been accomplished to form a perspective on EDT function, but many details still need further study, one of which is as follows:

[0538] Agreement CP Solution [...] Further consideration is needed as to whether changes to the T300 and mac-contention Resolution Timer are necessary.

[0539] Further consideration of timer aspects is considered in this appendix.

[0540] (2. Consideration) (2.1.Premise) During the discussion, it appears to be a common understanding that the EDT procedure begins with a UL EDT, e.g., upper layer sensor data, and ends with a DL EDT, e.g., a corresponding upper layer ACK, i.e., an upper layer round trip, within the EDT procedure (i.e., see “Complete EDT Procedure” in FIG. 26).

[0541] Observation 1: Common EDT procedures include UL EDT and DL EDT (within the random access procedure).

[0542] On the other hand, the UL-only EDT procedure and / or the DL-only EDT procedure is also useful in the following cases (see FIG. 26).

[0543] UDP type data transmission, i.e., no higher layer ACK.

[0544] Longer delay in upper layer round trip, i.e., upper layer ACK requires a certain amount of time before response.

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

[0546] The DL data in Msg4 is transmitted as CCCH SDUs, regardless of CP / UP, since in the case of CP solution the NAS PDU data in DL may be encapsulated or optionally encapsulated in the RRC message sent in Msg4, and in the case of UP solution the DL data can be optionally multiplexed with the MAC of Msg4 (i.e. DCCH (RRC message) and DTCH (UP data)).

[0547] Observation 2: UL-only EDT procedures are supported under current agreements.

[0548] On the other hand, for DL-EDT transmission, 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 capability, so based on the current agreements, support for DL-only EDT procedure is still unknown.

[0549] Proposal 1: RAN2 should consider whether DL-only EDT procedures are supported.

[0550] (2.2.T300 and Contention Resolution Timers) (2.2.1.Msg4 Delay Issue) In the current specification, there are two timers between Msg3 and Msg4 in RRC: T300 and mac-Contention Resolution Timer in MAC. The value of T300 is 100ms-2000ms in LTE and 2500ms-60000ms in NB-IoT. The value of mac-ContentionResolutionTimer is different: sf8-sf64 in LTE and pp1-pp64 in NB-IoT. When these timers expire, the UE considers that the RRC connection establishment / resumption or contention resolution, respectively, was not successful. It is still to be determined what the UE behavior should be when these existing timers expire under EDT, but it is also true that the current random access procedure is the baseline for the EDT procedure. Therefore, further consideration regarding the timers is required.

[0551] If sensor data is sent via UL EDT and the corresponding TCP ACK is sent via DL EDT (i.e., see “Full EDT procedure” in Figure 26), the Msg4 transmission in the EDT procedure will likely be the same as the traditional Msg4 that depends on the round trip time from upper layers.

[0552] Observation 3: The duration between Msg3 and Msg4 is likely to exceed the maximum legacy timer due to the round trip time from upper layers.

[0553] Therefore, it is easy to define a longer timer value to prevent unnecessary failures.

[0554] Proposal 2: RAN2 should define a longer value for the timer running between UL EDT on Msg3 and DL EDT on Msg4 for the Full EDT procedure.

[0555] (2.2.2.DRX for receiving Msg4) If proposal 2 is convincing, it is easy to extend the existing T300 and mac-Contention Resolution Timer timer values. However, this would cause additional UE power consumption due to continuous PDCCH monitoring until reception of Msg4, which may be delayed in EDT as described in the previous section. To avoid such unnecessary power consumption, some kind of DRX-like receive mode should be introduced into the EDT procedure.

[0556] For example, for a simple solution, the UE could monitor the PDCCH only in the subframe immediately before the timer expires, i.e., "one-shot" monitoring, which may work better than continuous monitoring for some MTC / NB-IoT use cases, such as high latency communications.

[0557] Proposal 3: RAN2 should consider whether discontinuous reception is acceptable in the EDT procedure (i.e., between the transmission of Msg3 and the reception of Msg4).

[0558] (2.2.3. Setting the timer value) Furthermore, it is questionable how the eNB sets the timer value, because when the TCP ACK arrives from the higher layer message is unknown to the eNB. Assuming there are many UEs implementing various applications in the cell, it is difficult for the eNB to set the appropriate timer value for all UEs.

[0559] Observation 4: Considering that different UEs may use different applications, it is difficult to set an appropriate timer value.

[0560] One possibility is to configure the timers using dedicated signaling in Msg2, but it is still difficult for the eNB to determine the timer values ​​without application layer knowledge. On the other hand, the UE can help to set the appropriate timer values ​​based on its timeout configuration in higher layers. For example, the UE can inform the eNB of its self-configured timer values ​​on Msg3.

[0561] Proposal 4: RAN2 should consider whether the UE is allowed to notify the eNB of the self-configuration timer value on Msg3.

[0562] (2.2.4. Timer definition) If one or more of the above proposals (Proposal 2 to Proposal 4) are convincing, the concept of timers for EDT is different from traditional timers. It is also possible that an EDT-capable UE initiates a legacy RRC connection establishment / resumption, e.g. for larger packet transmissions, so that legacy timers are applicable in this case. In this sense, it is easier to keep the existing timers as they are and define new timers specific to EDT instead of extending existing timers.

[0563] Proposal 5: RAN2 should agree to define a new timer that operates between UL EDT (Msg3 and above) and DL EDT (Msg4 and above) instead of the legacy timer.

[0564] [Appendix 6] (1. Introduction) RAN2#100 has been accomplished to form a perspective on EDT function, but many details still need further study, one of which is as follows:

[0565] Agreement CP Solution [...] Further consideration is needed as to whether changes to the T300 and mac-contention Resolution Timer are necessary.

[0566] Further consideration of timer aspects is considered in this appendix.

[0567] (2. Consideration) (2.1.Premise) Proposal 1: RAN2 should consider whether DL-only EDT procedures are supported.

[0568] (2.2.T300 and Contention Resolution Timers) (2.2.1.Msg4 Delay Issue) Observation 1: The duration between Msg3 and Msg4 in EDT is longer than before due to the round trip time from the upper layer.

[0569] Regarding the mac-Contention Resolution Timer, early contention resolution could be used to prevent the timer expiry. For NB-IoTUE, it was agreed that Rel-14 and later will support early contention resolution, but whether it is optional requires further study.

[0570] Proposal 2: If early contention resolution is supported by EDT-capable NB-IoT UEs, RAN2 should agree that no changes to the mac-Contention Resolution Timer are required.

[0571] As for T300, it is directly affected by the round trip time from the upper layer. It has been proposed to extend the timer value to take into account retransmissions and retransmissions of CE mode B.

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

[0573] Proposal 3: RAN2 should define a longer value for the timer running between ULEDT on Msg3 and DLEDT on Msg4 to prevent unnecessary failures due to the expiration of T300.

[0574] (2.2.2.DRX for receiving Msg4) If proposal 3 is convincing, it is easy to extend the existing T300 timer value. However, this would cause additional UE power consumption due to continuous PDCCH monitoring until reception of Msg4, which may be delayed in EDT as described in the previous section. To avoid such unnecessary power consumption, some kind of DRX-like receive mode should be introduced into the EDT procedure.

[0575] For example, as a simple solution, the UE could monitor the PDCCH only in the subframe immediately before the timer expires, i.e., "one-shot" monitoring, which may work better than continuous monitoring for some MTC / NB-IoT use cases, such as high latency communications

[10] .

[0576] Proposal 4: RAN2 should consider whether discontinuous reception is acceptable in the EDT procedure (i.e., between the transmission of Msg3 and the reception of Msg4).

[0577] (2.2.3. Setting the timer value) Furthermore, it is questionable how the eNB sets the timer value, since it is unknown to the eNB when the TCPACK arrives from the higher layer message. Since it is assumed that there are many UEs in a cell implementing various applications, it is difficult for the eNB to set appropriate timer values ​​for all UEs.

[0578] Observation 2: Considering that different UEs may use different applications, it is difficult to set an appropriate timer value.

[0579] One possibility is to set the timers using dedicated signaling in Msg2, but it is still difficult for the eNB to determine the timer values ​​without application layer knowledge. On the other hand, the UE can help to set the appropriate timer values ​​based on its timeout settings in higher layers. For example, the UE can inform the eNB of its self-configured timer values ​​on Msg3.

[0580] Proposal 5: RAN2 should consider whether the UE is allowed to inform the eNB of the self-configuration timer value on Msg3.

[0581] (2.2.4. Timer definition) If one or more of the above proposals (proposal 3 to 5) are agreeable, the concept of timers for EDT differs from traditional timers. It is also possible that an EDT-capable UE initiates a legacy RRC connection establishment / resumption, e.g. for larger packet transmissions, so that legacy timers are applicable in this case. In this sense, it is easier to keep the existing timers as they are and define new timers specific for EDT instead of extending existing timers.

[0582] Proposal 6: RAN2 should agree to define a new timer that operates between UL EDT (Msg3 and above) and DL EDT (Msg4 and above) instead of the legacy timer.

[0583] [Appendix 7] (1. Introduction) RAN2#101 agreed on the following solution to the UL EDT padding issue:

[0584] Agreement ·EDT UL grants shall always allow the maximum TB size broadcasted in the system information, unless the provided UL grant is a legacy Msg3 one.

[0585] EDT UL grant allows UE to select appropriate TB size, MCS, repetitions, and RU (for NB-IoT) from a set of provided TB sizes based on UL data. How the set of possible TB sizes, MCS, repetitions, and RU (for NB-IoT) is provided (e.g. hard-coded in the specification) needs further study. This is a pending RAN1 confirmation.

[0586] RAN2 assumes 8 possible values ​​of maximum TB size broadcasted in the system information. For each maximum TB size broadcasted, RAN2 assumes that up to 4 possible TB sizes, i.e. blind decoding options, are allowed.

[0587] For eMTC, the reserved bits in the MAC RAR can be used for the EDT functionality of eMTC only if necessary.

[0588] · Capture the above agreement including the agreement on maximum and minimum possible TB size and send LS to RAN1, asking RAN1 to confirm.

[0589] This appendix explores further how the solution works.

[0590] (2. Consideration) The association of TBS in the solution under the current assumptions can be expressed as shown in Figure 32. Figure 32 shows the UL grant size of the EDT and the actual UL transmission.

[0591] From the UE perspective, the UL grant for EDT with four 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 initiate legacy procedures and transition to RRC Connected. Therefore, from the UE perspective, the maximum TBS and the number of blind coding options should be set as high as possible.

[0592] Observation 1: The UE may initiate EDT if the max TBS and / or blind decoding options are a good "fit" for its UL data size.

[0593] In contrast, from the NW's perspective, the maximum TBS should be set to a low value that is practically achievable to minimize resource waste. Therefore, some implementations tend to set the maximum TBS value more conservatively. However, this setting has a direct impact on how many UEs utilize EDT, i.e., whether the NW supports low-power operation of UEs. Since the NW may not be aware of the required UL data size of UEs with various MTC applications, it is still unclear whether the NW implementation has the appropriate means to optimize the maximum TBS and blind decoding options.

[0594] Observation 2: The usefulness of EDT depends on the optimal maximum TBS setting.

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

[0596] Taking into account the above observations, it should be considered whether the UE needs to provide feedback about its intended application (in particular UL data size) as part of the network optimization.

[0597] Before the UE returns to RRC IDLE (e.g., sends RAI), the UE may have the opportunity to inform the eNB of its preferred TBS for EDT as assistance information. The assistance information is meaningful in the following cases:

[0598] Case 1: Similar to BSR, the information can be used as the expected data size of the next EDT, which can be one of the references for changing the SIB settings.

[0599] · Case 2: Similar to UE capabilities, the information may be used to determine whether NCC should be provided to the UE for the next EDT possibility.

[0600] · Case 3: Similar to MDT, the information can be used for statistical analysis and network optimization.

[0601] Therefore, supporting information related to the operation of EDT should be introduced.

[0602] Proposal 1: RAN2 should agree to enable the UE to send assistance information for TBS configuration optimization, e.g., its preferred TBS.

[0603] Furthermore, if the UE falls back to legacy, i.e. after sending an EDT indication for Msg1 and receiving a UL grant for EDT, the UE may still send legacy Msg3, for example because additional UL data was generated by the application. If that case needs to be taken into account, the EDT UL grant should always allow a blind decode option for the legacy Msg3 size in addition to the four agreed options.

[0604] Proposal 2: RAN2 should consider whether EDT UL grants should always allow a legacy Msg3 size blind decode option in addition to the four agreed options.

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

Claims

1. 1. A communication method comprising: a user equipment in a predetermined RRC state in which a UE context is held in a network, transmitting, during a random access procedure, a first message to a network node for transmitting uplink user data as a predetermined data transmission during the random access procedure; receiving, after transmitting the first message, from the network node, information to stop the predetermined data transmission together with a second message to maintain the user equipment in the predetermined RRC state; performing the predetermined data transmission at least once by the user equipment after transmitting the first message and before receiving the second message. Communication methods.

2. receiving, by the user equipment, a message including information regarding the predetermined data transmission, for transitioning the user equipment from an RRC connected state to the predetermined RRC state; The user equipment transitions from the RRC connected state to the predetermined RRC state in response to receiving the message; The method further includes a step of determining whether or not to perform the predetermined data transmission based on the information included in the message. The communication method according to claim 1 .

3. A user device, A transmitter configured to transmit, during a random access procedure, a first message to a network node, the first message being for transmitting uplink user data as a predetermined data transmission during the random access procedure, when the user equipment is in a predetermined RRC state in which a UE context is held in a network; a receiving unit configured to receive, after transmitting the first message, information for stopping the predetermined data transmission from the network node together with a second message for maintaining the user equipment in the predetermined RRC state; a control unit that performs the predetermined data transmission at least once after transmitting the first message and before receiving the second message. User equipment.

4. A chipset for controlling a user device, comprising: a process of transmitting, during a random access procedure, a first message to a network node, for transmitting uplink user data as a predetermined data transmission during the random access procedure, when the user equipment is in a predetermined RRC state in which a UE context is held in a network; receiving, after transmitting the first message, information for stopping the predetermined data transmission from the network node together with a second message for maintaining the user equipment in the predetermined RRC state; performing the predetermined data transmission at least once after transmitting the first message and before receiving the second message; Chipset.

5. A network node, A receiving unit that receives, during a random access procedure, a first message for transmitting uplink user data as a predetermined data transmission during the random access procedure from a user equipment in a predetermined RRC state in which a UE context is held in a network; A transmission unit that transmits, after receiving the first message, information for stopping the predetermined data transmission to the user equipment together with a second message for maintaining the user equipment in the predetermined RRC state, The receiver receives the predetermined data transmission at least once after receiving the first message and before transmitting the second message. Network node.

6. A user device includes: a process of transmitting, during a random access procedure, a first message to a network node, for transmitting uplink user data as a predetermined data transmission during the random access procedure, when the user equipment is in a predetermined RRC state in which a UE context is held in a network; receiving, after transmitting the first message, information for stopping the predetermined data transmission from the network node together with a second message for maintaining the user equipment in the predetermined RRC state; performing the predetermined data transmission at least once after transmitting the first message and before receiving the second message. program.

7. A system comprising a user equipment and a network node, The user device includes: When the user equipment is in a predetermined RRC state in which a UE context is held in a network, during a random access procedure, a first message is sent to the network node for sending uplink user data as a predetermined data transmission during the random access procedure; receiving, after transmitting the first message, information to stop the predetermined data transmission together with a second message to maintain the user equipment in the predetermined RRC state from the network node; After transmitting the first message and before receiving the second message, the predetermined data transmission is performed at least once. system.

Images