CN113228544A

CN113228544A - Retransmission scheme and optimization for preconfigured uplink resources

Info

Publication number: CN113228544A
Application number: CN201980087263.1A
Authority: CN
Inventors: T·蒂罗宁; 隋宇涛; S·N·卡丹维杜; G·A·麦地那阿科斯塔; O·利贝格; J·贝尔格曼; A·霍格隆德
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2018-10-31
Filing date: 2019-10-30
Publication date: 2021-08-06
Anticipated expiration: 2039-10-30
Also published as: US20210392659A1; EP3874645A1; WO2020091676A1; CN113228544B; EP3874645B1

Abstract

Example embodiments include a method for transmitting Uplink (UL) data by a User Equipment (UE) in a Radio Access Network (RAN) using pre-configured uplink resources (PURs). Such a method includes receiving a first PUR configuration from a network node in the RAN and transmitting a first UL data message to the network node based on the first PUR configuration. Such a method also includes receiving a first acknowledgement (PUR ACK) of the first UL data message from the network node. The first PUR ACK indicates whether the first UL data message was received correctly or incorrectly by the network node and includes information related to a subsequent UL transmission using the PUR (e.g., a second PUR configuration, a fallback indication, etc.). Some embodiments further comprise transmitting a second UL data message. Other embodiments include complementary methods performed by a network node, and UE network nodes and UEs configured to perform such methods.

Description

Retransmission scheme and optimization for preconfigured uplink resources

Technical Field

The present invention relates generally to wireless communication networks, and more particularly to improvements in the operation of very-low-power devices in wireless communication networks.

Background

In general, all terms used herein are to be interpreted according to their ordinary meaning in the relevant art unless a different meaning is clearly given and/or implied from the context in which it is used. All references to a/an/the element, device, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, device, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless the steps are explicitly described as either following or preceding another step, and/or where it is implied that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, where appropriate. Likewise, any advantage of any of the embodiments may apply to any other of the embodiments, and vice versa. Other objects, features and advantages of the appended embodiments will be apparent from the description that follows.

Long Term Evolution (LTE) is a generic term for the so-called fourth generation (4G) radio access technology (umbrella term), also known as evolved UTRAN (E-UTRAN), developed within the third generation partnership project (3 GPP) and initially standardized in release 8 (Rel-8) and release 9 (Rel-9). LTE targets various licensed frequency bands (licensed frequency bands) and is accompanied by improvements in non-radio aspects commonly referred to as System Architecture Evolution (SAE), which includes an Evolved Packet Core (EPC) network. LTE continues to evolve with subsequent releases. One of the features of release 11 is an enhanced physical downlink control channel (ePDCCH) with the goal of increasing capacity and improving spatial reuse of control channel resources, improving inter-cell interference coordination (ICIC), and supporting transmission diversity and/or antenna beamforming of control channels.

A general exemplary architecture of a network including LTE and SAE is shown in fig. 1. The E-UTRAN 100 includes one or more evolved node bs (enbs), such as

enbs

105, 110, and 115, and one or more User Equipments (UEs), such as UE 120. As used within the 3GPP specifications, "user equipment" (or "UE") may refer to any wireless communication device (e.g., a smartphone or computing device) capable of communicating with network equipment conforming to the 3GPP standards, including in some cases E-UTRAN and earlier generation RANs (e.g., UTRAN/"3G" and/or GERAN/"2G") and later generation RANs.

As specified by 3GPP, the E-UTRAN 100 is responsible for all radio related functions in the network, including radio bearer control (radio bearer control), radio admission control (radio admission control), radio mobility control, scheduling, dynamic allocation of resources to UEs in the Uplink (UL) and Downlink (DL), and security of communications with the UEs. These functions reside in enbs (such as

enbs

105, 110 and 115) that communicate with each other via the X1 interface. The eNB is also responsible for the E-UTRAN interface to the EPC 130, and in particular the S1 interface to the Mobility Management Entity (MME) and Serving Gateway (SGW) shown collectively in fig. 1 as MME/S-GW 134 and 138.

In general, the MME/S-GW handles both overall control of the UE and data flow between the UE (such as UE 120) and the rest of the EPC. More specifically, the MME handles signaling (e.g., control plane CP) protocols between the UE and the EPC 130, which are referred to as non-access stratum (NAS) protocols. The S-GW handles all Internet Protocol (IP) data packets (e.g., user plane UP) between the UE and EPC 130 and acts as a local mobility anchor (local mobility anchor) for data bearers as the UE moves between enbs, such as

enbs

105, 110 and 115.

The EPC 130 may also include a Home Subscriber Server (HSS) 131, which manages user and Subscriber related information. HSS 131 may also provide support functions in mobility management, call and session setup, user authentication, and access authorization. The function of the HSS 131 may be related to the function of a legacy (legacy) Home Location Register (HLR) and an authentication center (AuC) function or operation.

In some embodiments, HSS 131 may communicate with a User Data Repository (UDR) (labeled EPC-UDR 135 in fig. 1) via a Ud interface. The EPC-UDR 135 may store the user credentials after they have been encrypted by the AuC algorithm. These algorithms are not standardized (i.e., vendor specific) so that the encryption credentials stored in EPC-UDR 135 are not accessible to any other vendor than the vendor of HSS 131.

Fig. 2A shows a high-level block diagram of an exemplary LTE architecture in terms of the constituent entities (UE, E-UTRAN and EPC) of the exemplary LTE architecture and high-level functionality divided into an Access Stratum (AS) and a non-access stratum (NAS). Fig. 2A also illustrates two specific interface points, namely Uu (UE/E-UTRAN radio interface) and S1 (E-UTRAN/EPC interface), each using a specific set of protocols, namely a radio protocol and a S1 protocol. Each of these two protocols may be further partitioned into user plane (or "U-plane") and control plane (or "C-plane") protocol functionality. On the Uu interface, the U-plane carries (carry) user information (e.g., data packets), while the C-plane carries control information between the UE and the E-UTRAN.

Fig. 2B illustrates a block diagram of an exemplary C-plane protocol stack over the Uu interface, including a Physical (PHY) layer, a Medium Access Control (MAC) layer, a Radio Link Control (RLC) layer, a Packet Data Convergence Protocol (PDCP) layer, and a Radio Resource Control (RRC) layer. The PHY layer relates to how and what characteristics are used to transfer (transfer) data over a transport channel over the LTE radio interface. The MAC layer provides data transfer services on logical channels, maps the logical channels to PHY transport channels, and reallocates PHY resources to support these services. The RLC layer provides error detection and/or correction, concatenation (concatenation), segmentation, and reassembly, reordering of data transferred to or from an upper layer. The PHY, MAC and RLC layers perform the same functions for both the U-plane and the C-plane. The PDCP layer provides ciphering/deciphering and integrity protection for both the U-plane and the C-plane and provides other functions for the U-plane, such as header compression.

Fig. 2C shows a block diagram of an exemplary LTE radio interface protocol architecture from the perspective of PHY. The interface between the various layers is provided by Service Access Points (SAPs) indicated by ovals in fig. 2C. The PHY layer interfaces with the MAC and RRC protocol layers described above. The MAC provides different logical channels to the RLC protocol layer (also described above) characterized by the type of information transferred, while the PHY provides transport channels to the MAC characterized by how the information is transferred over the radio interface. In providing such transport services, the PHY performs various functions including: error detection and correction; mapping and rate matching of the coded transport channel onto the physical channel; power weighting, modulation and demodulation of physical channels; transmission diversity; beamforming Multiple Input Multiple Output (MIMO) antenna processing; and provide radio measurements to higher layers, such as RRC.

In general, a physical channel corresponds to a set of resource elements that carry information originating from higher layers. The downlink (i.e., eNB to UE) physical channels provided by the LTE PHY include a Physical Downlink Shared Channel (PDSCH), a Physical Multicast Channel (PMCH), a Physical Downlink Control Channel (PDCCH), a relay physical downlink control channel (R-PDCCH), a Physical Broadcast Channel (PBCH), a Physical Control Format Indicator Channel (PCFICH), and a physical hybrid ARQ indicator channel (PHICH). Further, the LTE PHY downlink includes various reference signals, synchronization signals, and discovery signals.

The PDSCH is the primary physical channel for unicast downlink data transmission and is used to transmit RAR (random access response), certain system information blocks, and paging information. The PBCH carries basic system information required by the UE to access the network. The PDCCH is used to transmit Downlink Control Information (DCI) that carries scheduling information for DL messages on the PDSCH and grants for UL transmissions on the PUSCH.

The uplink (i.e., UE to eNB) physical channels provided by the LTE PHY include a Physical Uplink Shared Channel (PUSCH), a Physical Uplink Control Channel (PUCCH), and a Physical Random Access Channel (PRACH). Further, the LTE PHY uplink includes various reference signals including: demodulation reference signals (DM-RSs) transmitted to help the eNB receive the associated PUCCH or PUSCH; and Sounding Reference Signals (SRS) not associated with any uplink channel.

The PUSCH is an uplink counterpart of the PDSCH. The UE transmits uplink control information including HARQ acknowledgement, channel state information report, etc. using PUCCH. The PRACH is used for random access preamble transmission.

The multiple access scheme of LTE PHY is based on Orthogonal Frequency Division Multiplexing (OFDM) with Cyclic Prefix (CP) in downlink and single carrier frequency division multiple access (SC-FDMA) with cyclic prefix in uplink. To support transmission in the paired and unpaired spectrum, the LTE PHY supports both Frequency Division Duplexing (FDD), including both full and half duplex operation, and Time Division Duplexing (TDD). FIG. 3A illustrates for LTE FDD Downlink (DL) operationAn exemplary radio frame structure ("type 1"). The DL radio frame has a fixed duration of 10 ms and consists of 20 slots, labeled 0 to 19, each having a fixed duration of 0.5 ms. A subframe of 1-ms comprises two consecutive slots, wherein a subframeiBy time slot 2iAnd 2i+ 1. Each exemplary FDD DL slot consists of N^DL _symbA plurality of OFDM symbols, each of the OFDM symbols consisting of N_scOne OFDM subcarrier. For subcarrier spacing (SCS) of 15 kHz, N^DL _symbAn exemplary value of (c) may be 7 (with normal CP) or 6 (with extended length CP). N is a radical of_scMay be configurable based on the available channel bandwidth. Since those skilled in the art are familiar with the principles of OFDM, further details are omitted from this description.

As shown in fig. 3A, a combination of specific subcarriers in a specific symbol is referred to as a Resource Element (RE). Each RE is used to transmit a certain number of bits, depending on the type of modulation and/or bit-mapped constellation used for that RE. For example, some REs may use QPSK modulation to carry two bits, while other REs may use 16-QAM or 64-QAM, respectively, to carry four or six bits. The radio resources of the LTE PHY are also defined in terms of Physical Resource Blocks (PRBs). One PRB in one time slot (i.e., N)^DL _symbOne symbol) across N^RB _scSub-carriers, wherein N^RB _scTypically 12 (in the case of a 15-kHz subcarrier bandwidth) or 24 (7.5-kHz bandwidth). In the whole sub-frame (i.e. 2N)^DL _symbSymbols) spanning the same N^RB _scThe PRBs of the subcarriers are called PRB pairs. Thus, the resources available in a subframe of the LTE PHY DL include N^DL _RBA PRB pair, each of the PRB pairs comprising 2N^DL _symb•N^RB _scAnd (4) RE. For normal CP and 15 KHz SCS, the PRB pair consists of 168 REs.

One exemplary characteristic of a PRB is a contiguously numbered PRB (e.g., a PRB)_iAnd PRB_i+1) Comprising contiguous blocks of subcarriers. For example, in the case of normal CP and sub-carrier bandwidth of 15-KHzUnder the condition of PRB₀Comprising subcarriers 0 to 11, and PRB₁Including subcarriers 12 through 23. LTE PHY resources may also be defined in terms of Virtual Resource Blocks (VRBs) that are the same size as PRBs, but may be of a localized or distributed type. Localized VRBs may be mapped directly to PRBs, such that VRBs n_VRBCorresponding to PRB n_PRB=n_VRB. On the other hand, distributed VRBs may be mapped to non-contiguous PRBs according to various rules, as described in 3GPP Technical Specification (TS) 36.213 or otherwise known to one of ordinary skill in the art. However, the term "PRB" should be used in this disclosure to refer to both physical and virtual resource blocks. Furthermore, unless otherwise specified, the term "PRB" will be used hereinafter to refer to resource blocks, i.e. PRB pairs, within a subframe duration.

