Patent Description:
There has been a lot of work in 3GPP on specifying technologies to cover Machine-to-Machine (M2M) and/or Internet of Things (IoT) related use cases. Most recent work for 3GPP Release <NUM>, <NUM> and <NUM> includes enhancements to support Machine-Type Communications (MTC) with new UE categories (Cat-M1, Cat-M2), supporting reduced bandwidth of up to <NUM> and <NUM> physical resource blocks (PRBs), and Narrowband loT (NB-loT) UEs providing a new radio interface (and UE categories Cat-NB1 and Cat-NB2).

LTE enhancements introduced in 3GPP Release <NUM>, <NUM>, and <NUM> for MTC may be referred to as "eMTC", including (not limiting) support for bandwidth limited UEs, Cat-M1, and support for coverage enhancements. This is to separate discussions from NB-loT (notation here used for any Release), although the supported features are similar on a general level.

For both eMTC and NB-loT, `CIoT EPS UP optimization' and 'CloT EPS CP optimization' signaling reductions were also introduced in Rel-<NUM>. The former, here referred to as UP-solution, allows the UE to resume a previously stored RRC connection (thus also known as RRC Suspend/Resume). The latter, here referred to as CP-solution, allows the transmission of user-plane data over NAS (aka DoNAS).

There are multiple differences between "legacy" LTE and the procedures and channels defined for eMTC and for NB-loT. Some important differences include a new physical channel, such as the physical downlink control channels, called MPDCCH in eMTC and NPDCCH in NB-loT, and a new physical random access channel, NPRACH, for NB-loT. Another important difference is the coverage level (also known as coverage enhancement level) that these technologies can support. By applying repetitions to the transmitted signals and channels, both eMTC and NB-loT allow UE operation down to much lower SNR level compared to LTE, i.e. Es/Iot≥-<NUM> dB being the lowest operating point for eMTC and NB-loT which can be compared to - <NUM> dB Es/loT for "legacy" LTE.

Uplink transmission efficiency and/or UE power consumption may be improved for LTE-M and NB-loT, by transmitting in preconfigured resources. Transmission may involve the use of preconfigured resources in idle and/or connected mode based on SC-FDMA waveform for UEs with a valid timing advance [RAN1, RAN2, RAN4]. Both shared resources and dedicated resources can be used. Some approaches may be limited to orthogonal (multi) access schemes.

The use of preconfigured uplink resources (PUR) may have some similarities with the use of semi-persistent scheduling (SPS) but extended to Idle mode, to common resources, and/or with considerably longer SPS interval. While dedicated resources (UE-specific) may be used for PUR, there are several problems, for example, with how radio resources are assigned to UEs in RRC_IDLE mode such that the eNB does not even know what UE is in the cell anymore, how the feature is configured, how it can be ensured that radio resources are not wasted, how it can provide an adaptive solution, etc..

<CIT> discloses an uplink data transmission scheme, including sending, by a terminal device to a network device, information used to request a grant-free transmission resource; receiving, by the terminal device, resource indication information sent by the network device, where the resource indication information is used to indicate a grant-free transmission resource that is allocated by the network device to the terminal device according to the information used to request the grant-free transmission resource; and determining, by the terminal device according to the resource indication information,.

Draft 3GPP document <NPL>", is concerned a transmission in preconfigured UL resources.

It is an object of the present invention to mitigate at least some of the problems discussed in the background section.

This object is achieved by the independent claims. Advantageous embodiments are described in the dependent claims and by the following description.

One advantage is that any PUR resource or configuration may be revoked and radio resources may be used for a better purpose. Another advantage of the embodiments is that PUR transmission is enabled in dedicated resources. This will limit the radio resource consumption and allow for a tailor-made solution according to the UEs traffic profile.

<FIG> depicts a method performed by a wireless device. The method includes receiving, during a connected mode in which the wireless device has a connection with the wireless communication network, control signaling indicating a first preconfigured resource configuration that configures a first preconfigured resource (block <NUM>). The method also includes transmitting or receiving user data using the first preconfigured resource (block <NUM>).

The wireless device transmits, in an uplink message, a request for a configuration of preconfigured uplink resources (block <NUM>). In some embodiments, this request may be a <NUM>-bit field. In some embodiments, the request may include one or more preferred parameters for the preconfigured uplink resources.

The method includes after, in conjunction with, or based on use of the first preconfigured resource, receiving control signaling indicating a second preconfigured resource configuration that configures a second preconfigured resource (block <NUM>). The method further includes the wireless device requesting second preconfigured resource configuration after, in conjunction with, or based on use of the first preconfigured resource (block <NUM>).

<FIG> depicts a method performed by a radio network node. The method includes transmitting, during a connected mode in which a wireless device has a connection with the wireless communication network, control signaling indicating a first preconfigured resource configuration that configures a first preconfigured resource (block <NUM>) and transmitting or receiving user data using the first preconfigured resource (block <NUM>).

The network node receives, in an uplink message, a request for a configuration of preconfigured uplink resources (block <NUM>). In some embodiments, this request may be a <NUM>-bit field. In some embodiments, the request may include one or more preferred parameters for the preconfigured uplink resources.

The method includes after, in conjunction with, or based on use of the first preconfigured resource, transmitting control signaling indicating a second preconfigured resource configuration that configures a second preconfigured resource (block <NUM>). The method includes receiving, from the wireless device, a request for the second preconfigured resource configuration after, in conjunction with, or based on use of the first preconfigured resource (block <NUM>).

As used herein, the term "preconfigured resource" (e.g., a preconfigured radio resource) refers to a resource on which a wireless device may transmit without having received a dynamic (and/or explicit) scheduling grant from a radio network node, e.g., on a downlink control channel. A preconfigured resource may be distinguished from a semi-persistent scheduling (SPS) resource in some embodiments, e.g., based on a preconfigured resource either not recurring or recurring with a longer period than an SPS resource. A preconfigured resource may be a resource on which a wireless device may transmit even in idle mode or inactive mode. In the uplink, a preconfigured resource is referred to herein as a preconfigured uplink resource, PUR.

Note that the apparatuses described above may perform the methods herein and any other processing by implementing any functional means, modules, units, or circuitry. For example, the apparatuses comprise respective circuits or circuitry configured to perform the steps shown in the method figures. The circuits or circuitry in this regard may comprise circuits dedicated to performing certain functional processing and/or one or more microprocessors in conjunction with memory. For instance, the circuitry may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory may include program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In embodiments that employ memory, the memory stores program code that, when executed by the one or more processors, carries out the techniques described herein.

<FIG> illustrates an exemplary wireless device <NUM>. As shown, the wireless device <NUM> includes processing circuitry <NUM> and communication circuitry <NUM>. The communication circuitry <NUM> (e.g., radio circuitry) is configured to transmit and/or receive information to and/or from one or more other nodes, e.g., via any communication technology. Such communication may occur via one or more antennas that are either internal or external to the wireless device <NUM>. The processing circuitry <NUM> is configured to perform processing described above, such as by executing instructions stored in memory <NUM>. The processing circuitry <NUM> in this regard may implement certain functional means, units, or modules.

Figure <NUM> illustrates a schematic block diagram of a wireless device <NUM> in a wireless network (for example, the wireless network shown in Figure <NUM>). As shown, the wireless device <NUM> implements various functional means, units, or modules, e.g., via the processing circuitry <NUM> in <FIG> and/or via software code. These functional means, units, or modules, e.g., for implementing the method(s) herein, include for instance: a signaling receiving unit <NUM> configured to receive, during a connected mode in which the wireless device has a connection with the wireless communication network, control signaling indicating a first preconfigured resource configuration that configures a first preconfigured resource and a data transmitting/receiving unit <NUM> configured to transmit or receive user data using the first preconfigured resource.

The signaling receiving unit <NUM> is configured to, after, in conjunction with, or based on use of the first preconfigured resource, receive control signaling indicating a second preconfigured resource configuration that configures a second preconfigured resource. The functional implementation may also include a requesting unit <NUM> configured to request the second preconfigured resource configuration after, in conjunction with, or based on use of the first preconfigured resource.

<FIG> illustrates an exemplary network node <NUM>. The network node <NUM> may be, for example, a radio network node. As shown, the network node <NUM> includes processing circuitry <NUM> and communication circuitry <NUM>. The communication circuitry <NUM> is configured to transmit and/or receive information to and/or from one or more other nodes, e.g., via any communication technology. The processing circuitry <NUM> is configured to perform processing described above, such as by executing instructions stored in memory <NUM>. The processing circuitry <NUM> in this regard may implement certain functional means, units, or modules.

<FIG> illustrates an exemplary schematic block diagram of a network node <NUM> in a wireless network (for example, the wireless network shown in <FIG>). As shown, the network node <NUM> implements various functional means, units, or modules, e.g., via the processing circuitry <NUM> in <FIG> and/or via software code. These functional means, units, or modules, e.g., for implementing the method(s) herein, include for instance: a signaling transmitting unit <NUM> configured to transmit, during a connected mode in which the wireless device has a connection with the wireless communication network, control signaling indicating a first preconfigured resource configuration that configures a first preconfigured resource and a data transmitting/receiving unit <NUM> configured to transmit or receive user data using the first preconfigured resource.

The signaling receiving unit <NUM> is configured to, after, in conjunction with, or based on use of the first preconfigured resource, transmit control signaling indicating a second preconfigured resource configuration that configures a second preconfigured resource. The functional implementation may also include a request receiving unit <NUM> configured to receive, from the wireless device, a request for the second preconfigured resource configuration after, in conjunction with, or based on use of the first preconfigured resource. Additional embodiments will now be described. At least some of these embodiments may be described as applicable in certain contexts and/or wireless network types for illustrative purposes, but the embodiments are similarly applicable in other contexts and/or wireless network types not explicitly described.

MTC traffic is typically very infrequent and one objective of PUR is to preconfigure radio resources for uplink transmission that the UE can immediately use to reduce the signaling overhead for transmission, reduce UE power consumption and improve transmission efficiency (since less radio resources are used). According to the WI-objective the UE must have a valid Timing Advance (TA) to use PUR. Acquiring a TA requires an uplink transmission from the UE, and the feedback from eNB on the timing offset that the UE should apply for subsequent uplink transmissions to be receiving in sync. This is the Timing Advance Command included in the Random Access response in Msg2, and this can also be included later during the connected session by eNB to adjust the TA. Therefore, an initial transmission in the cell is required by the UE and according to some embodiments, either the legacy RRC connection setup or Rel-<NUM> Early Data Transmission (EDT) is used for this purpose. The PUR configuration could then be provided during the initial connection or as a new addition to the EDT process.

A signaling diagram for the configuration is shown in <FIG>. In this example, the UE is configured with PUR via dedicated RRC signaling in the initial transmission in the cell (or group of cells if UE-context can be reused in other cells), the UE goes the RRC_IDLE (or INACTIVE) and then transmits data in the PUR resource at a later point in time. The PUR data transmission would be similar to the Rel-<NUM> EDT data transmission in Msg3 and/or Msg4 and the EDT RRC messages could either be reused or used as baseline for the PUR RRC message versions.

The PUR configuration could allocate one PUR resource at the time, and further PUR resources are configured in the subsequent PUR transmissions, as indicated in <FIG>.

The PUR configuration could also allocate a periodic PUR resource, or a pool of PUR resources, for the UE to use. This is illustrated in <FIG>.

The PUR data transmission could be contention-free. That is, the UE has a dedicated and collision-free radio resource for the transmission. The PUR data transmission can be contention-based. That is, the PUR data transmission is made in a common resource at the risk of collision with data transmission from other UEs. In the case where the PUR resource is dedicated (contention-free), the PUR configuration could be tailor-made to the UE category (e.g. Cat-M2, Cat-NB2) and capabilities (Multi-tone, <NUM> HARQ processes, etc.).

Further, any RAN1 enhancements that will be introduced for PUR could be configured in the PUR configuration. For example, in the cases of dedicated PUR resources, UE-specific parameters for the multiple access such as UE-specific codes, UE-specific tones/subcarrier, etc. could be indicated. Moreover, when the PUR configuration allocates a periodic PUR resource, a "PUR_resource_timer" can be used to indicate the UE for how long the uplink resources for PUR will keep reserved as to avoid a potential waste of resources (e.g., in case the UE has no more to transmit, or if the UE has abandoned the cell).

In various embodiments, the UE only transmits Msg1 and receives Msg2 of the Random Access procedure once and for all in the cell to obtain an initial TA, obtains the PUR configuration, and only Msg3 and Msg4 are transmitted for any subsequent PUR transmission in the cell. The omission of Msg1 and Msg2 will save transmissions and radio resources (i.e., signaling overhead reduction) and improve both uplink transmission efficiency and UE power consumption according to the WI-objective.

In one embodiment, the UE would, in an uplink message, transmit a 'PUR request' or 'PUR configuration request. ' That is, it would be transmitted in an indication to show the eNB that it is in its interest to be configured with PUR. The 'PUR request' or 'PUR configuration request' could be a simple <NUM>-bit indication or a control element including preferred PUR parameters such as PUR transport block size (TBS), PUR RNTI, PUR interval/time-offset, etc. The eNB would respond to this with a 'PUR response'. This, which also could be a control element, includes the eNB decision and a command which PUR-TBS, PUR-interval, RNTI, Multiple Access resource, or Modulation scheme the PUR resource allocation or "PUR UL grant" the UE should apply.

In one embodiment, the PUR is granted for one resource at the time, and PUR data transmission could be accompanied by a further 'PUR request' and 'PUR response'. Such a "chained" approached would reduce the limit the wasted resources assigned to UEs in RRC_IDLE (or INACTIVE state) to one PUR transmission occasion (if the UE leaves the cell or does not transmit for any other reason). In a further add-on to this embodiment, both the UE in 'PUR request' and the network in 'PUR response' can indicate that the message should be interpreted to contain the same information as last time. This may be done in order to reduce the signaling overhead in the case when the PUR preference or parameters are as applicable as last time.

In one embodiment, the 'PUR request' could share (N)PRACH resources similar to dedicated PHY scheduling requests, or it could multiplex the PUR request with PUR data transmission.

In one embodiment, the PUR is granted for a periodic resource and the same PUR resource would be periodically repeated in time unless there is explicit signaling on the contrary. The 'PUR request' and 'PUR response' messages would be used for re-configuring or terminating the periodic PUR resource. In a further embodiment, a "PUR_resource_timer" can be used to indicate the UE for how long time (which can be given in terms of slot, subframes, frames, etc) the uplink resources for PUR will keep reserved as to avoid a potential waste of resources.

In one embodiment, a PUR transmission in idle-mode can include mainly two steps. In a first step, the legacy connection establishment is re-used (e.g., legacy RRC connection setup or Rel-<NUM> Early Data Transmission (EDT)) to acquire the initial TA, and to get in connected-mode a pre-configuration of UL resources (PUR UL grant) that might be used by the UE in future idle mode transmissions. In a second step, after evaluating and fulfilling some criteria (including TA validity), the UE might perform an IDLE mode transmission on pre-configured UL resources directly on Msg3 (i.e., skipping Msg1 and Msg2) by using either a periodic or an on-demand approach.

In one embodiment, the PUR configuration or grant includes any of the following parameters: the time offset/interval, Timing Advance info, the repetition number or Coverage Enhancements level, PUR RNTI, the transport block size, modulation and coding scheme, resource indication for HARQ retransmissions, and/or any other parameters contained in the 'UL grant' according to <NUM>. Optionally, it could be indicated if the resource is contention-based or contention-free.

In one embodiment, the 'PUR response' includes a Timing Advance Command in order to update the Timing Advance applied by the UE.

In one embodiment, the PUR configuration parameters as of above, are added and stored as part of the UE-context (stored in eNB for CloT UP-optimization and stored in MME for CloT CP-optimization).

In one embodiment, the PUR resources are granted for certain time. That is, the UE is configured with a timer as part of the PUR configuration and the UE is only allowed to use the PUR resources as long as this timer has not expired.

In one embodiment, the PUR configuration includes parameters that the UE should apply for the PUR transmission. For example, parameters for Multiple Access in the PUR resources, such as a UE-specific code for CDMA, spatial parameters, sub-PRB parameters, a subcarrier allocation (e.g., single-tone and/or multi-tone allocation) that the UE should apply, etc..

In one embodiment, the PUR configuration is an uplink grant (or downlink assignment) with a longer time offset applied.

In one embodiment, the PUR configuration is generic and it would not be clear to the UE if it is a dedicated (contention-free) or common (contention-based) PUR resource. The decision to overload UEs in the same radio resources could then be left to eNB implementation.

In one embodiment, the Rel-<NUM> Early Data Transmission RRC messages for Msg3 and Msg4 are reused, or used as baseline, for the PUR data transmission. Either EDT Short-MAC-I, a new PUR RNTI, I-RNTI, or similar can be used as ResumelD.

In one embodiment, the UE must evaluate to check if its Timing Advance is still valid before transmission in PUR resources. The set of conditions could be based on testing any TA validity mechanism, e.g., detected change in UE position, change is RSRP/RSRQ, etc..

In one embodiment, the PUR configuration for a UE is based on the 'Subscription Based UE Differentiation Information' (see TS <NUM> and <NUM>). For example, the configuration may be based on the parameters: Periodic Time, Battery Indication, Traffic Profile, Stationary Indication, Scheduled Communication Time, etc..

In one embodiment, the PUR resources are available to the UE independent of whether it resides in RRC_IDLE or RRC_CONNECTED. In this way, the per-request/one-PUR-at-the-time solution would be an extension to legacy SPS operation in RRC_CONNECTED.

In one embodiment, it is up to the network whether to instruct the UE to move to RRC_CONNECTED mode or not after the PUR transmission.

In one embodiment, the UE does not trigger Scheduling Request, Random Access or any other uplink transmission if it has a valid PUR configuration that can be used for the data transmission.

In one embodiment, the UE is configured with a dedicated PUR RNTI which is used for HARQ retransmissions. That is, the eNB can make use of the dedicated PUR RNTI when scheduling retransmissions to allow HARQ soft-combining.

In one embodiment, the UE is configured with a common PUR RNTI and the HARQ retransmissions for PUR transmissions work in the same way as legacy Msg3 transmissions using the Temporary C-RNTI.

In one embodiment, the PUR RNTI is derived from the PUR resource used and from this it would be clear to the UE if it is requested to retransmit. It could be based on, for example, the subframe number, radio frame number, single-tone, subcarrier, carrier, CDMA code, NOMA resource, ResumelD, etc..

In one embodiment, to enable to eNB to schedule retransmissions, the UE is required to monitor (M/N)PDCCH during a (configured) time period with a (configured) DRX cycle after the PUR transmission (possibly with an offset for the start positioning making it a time window).

In one embodiment, the UE still monitors (M/N)PDCCH and is dependent of DCI assignment for PUR transmission. This is illustrated in <FIG>, which is a schematic illustration of DCI-based PUR operation. As compared to other solutions, the PUR configuration is configuring when the UE should monitor (M/N)PDCCH to check for DCI for PUR transmissions. That is, the UE could be configured to monitor (M/N)PDCCH with a certain RNTI (PUR-RNTI etc.) with a certain DRX cycle during a time window, e.g., monitor with DRX of <NUM> during a <NUM> time window in <NUM> after the configuration. In an example for periodic PUR, the UE would simply be configured to monitor (M/N)PDCCH with a certain RNTI and a certain DRX cycle (which could be different from the DRX cycle used for monitoring regular paging). The drawback of this embodiment would be additional signaling overhead and UE power consumption from transmitting and monitoring (M/N)PDCCH. The benefit of this solution is increased network control and it would be straight forward to revoke any resources earlier configured. That is, there would be no additional solution needed for access control, and the UE would reside to legacy (pre Rel-<NUM>) transmission of data if the UE has not received a PUR grant/assignment before a configured number of (N/M)PDCCH occasions or the expiration of a certain timer. This solution would be similar to a long-term or periodic Scheduling Request.

In an alternative embodiment, the semi-static part of the PUR configuration can be indicated in UE-specific RRC signaling and/or in cell-specific system information (signaling). The dynamic part of the PUR configuration can be indicated in the form of an UL grant carried by (M/N)PDCCH or carried by a message similar to a Random Access Response (RAR) message. For example, the semi-static part can indicate the time occasion where the UL grant can be transmitted, and the UL grant can indicate the frequency-domain resource allocation and modulation and coding scheme (MCS). In this case, the eNB performs the access control by sending an appropriate UL grant or by choosing not to send any UL grant. This embodiment provides eNB with a very flexible way to enable or disable UL resources for use as PUR resources.

Although the above description is for preconfigured uplink resources, various embodiments are generalized to also cover the case of preconfigured downlink resources.

Although the subject matter described herein may be implemented in any appropriate type of system using any suitable components, the embodiments disclosed herein are described in relation to a wireless network, such as the example wireless network illustrated in <FIG>. For simplicity, the wireless network of <FIG> only depicts network <NUM>, network nodes <NUM> and 760b, and WDs <NUM>, 710b, and 710c. In practice, a wireless network may further include any additional elements suitable to support communication between wireless devices or between a wireless device and another communication device, such as a landline telephone, a service provider, or any other network node or end device. Of the illustrated components, network node <NUM> and wireless device (WD) <NUM> are depicted with additional detail. The wireless network may provide communication and other types of services to one or more wireless devices to facilitate the wireless devices' access to and/or use of the services provided by, or via, the wireless network.

Thus, particular embodiments of the wireless network may implement communication standards, such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), Narrowband Internet of Things (NB-loT), and/or other suitable <NUM>, <NUM>, <NUM>, or <NUM> standards; wireless local area network (WLAN) standards, such as the IEEE <NUM> standards; and/or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave and/or ZigBee standards.

As used herein, the term "wireless device" (WD) refers to a device capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other wireless devices. Unless otherwise noted, the term WD may be used interchangeably herein with user equipment (UE). Communicating wirelessly may involve transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information through air. In some embodiments, a WD may be configured to transmit and/or receive information without direct human interaction. For instance, a WD may be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the network. Examples of a WD include, but are not limited to, a smart phone, a mobile phone, a cell phone, a voice over IP (VoIP) phone, a wireless local loop phone, a desktop computer, a personal digital assistant (PDA), a wireless cameras, a gaming console or device, a music storage device, a playback appliance, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop-embedded equipment (LEE), a laptop-mounted equipment (LME), a smart device, a wireless customer-premise equipment (CPE). a vehicle-mounted wireless terminal device, etc. A WD may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-everything (V2X) and may in this case be referred to as a D2D communication device. As yet another specific example, in an Internet of Things (IoT) scenario, a WD may represent a machine or other device that performs monitoring and/or measurements, and transmits the results of such monitoring and/or measurements to another WD and/or a network node. The WD may in this case be a machine-to-machine (M2M) device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the WD may be a UE implementing the 3GPP narrow band internet of things (NB-loT) standard. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances (e.g. refrigerators, televisions, etc.) personal wearables (e.g., watches, fitness trackers, etc.). In other scenarios, a WD may represent a vehicle or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation. A WD as described above may represent the endpoint of a wireless connection, in which case the device may be referred to as a wireless terminal. Furthermore, a WD as described above may be mobile, in which case it may also be referred to as a mobile device or a mobile terminal.

WD <NUM> may include multiple sets of one or more of the illustrated components for different wireless technologies supported by WD <NUM>, such as, for example, GSM, WCDMA, LTE, NR, WiFi, WiMAX, NB-loT, or Bluetooth wireless technologies, just to mention a few.

UE <NUM> may be any UE identified by the <NUM>rd Generation Partnership Project (3GPP), including a NB-loT UE, a machine type communication (MTC) UE, and/or an enhanced MTC (eMTC) UE.

Network connection interface <NUM> may be configured to provide a communication interface to network 843a. Network 843a may encompass wired and/or wireless networks such as a local-area network (LAN), a wide-area network (WAN), a computer network, a wireless network, a telecommunications network, another like network or any combination thereof. For example, network 843a may comprise a Wi-Fi network.

In <FIG>, processing circuitry <NUM> may be configured to communicate with network 843b using communication subsystem <NUM>. Network 843a and network 843b may be the same network or networks or different network or networks. Communication subsystem <NUM> may be configured to include one or more transceivers used to communicate with network 843b.

Network 843b may encompass wired and/or wireless networks such as a local-area network (LAN), a wide-area network (WAN), a computer network, a wireless network, a telecommunications network, another like network or any combination thereof. For example, network 843b may be a cellular network, a Wi-Fi network, and/or a near-field network.

In some embodiments, some signalling can be affected with the use of control system <NUM> which may alternatively be used for communication between the hardware nodes <NUM> and radio units <NUM>.

<FIG> illustrates a telecommunication network connected via an intermediate network to a host computer in accordance with some embodiments. In particular, with reference to <FIG>, in accordance with an embodiment, a communication system includes telecommunication network <NUM>, such as a 3GPP-type cellular network, which comprises access network <NUM>, such as a radio access network, and core network <NUM>. Access network <NUM> comprises a plurality of base stations 1012a, 1012b, 1012c, such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 1013a, 1013b, 1013c. Each base station 1012a, 1012b, 1012c is connectable to core network <NUM> over a wired or wireless connection <NUM>. A first UE <NUM> located in coverage area 1013c is configured to wirelessly connect to, or be paged by, the corresponding base station 1012c. A second UE <NUM> in coverage area 1013a is wirelessly connectable to the corresponding base station 1012a.

Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in the preceding paragraphs will now be described with reference to <FIG> illustrates host computer communicating via a base station with a user equipment over a partially wireless connection in accordance with some embodiments In communication system <NUM>, host computer <NUM> comprises hardware <NUM> including communication interface <NUM> configured to set up and maintain a wired or wireless connection with an interface of a different communication device of communication system <NUM>.

It is noted that host computer <NUM>, base station <NUM> and UE <NUM> illustrated in <FIG> may be similar or identical to host computer <NUM>, one of base stations 1012a, 1012b, 1012c and one of UEs <NUM>, <NUM> of <FIG>, respectively.

Wireless connection <NUM> between UE <NUM> and base station <NUM> is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to UE <NUM> using OTT connection <NUM>, in which wireless connection <NUM> forms the last segment. More precisely, the teachings of these embodiments enable any PUR resource or configuration to be revoked and radio resources used for a better purpose. Another advantage of the embodiments is that PUR transmission is enabled in dedicated resources. This will limit the radio resource consumption and allow for a tailor-made solution according to the UEs traffic profile. The embodiments thereby provide benefits such as better capacity, better responsiveness and better battery life.

One objective is to specify the following improvement for machine-type communications for BL/CE UEs:.

This appendix assesses the support of transmissions in pre-configured UL resources, while keeping compliant with the agreements and maintaining the specs impacts and implementation complexity minimized.

"Idle mode based pre-configured UL resources is supported for UEs in possession of a valid TA", which includes two actions for further study "FFS: Validation mechanism for TA" and "FFS: How the pre-configured UL resources is acquired". The subsections below provide a potential framework for transmitting on pre-configured UL resources in IDLE mode, which fulfils the WI objective while keeping the implementation and specification impacts minimized for RAN1 and other Working Groups.

To be able to transmit on pre-configured UL resources in IDLE mode, the UE has to have acquired an initial Timing Advance (TA) and guaranteeing that it is still valid by the time the transmission on pre-configured UL is intended to be performed. The initial timing advance command (which represents the total distance between the UE and the cell) is signalled in the random-access response. Thereafter, once the UE has entered into connected mode, the TA can be adjusted by advancing or delaying the uplink transmission timing.

The above indicates that the first step for a UE that intends to transmit in pre-configured UL resources is to acquire an initial TA, which can be obtained by following the legacy connection establishment. As a second step, and for later occasions in IDLE mode, the UE might benefit from transmitting on pre-configured UL resources if the network has authorized it to do so and the TA it holds is still deemed to be valid. Moreover, to give an answer on the "FFS: How the pre-configured UL resources is acquired", it is necessary to determine the traffic type that it is intended to be assessed by the transmissions over PUR. Depending on it, the PUR uplink resources could for example be acquired periodically or on an on-demand basis.

<FIG> provides an example of a Two-step PUR transmission in IDLE mode, which is composed by the legacy sequence for initial access followed by a PUR configuration in connected mode, plus the actual PUR transmission in idle mode.

Note: While in connected mode the TA might be adjusted, in that case it can be restored by the UE.

Otherwise, the legacy sequence for initial access starts over.

The advantage of following a two-step approach for transmitting in pre-configured uplink resources is that the legacy connection establishment would be re-used, while the actual PUR transmission would benefit from signalling load reductions, power savings and a reduced latency by transmitting directly on "Msg3" of an EDT-like framework, which would help to minimize the impact in RAN1 and other Working Groups (e.g., the EDT security aspects could be inherited).

In a first step the legacy connection establishment is re-used to acquire the initial TA, and to get a pre-configuration of UL resources which might be used by the UE in future idle mode transmissions.

In a second step, after evaluating and fulfilling some criteria (including TA validity) the UE might perform an IDLE mode transmission on pre-configured UL resources directly on Msg3 (i.e., skipping Msg1 and Msg2) by using either a periodic or an on-demand approach.

Performing a PUR transmission directly on Msg3 (i.e., skipping Msg1 and Msg2) would provide signalling load reductions, power savings and a reduced latency, while using an EDT-like frame work to achieve it would help to minimize the impact in RAN1 and other Working Groups.

The two-step PUR transmission scheme for idle-mode can serve either dedicated or shared uplink transmissions. For example, the UL grant design for transmissions over PUR could reuse a sub-PRB allocation to increase the spectral efficiency, in which case up four UEs could share the same PRB. Moreover, HARQ retransmissions could be also supported by re-using the corresponding fields (e.g., HARQ process number, new data indicator) in the DCI used by sub-PRB.

The support of transmissions on pre-configured UL resources in IDLE mode is tied to the condition of being in possession of a valid TA. Thus, once an initial TA has been acquired and thereafter retained by a UE that has stayed or moved back to IDLE mode, there needs to be a mechanism that can be used to determine the validity of such a TA at the moment an IDLE mode transmission on pre-configured UL resources is intended to be performed.

For stationary or low mobility devices a limited change in idle mode serving and neighbour cells signal strength can be expected. Hence, a possible way of determining the validity of a retained TA configuration can be based on identifying the large variations on the idle mode serving and neighbour cells signal strength (RSRP) and quality measurements (RSRQ).

For example, when the UE acquires the initial TA at time instance To, it measures the downlink signal strength RSRP(T<NUM>) and compares it to a configured threshold RSRPTH. If RSRP(T<NUM>) > RSRPTH the device takes this is an indication that it is in proximity to the base station. At a second-time instance T<NUM>, the higher layers in the device triggers an idle mode data transmission, and the device again measures the absolute signal strength RSRP(T<NUM>) of the serving cell to compare it against threshold RSRPTH. If RSRP(T<NUM>) > RSRPTH the device takes this is an indication that it is still in proximity to the base station and assumes that the stored TA(T<NUM>) value, is still valid.

Another possibility could be that the device calculates the change RSRP(T1) - RSRP(T0) in signal strength in the serving cell prior to transmitting idle mode data. The change in the value would be seen as an indication of mobility. If RSRP(T1) - RSRP(T0) is below a configured threshold, the device may assume that its TA(T0) value stored at time instance T<NUM> is still valid, and that can be used to perform an idle mode data transmission.

A device that is stationary, or of low mobility, can be expected to experience a limited change in the time difference of arrival (TDOA) of two or more reference signals received from two or more base stations.

<FIG> illustrates a UE that receives reference signals (RS) A and B transmitted from base stations eNB A and B. Based on the time of arrival (TOA) of each of these reference signals the UE can compute the TDOA between the two reference signals. As each of the TOAs corresponds to the distance between the base station and UE, the TDOA may serve as a strong indicator of mobility. A time variant TDOA indicates mobility, while a time invariant TDOA indicates low or no mobility.

The amount of timing error tolerance provided by the cyclic prefix along with knowing the serving cell's radius can be used to determine the validity of a TA. Recall that <NUM> step TA is equal to 16Ts = <NUM>, which translated to meters is around ((16Ts)( <NUM>))/<NUM>= <NUM>.

For example, in the case of a small cell deployment, when a normal cyclic prefix has been configured (i.e., CP length <NUM>) and the cell radius happens to be Y= <NUM> meters, the TA value that the UE currently holds can be considered to be valid if it is less than a threshold X = <NUM>, which corresponds to ~ <NUM> (The computation of the threshold can be generalized for any cell radius as follows floor(Y/((16Ts c)/<NUM>))).

The above prevents that UEs located near the cell edge on spotty coverage areas transmit in uplink with outdated/incorrect TA values.

It might be possible to determine the TA validity based on previously assigned TA. For example, the eNodeB and/or UE can keep tracking of previous TA values assigned to a particular UE, and based on how often the TA values were updated, the eNodeB can understand whether the UE is stationary or a semi-stationary device. This information can then be used to determine whether the UE is allowed to apply some TA values directly next time it intends to transmit UL data in idle mode without having to acquire a new TA value.

To be more specific, if the TA value that the eNB estimated and assigned to a UE has not been changed for a predetermined time (e. g, can be tens of minutes, several hours or even several days), the eNB and/or network can (temporally) identify the UE as a (semi-)stationary UE, and can assign to it a TA value with long term validity time.

Once the UE obtains a TA, the eNodeB provides a configurable timer (Time Alignment Timer) that can be UE-specific or cell-specific, which is used to control for how long the UE is considered to be uplink time aligned. Similarly, a Time Alignment Timer for idle mode can be introduced, for example in combination with some other TA validity mechanism aiming at providing a periodic TA refresh.

The appendix concerns improving the uplink transmission efficiency and/or UE power consumption by means of transmission in preconfigured resources:.

Due to massive MTC characteristic of small infrequent data, we believe preconfigured uplink resources (PUR) to be most relevant and beneficial in RRC_IDLE. Therefore, there continued discussion is for Idle-PUR unless otherwise mentioned. Connected-PUR is discussed at the end in Section Error! Reference source not found. Further, the use case of uplink reporting is considered in the discussion below. the UE is allowed to use PUR "with a valid timing advance". In legacy operation, in Msg2 the UE obtains the Timing Advance (TA) to apply for uplink transmissions to be received in sync (Timing Advance Command in RAR, see TS <NUM>). The eNB configures the UE with a timer during which it should consider the timing advance to be valid (timeAlignmentTimer in MAC-MainConfig in TS <NUM>), and after the expiration of this timer the UE must again perform random access to obtain a new Timing Advance. Since it is stated that the UE must have a valid TA for Rel-<NUM> PUR, there are two options: <NUM>) the UE is stationary enough to reuse its previous TA, i.e. moving within the length of the cyclic prefix, or <NUM>) the UE moves but constantly updates TA to keep it valid. For option <NUM>) to work, signaling is required. triggering a random access whenever the UE has moved more than what can be covered by the cyclic prefix. In any way uplink transmissions are required, which has a negative impact on the two KPIs the WI-objective tries to improve: UL transmission efficiency and UE power consumption.

Maintaining a valid Timing Advance for mobile UEs in RRC_IDLE is not feasible.

Transmission in preconfigured uplink resources in RRC_IDLE is limited to UEs which can reuse their Timing Advance from previous transmission.

For legacy operation, eNB can base the length of the timeAlignmentTimer on the UEs speed, cell size, etc. Moreover, low mobility UEs will not move very far during the relatively short time in RRC_CONNECTED. For PUR, however, the UE can be in RRC_IDLE for several hours and then return to transmit. A timer-based solution is then not sufficient since eNB has no means to estimate whether the UE's TA will be valid or not when it returns. Therefore, and since the UE will be in RRC_IDLE, there will be a need for requirements on the UE. That is, the UE should fulfil certain conditions to check that the TA is valid before PUR access.

The UE must fulfil certain requirements to ensure its Timing Advance is valid before accessing preconfigured uplink resources.

Furthermore, again based on legacy operation, the UE must transmit at least once in the UL in order to be assigned a TA. That is, in practice PUR will not be applicable for the initial transmission in a cell.

Since the UE must obtain the Timing Advance, transmission in preconfigured uplink resources is not possible for the initial transmission in a cell.

Therefore, a legacy transmission is required for the initial data transmission and the most straight forward solution is to configure PUR via dedicated RRC signalling.

Transmission in preconfigured uplink resources is configured by dedicated RRC signalling.

For the actual data transmission there are potentially a lot of RAN2 open issues. If in general RAN1 agrees on some new physical channel for PUR transmission (potentially supporting only smaller TBSs), RAN2 needs to ensure a solution with working data addressing/routing, working retransmissions, potentially contention resolution, security, etc. This could require a lot of RAN2 work and all protocol layers would have to be looked at; MAC, RLC, PDCP, etc. Transmission in preconfigured uplink resources could potentially have a Iot of RAN2 impact.

However, the data transmission could reuse a lot of work from Rel-<NUM> EDT, where all these issues have been solved. That is, for both solutions considered below, the data transmission part could be done similar to the EDT data transmission in Msg3. Potentially RAN2 could also consider reusing the EDT Msg3 and Msg4 RRC messages or use them as a baseline for new PUR RRC messages. This would resolve all the open issues described above.

Rel-<NUM> EDT Msg3/Msg4 data transmission is used as baseline for transmission in preconfigured uplink resources.

For RAN2 it does not matter if the PUR resource the UE is configured with is a dedicated or shared radio resource. For example, the UE can be assigned a UE-specific code for CDMA in a shared resource. What matters however is if the PUR data transmission is contention-based or contention-free.

For contention-based PUR. as illustrated in <FIG>, the UE would be given a common PUR configuration and TA in the initial access. These common PUR could be selected by any UE and transmitting data there would be at the risk of collision. The configuration is perhaps most motivated as periodic resources, much like how PRACH is configured. In a similar way different CE-levels would have to be supported, and in addition several TBSs, which may make this solution very resource consuming.

Upon data arrival, the UE would select the subsequent periodic PUR to transmit its data. No knowledge of UE predicted traffic would be required. However, transmissions would be performed at the risk of collision, and if no improvements are done at the PHY-layer the collision risk is x64 or x48 compared to legacy for LTE-M and NB-loT, respectively, due to the lack of preamble selection. If it cannot be ensured that the collision risk is lower than for the legacy procedure (i.e. compared to EDT), common-PUR could perform worse than legacy. If so, it is very hard to motive contention-based PUR. Further, according to legacy procedure, the HARQ retransmissions would not be possible in this case since eNB cannot do soft-combining. there is no possiblity to schedule a retransmission or, if the subsequent common-PUR resource is used, to know that it is a retransmission or not. Since the resources are to be used by any UE, there is no possiblity to make use of higher UE capabilities unless the PUR feature is limited to those UEs. Due to this fact, Contention-based PUR is perhaps most well suited for use-cases with sporadic traffic were most often nothing is being transmitted, such as alarms etc. Even then uplink efficiency gains are highly questionable, but UEs would have somewhat reduced power consumption since Msg1 and Msg2 can be omitted. Whether that reduction is noticeable when there is most often no transmission remains to be seen.

Thus, contention-based transmission in preconfigured uplink resources may be justified by use-cases with sporadic and rare transmissions, such as alarms etc..

For contention-free PUR, as illustrated in <FIG>, the UE would be given a dedicated PUR resource and TA in the initial access. The PUR resource could be configured tailor-made to the UEs traffic profile, capabilities and CE-level. In addition, the PUR transmission would be guaranteed to be collision free. Therefore, as long as the configured resources are used, gains in both uplink transmission efficiency and UE power consumption would be ensured. A potential problem is the configuration of dedicated radio resources to UEs in RRC_IDLE mode. That is, eNB does not normally keep track of UEs in RRC_IDLE mode and reserving radio resources for UEs that might no longer be in the cell would rather degrade UL transmission efficiency than to improve it since resources would be wasted. However, there is no reason why periodic resource would have to be reserved. Dedicated-PUR resources could be reserved for one PUR transmission at the time. , only one PUR resource allocated, and later upon that transmission resources are reserved for the next PUR transmission, and so on. This would greatly limit the potential resource waste and make the feature useful to more those use-cases with periodic traffic. Alternatively, the resource reservation could be timer based. There may be the following advantages for dedicated preconfigured uplink resources: Less resource waste, resources assigned only when needed; Adaptive to UE, no additional resource waste from multiple CE-levels, TBSs, etc.; Collision free → guaranteed gains for both UE power consumption & UL Tx efficiency; UE-specific higher data rates possible (i.e. gains from capabilities such as multi-tone, Cat-M2/Cat-NB2, etc.); HARQ retransmissions.

Thus, contention-free PUR ismay be regarded a good solution due to less system overhead and guaranteed gains according to the WI-objective.

Thus, transmission in preconfigured uplink resources is supported in RRC_IDLE in dedicated resources.

For dedicated-PUR some UE-specific parameters would have to be configured over dedicated RRC signalling. These would for example be the PUR interval (i.e. resource time offset), the PUR TBS, any allocation information for the PUR resource, etc. As described above there is big potential benefit with assigning only one PUR resource at the time, and the same principle as for Rel-<NUM> power saving mode (PSM) could be applied. That is, per uplink transmission the UE would request a PUR-interval and PUR-TBS, and the network reply with the configuration parameters the UE should apply. This automatically reduces the resource waste since at most one transmission occasions is wasted if the UE leaves the cell or for other reasons do not transmit in the PUR resource. Further, it is more adaptive if either the TBS or interval should change. The drawback is, of course, the signalling overhead if the interval and TBS should always be the same for some UE. This could however easily be solved by a flag stating that the same interval and TBS as last time should be applied.

Thus, dedicated transmission in preconfigured uplink resources is configured for one transmission occasion at the time.

As illustrated, the UE would be configured during an RRC Connection (or EDT transmission). Both eNB and UE would need to have a common understanding of when the subsequent transmission will occur.

Thus, interval (time resource offset) and TBS are used as configuration parameters for dedicated transmission in preconfigured uplink resources.

The network would then need to store these parameters when the UE moves to RRC_IDLE. For the CloT UP-solution (RRC Suspend/Resume), this would mean adding the PUR parameters to the stored UE context. For the CloT CP-solution (DoNAS), this would mean adding the PUR parameters to the stored UE context in MME. Further, it must also be ensured that the scheduler is aware of all these PUR occasions.

Thus, configuration parameters for preconfigured uplink resources are added to the UE-context.

Above, PUR in RRC_IDLE has been discussed but the WI-objective potentially also includes PUR in RRC_CONNECTED. First, consider common-PUR in Connected. The UE has gone through the random access procedure to obtain a connection and dedicated radio resources for transmission. To then transmit data in common resources at the risk of collision and retransmission is less efficient than to trigger a Scheduling Request.

Dedicated-PUR in Connected, on the other hand, would be very similar to SPS. Note that LTE-M already has support for SPS, whereas for NB-loT no strong need was seen in Rel-<NUM> and SPS support Rel-<NUM> was only introduced for BSR. However, since massive MTC traffic is not perfectly periodic on subframe-level, like VoIP that SPS was originally introduced for, there would still be a need for some PUR modifications of SPS. For example, the configuration of one PUR resource at the time as discussed above for Idle mode.

Transmission in preconfigured uplink resources in RRC_CONNECTED is considered in dedicated resources (contention-free) but not in common resources (contention-based).

In <FIG> an example of a signaling diagram for PUR configuration is given. Note that this is assuming a legacy connection establishment procedure for the initial access in the cell, but as an optimization it may be applicable with EDT as well.

Claim 1:
A method performed by a wireless device configured for use in a wireless communication network, the method comprising:
transmitting (<NUM>), in an uplink message, a request for a preconfigured uplink resource configuration, wherein a preconfigured uplink resource is a resource on which a wireless device may transmit without having received a dynamic and/or explicit scheduling grant from a radio network node;
receiving (<NUM>), during a connected mode in which the wireless device has a connection with the wireless communication network, control signaling indicating a first preconfigured resource configuration that configures a first preconfigured resource;
characterized in that
the first preconfigured resource is a non-recurring preconfigured resource dedicated to the wireless device;
in conjunction with transmitting (<NUM>) user data using the first preconfigured resource requesting (<NUM>) a second preconfigured resource configuration; and
receiving control signaling (<NUM>) indicating a second preconfigured resource configuration that configures a second preconfigured resource, wherein the second preconfigured resource is a non-recurring preconfigured resource dedicated to the wireless device.