Fig. 3B shows an exemplary LTE FDD Uplink (UL) radio frame configured in a similar manner to the exemplary FDD DL radio frame shown in fig. 3A. Using terminology consistent with the DL description above, each UL slot is defined by N^UL _symbA plurality of OFDM symbols, each of the OFDM symbols consisting of N_scOne OFDM subcarrier.

As described above, the LTE PHY maps various DL and UL physical channels to resources shown in fig. 3A and 3B, respectively. For example, the PHICH carries HARQ feedback (e.g., ACK/NAK) for UL transmissions of the UE. Similarly, the PDCCH carries scheduling assignments, channel quality feedback (e.g., CSI) for the UL channel, and other control information. Also, the PUCCH carries uplink control information such as scheduling requests, CSI for downlink channels, HARQ feedback for eNB DL transmissions, and other control information. Both PDCCH and PUCCH can be transmitted on an aggregation of one or several consecutive Control Channel Elements (CCEs), and the CCEs are mapped to physical resources based on Resource Element Groups (REGs), each of which consists of multiple REs. For example, a CCE may include nine (9) REGs, each of which may include four (4) REs.

In LTE, DL transmissions are dynamically scheduled, i.e. in each subframe the base station transmits control information in the current downlink subframe indicating which data to transmit to the UE and on which resource blocks. This control signaling is typically transmitted in the first n OFDM symbols in each subframe, and the number n (= 1, 2, 3, or 4) is referred to as the Control Format Indicator (CFI), which is indicated by the PCFICH transmitted in the first symbol of the control region.

Recently, there has been a significant amount of 3GPP standardization activity directed to specifying LTE enhancements to cover machine-to-machine (M2M) and/or internet of things (IoT) related use cases. 3GPP release 13 (Rel-13) and release 14 (Rel-14) include enhancements to the following technologies: machine Type Communication (MTC) with new UE classes (e.g., Cat-M1, Cat-M2) with reduced bandwidth supporting 6 Physical Resource Blocks (PRBs) (or up to 24 PRBs for Cat-M2), and narrowband IoT (NB-IoT) with new NB radio interfaces and corresponding new UE classes (e.g., Cat-NB1 and Cat-NB 2) are supported. In the following discussion, the term "eMTC" is used to distinguish MTC-related LTE enhancements introduced in 3GPP release 13-15 from NB-IoT specific features.

In 3GPP Rel-16, an important objective is to improve transmission efficiency and/or power consumption for UE UL transmissions, which is especially important for NB-IoT UEs and MTC/eMTC UEs. One mechanism for these desired improvements is UE transmission in pre-configured UL resources (PURs) when the UE is in RRC _ IDLE and/or RRC _ CONNECTED states. When using the PUR, the UE does not need to obtain resource allocation for each transmission after failure of initial data transmission using the PUR, thereby reducing energy consumption. Because wireless transmission of data often suffers from errors and packet loss, data retransmission mechanisms are required. However, when using PUR, there is no existing mechanism to facilitate UE retransmission of UL data.

Disclosure of Invention

Embodiments of the present disclosure provide particular improvements to communications between a User Equipment (UE) and a network node in a wireless communications network, such as by facilitating a solution that overcomes the above-described exemplary problems.

Some example embodiments of the present disclosure include methods (e.g., procedures) for transmitting Uplink (UL) data using pre-configured uplink resources (PURs) in a Radio Access Network (RAN). These example methods may be performed by a user equipment (e.g., a UE, a wireless device, an MTC device, an NB-IoT device, a modem, etc., or a component thereof) in communication with a network node (e.g., a base station, an eNB, a gNB, etc., or a component thereof) serving a cell in a RAN.

The example methods may include receiving a first PUR configuration from a network node in a RAN. The example methods may also include transmitting a first UL data message to the network node based on the first PUR configuration. The example methods may also include receiving a first acknowledgement of the first UL data message (PUR ACK) from the network node. The first PUR ACK may indicate whether the first UL data message was received correctly or incorrectly by the network node and may include information related to a subsequent UL transmission using the PUR.

In some embodiments, these exemplary methods may further comprise: transmitting a second UL data message to the network node based on information included in the first PUR ACK relating to the subsequent UL transmission. For example, the second UL data message may be different from the first UL data message if the first PUR ACK indicates that the first UL data message was received correctly. Likewise, if the first PUR ACK indicates that the first UL data message was incorrectly received, the second UL data message may be a retransmission of the first UL data message.

In some embodiments, the information related to the subsequent UL transmission may include at least one of:

a timing advance for uplink timing alignment;

allocating transmission resources;

the number of repetitions of the UL data message;

a power control command;

a redundancy version of the UL data message;

modulation and coding scheme of UL data messages; and

transport block size of UL data message.

In some embodiments, the information related to the subsequent UL transmission may include a second PUR configuration and transmit a second UL data message (based on the second PUR configuration). In some embodiments, for example, the information related to the subsequent UL transmission may include one or more physical layer (PHY) parameters in addition to or in place of the parameters including the second PUR configuration. In such embodiments, the second UL data message may be transmitted based on one or more PHY parameters.

In some embodiments, both the first PUR configuration and the second PUR configuration may be one of: a dedicated PUR configuration, a contention-free shared (CFS) PUR configuration, or a contention-based shared (CBS) PUR configuration. In some embodiments, the second PUR configuration may be the same as the first PUR configuration.

In some embodiments, both the first PUR configuration and the second PUR configuration may be contention-based shared (CBS) PUR configurations. In such embodiments, the second PUR configuration may identify a first portion of the one or more transmission time windows that may be used for initial transmission of the UL data message and a second portion of the one or more transmission time windows that is reserved for retransmission of the UL data message. An example of such an embodiment is shown in fig. 5.

In some embodiments, if the first PUR ACK indicates that the first UL data message was incorrectly received by the network node, the second UL data message may be transmitted according to a fallback procedure. In other embodiments, these exemplary methods may further comprise: transmitting a third UL data message according to a fallback procedure if the second PUR ACK is not received within a predetermined time after transmitting the second UL data message.

In some embodiments, the information related to the subsequent UL transmission may include an indication that the UE should use a fallback procedure for transmitting one or more subsequent UL data messages (e.g., a second UL data message or a third UL data message). In some embodiments, the indication further indicates that the UE should use a fallback procedure for transmitting all subsequent UL data messages. In some embodiments, the fallback procedure comprises a conventional random access procedure or an Early Data Transmission (EDT) procedure (e.g., such as standardized in 3GPP Rel-15).

In some embodiments, a first value of a transmission parameter may be used when transmitting a first UL data message, and a second value of the transmission parameter is used when transmitting a subsequent UL data message according to a fallback procedure. As described above, the subsequent UL data message may be the second UL data message or the third UL data message.

In some embodiments, transmitting the first UL data message may include determining a first value of a transmission parameter based on one or more first criteria (criteria). Likewise, transmitting the subsequent UL data message may include determining a second value of the transmission parameter based on one or more second criteria. In some embodiments, the second criterion is based on the first criterion and a respective predetermined offset. In some embodiments, the second criterion includes one or more criteria not included in the first criterion. In some embodiments, the transmission parameter evaluated according to the first and second criteria may be a Timing Advance (TA) or a transmission power level for transmission timing alignment.

In some embodiments, the first PUR ACK may be received as one of: DCI; hybrid arq (harq) acknowledgement messages; or a Radio Link Control (RLC) acknowledge message. In some embodiments, if the first PUR ACK indicates that the first UL data message was incorrectly received, the information related to the subsequent UL transmission (e.g., included within the first PUR ACK) includes an allocation of dedicated resources for retransmission of the first UL data message.

In some embodiments, the first UL data message may include a request for resources to transmit a Buffer Status Report (BSR) or a Scheduling Request (SR). In such embodiments, the first PUR ACK includes an allocation of dedicated resources for transmission of the BSR or SR.

Other example embodiments of the present disclosure include methods (e.g., procedures) for receiving, in a Radio Access Network (RAN), Uplink (UL) data transmitted by one or more User Equipments (UEs) using Preconfigured Uplink Resources (PURs). These example methods may be performed by a network node (e.g., a base station, an eNB, a gNB, etc., or components thereof) in communication with one or more user equipments (UEs, e.g., wireless devices, MTC devices, NB-IoT devices, modems, etc., or components thereof) via a cell in a RAN.

The example methods may include transmitting a first PUR configuration to a UE. The example methods may also include receiving a first UL data message from the UE based on the first PUR configuration. The example methods may also include transmitting a first acknowledgement of the first UL data message to the UE (PUR ACK). The first PUR ACK may indicate whether the first UL data message was received correctly or incorrectly by the network node and may include information related to a subsequent UL transmission using the PUR.

In some embodiments, these exemplary methods may further comprise: receiving a second UL data message from the UE based on information included in the first PUR ACK relating to a subsequent UL transmission. For example, the second UL data message may be different from the first UL data message if the first PUR ACK indicates that the first UL data message was received correctly. Likewise, if the first PUR ACK indicates that the first UL data message was incorrectly received, the second UL data message may be a retransmission of the first UL data message.

In some embodiments, the information related to the subsequent UL transmission using the PUR may include at least one of:

a timing advance for uplink timing alignment;

allocating transmission resources;

the number of repetitions of the UL data message;

a power control command;

a redundancy version of the UL data message;

modulation and coding scheme of UL data messages; and

transport block size of UL data message.

In some embodiments, the information related to the subsequent UL transmission includes a second PUR configuration, and the second UL data message may be received based on the second PUR configuration. In some embodiments, for example, the information related to the subsequent UL transmission may include one or more physical layer (PHY) parameters in addition to or in place of the parameters including the second PUR configuration.

In some embodiments, the first PUR ACK may be transmitted as one of: DCI; a HARQ acknowledgement message; or an RLC acknowledgement message. In some embodiments, if the first PUR ACK indicates that the first UL data message was incorrectly received, the information related to the subsequent UL transmission (e.g., included within the first PUR ACK) may include one of: an indication of a fallback procedure for the UE; or an allocation of dedicated resources for retransmission of the first UL data message. In some embodiments, the fallback procedure may be a legacy random access procedure or an EDT procedure (e.g., such as standardized in 3GPP Rel-15).

In some embodiments, the first UL data message may include a request for resources to transmit a Buffer Status Report (BSR) or a Scheduling Request (SR). In such embodiments, the first PUR ACK may include an allocation of dedicated resources for transmission of the BSR or SR.

Other example embodiments include a user equipment (UE, e.g., a wireless device, MTC device, NB-IoT device, or a component thereof, such as a modem) or a network node (e.g., a base station, eNB, gNB, MME, AMF, SMF, etc., or a component thereof) configured to perform operations corresponding to any of the example methods and/or processes described herein. Other example embodiments include a non-transitory computer-readable medium storing program instructions that, when executed by processing circuitry, configure such a UE or network node to perform operations corresponding to any of the example methods and/or processes described herein.

These and other objects, features and advantages of embodiments of the present disclosure will become apparent upon reading the following detailed description in view of the drawings, which are briefly described below.

Drawings

Fig. 1 is a high-level block diagram of an exemplary architecture of a Long Term Evolution (LTE) evolved UTRAN (E-UTRAN) and Evolved Packet Core (EPC) network as standardized by the 3 GPP.

Fig. 2A is a high-level block diagram of an exemplary E-UTRAN architecture in terms of the constituent components, protocols, and interfaces of the E-UTRAN architecture.

FIG. 2B is a block diagram of exemplary protocol layers of a control plane portion of a radio (Uu) interface between a User Equipment (UE) and an E-UTRAN.

Fig. 2C is a block diagram of an exemplary LTE radio interface protocol architecture from the perspective of the PHY layer.

Fig. 3A and 3B are block diagrams of exemplary downlink and uplink LTE radio frame structures, respectively, for Frequency Division Duplex (FDD) operation;

fig. 4 illustrates a timeline of various exemplary messages exchanged between a UE and an eNB, according to various exemplary embodiments of the present disclosure.

Fig. 5 illustrates an example arrangement in which a first pre-configured uplink resource (PUR) in each transmission window is available for initial transmission and the remaining PURs in each transmission window are reserved for retransmission, according to various example embodiments of the present disclosure.

Fig. 6 shows a high-level view of an exemplary 5G network architecture.

Fig. 7 illustrates a flow diagram of an example method (e.g., process) performed by a user equipment (UE, e.g., a wireless device, MTC device, NB-IoT device, modem, etc., or a component thereof) in accordance with various example embodiments of the present disclosure.

Fig. 8 illustrates a flow diagram of an example method (e.g., process) performed by a network node (e.g., a base station, a gNB, an eNB, an MME, an AMF, an SMF, etc., or a component thereof) in a Radio Access Network (RAN), according to various example embodiments of the present disclosure.

Fig. 9 illustrates a block diagram of an example wireless device or UE in accordance with various example embodiments of the present disclosure.

Fig. 10 illustrates a block diagram of an example network node, according to various example embodiments of the present disclosure.

Fig. 11 illustrates a block diagram of an exemplary network configured to provide over-the-top (OTT) data services between a host computer and a UE, in accordance with various exemplary embodiments of the present disclosure.

Detailed Description

Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. However, other embodiments are included within the scope of the subject matter disclosed herein, and the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art. Further, throughout the description given below, the following terms are used:

the radio node: as used herein, a "radio node" may be a "radio access node" or a "wireless device".

A radio access node: a "radio access node" (or equivalently a "radio network node", "radio access network node" or "RAN node") as used herein may be any node in a Radio Access Network (RAN) of a cellular communication network that operates to wirelessly transmit and/or receive signals. Some examples of radio access nodes include, but are not limited to: base stations (e.g., NR base stations (gbbs) in 3GPP fifth generation (5G) new air interface (NR) networks or enhanced or evolved node bs (enbs) in 3GPP LTE networks), base station distributed components (e.g., CUs and DUs), high power or macro base stations, low power base stations (e.g., micro base stations)A pico, femto, or home base station, etc.), an Integrated Access Backhaul (IAB) node, a transmission point, a remote radio unit (RRU or RRH), and a relay node.

A core network node: as used herein, a "core network node" is any type of node in a core network. Some examples of core network nodes include, for example, a Mobility Management Entity (MME), a Serving Gateway (SGW), a packet data network gateway (P-GW), an access and mobility management function (AMF), a session management function (AMF), a User Plane Function (UPF), a Service Capability Exposure Function (SCEF), and so forth.

A wireless device: as used herein, a "wireless device" (or simply "WD") is any type of device that has access to (i.e., is served by) a cellular communication network by wirelessly communicating with a network node and/or other wireless devices. Wirelessly communicating may involve transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for communicating information over the air. Unless otherwise indicated, the term "wireless device" is used interchangeably herein with "user equipment" (or simply "UE"). Some examples of wireless devices include, but are not limited to, smart phones, mobile phones, cellular phones, voice over IP (VoIP) phones, wireless local loop phones, desktop computers, Personal Digital Assistants (PDAs), wireless cameras, gaming consoles or devices, music storage devices, playback appliances, wearable devices, wireless endpoints, mobile stations, tablets, laptop computers, Laptop Embedded Equipment (LEEs), laptop installation equipment (LMEs), smart devices, wireless Customer Premises Equipment (CPE), mobile communication (MTC) devices, internet of things (IoT) devices, vehicle-mounted wireless terminalsEnd devices, etc.

A network node: as used herein, a "network node" is a part of a radio access network (e.g. a radio access node or equivalent name discussed above) or a core network (e.g. a core network node discussed above) that is a cellular communication network. Functionally, a network node is a device that is capable, configured, arranged and/or operable to communicate directly or indirectly with a wireless apparatus and/or with other network nodes or devices in a cellular communication network to enable and/or provide wireless access to the wireless apparatus and/or perform other functions (e.g., management) in the cellular communication network.

Note that the description given herein focuses on 3GPP cellular communication systems, and as such, 3GPP terminology or terminology similar to 3GPP terminology is often used. However, the concepts disclosed herein are not limited to 3GPP systems. Furthermore, although the term "cell" is used herein, it should be understood that a beam may be used instead of a cell (particularly with respect to 5G NR) and, as such, the concepts described herein apply equally to both cells and beams.

As briefly mentioned above, when using pre-configured uplink resources (PURs), there is no existing mechanism for data retransmission, e.g. after an initial data transmission failure using the PURs. Since wireless transmission of data often suffers from errors and packet loss, a retransmission scheme is required even in the case of using PUR. This is discussed in more detail below.

There are various differences between "legacy" LTE and the procedures and channels defined for eMTC and NB-IoT. These differences include newly defined physical channels such as a new physical downlink control channel (called MPDCCH in eMTC and NPDCCH in NB-IoT) and a new physical random access channel for NB-IoT (called NPRACH). These differences also include coverage level enhancements. By applying repetition to the transmitted signal and channel, eMTC and NB-IoT both facilitate the UE to operate at a much lower signal-to-noise ratio (SNR, also referred to as Es/IoT) compared to LTE. For example, eMTC and NB-IoT have operating points of Es/Iot ≧ 15dB, whereas "legacy" LTE UEs can only operate as low as-6 dB Es/IoT-a significant 9-dB enhancement.

As briefly mentioned above, in 3GPP Rel-16, an important objective is to improve the transmission efficiency and/or power consumption for UE UL transmissions. For example, in the case of eMTC, approved Work Items (WI) suggest research and, if found beneficial, provision for support of UL transmissions in preconfigured resources in idle and/or connected mode based on SC-FDMA waveforms of UEs with a valid Timing Advance (TA). This pre-configured uplink resource (PUR) assigned to the UE may include time-frequency resources, duration, periodicity, UE-specific DMRS sequences, and so on. The PUR may be assigned to the UE, for example, by RRC signaling from the network.

Some current agreements related to PUR in LTE-M include the following:

1. in idle mode, the UE will consider at least one or more of the following attributes (allowing a combination of multiple attributes) when verifying the TA:

serving cell change (serving cell means cell where the UE is camping)

Time alignment timer for idle mode

Serving cell Reference Signal Received Power (RSRP) change (serving cell refers to the cell in which the UE is camping)

Other attributes to be further studied (FFS):

neighbor cell RSRP change

TDOA for > =2 enbs

TA History

Subscription-based UE differentiation

Not to exclude others (e.g. attributes to be considered for high mobility UEs)

Note that for the FFS attribute, the UE power consumption should be taken into account.

2. Dedicated pre-configured UL resources are defined as PUSCH resources used by a single UE

The PUSCH resources are time-frequency resources; and

dedicated PURs are contention-free.

3. Contention-free shared pre-configured UL resources (CFS PURs) are defined as PUSCH resources used simultaneously by more than one UE.

The PUSCH resource is at least a time-frequency resource; and

CFS PUR is contention-free.

4. Contention-based shared pre-configured UL resources (CBS PURs) are defined as PUSCH resources used simultaneously by more than one UE.

The PUSCH resource is at least a time-frequency resource; and

CBS PUR is contention-based (CBS PUR may require a contention resolution).

5. In idle mode, HARQ is supported for transmissions in dedicated PURs.

A single HARQ process is supported (whether more than one HARQ process FFS is supported).

FFS: design of corresponding MPDCCH search space

6. In idle mode, dedicated PURs are supported.

FFS is supported for CFS PUR.

FFS is supported for CBS PUR.

7. For UL transmissions in pre-configured resources, a fallback mechanism to RACH/EDT procedures is supported.

8. For transmissions in preconfigured UL resources, the RRC idle UE may use the latest TA that passes the verification criteria.

9. The pre-configured UL resources for data transmission are indicated by RRC signaling. At least UE-specific RRC signaling is supported.

Also, some current agreements related to PURs in NB-IoT include:

serving cell change (serving cell means cell where the UE is camping)

Time alignment timer for idle mode

Serving cell NRSRP change (serving cell means cell where UE is camping)

Other attributes of FFS:

neighbor cell NRSRP change

TDOA for > =2 enbs

TA History

Subscription-based UE differentiation

Not to exclude others (e.g. attributes to be considered for high mobility UEs)

2. For transmissions in preconfigured UL resources, the RRC idle UE may use the latest TA that passes the verification criteria.

3. The pre-configured UL resources for data transmission are indicated by RRC signaling. At least UE-specific RRC signaling is supported.

4. The resource configuration includes at least the following:

time domain resource comprising periodicity(s)

Frequency domain resources

TBS (s)/MCS(s)

5. For UL transmissions in pre-configured resources, a fallback mechanism to RACH/EDT procedures is supported.

6. Dedicated pre-configured UL resources are defined as NPUSCH resources used by a single UE

NPUSCH resources are time-frequency resources

The dedicated PUR is contention-free

7. A contention-free shared pre-configured UL resource (CFS PUR) is defined as an NPUSCH resource used by more than one UE simultaneously

The NPUSCH resources are at least time-frequency resources

CFS PUR is contention-free

8. Contention-based shared pre-configured UL resources (CBS PURs) are defined as NPUSCH resources used by more than one UE simultaneously

The NPUSCH resources are at least time-frequency resources

CBS PUR is contention-based (CBS PUR may require a contention resolution)

9. Supporting HARQ for transmissions in dedicated PUR in idle mode

A single HARQ process is supported and,

whether two HARQ processes FFS are supported

FFS: design of corresponding NPDCCH search space

10. In idle mode, dedicated PURs are supported.

FFS is supported for CFS PUR.

FFS is supported for CBS PUR.

Further, for both LTE-M and NB-IoT, agreement is reached with respect to the following terms:

dedicated pre-configured UL resources (dedicated PURs) are defined as contention-free PUSCH time-frequency resources used by a single UE.

Contention-free shared pre-configured UL resources (CFS PURs) are defined as contention-free PUSCH time-frequency resources used simultaneously by more than one UE

Contention-based shared pre-configured UL resources (CBS PURs) are defined as PUSCH resources used simultaneously by more than one UE, which may require contention resolution before being used by a particular UE.

In idle mode, dedicated PURs are supported. Support for CFS PUR and CBS PUR is under further investigation (FFS).

MTC traffic is typically very rare. Conceptually, given a PUR for UL transmission, a UE may use such a PUR for sending MTC UL data after confirming that it still possesses a valid Timing Advance (TA). This reduces and/or eliminates the conventional signaling overhead for acquiring a new TA and thus reduces UE power consumption and improves transmission efficiency since less radio resources are used. The PUR resource may be similar to the PUSCH in the sense that the UE may wake UP and immediately transmit User Plane (UP) data, as long as it has a valid TA.

Accordingly, exemplary embodiments of the present disclosure provide novel, flexible and efficient techniques for retransmitting UL data when an initial transmission using a PUR is received incorrectly (or not at all), e.g., by an eNB. In general, after transmitting UL data using PUR, the UE must wait for an acknowledgement from the eNB (e.g., PUR ACK) for transmitting the data. In various embodiments, the PUR ACK may be sent on the (N/M) PDCCH, or a message on the (N/M) PDCCH may be used to schedule resources for sending the PUR ACK on the (N) PDSCH. In some embodiments, both of these options may be used. However, in general, the UE follows the principles of asynchronous adaptive HARQ, whereby the UE retains transmitted data in the UL buffer until it explicitly receives an instruction from the eNB (e.g., via DCI in the (M/N) PDCCH) to request retransmission of data or to transmit new data.

Note that unless otherwise specified, the terms "acknowledgement" and "PUR ACK" are used herein to refer to both a positive acknowledgement of correct reception and a negative acknowledgement of incorrect reception (i.e., NACK).

Fig. 4 illustrates a timeline of various exemplary messages exchanged between a UE and an eNB, according to various exemplary embodiments of the present disclosure. Although the various messages are shown in a particular sequence, the sequence is merely exemplary such that the sequence may be rearranged, messages may be removed from the sequence, and/or messages may be added to the sequence (e.g., between displayed messages). Further, numbering of the different operations and/or messages making up the sequence is used to facilitate explanation and understanding, rather than suggesting any particular order.

In operation 410, a particular UE (e.g., an MTC UE or an NB-IoT UE) connects to a particular eNB, e.g., the eNB configures the UE with a PUR (i.e., according to a first PUR configuration) for subsequent UL transmission of data when the UE has one of the rare instances of data to transmit. In various embodiments, the first PUR configuration may be dedicated, contention-free shared (CFS) or contention-based shared (CBS). At some future time t1, in operation 420, the UE transmits the first UL data using the PUR received in operation 410. However, the UE may verify that it has a valid TA before performing the transmission in operation 420. In operation 430, after receiving the first data transmitted in operation 420, the eNB transmits a first PUR ACK indicating that the data is correctly received.

In some embodiments, after transmitting the first UL data using the dedicated PUR, CFS PUR, or CBS PUR (e.g., operation 420), the UE waits for a corresponding first PUR ACK from the eNB. If the first PUR ACK is not received after a certain time, the UE may determine a legacy (or "fallback") access method (e.g., Rel-13/14 random access procedure and/or Rel-15 EDT procedure) supported by both the UE and the eNB and access the system using the determined fallback method. The backoff procedure may be triggered by the expiration of a timer (e.g., a backoff timer started at the time of the PUR transmission), at which point the UE will conclude that the transmission was unsuccessful and that a backoff procedure is required. Alternatively, if a PUR ACK has not been received during N (M/N) PDCCH opportunities, the UE may fall back to the legacy procedure, where N is predetermined. Alternatively, if the UE enters Discontinuous Reception (DRX) after a PUR transmission (e.g., operation 420), the back-off timer may be specified for a predetermined number (e.g., N) of DRX-on cycles during which the UE monitors (M/N) the PDCCH.

The PUR ACK (e.g., the first PUR ACK transmitted/received in operation 430) may take various forms. In some embodiments, the PUR ACK may be a conventional HARQ ACK or RLC ACK message. In other embodiments, a new DCI format, message, and/or signal may be defined to include any of the following discussed below with respect to PUR ACK: information, fields, parameters, values, settings, etc.

In some embodiments, the UE waits for a PUR ACK from the eNB for both initial transmission and retransmission of UL data using dedicated PURs, CFS PURs, or CBS PURs. In addition to an indication that a data (re) transmission is (not) correctly received, a PUR ACK may include various information related to subsequent UL transmissions using the PUR. For example, the first PUR ACK may include additional values for any of the following parameters related to subsequent UL transmissions of the UE using PUR:

(one or moreOne) a Timing Advance (TA) value;

updated PUR resource allocation;

the number of repetitions;

a preferred UL reception target;

a power control command;

redundancy version(s) (RV);

modulation and Coding Scheme (MCS);

a Transport Block Size (TBS); and/or

Any other parameters related to the PUR configuration.

Some of the above parameters may be updated values of the parameters provided in the first PUR configuration. Others may be in addition to the first PUR configuration.

After receiving the information, the UE takes the information and applies it to subsequent PUR transmissions, including initial transmissions of data and/or retransmissions of data. For dedicated PURs and CFS PURs, some or all of this received information may be considered as a "second PUR configuration" that overwrites (overrides) the first PUR configuration. In some embodiments, this information may overwrite a previous CBS PUR, which may be common to other UEs sharing that particular CBS PUR. Further, the information may include PHY layer parameters (e.g., RV, MCS, TBS, etc.) that are not strictly associated with the PUR and/or that are not included in the first PUR configuration. The UE may also take these parameters and apply them for subsequent PUR transmissions.

In some embodiments, the UE waits for a PUR ACK from the eNB after the initial transmission of UL data using a dedicated PUR, CFS PUR, or CBS PUR. If the acknowledgement is negative ("NACK") or no acknowledgement is received (indicating, e.g., that the UL transmission was not received by the eNB), the UE re-evaluates the validity of its TA value. The TA re-evaluation of the UE may be based on a second criterion that is stricter than a first criterion for evaluating TA validity prior to initial data transmission using the PUR. Various criteria may be used, including the criteria mentioned above. For example, the eNB may signal both the first criterion and the second criterion in an RRC message. Alternatively, the eNB may signal the first criterion, and the UE may derive the second criterion from the first criterion and one or more offset values. For example, if the TA evaluation is based on a serving cell Reference Signal Received Power (RSRP) change, the first criterion may include an X dB change, while the second criterion (e.g., if the first PUR attempt fails) may include an X- Δ dB change, where offset Δ >0 may be signaled by the network (e.g., via RRC) or explicitly predetermined. In some embodiments, different criteria (e.g., different Δ values) may be used for each successive retransmission attempt.

In some embodiments, TA evaluation may use different methods for initial evaluation (e.g., prior to initial transmission) and re-evaluation after NACK or no acknowledgement. For example, the initial evaluation may be based on RSRP variations, while the re-evaluation may also be based on time difference of arrival (TDOA) and Reference Signal Received Quality (RSRQ) (possibly including signals from more than one cell).

In some embodiments, the UE may also re-evaluate its UL transmission power if the acknowledgement is negative ("NACK") or no acknowledgement is received (indicating, e.g., that the UL transmission was not received by the eNB). This may be particularly important in the case when no acknowledgement is received. Thus, the first criterion and the second criterion may comprise different transmission power values in the same way as the TA discussed above.

In both dedicated PURs and CFS PURs, a UE is assigned resources that exclude resources assigned to other UEs so that data is not lost due to contention with other UEs. Thus, these two techniques may be generally referred to as "contention-free PUR". For CFS PUR, this may often involve another resource dimension than time and frequency, such as the spatial or code domain. Even so, the initial contention-free PUR transmission may not be successful for different reasons, such as insufficient UE UL power, signal fading, or too high code rate (e.g., insufficient redundancy). In some cases, the eNB may not detect the UL signal at all, e.g., due to insufficient received power or too high interference. In some cases, the eNB may detect the UL signal but may not decode the message, e.g., due to a code rate that is too high and/or a TA value error. As such, these different scenarios require different error handling.

In some embodiments, the UE waits for a PUR ACK from the eNB after the initial transmission of UL data using dedicated PURs or CFS PURs. In a PUR ACK, the eNB may indicate that the initial message was received incorrectly and that the UE should use a different "fallback" procedure to access the system, preferably a procedure supported by both the UE and the eNB. For example, such a fallback procedure may include a Rel-13/Rel-14 ("legacy") random access procedure and/or a Rel-15 Early Data Transfer (EDT) procedure.

In some embodiments, the UE waits for a PUR ACK from the eNB after the initial transmission of UL data using dedicated PURs or CFS PURs. In a PUR ACK, the eNB may indicate that the UE is not allowed to use PUR transmission for a certain number of PUR transmission opportunities ("suspended PUR"), or may revoke the UE's PUR configuration ("deactivated PUR").

In some embodiments, in a dedicated PUR or CFS PUR, different Redundancy Versions (RVs) may be used for initial transmission of data and retransmission(s) of the data. The initial transmission may be configured explicitly or implicitly (e.g., during a setup operation in 410) or may be predetermined (e.g., specified in a standard). After transmitting the initial message in the UL, the UE waits for an acknowledgement from the eNB. If the eNB detects a UL transmission but cannot successfully decode the transmission, the eNB may allocate dedicated time-frequency UL resources in the PUR ACK for retransmission. For example, the message carrying the PUR ACK may also include dynamically scheduled DCI for retransmission. In some embodiments, the eNB may indicate a particular RV for retransmission.

Returning to the example in fig. 4, then in operation 440, at some future time t2, the UE transmits a second UL data message using the PUR received in operation 410. If the eNB receives the second UL data message, it responds with a corresponding second PUR ACK in operation 450 in the same manner as in operation 430 discussed above. Further, the eNB may include various information related to subsequent UL transmissions using the PURs discussed above. For example, the eNB may include a parameter update 452, which may include any of the parameters listed above related to subsequent UL transmissions by the UE. In some cases, the information related to the subsequent UL transmission contained in the PUR ACK 450 may identify dedicated time-frequency resources (shown as field "DCI-ReTx 456") for data retransmission. For example, if PUR ACK 450 indicates that the second UL data message sent in 440 was not correctly received by the eNB, this information may be included.

In some embodiments, the information related to the subsequent UL transmission may include a backoff indicator 458 by which the eNB may indicate that the UE should use the backoff procedure(s) to access the network, such as the conventional random access procedure and/or EDT procedure discussed above. Optionally, the fallback indicator 458 may identify the fallback procedure(s).

In some embodiments, the second UL data message for the UE transmitted in operation 440 may include a request for resources to transmit a Buffer Status Report (BSR) and/or a Scheduling Request (SR). This is illustrated in fig. 4 as a "BSR/SR request 442". In such a case, the eNB may include a DCI-BSR/SR field 456 in the second PUR ACK (i.e., the second PUR ACK transmitted in operation 450), the DCI-BSR/SR field 456 identifying the dedicated time-frequency resources for UE transmission of the BSR and/or SR.

It should be noted that if the UE did not receive the first PUR ACK 430, the second UL data message transmitted in operation 440 would be a retransmission of the first UL data message sent in 420. In such a case, the UE may re-evaluate its transmission power and/or TA prior to transmission in operation 440 in the manner discussed above. Likewise, if the first PUR ACK 430 is not received or indicates an incorrect receipt of the first UL data message by the eNB, the UE may retransmit the first UL data message in operation 440 according to a fallback procedure.

Subsequently, at operation 460, at some future time t3, the UE transmits additional UL data using the first PUR configuration received in operation 410 or an updated PUR configuration according to the information received in operation 450. If the transmission in 440 is correctly received as indicated by a positive PUR ACK in operation 450, the additional UL data may be an initial transmission of third UL data. If the transmission in operation 440 is not received correctly as indicated by a negative PUR ACK in operation 450 (described above), the additional UL data may be a retransmission of the second UL data that was initially transmitted in operation 440. In operation 470, the eNB responds with a PUR ACK for the additional UL data transmitted in operation 460. This PUR ACK may be a positive or negative acknowledgement and may include any of the information discussed above with respect to the various embodiments.

With regard to contention-based shared (CBS) PURs, the UE and eNB may generally operate in the same manner as discussed above with regard to contention-free PURs. For example, the eNB may include a parameter update 452 in the PUR ACK that indicates any of additional configuration settings, parameters, and/or values related to the CBS PUR or PHY layer. Nevertheless, some embodiments specific to CBS PURs are discussed in more detail below.

In some embodiments, the UE waits for a PUR ACK from the eNB after the initial transmission of UL data using CBS PUR. In the PUR ACK, the eNB may indicate: the initial data transmission using the CBS PUR is incorrectly received ("NACK"), and the UE(s) assigned to the CBS PUR should use a different CBS PUR configuration, e.g., corresponding to an enhanced coverage level. In some embodiments, the eNB may also indicate, along with the NACK, the TA value, CBS PUR configuration, and/or PHY layer parameters to revoke the particular UE for the initial transmission.

In some embodiments, the UE waits for a PUR ACK from the eNB after the initial transmission of UL data using CBS PUR. In a PUR ACK, the eNB may include additional PUR configurations (e.g., additional time and frequency resources) for any potential retransmissions. The retransmission configuration may include a PUR resource or multiple duplicate PUR resources in a certain retransmission window. Fig. 5 shows an example arrangement in accordance with these embodiments, where a first PUR in each UE transmission window is available for initial transmission and the remaining PURs in each transmission window are reserved for retransmission.

Each contention-free PUR is configured according to the expected traffic periodicity of a particular UE. However, in CBS PUR, the shared PUR is expected to be allocated more frequently than the expected traffic periodicity for any particular UE. In other words, several shared PURs in a transmission window may be used for each UE UL data transmission. In some embodiments, some number of CBS PURs in a transmission window may be allocated for initial data transmission, while the remaining CBS PURs in the transmission window may be reserved for retransmission of data. Fig. 5 shows an example arrangement in which the first PUR in each window is available for initial transmission and the remaining three PURs in each transmission window are reserved for retransmission.

In some embodiments, the eNB may send a contention resolution identity (contention resolution identity) to the UE that resolves contention for the CBS PUR. In such embodiments, the UE may interpret the identity as a (positive) PUR ACK for the initial PUR transmission. This identity may be associated with the UE during configuration of the PUR resources (e.g., operation 410), or it may be the same or similar to the identity used in legacy connections, e.g., C-RNTI, the UE contention resolution identity corresponding to the transmitted CCCH SDU, as specified in 3GPP TS 36.321.

In some embodiments, a new type of contention resolution message sent by the eNB to the UE may be defined to include any of the information discussed above that is included in the PUR ACK. In some embodiments, such a message may also include a contention resolution identity.

Although embodiments have been described above in relation to communication between a UE and an eNB, other embodiments may relate to communication between a UE and different network nodes. For example, the UE may communicate with the MME for PUR using CIoT CP optimization and configuration of PUR parameters.

As another example, for a 5G network, the UE may communicate with the gNB or components thereof (such as the gNB-CU and/or the gNB-DU) as well as other 5GC nodes (such as Access Management Functions (AMFs), Session Management Functions (SMFs)), and so on.

The above embodiments are also applicable to 5G networks. While LTE is primarily designed for user-to-user communications, 5G (also referred to as "NR") networks are envisioned to support both high single-user data rates (e.g., 1 Gb/s) and large-scale machine-to-machine communications involving short burst transmissions from many different devices sharing a frequency bandwidth. The 5G radio standard (also referred to as "new air interface" or "NR") is currently directed to a wide range of data services, including eMBB (enhanced mobile broadband), URLLC (ultra-reliable low-time communication), and Machine Type Communication (MTC). These services may have different requirements and purposes. For example, URLLC aims to provide a system with extremely strict error and latency requirements (e.g., error probability as low as 10^-5Or lower and 1 ms end-to-end delay or lower). For eMBB, the requirements for latency and error probability may be less stringent, while the required supported peak rate and/or spectral efficiency may be higher. In contrast, URLLC requires low latency and high reliability, but the requirements on data rates are less stringent.

One of the solutions for low latency data transmission is a shorter transmission time interval. For NR, in addition to transmission in a slot (such as for LTE, as described above), mini-slot transmission (mini-slot transmission) is allowed to reduce latency. A minislot may consist of any number of OFDM symbols from 1 to 14. It should be noted that the concept of time slots and micro-slots is not specific to a particular service, which means that micro-slots may be used for eMBB, URLLC or other services.

Fig. 6 shows a high-level view of an exemplary 5G network architecture, including a next generation RAN (NG-RAN) 699 and a 5G core network (5 GC) 698. As shown in the figure, the NG-RAN 699 may include a gNB 610 (e.g., 610a, b) and a NG-eNB 620 (e.g., 620a, b) interconnected with each other via respective Xn interfaces. The gNB and NG-eNB are also connected to a 5GC 698 via NG interfaces, more specifically to AMFs (access and mobility management functions) 630 (e.g., AMFs 630a, b) via respective NG-C interfaces and to UPFs (user plane functions) 640 (e.g., UPFs 640a, b) via respective NG-U interfaces.

Each of the gnbs 610 may support an NR radio interface including Frequency Division Duplex (FDD), Time Division Duplex (TDD), or a combination thereof. NG-enbs 620 each support an LTE radio interface and connect to the 5GC via an NG interface, while conventional LTE enbs connect to the EPC via an X2 interface (e.g., as shown in fig. 1).

Each of the gnbs 610a, b shown in fig. 6 may include a central (or centralized) unit (CU or gNB-CU) and one or more distributed (or decentralized) units (DU or gNB-DU). A CU is a logical node that hosts higher layer protocols and performs various gNB functions, such as controlling the operation of DUs. Likewise, the DU is a logical node that hosts lower layer protocols and may include various subsets of the gNB function, depending on the function split. As such, each of the CUs and DUs may include various circuitry required to perform their respective functions, including processing circuitry, transceiver circuitry (e.g., for communication), and power supply circuitry. The gNB-CU is connected to its gNB-DU via a corresponding F1 logical interface.

The above embodiments may be further explained with reference to fig. 7-8, which fig. 7-8 depict exemplary methods (e.g., procedures) performed by a UE and a network node, respectively. In other words, various features of the operations described below correspond to the various embodiments described above.

In particular, fig. 7 shows a flowchart of an example method (e.g., process) for transmitting Uplink (UL) data in a Radio Access Network (RAN) using pre-configured uplink resources (PURs), according to various example embodiments of the present disclosure. An example method may be performed by a user equipment (e.g., a UE, a wireless device, an MTC device, an NB-IoT device, a modem, etc., or a component thereof) in communication with a network node (e.g., a base station, an eNB, a gNB, etc., or a component thereof) serving a cell in a RAN. For example, the exemplary method illustrated in fig. 7 may be implemented in a UE or apparatus configured, for example, in accordance with fig. 9 (described below).

Moreover, the example method shown in fig. 7 may be used in conjunction with other example methods described herein (e.g., fig. 8) to provide various example benefits described herein. Although fig. 7 shows certain blocks in a certain order, the operations of an exemplary method may be performed in an order different than that shown and may be combined and/or separated into blocks having functionality different than that shown. Optional blocks or operations are indicated by dashed lines.

The example method may include operations of block 710, where the UE may receive a first PUR configuration from a network node (e.g., in a RAN). The example method may also include the operation of block 720, wherein the UE may transmit a first UL data message to the network node based on the first PUR configuration. The example method may also include the operation of block 730, wherein the UE may receive a first acknowledgement of the first UL data message (PUR ACK) from the network node. The first PUR ACK may indicate whether the first UL data message was received correctly or incorrectly by the network node and may include information related to a subsequent UL transmission using the PUR.

In some embodiments, the example method may further include the operation of block 740, wherein the UE may transmit a second UL data message to the network node based on the information related to the subsequent UL transmission included in the first PUR ACK. For example, the second UL data message may be different from the first UL data message if the first PUR ACK indicates that the first UL data message was received correctly. Likewise, if the first PUR ACK indicates that the first UL data message was incorrectly received, the second UL data message may be a retransmission of the first UL data message.

a timing advance for uplink timing alignment;

allocating transmission resources;

the number of repetitions of the UL data message;

a power control command;

a redundancy version of the UL data message;

modulation and coding scheme of UL data messages; and

transport block size of UL data message.

In some embodiments, the information related to the subsequent UL transmission comprises a second PUR configuration, and the second UL data message is transmitted based on the second PUR configuration (e.g., in block 740).

In some embodiments, for example, the information related to the subsequent UL transmission may include one or more physical layer (PHY) parameters in addition to or in place of the parameters including the second PUR configuration. In such embodiments, the second UL data message may be transmitted based on one or more PHY parameters.

In some embodiments, the operations of block 740 may include operations of a subframe 741, wherein the UE may transmit a second UL data message according to a fallback procedure if the first PUR ACK indicates that the first UL data message was incorrectly received by the network node. In other embodiments, the example method may further include the operation of block 750, wherein the UE may transmit a third UL data message according to a fallback procedure if the second PUR ACK is not received within a predetermined time after transmitting the second UL data message. However, the skilled person will recognize that if the first PUR ACK is not received in block 730 within a predetermined time after transmitting the first UL data message, the UE may transmit a second UL data message according to a backoff process, assuming that the UE was previously configured (or preconfigured) with a backoff process.

In some embodiments, the information related to the subsequent UL transmission may include an indication that the UE should use a fallback procedure for transmitting one or more subsequent UL data messages (e.g., a second UL data message or a third UL data message). In some embodiments, the indication further indicates that the UE should use a fallback procedure for transmitting all subsequent UL data messages. In some embodiments, the fallback procedure comprises a legacy random access procedure or an Early Data Transmission (EDT) procedure (e.g., such as standardized in 3GPP Rel-15).

In some embodiments, a first value of a transmission parameter may be used when transmitting a first UL data message (e.g., in block 720), and a second value of the transmission parameter is used when transmitting a subsequent UL data message according to a fallback procedure. The subsequent UL data message may be a second UL data message transmitted in subframe 741 or a third UL data message transmitted in block 750.

In some embodiments, transmitting the first UL data message in block 720 may include determining a first value of a transmission parameter based on one or more first criteria (e.g., in subframe 721). Likewise, transmitting the subsequent UL data message (e.g., in subframe 741 or block 750) may include determining a second value of the transmission parameter (e.g., in subframe 741A or 751) based on one or more second criteria. In some embodiments, the second criterion is based on the first criterion and a corresponding predetermined offset (e.g., the offset Δ discussed above). In some embodiments, the second criterion includes one or more criteria not included in the first criterion (e.g., RSRP in the first criterion, TDOA and RSRQ in the second criterion, as discussed above). In some embodiments, the transmission parameter evaluated according to the first and second criteria may be a Timing Advance (TA) or a transmission power level for transmission timing alignment.

In some embodiments, the first PUR ACK may be received as one of: DCI; a HARQ acknowledgement message; or an RLC acknowledgement message. In some embodiments, if the first PUR ACK indicates that the first UL data message was incorrectly received, the information related to the subsequent UL transmission (e.g., included within the first PUR ACK received in block 730) includes an allocation of dedicated resources for retransmission of the first UL data message (e.g., as illustrated by field 456 in fig. 4).

In some embodiments, the first UL data message may include a request for resources to transmit a Buffer Status Report (BSR) or a Scheduling Request (SR) (e.g., as illustrated by field 442 in fig. 4). In such embodiments, the first PUR ACK includes an allocation of dedicated resources for transmission of the BSR or SR (e.g., as illustrated by field 454 in fig. 4).

Further, fig. 8 illustrates a flowchart of an example method (e.g., process) for receiving Uplink (UL) data transmitted by pre-configured uplink resources (PURs) used by one or more User Equipments (UEs) in a Radio Access Network (RAN), according to various example embodiments of the present disclosure. An example method may be performed by a network node (e.g., a base station, an eNB, a gNB, etc., or components thereof) in communication with one or more user equipments (UEs, e.g., wireless devices, MTC devices, NB-IoT devices, modems, etc., or components thereof) via a cell in a RAN. For example, the exemplary method shown in fig. 8 may be performed by a network node configured in accordance with fig. 10 (described below).

Moreover, the example method shown in fig. 8 may be used in conjunction with other example methods described herein (e.g., fig. 7) to provide various example benefits described herein. Although fig. 8 shows certain blocks in a certain order, the operations of an exemplary method may be performed in an order different than that shown and may be combined and/or separated into blocks having functionality different than that shown. Optional blocks or operations are indicated by dashed lines.

The example method illustrated in fig. 8 may include operations of block 810, where a network node may transmit a first PUR configuration to a UE. The example method may also include the operations of block 820, wherein the network node may receive a first UL data message from the UE based on the first PUR configuration. The example method may also include the operation of block 830, wherein the network node may transmit a first acknowledgement of the first UL data message (PUR ACK) to the UE. The first PUR ACK may indicate whether the first UL data message was received correctly or incorrectly by the network node and may include information related to a subsequent UL transmission using the PUR.

In some embodiments, the example method may also include the operation of block 840, where the network node may receive a second UL data message from the UE based on information related to the subsequent UL transmission included in the first PUR ACK. For example, the second UL data message may be different from the first UL data message if the first PUR ACK indicates that the first UL data message was received correctly. Likewise, if the first PUR ACK indicates that the first UL data message was incorrectly received, the second UL data message may be a retransmission of the first UL data message.

a timing advance for uplink timing alignment;

allocating transmission resources;

the number of repetitions of the UL data message;

a power control command;

a redundancy version of the UL data message;

modulation and coding scheme of UL data messages; and

transport block size of UL data message.

In some embodiments, the information related to the subsequent UL transmission includes a second PUR configuration, and the second UL data message is received based on the second PUR configuration (e.g., in block 840).

In some embodiments, the first PUR ACK may be transmitted as one of: DCI; a HARQ acknowledgement message; or an RLC acknowledgement message. In some embodiments, if the first PUR ACK indicates that the first UL data message was incorrectly received, the information related to the subsequent UL transmission (e.g., included within the first PUR ACK transmitted in block 830) may include one of: an indication of a fallback procedure for the UE (e.g., as illustrated by field 458 in fig. 4); or an allocation of dedicated resources for retransmission of the first UL data message (e.g., as illustrated by field 456 in fig. 4). In some embodiments, the fallback procedure may be a legacy random access procedure or an Early Data Transmission (EDT) procedure (e.g., such as standardized in 3GPP Rel-15).

In some embodiments, the first UL data message may include a request for resources to transmit a Buffer Status Report (BSR) or a Scheduling Request (SR) (e.g., as illustrated by field 442 in fig. 4). In such embodiments, the first PUR ACK may include an allocation of dedicated resources for transmission of the BSR or SR (e.g., as illustrated by field 454 in fig. 4).

Although various embodiments are described herein above in terms of methods, apparatus, devices, computer-readable media, and receivers, persons of ordinary skill in the art will readily appreciate that such methods may be embodied by various combinations of hardware and software in various systems, communication devices, computing devices, control devices, apparatus, non-transitory computer-readable media, and so forth.

Fig. 9 shows a block diagram of an example wireless device or User Equipment (UE) 900 (hereinafter "UE 900"), including those described above with reference to other figures, according to various embodiments of the disclosure. For example, the UE 900 may be configured by executing instructions stored on a computer-readable medium to perform operations corresponding to one or more of the example methods and/or processes described above.

The UE 900 may include a processor 910 (also referred to as "processing circuitry") that may be operatively connected to a program memory 920 and/or a data memory 930 via a bus 970, which may include parallel address and data buses, serial ports, or other methods and/or structures known to those of ordinary skill in the art. Program memory 920 may store software code, programs, and/or instructions (collectively shown in fig. 9 as computer program product 921) that, when executed by processor 910, may configure and/or facilitate UE 900 in performing various operations, including the operations described below. For example, execution of such instructions may configure and/or facilitate the UE 900 to communicate using one or more wired or wireless communication protocols, including one or more wireless communication protocols standardized by 3GPP, 3GPP2, or IEEE, such as those commonly referred to as 5G/NR, LTE-a, UMTS, HSPA, GSM, GPRS, EDGE, 1xRTT, CDMA2000, 802.11 WiFi, HDMI, USB, Firewire, etc., or any other current or future protocol that may be utilized in connection with the radio transceiver 940, user interface (user interface) 950, and/or host interface 960.

As another example, processor 910 may execute program code stored in program memory 920 that corresponds to MAC, RLC, PDCP, and RRC layer protocols standardized by 3GPP (e.g., for NR and/or LTE). As a further example, processor 910 may execute program code stored in program memory 920 that, together with radio transceiver 940, implements corresponding PHY layer protocols, such as Orthogonal Frequency Division Multiplexing (OFDM), Orthogonal Frequency Division Multiple Access (OFDMA), and single carrier frequency division multiple access (SC-FDMA). As another example, the processor 910 may execute program code stored in the program memory 920 that, together with the radio transceiver 940, enables device-to-device (D2D) communication with other compatible devices and/or UEs.

Program memory 920 may also include software code executed by processor 910 to control functions of UE 900, including configuring and controlling various components, such as radio transceiver 940, user interface 950, and/or host interface 960. Program memory 920 may also include one or more application programs and/or modules comprising computer-executable instructions embodying any of the exemplary methods and/or processes described herein. Such software code may be specified or written using any known or future developed programming language, such as, for example, Java, C + +, C, Objective C, HTML, XHTML, machine code, Assembler (Assembler), as long as the desired functionality (e.g., as defined by the method steps implemented) is preserved. In addition, or in the alternative, program memory 920 may include an external storage arrangement (not shown) remote from UE 900 from which instructions may be downloaded into program memory 920 located within UE 900 or removably coupled to UE 900, so as to enable execution of such instructions.

The data memory 930 may include storage areas for the processor 910 to store variables used in the protocols, configurations, control, and other functions of the UE 900, including operations corresponding to or including any of the example methods and/or processes described herein. Also, program memory 920 and/or data memory 930 may include non-volatile memory (e.g., flash memory), volatile memory (e.g., static or dynamic RAN), or a combination thereof. Still further, the data storage 930 may include Memory slots (Memory slots) through which one or more formats of removable Memory cards (e.g., SD cards, Memory sticks, compact flash, etc.) may be inserted and removed.

One of ordinary skill will recognize that processor 910 may include a plurality of separate processors (including, for example, a multi-core processor), each of which implements a portion of the functionality described above. In such a case, multiple separate processors may be connected in common to program memory 920 and data memory 930, or separately to multiple separate program and or data memories. More generally, those of ordinary skill in the art will recognize that other functions and various protocols of the UE 900 may be implemented in many different computer arrangements, including different combinations of hardware and software, including but not limited to application processors, signal processors, general purpose processors, multi-core processors, ASICs, fixed and/or programmable digital circuitry, analog baseband circuitry, radio frequency circuitry, software, firmware, and middleware.

The radio transceiver 940 may include radio frequency transmitter and/or receiver functionality that facilitates the UE 900 to communicate with other devices supporting similar wireless communication standards and/or protocols. In some demonstrative embodiments, radio transceiver 940 includes one or more transmitters and one or more receivers, which enable UE 900 to communicate in accordance with various protocols and/or methods set forth by 3GPP and/or other standards bodies for standardization. For example, such functionality may cooperate with the processor 910 to implement a PHY layer based on OFDM, OFDMA, and/or SC-FDMA techniques, such as described herein with respect to other figures.

In some demonstrative embodiments, radio transceiver 940 includes one or more transmitters and one or more receivers, which may facilitate UE 900 to communicate with various LTE, LTE-advanced (LTE-a) and/or NR networks according to standards promulgated by the 3 GPP. In some example embodiments of the present disclosure, the radio transceiver 940 includes circuitry, firmware, etc., necessary for the UE 900 to also communicate with various NR, NR-U, LTE-A, LTE-LAA, UMTS, and/or GSM/EDGE networks in accordance with the 3GPP standards. In some embodiments, the radio transceiver 940 may include circuitry to support D2D communication between the UE 900 and other compatible devices.

In some embodiments, the radio transceiver 940 includes the circuitry, firmware, etc., necessary for the UE 900 to communicate with various CDMA2000 networks in accordance with the 3GPP2 standard. In some embodiments, radio transceiver 940 may be capable of communicating using radio technologies operating in unlicensed frequency bands, such as IEEE 802.11 WiFi operating using frequencies in the 2.4, 5.6, and/or 60 GHz ranges. In some embodiments, radio transceiver 940 may include a transceiver capable of wired communication, such as by using IEEE 802.3 ethernet technology. Functionality specific to each of these embodiments may be coupled to and/or controlled by other circuitry in the UE 900, such as the processor 910 executing program code stored in the program memory 920 in conjunction with and/or supported by the data memory 930.

The user interface 950 may take various forms depending on the particular embodiment of the UE 900, or may be completely absent from the UE 900. In some embodiments, the user interface 950 may include a microphone, a slidable button, a depressible button, a display, a touch screen display, a mechanical or virtual keypad (keypad), a mechanical or virtual keyboard, and/or any other user interface feature typically found on mobile phones. In other embodiments, the UE 900 may comprise a tablet computing device comprising a larger touch screen display. In such embodiments, one or more of the mechanical features of the user interface 950 may be replaced by comparable or functionally equivalent virtual user interface features (e.g., virtual keypads, virtual buttons, etc.) implemented using a touch screen display, as will be familiar to those of ordinary skill in the art. In other embodiments, the UE 900 may be a digital computing device, such as a laptop computer, desktop computer, workstation, or the like, that includes a mechanical keyboard, which may be integrated, removable, or detachable, depending on the particular exemplary embodiment. Such digital computing devices may also include touch screen displays. Many exemplary embodiments of the UE 900 having a touch screen display are capable of receiving user input, such as input related to the exemplary methods and/or processes described herein or other input known to one of ordinary skill in the art.

In some embodiments, the UE 900 may include an orientation sensor (orientation sensor), which may be used in various ways depending on the features and functionality of the UE 900. For example, the UE 900 may use the output of the orientation sensor to determine when the user has changed the physical orientation of the UE 900's touchscreen display. The indication signal from the orientation sensor may be used for any application executing on the UE 900 such that when the indication signal indicates that the physical orientation of the device has changed by approximately 90 degrees, the application may automatically change the orientation of the screen display (e.g., from portrait to landscape). In such an exemplary manner, the application may maintain the screen display in a manner readable by the user, regardless of the physical orientation of the device. Further, the output of the orientation sensor may be used in conjunction with various exemplary embodiments of the present disclosure.

The control interface 960 of the UE 900 may take various forms depending on the particular interface requirements of other devices with which the UE 900 intends to communicate and/or control and the particular exemplary embodiment of the UE 900. For example, the control interface 960 may include an RS-232 interface, an RS-495 interface, a USB interface, an HDMI interface, a Bluetooth interface, an IEEE ("Firewire") interface, I²C interface, PCMCIA interface, etc. In some example embodiments of the present disclosure, the control interface 960 may include an IEEE 802.3 ethernet interface such as described above. In some example embodiments of the present disclosure, control interface 960 may include analog interface circuitry including, for example, one or more digital-to-analog (D/a) converters and/or analog-to-digital (a/D) converters.

Those of ordinary skill in the art will recognize that the above list of features, interfaces, and radio frequency communication standards is merely exemplary and does not limit the scope of the present disclosure. In other words, the UE 900 may include more functionality than illustrated in fig. 9, including, for example, a video and/or still image camera, a microphone, a media player and/or recorder, and so forth. Further, the radio transceiver 940 may include circuitry necessary to communicate using additional radio frequency communication standards, including Bluetooth, GPS, and/or other standards. Also, the processor 910 may execute software code stored in the program memory 920 to control such additional functionality. For example, the directional velocity and/or position estimates output from the GPS receiver may be used for any application executing on the UE 900, including various exemplary methods and/or computer-readable media according to various exemplary embodiments of the present disclosure.

Fig. 10 shows a block diagram of an exemplary network node 1000, including those described above with reference to other figures, according to various embodiments of the present disclosure. For example, the example network node 1000 may be configured to perform operations corresponding to one or more of the example methods and/or processes described above by executing instructions stored on a computer-readable medium. In some example embodiments, network node 1000 may comprise a base station, an eNB, a gNB, or one or more components thereof. For example, the network node 1000 may be configured as a Central Unit (CU) and one or more Distributed Units (DU) according to the NR gNB architecture specified by 3 GPP. More generally, the functionality of the network node 1000 may be distributed across various physical devices and/or functional units, modules, etc.

The network node 1000 may include a processor 1010 (also referred to as "processing circuitry") operatively connected to a program memory 1020 and/or a data memory 1030 via a bus 1070, which may include parallel address and data buses, serial ports, or other methods and/or structures known to those of ordinary skill in the art.

Program memory 1020 may store software code, programs, and/or instructions (collectively shown in fig. 10 as computer program product 1021) that, when executed by processor 1010, may configure and/or facilitate network node 1000 to perform various operations. For example, execution of such stored instructions may configure network node 1000 to communicate with one or more other devices using a protocol that includes one or more of the exemplary methods and/or processes discussed above in accordance with various embodiments of the present disclosure. Program memory 1020 may also include software code executed by processor 1010 that may facilitate network node 1000, and in particular configure network node 1000 to communicate with one or more other devices using other protocols or protocol layers, such as one or more of the PHY, MAC, RLC, PDCP, and RRC layer protocols standardized by 3GPP for LTE, LTE-a, and/or NR, or any other higher layer protocol utilized in conjunction with radio network interface 1040 and core network interface 1050. By way of example and not limitation, core network interface 1050 may include an S1 interface and radio network interface 1040 may include a Uu interface as standardized by 3 GPP. The program memory 1020 may further include software code executed by the processor 1010 to control the functions of the network node 1000, including configuring and controlling various components, such as a radio network interface 1040 and a core network interface 1050.

The data storage 1030 may comprise a storage area for the processor 1010 to store variables used in the protocols, configurations, control and other functions of the network node 1000. As such, program memory 1020 and data memory 1030 may include non-volatile memory (e.g., flash memory, hard disk, etc.), volatile memory (e.g., static or dynamic RAM), network-based (e.g., "cloud") storage, or a combination thereof. One of ordinary skill in the art will recognize that processor 1010 may include a plurality of separate processors (not shown), each of which implements a portion of the functionality described above. In such a case, multiple separate processors may be connected in common to the program memory 1020 and the data memory 1030, or separately to multiple separate program and/or data memories. More generally, those of ordinary skill will recognize that other functions and various protocols of network node 1000 may be implemented in many different combinations of hardware and software, including, but not limited to, application processors, signal processors, general purpose processors, multi-core processors, ASICs, fixed digital circuitry, programmable digital circuitry, analog baseband circuitry, radio frequency circuitry, software, firmware, and middleware.

The radio network interface 1040 may include a transmitter, receiver, signal processor, ASIC, antenna, beamforming unit, and other circuitry to enable the network node 1000 to communicate with other devices, such as a plurality of compatible User Equipments (UEs) in some embodiments. In some embodiments, interface 1040 may also enable network node 1000 to communicate with a compatible satellite of a satellite communications network. In some demonstrative embodiments, radio network interface 1040 may include various protocols or protocol layers, such as PHY, MAC, RLC, PDCP and/or RRC layer protocols standardized by 3GPP for LTE, LTE-A, LTE-LAA, NR-U, and the like; improvements thereto such as those described herein above; or any other higher layer protocol utilized in conjunction with the radio network interface 1040. According to further example embodiments of the present disclosure, radio network interface 1040 may include a PHY layer based on OFDM, OFDMA, and/or SC-FDMA techniques. In some embodiments, the functionality of such a PHY layer may be provided by the radio network interface 1040 in cooperation with the processor 1010 (including program code in memory 1020).

The core network interface 1050 may include a transmitter, receiver, and other circuitry that enables the network node 1000 to communicate with other devices in a core network, such as a Circuit Switched (CS) and/or Packet Switched (PS) core network in some embodiments. In some embodiments, the core network interface 1050 may include an S1 interface standardized by 3 GPP. In some embodiments, the core network interface 1050 may include an NG interface standardized by 3 GPP. In some demonstrative embodiments, core network interface 1050 may include one or more interfaces to one or more AMFs, SMFs, SGWs, MMEs, SGSNs, GGSNs, and other physical devices including functionality found in GERAN, UTRAN, EPC, 5GC, and CDMA2000 core networks, known to those of ordinary skill in the art. In some embodiments, these one or more interfaces may be multiplexed together on a single physical interface. In some embodiments, the lower layers of the core network interface 1050 may include one or more of Asynchronous Transfer Mode (ATM), Internet Protocol (IP) over Ethernet, SDH over optical fiber, T1/E1/PDH over copper wire, microwave radio, or other wired or wireless transmission techniques known to those of ordinary skill in the art.

OA & M interface 1060 may include a transmitter, receiver, and other circuitry that enables network node 1000 to communicate with external networks, computers, databases, and the like, for the purpose of operating, managing, and maintaining network node 1000, or other network devices operatively connected thereto. The lower layers of OA & M interface 1060 may include one or more of Asynchronous Transfer Mode (ATM), Internet Protocol (IP) over Ethernet, SDH over optical fiber, T1/E1/PDH over copper wire, microwave radio, or other wired or wireless transmission techniques known to those of ordinary skill in the art. Further, in some embodiments, one or more of the radio network interface 1040, the core network interface 1050, and the OA & M interface 1060 may be multiplexed together on a single physical interface, such as the examples listed above.

Fig. 11 is a block diagram of an exemplary communication network configured to provide over-the-top (OTT) data services between a host computer and User Equipment (UE), in accordance with one or more exemplary embodiments of the present disclosure. The UE 1110 may communicate with a Radio Access Network (RAN) 1130 over a radio interface 1120, which may be based on protocols described above including, for example, LTE-a, 5G/NR. For example, the UE 1110 may be configured and/or arranged as shown in the other figures discussed above.

RAN 1130 may include one or more terrestrial network nodes (e.g., base stations, enbs, gnbs, controllers, etc.) operable in licensed frequency bands and one or more network nodes operable in unlicensed spectrum (e.g., using LAA or NR-U technologies), such as 2.4-GHz frequency bands and/or 5-GHz frequency bands. In such a case, the network nodes, including the RAN 1130, may operate cooperatively using licensed and unlicensed spectrum. In some embodiments, RAN 1130 may include or be capable of communicating with one or more satellites, including a satellite access network. In various embodiments, the RAN 1130 may be an E-UTRAN (e.g., as illustrated in FIG. 1) or a NG-RAN (e.g., as illustrated in FIG. 8).

The RAN 1130 may further communicate with the core network 1140 in accordance with various protocols and interfaces described above. For example, one or more devices (e.g., base stations, enbs, gnbs, etc.) including the RAN 1130 may communicate with the core network 1140 via the core network interface 1150 described above. In some demonstrative embodiments, RAN 1130 and core network 1140 may be configured and/or arranged as shown in the other figures discussed above. For example, an eNB including E-UTRAN 1130 may communicate with EPC 1140 via an S1 interface. As another example, a gNB including the NG-RAN 1130 may communicate with the 5GC 1130 via an NG interface.

The core network 1140 may further communicate with an external packet data network, shown in fig. 11 as the internet 1150, according to a variety of protocols and interfaces known to those of ordinary skill in the art. Many other devices and/or networks can also be connected to and communicate via the internet 1150, such as the exemplary host computer 1160. In some example embodiments, the host computer 1160 may communicate with the UE 1110 using the internet 1150, the core network 1140 and the RAN 1130 as an intermediary (intermediary). The host computer 1160 may be a server (e.g., an application server) under the ownership and/or control of a service provider. Host computer 1160 may be operated by an OTT service provider or another entity on behalf of the service provider.

For example, the host computer 1160 may provide over-the-top (OTT) packet data services to the UE 1110 using the facilities of the core network 1140 and the RAN 1130, which may not be aware of the routing of outgoing/incoming communications to/from the host computer 1160. Similarly, the host computer 1160 may not be aware of the route of transmission from the host computer to the UE, such as the route transmitted through the RAN 1130. Various OTT services may be provided using the exemplary configuration shown in fig. 11, including, for example, streaming (unidirectional) audio and/or video from a host computer to a UE, interactive (bi-directional) audio and/or video between a host computer and a UE, interactive messaging (social communication), interactive virtual reality or augmented reality, and so forth.

The exemplary network shown in fig. 11 may also include measurement processes and/or sensors that monitor network performance metrics including data rate, latency, and other factors improved by the exemplary embodiments disclosed herein. The exemplary network may also include functionality for reconfiguring a link between endpoints (e.g., host computer and UE) in response to a change in the measurement results. Such processes and functionality are known and practiced; if the network is hidden from the OTT service provider or abstracts the radio interface, the measurements may be facilitated by proprietary signaling between the UE and the host computer.

Example embodiments described herein provide techniques for improving transmission efficiency and/or power consumption of UE UL transmissions using a pre-configured uplink resource (PUR), such as by facilitating the UE to retransmit UL data messages that were originally sent via the PUR and that were incorrectly received by a network node (or not received at all). By facilitating retransmission by the UE configured with the PUR, such techniques may reduce lost UL data messages (e.g., lost packets) and/or reduce UE power consumption. When used in LTE or NR UEs (e.g., UE 1110) and enbs or gnbs (e.g., a gNB including RAN 1130), the example embodiments described herein may provide various improvements, benefits, and/or advantages to OTT service providers and end users, including more consistent data throughput and less latency, without excessive UE power consumption or other reduction in user experience.

The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements and procedures which, although not explicitly shown or described herein, embody the principles of the disclosure and are thus within the spirit and scope of the disclosure. As will be appreciated by one of ordinary skill in the art, the various exemplary embodiments may be used with each other and interchangeably.

The term "unit" as used herein may have a conventional meaning in the field of electronics, electrical devices and/or electronic devices, and may include, for example, electrical and/or electronic circuits, devices, modules, processors, memories, logical solid-state and/or discrete devices, computer programs or instructions for carrying out the respective tasks, processes, calculations, output and/or display functions, etc., such as those described herein.

Any suitable steps, methods, features, functions or benefits disclosed herein may be performed by one or more functional units or modules of one or more virtual devices. Each virtual device may include a plurality of these functional units. These functional units may be implemented via processing circuitry that may include one or more microprocessors or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), dedicated 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 (RAM), cache memory, flash memory devices, optical storage devices, and so forth. Program code stored in the memory includes program instructions for executing one or more telecommunications and/or data communications protocols, as well as instructions for performing one or more of the techniques described herein. In some implementations, processing circuitry may be used to cause respective functional units to perform corresponding functions in accordance with one or more embodiments of the present disclosure.

As described herein, an apparatus and/or device may be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such a chip or chipset; however, this does not exclude the possibility of: the functionality of the apparatus or device is not implemented by hardware but as software modules, such as a computer program or a computer program product, comprising executable software code portions for execution or running on a processor. Furthermore, the functionality of the apparatus or device may be implemented by any combination of hardware and software. An apparatus or device may also be considered to be an assembly of multiple apparatuses and/or devices, whether functionally in cooperation or independent of each other. Further, the apparatus and devices may be implemented in a distributed fashion throughout the system, so long as the functionality of the apparatus or device is preserved. Such and similar principles are considered to be known to the skilled person.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms used herein should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and the present specification and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

Furthermore, certain terms used in the present disclosure, including the description, drawings, and exemplary embodiments thereof, may be used synonymously in certain instances, including but not limited to, for example, data and information. It should be understood that although these terms and/or other terms that may be synonymous with one another may be used synonymously herein, there may be instances where such terms may not be intended to be used synonymously. Further, to the extent that prior art knowledge has not been explicitly incorporated by reference above, it is explicitly incorporated herein in its entirety. All publications cited are herein incorporated by reference in their entirety.

Embodiments of the techniques and devices described herein include, but are not limited to, the following enumerated examples:

1. a method for transmitting Uplink (UL) data by a User Equipment (UE) using pre-configured uplink resources (PURs) in a Radio Access Network (RAN), the method comprising:

receiving a first PUR configuration from a network node in the RAN;

transmitting a first UL data message to the network node using resources corresponding to the first PUR configuration; and

transmitting a second UL data message to the network node using resources corresponding to the second PUR configuration.

2. The method of embodiment 1, wherein both the first PUR configuration and the second PUR configuration are contention-free PUR configurations.

3. The method of embodiment 1, wherein both the first PUR configuration and the second PUR configuration are contention-based shared (CBS) PUR configurations.

4. The method of any of embodiments 1-3, further comprising: after transmitting the first UL data message but before transmitting the second UL data message, receiving an acknowledgement of the first UL data message from the network node (PUR ACK), wherein the PUR ACK indicates whether the first UL data message was received correctly or incorrectly by the network node.

5. The method of embodiment 4, wherein the second UL data message is different than the first UL data message if the PUR ACK indicates that the first UL data message was received correctly.

6. The method of any of embodiments 1-5, wherein the second PUR configuration is the same as the first PUR configuration.

7. The method of any of embodiments 4-6, wherein the second UL data message is a retransmission of the first UL data message if the PUR ACK indicates that the first UL data message was incorrectly received.

8. The method of any of embodiments 4-7, wherein the PUR ACK further comprises a second PUR configuration.

9. The method of any of embodiments 4-8, wherein the PUR ACK further includes one or more physical layer (PHY) parameters, and the second data message is transmitted using the one or more PHY parameters.

10. The method of any of embodiments 4-9, wherein the PUR ACK further indicates a fallback method for the UE to use when accessing the network node.

11. The method of any of embodiments 1-10, further comprising:

prior to transmitting the first UL data message, determining a first value of a parameter associated with transmission of the first UL data message; and

determining a second value of a parameter associated with transmission of a second UL data message if an acknowledgement of the first data message (PUR ACK) is not received within a predetermined duration after transmitting the first data message.

12. The method of embodiment 11, wherein the parameter is one of:

a Timing Advance (TA) value for transmission timing alignment; and

a transmission power level.

13. The method of any of embodiments 11-12, wherein:

determining a first value based on one or more first criteria; and

the second value is determined based on one or more second criteria.

14. The method of embodiment 13, further comprising: the second one or more criteria are determined based on the one or more first criteria and the corresponding one or more predetermined offsets.

15. The method of any of embodiments 11-14, further comprising:

transmitting a first UL data message according to the first parameter value; and

transmitting a second UL data message according to the second parameter value.

16. A method for receiving Uplink (UL) data transmitted by one or more User Equipments (UEs) using Preconfigured Uplink Resources (PURs) in a Radio Access Network (RAN), the method comprising:

transmitting the first PUR configuration to the UE;

receiving a first UL data message from the UE using a resource corresponding to the first PUR configuration; and

a second UL data message is received from the UE using resources corresponding to the second PUR configuration.

17. The method of embodiment 16, wherein both the first PUR configuration and the second PUR configuration are contention-free PUR configurations.

18. The method of embodiment 16, wherein both the first PUR configuration and the second PUR configuration are contention-based shared (CBS) PUR configurations.

19. The method of embodiment 18, wherein the second PUR configuration identifier:

a first portion of one or more transmission time windows available for initial transmission of an UL data message; and

a second portion of the one or more transmission time windows reserved for retransmission of the UL data message.

20. The method of any of embodiments 16-19, further comprising: it is determined whether the first UL data message was received correctly or incorrectly.

21. The method of any of embodiments 16-20, further comprising: after receiving the first UL data message but before receiving the second UL data message, transmitting an acknowledgement of the first UL data message to the UE (PUR ACK), wherein the PUR ACK indicates whether the first UL data message was received correctly or incorrectly by the network node.

22. The method of embodiment 21, wherein the second UL data message is different from the first UL data message if the PUR ACK indicates that the first UL data message was received correctly.

23. The method of any of embodiments 16-22, wherein the second PUR configuration is the same as the first PUR configuration.

24. The method of any of embodiments 21-23, wherein the second UL data message is a retransmission of the first UL data message if the PUR ACK indicates that the first UL data message was incorrectly received.

25. The method of any of embodiments 21-24, wherein the PUR ACK further comprises a second PUR configuration.

26. The method of any of embodiments 21-25, wherein the PUR ACK further comprises one or more physical layer (PHY) parameters, and the second data message is received using the one or more PHY parameters.

27. The method of any of embodiments 21-26, wherein the PUR ACK further indicates a fallback method for the UE to use when accessing the network node.

28. A User Equipment (UE) configured to transmit Uplink (UL) data using pre-configured uplink resources (PURs) in a Radio Access Network (RAN), the UE comprising:

communication circuitry configured to communicate with one or more network nodes in the RAN; and

processing circuitry operatively associated with the communication circuitry and configured to perform operations corresponding to the method of any of exemplary embodiments 1-15.

29. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by at least one processor of a User Equipment (UE), configure the UE to perform operations corresponding to the method of any of exemplary embodiments 1-15.

30. A network node of a Radio Access Network (RAN) configured to receive Uplink (UL) data transmitted by one or more User Equipments (UEs) using Preconfigured Uplink Resources (PURs) in the RAN, the network node comprising:

communication circuitry configured to communicate with the one or more UEs; and

processing circuitry operatively associated with the communication circuitry and configured to perform operations corresponding to the methods of any of exemplary embodiments 16-28.

31. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by at least one processor of a network node, configure the network node to perform operations corresponding to the method of any of exemplary embodiments 16-28.

Claims

1. A method for transmitting uplink, UL, data by a user equipment, UE, in a radio access network, RAN, using preconfigured uplink resources, PUR, the method comprising:

receiving (710) a first PUR configuration from a network node in the RAN;

transmitting (720) a first UL data message to the network node based on the first PUR configuration; and

receiving (730), from the network node, a first acknowledgement, PUR ACK, of the first UL data message, wherein the first PUR ACK:

indicating whether the first UL data message was received correctly or incorrectly by the network node, an

Including information related to subsequent UL transmissions using the PUR.

2. The method of claim 1, wherein the information related to subsequent UL transmissions using PURs comprises at least one of:

a timing advance for uplink timing alignment;

allocating transmission resources;

the number of repetitions of the UL data message;

a power control command;

a redundancy version of the UL data message;

modulation and coding scheme of UL data messages; and

transport block size of UL data message.

3. The method of any of claims 1-2, further comprising: transmitting (740) a second UL data message to the network node based on information related to a subsequent UL transmission included in the first PUR ACK.

4. The method of claim 3, wherein:

the information related to a subsequent UL transmission comprises a second PUR configuration; and

transmitting the second UL data message based on the second PUR configuration.

5. The method of claim 4, wherein the first PUR configuration and the second PUR configuration are both one of:

the configuration of the dedicated PUR is such that,

a shared CFS PUR configuration without contention, or

Shared CBS PUR configuration based on contention.

6. The method of any one of claims 4-5, wherein:

both the first and second PUR configurations are CBS PUR configurations; and

the second PUR configuration identifier:

a second portion of the one or more transmission time windows reserved for retransmission of UL data messages.

7. The method of any one of claims 3-6, wherein:

the information related to a subsequent UL transmission comprises one or more physical layer PHY parameters; and

transmitting the second UL data message based on the one or more PHY parameters.

8. The method of any of claims 3-7, wherein transmitting (740) the second UL data message comprises: transmitting (741) the second UL data message according to a fallback procedure if the first PUR ACK indicates that the first UL data message was incorrectly received by the network node.

9. The method of any of claims 3-7, further comprising: transmitting (750) a third UL data message according to a fallback procedure if a second PUR ACK is not received within a predetermined time after transmitting the second UL data message.

10. The method of any of claims 8-9, wherein the information related to a subsequent UL transmission comprises an indication that the fallback procedure should be used by the UE for transmitting one or more subsequent UL data messages.

11. The method of claim 10, wherein the indication further indicates that the UE should use the fallback procedure for transmitting all subsequent UL data messages.

12. The method of any of claims 8-11, wherein the fallback procedure comprises one of:

a conventional random access procedure; or

Early data transfer process.

13. The method of any one of claims 8-11, wherein:

using a first value of a transmission parameter when transmitting (720) the first UL data message; and

using a second value of the transmission parameter when transmitting (741, 750) a subsequent UL data message according to the fallback procedure.

14. The method of claim 13, wherein:

transmitting the first UL data message comprises determining (721) the first value of the transmission parameter based on one or more first criteria; and

transmitting (741, 750) the subsequent UL data message inclusion according to the fallback procedure.

15. The method of claim 14, wherein a second criterion is based on the first criterion and a corresponding predetermined offset.

16. The method of claim 14, wherein second criteria include one or more criteria not included in the first criteria.

17. The method according to any of claims 14-16, wherein the transmission parameter is one of:

a timing advance for transmission timing alignment; or

A transmission power level.

18. The method of any one of claims 2-17, wherein:

the second UL data message is different than the first UL data message if the first PUR ACK indicates that the first UL data message was received correctly; and

the second UL data message is a retransmission of the first UL data message if the first PUR ACK indicates that the first UL data message was incorrectly received.

19. The method of claim 18, wherein the information related to a subsequent UL transmission comprises an allocation of dedicated resources for retransmission of the first UL data message if the first PUR ACK indicates that the first UL data message was incorrectly received.

20. The method of any of claims 1-19, wherein the first PUR ACK is received as one of:

physical layer downlink control information, DCI; or

Hybrid ARQ HARQ or radio link control RLC acknowledgement messages.

21. The method of any one of claims 1-20, wherein:

the first UL data message comprises a request for resources to transmit a Buffer Status Report (BSR) or a Scheduling Request (SR); and

the first PUR ACK includes an allocation of dedicated resources for transmission of the BSR or the SR.

22. A method for receiving uplink, UL, data transmitted by one or more user equipments, UEs, using preconfigured uplink resources, PURs, in a radio access network, RAN, the method comprising:

transmitting (810) the first PUR configuration to the UE;

receiving (820) a first UL data message from the UE based on the first PUR configuration; and

transmitting (830) a first acknowledgement, PUR ACK, of the first UL data message to the UE, wherein the first PUR ACK:

indicating whether the first UL data message was received correctly or incorrectly by a network node; and

including information related to subsequent UL transmissions using the PUR.

23. The method of claim 22, wherein the information related to subsequent UL transmissions using PURs comprises at least one of:

a timing advance for uplink timing alignment;

allocating transmission resources;

the number of repetitions of the UL data message;

a power control command;

a redundancy version of the UL data message;

modulation and coding scheme of UL data messages; and

transport block size of UL data message.

24. The method of any of claims 22-23, further comprising: receiving (840) a second UL data message from the UE based on information related to a subsequent UL transmission included in the first PUR ACK.

25. The method of claim 24, wherein:

receiving the second UL data message based on the second PUR configuration.

26. The method of claim 25, wherein the first PUR configuration and the second PUR configuration are both one of:

the configuration of the dedicated PUR is such that,

a shared CFS PUR configuration without contention, or

Shared CBS PUR configuration based on contention.

27. The method of any one of claims 25-26, wherein:

both the first and second PUR configurations are CBS PUR configurations; and

the second PUR configuration identifier:

28. The method of any one of claims 23-27, wherein:

receiving the second UL data message based on the one or more PHY parameters.

29. The method of any one of claims 22-28, wherein:

the first PUR ACK indicates that the first UL data message was incorrectly received by the network node; and

the information related to a subsequent UL transmission comprises one of:

an indication of a fallback procedure for the UE; or

An allocation of dedicated resources for retransmitting the first UL data message.

30. The method of claim 29, wherein the fallback procedure comprises one of:

a conventional random access procedure; or

Early data transfer process.

31. The method of any one of claims 22-30, wherein:

32. The method of any of claims 22-31, wherein the first PUR ACK is transmitted as one of:

physical layer downlink control information, DCI; or

Hybrid ARQ HARQ or radio link control RLC acknowledgement messages.

33. The method of any one of claims 22-32, wherein:

34. A user equipment, UE, (120, 900) configured to transmit uplink, UL, data in a radio access network, RAN, (100, 699) using preconfigured uplink resources, PUR, the UE comprising:

a transceiver circuit (940) configured to communicate with the network node; and

processing circuitry (910) operably coupled to the transceiver circuitry, whereby the processing circuitry and the transceiver circuitry are configured to perform operations corresponding to any of the methods of claims 1-21.

35. A user equipment, UE, (120, 900) configured to transmit uplink, UL, data using preconfigured uplink resources, PUR, in a radio access network, RAN, (100, 699), the UE being further arranged to perform operations corresponding to any of the methods of claims 1-21.

36. A non-transitory computer-readable medium (920) storing computer-executable instructions (921) that, when executed by processing circuitry (910) of a user equipment, UE, (120, 900), configure the UE to perform operations corresponding to any of the methods of claims 1-21.

37. A computer program product (921) comprising computer-executable instructions that, when executed by processing circuitry (910) of a user equipment, UE, (120, 900), configure the UE to perform operations corresponding to any of the methods of claims 1-21.

38. A network node (105, 115, 610, 620, 1000) of a radio access network, RAN, (100, 699) configured to receive uplink, UL, data transmitted by one or more user equipments, UEs, using pre-configured uplink resources, PURs, the network node comprising:

a radio network interface (1040) configured to communicate with the one or more UEs; and

processing circuitry (1010) operably coupled to the radio network interface, whereby the processing circuitry and the radio network interface are configured to perform operations corresponding to any of the methods of claims 22-33.

39. A network node (105, 115, 610, 620, 1000) of a radio access network, RAN, (100, 699) configured to receive uplink, UL, data transmitted by one or more user equipments, UEs, using preconfigured uplink resources, PURs, the network node being further arranged to perform operations corresponding to any of the methods of claims 22-33.

40. A non-transitory computer-readable medium (1020) storing computer-executable instructions (1021) that, when executed by processing circuitry (1010) of a network node (105) and 115, 610 and 620, 1000), configure the network node to perform operations corresponding to any of the methods of claims 22-33.

41. A computer program product (1021) comprising computer executable instructions that, when executed by processing circuitry (1010) of a network node (105, 610, 620, 1000), configure the network node to perform operations corresponding to any of the methods as claimed in claims 22-33.