Allocation of preempted uplink resources

Abstract

The present invention relates to the allocation of preempted uplink resources. An apparatus, a method, and a system for preempted uplink resource allocation are disclosed. An apparatus (700) includes a processor (705) and a transceiver (725). The transceiver (725) receives (805) a first allocation of uplink resources in a mobile communication network and receives (810) a second allocation of uplink resources. Here, the second allocation overlaps with the first allocation at least partially in time, and the second allocation is received at a time later than the first allocation. The processor (505) determines (815) whether the second allocation is associated with a higher-priority service than the first allocation, and in response to the second allocation being associated with a higher-priority service than the first allocation, preempts (820) the first allocation to generate a transport block (TB) according to the second allocation.

Description

[0001] This application is a divisional application of an application with PCT application number PCT / IB2019 / 001176, international filing date of October 31, 2019, Chinese application number 201980064099.2, and invention title of "Allocation of Preempted Uplink Resources", which entered the Chinese national phase on March 29, 2021.

[0002] Cross - reference to related applications

[0003] This application claims priority to U.S. Provisional Patent Application 62 / 753,824, titled "Efficient Protocol Operation for Uplink Preemption", filed on October 31, 2018 by Joachim Loehrm, Alexander Johann Maria Golitschek Edler von Elbwart, Ravi Kuchibhotla, and Prateek Basu Mallick, which is incorporated herein by reference. Technical field

[0004] The subject matter disclosed herein generally relates to wireless communications, and more particularly to efficient protocol operation for uplink preemption. Background art

[0005] The following abbreviations are defined herein, and at least some of them are referenced in the following description: 3rd Generation Partnership Project (“3GPP”), 5th Generation Core Network (“5GC”), Access and Mobility Management Function (“AMF”), Acknowledgement (“ACK”), Access Stratum (“AS”), Base Station (“BS”), Control Element (“CE”), Channel State Information (“CSI”), Core Network (“CN”), Control Plane (“CP”), Downlink Control Information (“DCI”), Downlink (“DL”), Evolved Node B (“eNB”), Evolved Packet Core (“EPC”), Global System for Mobile Communications (“GSM”), Hybrid Automatic Repeat reQuest (“HARQ”), Home Subscriber Server (“HSS”), Information Element (“IE”), Internet of Things (“IoT”), Long Term Evolution (“LTE”), Multiple Access (“MA”), Mobility Management Entity (“MME”), Modulation and Coding Scheme (“MCS”), Machine Type Communication (“MTC”), Negative Acknowledgement (“NACK”) or (“NAK”), New Generation (5G) Node B (“gNB”), New Generation Radio Access Network (“NG-RAN”, the RAN for 5G networks), New Radio (“NR”, 5G radio access technology;Also known as "5G NR"), non-access stratum ("NAS"), network slice selection assistance information ("NSSAI"), packet data unit ("PDU", used in combination with "PDU session"), physical downlink control channel ("PDCCH"), physical downlink shared channel ("PDSCH"), physical random access channel ("PRACH"), physical resource block ("PRB"), physical uplink control channel ("PUCCH"), physical uplink shared channel ("PUSCH"), public land mobile network ("PLMN"), quality of service ("QoS"), radio access network ("RAN"), radio access technology ("RAT"), radio bearer ("RB"), radio resource control ("RRC"), random access procedure ("RACH"), random access response ("RAR"), radio network temporary identifier ("RNTI"), reference signal ("RS"), registration management ("RM", referring to NAS layer processes and states), receive ("RX"), radio link control ("RLC"), scheduling request ("SR"), shared channel ("SCH"), session management function ("SMF"), sounding reference signal ("SRS"), transport block ("TB"), transport block size ("TBS"), transmit ("TX"), unified data management ("UDM"), user data repository ("UDR"), uplink control information ("UCI"), user entity / device (mobile terminal) ("UE"), uplink ("UL"), user plane ("UP"), ultra-reliable and low-latency communication ("URLLC"), and worldwide interoperability for microwave access ("WiMAX"). As used herein, "HARQ-ACK" can collectively represent an affirmative acknowledgment ("ACK") and a negative acknowledgment ("NACK"). ACK means that the TB has been correctly received, while NACK (or NAK) means that the TB has been received incorrectly.;

[0006] In NR Rel-15, it is not possible to preempt a dynamic uplink grant allocation using another dynamic grant received via DCI, i.e., uplink preemption is not supported. In other words, within a single cell, for the case of two dynamic grants, out-of-order scheduling is not supported in Rel-15. Instead, once the DCI for PUSCH transmission is received for the first time, the later received DCI should correspond to a PUSCH transmission at a later time. Additionally, for a resource conflict between a configured grant resource and a dynamically allocated resource, a UE following the currently specified NR Rel-15 behavior will always give priority to the dynamic grant over the configured grant. However, this may lead to the problem that the UE has to use a grant that is not suitable for the transmission of critical / high-urgency packets. Summary of the Invention

[0007] The present disclosure provides efficient protocol operations for the case of UL prioritization within a UE. For the uplink, two dynamic uplink grants can be utilized to schedule the UE, and these two dynamic uplink grants allocate overlapping PUSCH resources for data of different priority levels. For example, the gNB can schedule an emergency / critical URLLC PUSCH transmission, e.g., by using a high-reliability MCS for transmission, to pre-empt a previously scheduled PUSCH transmission intended for lower-priority eMBB data. Several embodiments of the present disclosure relate to the detailed UE behavior for UL pre-emption.

[0008] The present disclosure further includes embodiments that provide solutions for the case when there are conflicts in the allocated UL resources. For the uplink, the UE can send high-priority data (e.g., URLLC) on the resources allocated by the configured grant. Additionally, the UE can be scheduled by a dynamic UL grant, e.g., for transmitting lower-priority data such as eMBB, which may result in a UL resource conflict, i.e., the UE has two allocated UL resources during uplink transmission.

[0009] Other embodiments relate to supporting packets of different priority / urgency levels within one radio bearer or QoS flow. For example, an industrial IoT traffic flow can support critical packets, such as an emergency stop packet, within a radio bearer or QoS flow. The priority of these critical data packets is higher than that of other data packets in the same radio bearer or QoS flow. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] A more specific description of the embodiments briefly described above will be presented by referring to specific embodiments illustrated in the drawings. It should be understood that these drawings only depict some embodiments and should not be considered as limiting the scope. The embodiments will be described and explained with additional features and details by using the drawings, where:

[0011] Figure 1 is a schematic block diagram illustrating an embodiment of a wireless communication system for uplink pre-emption;

[0012] Figure 2 is a diagram illustrating an embodiment of a network process for uplink pre-emption;

[0013] Figure 3 is a diagram illustrating an embodiment of the timing of uplink pre-emption;

[0014] Figure 4 is a diagram illustrating another embodiment of the timing of uplink pre-emption;

[0015] Figure 5 is a diagram illustrating another embodiment of a network process for uplink pre-emption;

[0016] Figure 6 FIG. is a diagram illustrating an embodiment of a UE protocol stack for uplink preemption;

[0017] Figure 7 FIG. is a schematic block diagram illustrating an embodiment of a user equipment device that can be used for uplink preemption; and

[0018] Figure 8 FIG. is a block diagram illustrating an embodiment of a method for uplink preemption. DETAILED DESCRIPTION

[0019] As will be appreciated by one skilled in the art, aspects of the embodiments can be embodied as a system, apparatus, method, or program product. Accordingly, the embodiments can take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.) or an embodiment combining software and hardware aspects that may generally be referred to herein as a "circuit," "module," or "system." Additionally, the embodiments can take the form of a program product embodied in one or more computer-readable storage devices storing machine-readable code, computer-readable code, and / or program code hereinafter referred to as code. The storage device can be tangible, non-transitory, and / or non-transmission. The storage device may not embody a signal. In one embodiment, the storage device merely takes the form of a signal for accessing the code.

[0020] Any combination of one or more computer-readable media may be utilized. The computer-readable media may be a computer-readable storage medium. The computer-readable storage medium may be a storage device storing the code. The storage device may be, by way of example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micro-mechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

[0021] More specific examples (a non-exhaustive list) of the storage device would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory ("RAM"), a read-only memory ("ROM"), an erasable programmable read-only memory ("EPROM" or Flash memory), a portable compact disc read-only memory ("CD-ROM"), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0022] The code for performing the operations of the embodiments can be any number of lines and can be written in any combination of one or more programming languages including object-oriented programming languages such as Python, Ruby, Java, Smalltalk, C++, etc., and traditional procedural programming languages such as the "C" programming language, and / or machine languages such as assembly language. The code can be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer via any type of network connection, including a local area network ("LAN") or a wide area network ("WAN"), or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0023] References in this specification to "one embodiment", "an embodiment", or similar language mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, unless expressly stated otherwise, the phrases "in one embodiment", "in an embodiment", and similar language that appear throughout this specification may, but do not necessarily, all refer to the same embodiment, but mean "one or more but not all embodiments". Unless expressly stated otherwise, the terms "comprises", "comprising", "has", and variations thereof mean "including but not limited to". Unless expressly stated otherwise, a list of items does not imply that any or all of the items are mutually exclusive. Unless expressly stated otherwise, the terms "a", "an", and "the" also refer to "one or more".

[0024] As used herein, a list with a conjunction of "and / or" includes any single item in the list or a combination of items in the list. For example, the list of A, B, and / or C includes only A; only B; only C; the combination of A and B; the combination of B and C; the combination of A and C; or the combination of A, B, and C. As used herein, a list using the term "one or more" includes any single item in the list or a combination of items in the list. For example, one or more of A, B, and C includes only A; only B; only C; the combination of A and B; the combination of B and C; the combination of A and C; or the combination of A, B, and C. As used herein, a list using the term "one of..." includes one and only one of any single item in the list. For example, "one of A, B, and C" includes only A, only B, or only C, and excludes the combination of A, B, and C. As used herein, "a member selected from the group consisting of A, B, and C" includes one or only one of A, B, or C, and excludes the combination of A, B, and C. As used herein, "a member selected from the group consisting of A, B, and C and their combinations" includes only A; only B; only C; the combination of A and B; the combination of B and C; the combination of A and C; or the combination of A, B, and C.

[0025] In addition, the features, structures, or characteristics of the described embodiments can be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of the embodiments. However, those skilled in the relevant art will recognize that the embodiments can be practiced without one or more of the specific details, or by using other methods, components, materials, etc. In other cases, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring some aspects of the embodiments.

[0026] Aspects of the embodiments are described below with reference to the schematic flowcharts and / or schematic block diagrams of methods, apparatuses, systems, and program products according to the embodiments. It will be understood that each block of the schematic flowcharts and / or schematic block diagrams, and combinations of blocks in the schematic flowcharts and / or schematic block diagrams, can be implemented by code. The code can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to generate a machine, such that instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions / operations specified in the blocks of the schematic flowcharts and / or schematic block diagrams.

[0027] The code can also be stored in a storage device, which can direct a computer, other programmable data processing apparatus, or other devices to operate in a specific manner, such that the instructions stored in the storage device produce an article of manufacture including the instructions that implement the functions / operations specified in the blocks of the schematic flowchart and / or the schematic block diagram.

[0028] The code can also be loaded onto a computer, other programmable data processing apparatus, or other devices, such that a series of operational steps are performed on the computer, other programmable apparatus, or other devices to produce a computer-implemented process, such that the code executed on the computer or other programmable apparatus provides a process for implementing the functions / operations specified in the blocks of the flowchart and / or the block diagram.

[0029] The schematic flowcharts and / or schematic block diagrams in the figures illustrate the possible architectures, functions, and operations of apparatuses, systems, methods, and program products according to various embodiments. In this regard, each block in the schematic flowchart and / or schematic block diagram can represent a module, segment, or portion of code that includes one or more executable instructions for implementing the specified logical function.

[0030] It should also be noted that in some alternative embodiments, the functions noted in the blocks may not occur in the order noted in the figures. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Other steps and methods may be envisioned that are equivalent in function, logic, or effect to one or more blocks or portions of the figures shown.

[0031] Although various arrow types and line types may be employed in the flowchart and / or block diagram, it should be understood that they do not limit the scope of the corresponding embodiments. In fact, some arrows or other connectors may be used only to indicate the logical flow of the depicted embodiment. For example, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated steps of the depicted embodiment. It will also be noted that each block of the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented by a system based on dedicated hardware that performs a specific function or operation, or by a combination of dedicated hardware and code.

[0032] The description of the elements in each figure may refer to the elements of the preceding figures. In all the figures, the same numerals refer to the same elements, including alternative embodiments of the same elements.

[0033] Generally, the present disclosure describes systems, methods, and apparatuses for efficient protocol operations for uplink preemption. For the case of UL prioritization within a UE, the present disclosure provides efficient protocol operations. For the uplink ("UL"), two dynamic uplink grants can be utilized to schedule UEs, and these two dynamic uplink grants allocate overlapping PUSCH resources for data of different priority levels. For example, the gNB can schedule an emergency / critical URLLC PUSCH transmission using, for example, a high-reliability MCS for transmission to preempt a previously scheduled PUSCH transmission intended for lower-priority eMBB data. Several embodiments of the present disclosure relate to detailed UE behavior for UL preemption.

[0034] The present disclosure further includes embodiments that provide solutions for situations where there are conflicts in the allocated UL resources. For the UL, a UE can send high-priority data (e.g., URLLC) on the resources allocated by a configured grant. Additionally, a UE can be scheduled via a dynamic UL grant, for example, for transmitting lower-priority data such as eMBB, which may result in a UL resource conflict, i.e., the UE has two allocated UL resources during an uplink transmission. Recall that a UE according to the currently specified NR Rel-15 behavior will always prioritize the dynamic grant (here, associated with lower-priority data) over the configured grant (here, associated with higher-priority data).

[0035] Other embodiments relate to supporting packets of different priority / urgency levels within a radio bearer or QoS flow. For example, an industrial IoT ("IIoT") traffic flow can support critical packets, such as an emergency stop packet, within a radio bearer or QoS flow. The priority of these critical data packets is higher than that of other data packets in the same radio bearer or QoS flow.

[0036] The 3GPP has not yet addressed the first problem mentioned above, i.e., the detailed UE / protocol behavior for UL preemption. Recall that in NR Rel-15, it was not possible to preempt a dynamic uplink grant allocation with another dynamic DCI, i.e., uplink preemption was not supported. In other words, within a single cell, (at least for the case of two dynamic grants), out-of-order scheduling is not supported in Rel-15, i.e., once a DCI for PUSCH transmission is received, a later DCI will correspond to a later PUSCH transmission.

[0037] For the second problem above, i.e., the resource conflict between the configured licensed resources and the dynamically allocated resources, the UE according to the currently specified NR Rel-15 behavior will give priority to the dynamic grant over the configured grant. As described above, this may cause the problem that the UE will have to use a grant that is not applicable to transmitting critical / high-urgency packets. Additionally, in the currently specified NR Rel-15, so far, it does not support different priority packets within the same radio bearer / QoS flow.

[0038] Figure 1 FIG. 4 depicts an embodiment of a wireless communication system 100 for efficient protocol operation of uplink preemption according to various embodiments of the present disclosure. In one embodiment, the wireless communication system 100 includes a remote unit 105, a base station unit 110, and a communication link 115. Even though Figure 1 a specific number of remote units 105, base station units 110, and communication links 115 are depicted in FIG. 4, those skilled in the art will recognize that any number of remote units 105, base station units 110, and communication links 115 may be included in the wireless communication system 100.

[0039] In one embodiment, the wireless communication system 100 is compatible with the NR system specified in the 3GPP specifications and / or the LTE system specified in 3GPP. However, more generally, the wireless communication system 100 may implement some other open or proprietary communication networks in other networks, such as WiMAX. The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol.

[0040] In one embodiment, the remote unit 105 may include a computing device, such as a desktop computer, a laptop computer, a personal digital assistant (“PDA”), a tablet computer, a smart phone, a smart TV (e.g., a TV connected to the Internet), a smart appliance (e.g., an appliance connected to the Internet), a set-top box, a gaming console, a security system (including security cameras), an in-vehicle computer, a network device (e.g., a router, a switch, a modem), etc. In some embodiments, the remote unit 105 includes a wearable device, such as a smart watch, a fitness band, an optical head-mounted display, etc. Additionally, the remote unit 105 may be referred to as a subscriber unit, a mobile phone, a mobile station, a user, a terminal, a mobile terminal, a fixed terminal, a subscriber station, a UE, a user terminal, a device, or other terms used in the art. The remote unit 105 may communicate directly with one or more base station units 110 via uplink (“UL”) and downlink (“DL”) communication signals. Additionally, the UL and DL communication signals may be carried on the communication link 115.

[0041] In some embodiments, the remote unit 105 may establish a data connection (e.g., a PDU session) with the data network 150 via the mobile core network 130. Here, a data path for the PDU session may be established on one of the multiple network slices 138 supported by the mobile core network 130. The specific network slice 138 used for the PDU session may be determined by the S-NSSAI attribute of the PDU session. Here, a network slice selection policy ("NSSP") rule may be provided to the remote unit 105, which is used to determine how to route the requested PDU session.

[0042] The base station units 110 may be distributed over a geographical area. In certain embodiments, the base station units 110 may also be referred to as RAN nodes, access terminals, bases, base stations, Node B, eNB, gNB, home Node B, relay nodes, femtocells, access points, devices, or any other term used in the art. The base station units 110 are generally part of an access network 120 such as a radio access network ("RAN"), which may include one or more controllers communicatively coupled to one or more corresponding base station units 110. These and other elements of the access network 120 are not shown, but are well known to those of ordinary skill in the art. The base station units 110 are connected to the mobile core network 130 via the access network 120. The access network 120 and the mobile core network 130 may be collectively referred to herein as the "mobile network" or "mobile communication network".

[0043] The base station unit 110 may serve multiple remote units 105 within a service area (e.g., a cell or a cell sector) via a wireless communication link. The base station unit 110 may communicate directly with one or more remote units 105 via communication signals. Generally, the base station unit 110 transmits downlink ("DL") communication signals in the time domain, frequency domain, and / or spatial domain to serve the remote units 105. In addition, the DL communication signals may be carried on the communication link 115. The communication link 115 may be any suitable carrier in licensed or unlicensed radio spectrum. The communication link 115 facilitates communication between one or more remote units 105 and / or one or more base station units 110.

[0044] In one embodiment, the mobile core network 130 is a 5G core network (“5GC”), which may be coupled to data networks 150 in other data networks, such as the Internet and private data networks. In some embodiments, the remote unit 105 communicates with an application function (“AF”) (outside the mobile core network 130) via a network connection to the mobile core network 130. Each mobile core network 130 belongs to a single public land mobile network (“PLMN”). The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol. For example, other embodiments of the mobile core network 130 include an evolved packet core (“EPC”) or a multi-service core as described by the Broadband Forum (“BBF”).

[0045] The mobile core network 130 includes a number of network functions (“NFs”) and multiple network slices 138. As shown, the mobile core network 130 includes at least one unified data management with an internal user data repository (“UDM / UDR”), at least one policy control function (“PCF”) 134, at least one access and mobility management function (“AMF”) 136, and at least one network exposure function (“NEF”). Although a specific number of NFs are depicted, those skilled in the art will recognize that any number of NFs may be included in the mobile core network 130. In certain embodiments, each of the multiple network slices 138 includes its own dedicated network functions (not shown), such as a session management function (“SMF”) and a user plane function (“UPF”). Although the depicted embodiment shows a single AMF in the mobile core network 130, in other embodiments, each of the multiple network slices 138 may implement its own AMF. Figure 1 The UDM / UDR 132 includes unified data management (“UDM”) and its internal component user data repository (“UDR”). The UDR stores subscription data including policy data. Specifically, the policy data stored by the UDM / UDR 132 includes NSSP. The UDM / UDR 132, PCF 134, AMF 136, and SMF (not shown) are examples of control plane network functions of the mobile core network 130. Control plane network functions provide services such as UE registration, UE connection management, UE mobility management, session management, etc. In contrast, the UPF provides data transfer services to the remote unit 105.

[0046]

[0047] ​Multiple network slices 138 are logical networks within the mobile core network 130. A network slice 138 is a partition of the resources and / or services of the mobile core network 130. Different network slices 138 can be used to meet different service requirements (e.g., latency, reliability, and capacity). Examples of different types of network slices 138 include enhanced mobile broadband ("eMBB"), massive machine type communication ("mMTC"), and ultra-reliable and low-latency communication ("URLLC"). The mobile core network 130 can include multiple network slice instances of the same network slice type. Different network slice instances of the same type can be distinguished by a slice "tenant" (also referred to as a "slice differentiator") associated with the instance.

[0048] In some embodiments, two dynamic uplink grants that allocate overlapping PUSCH resources to data of different priorities can be utilized to schedule the remote unit 105. Here, the later received dynamic grant can allocate resources for higher priority traffic. Thus, the remote unit 105 "out-of-orders" the uplink grant by pre-empting the first received dynamic grant (associated with lower priority traffic) in order to process and implement the second received grant (associated with higher priority traffic).

[0049] In some embodiments, the remote unit 105 can receive a dynamic grant for PUSCH resources that conflicts (e.g., overlaps) with a previously configured grant. Here, the (previously) configured grant may be associated with higher priority traffic, while the later received dynamic grant may allocate resources for lower priority traffic. Although the dynamic grant is generally of higher priority than the configured grant, the remote unit 105 here identifies that the configured grant is associated with traffic of a higher urgency than the dynamic grant, and thus pre-empts the dynamic grant (associated with lower priority traffic) in order to process and implement the configured grant (associated with higher priority traffic).

[0050] In some embodiments, the remote unit 105 can support different priorities within the same radio bearer or QoS flow. Here, the remote unit 105 prioritizes higher priority (e.g., more critical) data packets over other packets within the same radio bearer or QoS flow.

[0051] For uplink preemption, if the preempted DCI is used to schedule a retransmission, the remote unit 105 follows the preempting DCI (e.g., associated with higher-priority data) and further processes the TB according to the preemption grant, which may be stored in the HARQ transmission buffer for retransmission (similar processing to a measurement gap). However, if the preempted DCI is used to schedule an initial transmission, the remote unit 105 may ignore the preempted DCI and only follow the preempting DCI. For example, for a preempted lower-priority DCI, no TB is generated. Note that if the processing of the preempted DCI has already started, the remote unit may pause (e.g., interrupt) the processing of the preempting (lower-priority) DCI to follow the preempting (higher-priority) DCI.

[0052] In some embodiments, the remote unit 105 may receive a DCI that explicitly indicates that it is a preemption grant. In one embodiment, the UL-SCH indicator (e.g., 1-bit field) in DCI 0-1 may be used to indicate preemption (e.g., the DCI is associated with high urgency). In another embodiment, an SRS with an invalid state is used to indicate high urgency / preemption grant. In yet another embodiment, a specific RNTI may be used to indicate preemption.

[0053] If the remote unit 105 has some (dynamically) scheduled UL resources intended for low-priority traffic (e.g., eMBB), and then high-urgency / reliable data arrives in the buffer of the remote unit, the remote unit 105 may be allowed to use the scheduled resources for the transmission of high-urgency / reliable data. In some embodiments, the remote unit 105 uses an MCS / TB size different from the scheduled MCS / TB size for the transmission of high-urgency data. Thus, the remote unit 105 may also include some UCI (uplink control information) in the allocated resources indicating the MCS for gNB detection.

[0054] Here, the UCI includes will be completed at the PHY layer entity. Additionally, the UCI position can be fixed such that the base station unit 110 can detect the UCI based on CRC check. In some embodiments, the UCI is located at the start of the PUSCH resource, e.g., after the very first DM-RS. In some embodiments, the modulation scheme of the UCI can be predefined or fixed (e.g., always QPSK). Additionally, the remote unit 105 can modify the power control parameters. For example, the remote unit 105 can apply some predefined power settings (Po, α) to transmit high-urgency data. Moreover, the remote unit 105 can determine whether the allocated UL resources are allowed / can be used to transmit high-urgency / reliable data. In one embodiment, the remote unit 105 can have a table in which, for different TB sizes, the required number of allocated RBs is defined. In the case where the size of the allocated RBs for low-priority grants supports the packet size of high-urgency data, the remote unit 105 is allowed to transmit data on the allocated UL resources. In another embodiment, the remote unit 105 can use the modulation scheme given for the allocated UL resources and calculate the coding rate for transmitting high-urgency data. In the case where the determined coding rate is lower than a predetermined threshold, the remote unit 105 transmits data on the allocated UL resources.

[0055] For the case where the remote unit 105 has configured grants and dynamically scheduled resources and needs to transmit critical / high-urgency data, depending on certain defined criteria, the remote unit 105 determines which UL resources are used to transmit critical data. For example, if the high-urgency data packet size only fits the dynamically scheduled UL resources, the remote unit 105 uses the dynamically scheduled UL resources. If the high-urgency data packet size only fits the configured UL resources, the remote unit 105 uses the configured UL resources. If the high-urgency data packet size fits both the dynamically scheduled UL resources and the configured UL resources, the remote unit 105 decides based on further criteria. If the high-urgency data packet size fits neither the dynamically scheduled UL resources nor the configured UL resources, the remote unit 105 sends some "high-urgency BSR" together with eMBB (or other non-high-urgency) data on the dynamically allocated UL resources indicating the size of the high-urgency data.

[0056] Moreover, the protocol behavior for the case of supporting packets with different priorities within one bearer / QoS flow can include the remote unit 105 having a PDCP entity that is mapped to several RLC entities / LCHs without duplication.

[0057] Figure 2Depicts a network process 200 for efficient uplink preemption according to an embodiment of the present disclosure. The network process 200 involves a UE 205 and a RAN node 210. Here, the UE 205 may be an embodiment of the remote unit 105. Additionally, the RAN node 210 may be an embodiment of the base station unit 110. Examples of the RAN node 210 include a gNB or other fifth-generation base stations.

[0058] The RAN node 210 sends a first UL grant 215 to the UE 205. At a later time point, but before the UE 205 transmits according to the first UL grant, the RAN node 210 sends a second (dynamic) UL grant 220 to the UE 205. In one embodiment, the first UL grant 215 is a grant related to the configuration of periodic UL resources (e.g., a semi-static grant). In another embodiment, the first UL grant 215 is a dynamic grant that allocates UL resources. The difference between a configured grant and a dynamically scheduled grant is that the resources in a configured grant are scheduled periodically and semi-permanently. In some embodiments, multiple devices may share the periodic resources. In contrast, a dynamic grant is a one-time grant of (non-periodic) resources. Generally, the resources scheduled by a dynamic grant are not shared among multiple devices.

[0059] To handle UL transmissions efficiently, the UE 205 identifies the traffic type associated with "conflicting" UL grants (e.g., UL grants scheduled for the same transmission opportunity - e.g., the same and / or overlapping frames, time slots, TTIs, etc.), and, if necessary, preempts the higher-priority grant type in order to act on the highest-priority traffic type (see block 225).

[0060] For example, the first UL grant 215 may be a dynamic grant. As described above, the UE 205 will typically act on the first received dynamic UL grant before acting on the second received dynamic UL grant. However, in the case where the traffic type associated with the second received dynamic UL grant has a higher priority than the traffic associated with the first received dynamic UL grant, the UE 205 will preempt the first received dynamic UL grant in order to act on the second received dynamic UL grant.

[0061] In another example, the first UL grant 215 may be a configured (e.g., semi-persistent) grant. As described above, the UE 205 will typically act on a dynamic UL grant before acting on a configured UL grant (e.g., the priority of a dynamic grant is higher than that of a configured grant). However, in the case where the traffic type associated with the configured UL grant has a higher priority than the traffic associated with the dynamic UL grant, the UE 205 will preempt the dynamic UL grant (e.g., the second UL grant) in order to act on the configured UL grant.

[0062] As depicted, UE 205 transmits a PUSCH 230 associated with a higher-priority traffic type to RAN node 210. In the first example above, UE 205 transmits a PUSCH 230 associated with the second received UL grant 220 because it is associated with a higher-priority traffic than the first received UL grant 215. In the second example above, UE 205 transmits a PUSCH 230 associated with the configured UL grant because it is associated with a higher-priority traffic in the dynamic UL grant.

[0063] Figure 3 A timing diagram depicting a UL preemption scenario 300 according to an embodiment of the present disclosure is shown. The UL preemption scenario 300 can be implemented at a UE such as remote unit 105 and / or UE 205. At time "t1", the UE receives an allocation of uplink resources (e.g., PUSCH resources) via PDCCH. In Figure 3 the embodiment, it is assumed that the scheduled resources are for normal-priority data and are associated with an initial transmission for a first HARQ process (HARQ#1). Here, the allocation of the uplink resources can be a dynamic grant received via DCI. As depicted, the allocated uplink resources (PUSCH resources) start at time "t2". Thus, the UE transmits data for HARQ#1 in the PUSCH transmission starting at time "t2".

[0064] At time "t3", the UE receives another allocation of uplink resources (e.g., PUSCH resources) via PDCCH. The second grant is also associated with an initial transmission for the first HARQ process (HARQ#1). Here, the allocation of the uplink resources can be a dynamic grant received via DCI. As depicted, the allocated uplink resources (PUSCH resources) start at time "t5".

[0065] At time "t4" (e.g., after receiving the allocation of uplink resources but before time "t5"), the UE receives a preemption DCI allocation resource for high-urgency (or critical) data that at least partially overlaps with the resource allocation scheduled by the grant received at time "t3". In Figure 3 the embodiment, the high-urgency / critical data is associated with an initial transmission for a different HARQ process (e.g., HARQ#2). The DCI received at "t4" preempts the PUSCH transmission scheduled by the DCI received at "t3", so the UE transmits the high-urgency / critical data in the PUSCH resources scheduled at "t5".

[0066] According to the first solution for efficient uplink preemption, two dynamic grants (DCIs) that allocate overlapping PUSCH resources are used to schedule the UE, where the second dynamic grant received later than the first dynamic grant allocates UL resources for high urgency / priority traffic. According to this embodiment, the second (later) DCI that allocates PUSCH resources for high urgency data has a higher priority than the PUSCH resources allocated by the first DCI, i.e., the second DCI preempts the PUSCH transmission previously scheduled by the first DCI. In one example, the gNB schedules the URLLC PUSCH transmission by means of DCI to preempt the PUSCH transmission previously scheduled for eMBB traffic.

[0067] According to this first solution, the UE - for example, the MAC entity of the UE - processes and uses it according to the second (later) received DCI (also referred to as "preemption grant" or "preemption DCI") that schedules PUSCH resources for high urgency / priority / reliability. For the case where the first received DCI (referred to as "preemption grant") is scheduling PUSCH resources for retransmission, i.e., without switching the NDI, the UE can also further execute / process the first received DCI in parallel. More specifically, the MAC entity identifies the HARQ process associated with the preemption grant, generates a MAC PDU according to the transport block size indicated in the grant (assuming the preemption grant requests a new initial transmission), and stores the generated MAC PDU in the associated HARQ buffer. In addition, the MAC entity in the UE generates a retransmission of the TB stored in the HARQ process indicated in the preemption grant, i.e., the MAC passes the TB stored in the HARQ process (Tx buffer) to the physical layer.

[0068] Even though the physical layer may not perform the retransmission of the TB because the priority of the high urgency grant is higher than the preempted retransmission grant (i.e., the physical layer performs the transmission according to the preemption grant), from the perspective of the MAC layer / HARQ protocol, the transmission (retransmission) occurs (this behavior is similar to the case where the PUSCH transmission conflicts with the measurement gap). It should be noted that the assumption for the described behavior is that the HARQ process indicated by the preemption grant is different from the HARQ process addressed by the preempted grant.

[0069] According to one embodiment of the first solution, a UE, e.g., the MAC entity of the UE, can process and execute a second (later) received DCI for scheduling PUSCH resources for high urgency / priority / reliability services, i.e., the "preemption grant / DCI", and for the case where the preempted grant is scheduling an initial new transmission, i.e., in the case of a switched NDI, ignore the first received uplink grant, i.e., the "preempted grant". More specifically, the MAC entity identifies the HARQ process associated with the preemption grant, generates a MAC PDU according to the transport block size indicated in the grant (assuming the preemption grant requests a new initial transmission), and stores the generated MAC PDU in the associated HARQ buffer. Here, the UE (e.g., the MAC entity of the UE) ignores the preempted uplink grant, i.e., treats the preempted grant as not received yet.

[0070] One of the consequences of ignoring the preempted grant is that the grant is not stored for the corresponding HARQ process (even if received), and the NDI signaled within the grant is not used for later NDI comparison, i.e., to determine whether the gNB requests an initial transmission or a retransmission. One motivation for ignoring the preempted grant - i.e., the first received DCI - is that due to processing time constraints, the UE may not be able to complete the generation of the transport block or channel coding / rate matching according to the first received DCI, in addition to the generation / transmission of high-urgency TBs.

[0071] According to another embodiment of the first solution, a UE, e.g., the MAC entity of the UE, processes / executes the preemption grant and also, for the case where the preempted grant is scheduling a new initial transmission, i.e., in the case of a switched NDI, also processes the first received uplink grant, i.e., the "preemption grant". According to this embodiment, the UE will still follow / process the preempted uplink grant, but may interrupt the generation / processing of the transport block while executing / processing the preempted grant. Assume that when the second DCI (i.e., the preemption grant) is received, the UE has already started executing / processing the first received uplink grant, i.e., has already started the LCP. When the UE has sufficient available processing resources, once the generation (and channel coding / rate matching, etc.) of the high-urgency / critical TBs is completed respectively, the processing of the preempted grant can be resumed, e.g., completing the generation of the MAC PDU and storing it in the corresponding HARQ buffer.

[0072] According to another embodiment of the first solution, the UE does not process / execute the received UL grant until a time point when a potential preemption of the UL grant may occur, i.e., a time slot or a PDCCH occasion, e.g., to start the LCP procedure. Before the allocated PUSCH resources can be configured or fixed, i.e., the minimum processing time for the UE for PUSCH transmission, the latest timing of a potential preemption DCI may occur, i.e., a time slot or a PDCCH occasion (e.g., as defined in Section 6.4 of TS 38.214).

[0073] In various embodiments, the MAC entity knows the received DCI that preempts an earlier scheduled PUSCH allocation in order to act according to the above specific behavior, e.g., if the UE has not started processing it (the UE has not started forming the corresponding MAC TB), ignore the preempted grant, or interrupt the processing of the preempted grant after the preempted grant has been processed and resume processing at the next available occasion. In various embodiments, the physical layer indicates to the MAC entity whether the received grant is of high urgency or a preemption DCI, e.g., in addition to the traditional grant information such as TBS, NDI, numerology, RV, etc. Thus, according to the second solution for efficient uplink preemption, the DCI (uplink grant) explicitly indicates that the DCI has a high-urgency / priority PUSCH allocation that (potentially) preempts an earlier overlapping PUSCH allocation.

[0074] According to one embodiment of the second solution, a new RNTI is defined, which indicates that the DCI (uplink grant) for this RNTI is a high-priority / priority DCI that preempts a potentially earlier overlapping PUSCH allocation. In some embodiments, the INT-RNTI that indicates preemption in the DL in the traditional NR specification is also used to indicate UL preemption. According to another embodiment of the second embodiment, one or more fields or the code points of the fields in the DCI are used to indicate high urgency / preemption. In one embodiment, the "UL-SCH indicator" field in the DCI, e.g., DCI format 0-1, is used together with the "CSI request" field to indicate a high-urgency / preemption grant. A value of "0" for the UL-SCH indicator field and a "CSI request" field set to all zeros indicate a high-urgency / preemption DCI.

[0075] In an alternative embodiment of the second solution, the SRS request field set to a predefined value / code point indicates a high-urgency / preemption grant, i.e., in this case, the UE will not perform SRS transmission.

[0076] According to the third solution for efficient uplink preemption, the UE determines whether to use the configured grant allocation or the dynamically scheduled UL resources to transmit high-urgency / critical data based on at least one of the following criteria: packet size, code rate, modulation level, spectral efficiency, and power headroom.

[0077] In various embodiments, the UE considers the data packet size when determining whether to use the configured grant allocation or the dynamically scheduled UL resources for transmitting high-urgency / critical data. If the high-urgency data packet size is only suitable for the dynamically scheduled UL resources, the UE uses the dynamically scheduled UL resources. If the high-urgency data packet size is only suitable for the configured UL resources, the UE uses the configured UL resources.

[0078] If the high-urgency data packet size is suitable for both the dynamically scheduled UL resources and the configured UL resources, the UE determines the UL resources for transmission based on at least one of the following defined options: In the first option, the UE is configured to use which resource (or is fixed by the specification). According to the second option, the UE uses the resource with the lower resulting code rate. According to the third option, the UE uses the resource with the lower rate for the modulation level, and if the modulation levels are the same, it returns to option 2. According to the fourth option, the UE uses the resource with the lower resulting spectral efficiency. According to the fifth option, the UE uses the resource with the larger resulting power headroom.

[0079] If the high-urgency data packet size is not suitable for either the dynamically scheduled UL resources or the configured UL resources, the UE sends some "high-urgency BSR" together with eMBB (or other non-high-urgency) data on the dynamically allocated UL resources, indicating the size of the high-urgency data. Here, the "high-urgency BSR" indicates the size (quantity) of the high-urgency / critical data.

[0080] Figure 4 A timing diagram depicting the UL preemption scenario 400 according to an embodiment of the present disclosure is shown. The UL preemption scenario 400 can be implemented at a UE such as the remote unit 105 and / or the UE 205. At time "t1", the UE receives an allocation of uplink resources (e.g., PUSCH resources) via the PDCCH. In Figure 4 the embodiment, it is assumed that the scheduled resources are for normal-priority data and are associated with the initial transmission for the first HARQ process (HARQ#1). Here, the allocation of the uplink resources can be a dynamic grant received via DCI. As depicted, the allocated uplink resources (PUSCH resources) start at time "t3".

[0081] At time "t2" (e.g., after receiving an uplink resource allocation but before time "t3"), high urgency / critical data arrives at the UE buffer. The arrival of the high urgency / critical data causes the UE to preempt lower priority data and instead use the previously scheduled PUSCH resources to transmit the high urgency / critical data at time "t3".

[0082] According to the fourth solution, the UE can transmit high urgency / critical data on the PUSCH resources allocated for lower priority data. There may be a situation where, when the high urgency / critical data arrives at the UE buffer, PUSCH resources have already been allocated to the UE for eMBB low priority services, for example - these PUSCH resources may have been allocated by DCI. It should be noted that the transmission parameters of the PUSCH resources scheduled by DCI, i.e., MCS, number of RBs, etc., may not be suitable for the transmission of high urgency / critical data. Critical data may require a very reliable transmission, e.g., successful decoding should be possible without any HARQ retransmissions to meet the latency requirements.

[0083] According to one embodiment of the fourth solution, the UE can use the allocated PUSCH resources for the transmission of critical / urgency data. To meet the reliability / QoS requirements of the critical data, the UE can use different uplink transmission parameters, such as modulation scheme, coding rate, TB size, redundancy version, etc., as the parameters scheduled for the PUSCH (by DCI). To facilitate decoding at the gNB and avoid increased blind decoding, when different transmission parameters from those allocated by the scheduler are used for uplink transmission, the UE can include uplink control information (UCI) indicating the transmission parameters used in the PUSCH transmission. Here, the inclusion of UCI will be done at the PHY, e.g., by rate matching. The position of the UCI within the PUSCH resources can be fixed. In some embodiments, the gNB can detect the presence of the UCI based on some CRC attached to the UCI. In some embodiments, the UCI can be located, for example, at the start of the PUSCH resources, e.g., after the first DM-RS, to allow for quick detection of the UCI at the gNB side. The modulation scheme used for the transmission of the UCI can be predefined / configured or fixed in the specification, e.g., always use QPSK.

[0084] According to one embodiment of the fourth solution, when adjusting transmission parameters for PUSCH resource scheduling - for example, TBS, MCS, RV, etc. - the UE can also use different transmission power control parameters compared to the power control parameters that the UE will use for PUSCH transmission according to the scheduling grant. The power control parameters for high urgency / critical transmission - for example, P0 or α - can be different compared to the power control parameters for lower priority data transmission (eMBB). In some embodiments, the power control parameters for high urgency / critical data transmission are predefined / configured or fixed in the specification.

[0085] According to another embodiment of the fourth solution, the UE determines whether it is allowed to use the allocated (low priority) UL resources to transmit high urgency / critical data based on certain criteria. According to one possible embodiment, the UE is configured with a table that indicates the corresponding minimum required number of allocated resource blocks (RBs) for different TB sizes. For the case where the number of RBs of the allocated (low priority) PUSCH resources is greater than or equal to the minimum #RBs given in the table for the TB size required for high urgency data, the UE determines that it is allowed to send critical / high urgency data on the allocated (low priority) PUSCH resources, i.e., with adapted transmission parameters and / or power control parameters. According to an alternative method, the UE uses the modulation scheme scheduled for the allocated (low priority) PUSCH resources and calculates the coding rate for the transmission of high urgency / critical data based on the number of allocated RBs. In the case where the calculated coding rate is lower than a threshold - i.e., the threshold can be fixed or pre-configured - the UE will send data on the dynamically allocated UL resources.

[0086] In the case where the UE determines that it is not allowed to send high urgency / critical data on the dynamically allocated UL resources, for example, the determined coding rate is too high or the number of RBs is too small, the UE can send a "critical data BSR" together with other non-critical data on the dynamically allocated UL resources. This new type of buffer status report ("BSR") indicates the size of the high urgency / critical data to be processed. A new BSR MAC CE format can be introduced for the critical data BSR, which is identified by a reserved logical channel ID.

[0087] In various embodiments, when a UE is configured with uplink resources, i.e., by means of a configured grant, for high urgency / critical data, in the case where they overlap in the time domain, there may be a resource conflict between the configured grant resources and additional dynamic UL allocations (intended for other lower-priority data). If high urgency / critical data is available for transmission in the UE and the UE has dynamically scheduled UL resources in addition to the configured UL resources, it is necessary to define the UE behavior. According to the traditional NR Rel-15 specification, the configured grant allocation is always pre-empted / overridden by the dynamic grant (DCI / PDCCH).

[0088] Figure 5 A network procedure 500 for uplink pre-emption according to an embodiment of the present disclosure is depicted. The network procedure 500 involves a UE 205 and a RAN node 210. As depicted, the UE receives a configured UL grant 505 shared by a plurality of UEs served by the RAN node 210. At some time after receiving the configured UL grant 505, the UE 205 detects the arrival of high urgency / critical data 510. The UE 205 generates a TB 515 with the high urgency / critical data including the C-RNTI. Additionally, the UE 205 transmits a PUSCH transmission 520 of higher-priority data (e.g., high urgency / critical data).

[0089] According to the fifth solution, for high-priority / critical data shared by several UEs, the UE can send high urgency / critical data on, for example, PUSCH resources semi-statically allocated by means of a configured grant. Whenever the emergency / critical data arrives at the UE buffer, the UE uses those configured UL resources for transmitting the critical data. Since the configured resources are not allocated to one UE in a dedicated manner only, but are shared among a group of UEs, the UE includes an identifier, such as the C-RNTI, in the PUSCH transmission to provide information about the UE identity to the gNB.

[0090] Note that the transmission parameters of the PUSCH resources allocated by the configured grant, i.e., MCS, number of RBs, etc., may not always be suitable for the transmission of high urgency / critical data, i.e., there may be different packet sizes. Thus, the UE may use different uplink transmission parameters such as modulation scheme, coding rate, TB size, redundancy version, etc. as the uplink transmission parameters scheduled for the PUSCH (e.g., via the configured grant). To facilitate decoding at the gNB and avoid increased blind decoding, the UE may include uplink control information (UCI) indicating the transmission parameters used in the PUSCH transmission and the UE identity (e.g., C-RNTI). The UCI may also contain the ID of the HARQ process used. The inclusion of the UCI will be done at the PHY, e.g., via rate matching. The position of the UCI within the PUSCH resources may be fixed. In one embodiment, the gNB may detect the presence of the UCI based on some CRC. In some embodiments, the UCI may be located at the start of the PUSCH resources (e.g., after the very first DM-RS) to allow for quick detection of the UCI at the gNB side. The modulation scheme used for the transmission of the UCI may be predefined / configured or fixed in the specification, e.g., QPSK may always be used.

[0091] Figure 6 Depicted is a protocol stack 600 for use with UL preemption in accordance with an embodiment of the present disclosure. The protocol stack 600 may be implemented within a UE such as UE 205. The protocol stack 600 includes a PDCP entity 605 located at the PDCP layer. The PDCP entity 605 is mapped to a plurality of RLC entities, herein a first RLC entity 610 (associated with a first logical channel 615) and a second RLC entity 620 (associated with a second logical channel 625). Herein, the first RLC entity 610 is mapped to normal data, while the second RLC entity 620 is mapped to high urgency data. In the depicted embodiment, each RLC entity 610, 620 is mapped to the same MAC entity 630.

[0092] According to the sixth solution for efficient uplink preemption, in UE 205, one PDCP entity (e.g., PDCP entity 605) can be mapped to multiple RLC entities / logical channels to support packets with different priority / urgency levels within one radio bearer or QoS flow. For example, an IIoT traffic flow can support critical packets within a radio bearer or QoS flow, such as an emergency stop packet. The priority of these critical packets is higher than that of other packets within the same radio bearer or QoS flow. The PDCP entity in the UE receives SDUs with a tag indicating whether a specific SDU is considered critical / high urgency. Such packet tagging can be done by a higher layer such as the application layer or IP layer. The PDCP PDU containing these SDUs will be submitted to another RLC entity (an RLC entity other than the RLC entity for "normal" packets) that processes these critical packets. If there are different levels of criticality / urgency, the PDCP PDU containing these SDUs will be submitted to the RLC entity that processes the corresponding critical / urgency level, e.g., one RLC entity / LCH that supports one level of urgency.

[0093] To make the uplink transmission parameters (including parameter set, PUSCH transmission duration, MCS, etc.) used for PUSCH transmission better match the logical channel (LCH) requirements and enable efficient scheduling of uplink transmissions, the NR system can use multiple single and SR configurations to early indicate to the gNB the type of traffic on the logical channel that triggers SR. The SR configuration can consist of a set of PUCCH resources for SR across different bandwidth parts (BWPs) and serving cells. According to one embodiment of the sixth solution, each LCH of a bearer that supports packets with different priority / urgency levels (e.g., in a radio bearer with multiple associated LCH / RLC entities) can be mapped to zero or one SR configuration. In other words, a radio bearer mapped to multiple LCHs can be mapped to more than one SR configuration. Each SR configuration indicates to the gNB the type of traffic on the logical channel that triggers SR, i.e., certain priority / urgency levels of the data.

[0094] Figure 7The user equipment device 700 depicts operations for uplink preemption that can be used according to an embodiment of the present disclosure. The user equipment device 700 is an embodiment of the remote unit 105 or UE as described above. Additionally, the user equipment device 700 may include a processor 705, a memory 710, an input device 715, an output device 720, and a transceiver 725. In some embodiments, the input device 715 and the output device 720 are combined into a single device, such as a touch screen. In certain embodiments, the user equipment device 700 may not include any input device 715 and / or output device 720. In various embodiments, the user equipment device 700 may include one or more of the processor 705, the memory 710, and the transceiver 725, and may not include the input device 715 and / or the output device 720.

[0095] In one embodiment, the processor 705 may include any known controller capable of executing computer-readable instructions and / or capable of performing logical operations. For example, the processor 705 may be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), a co-processing unit, a field-programmable gate array (“FPGA”), or a similar programmable controller. In some embodiments, the processor 705 executes instructions stored in the memory 710 to perform the methods and routines described herein. The processor 705 is communicatively coupled to the memory 710, the input device 715, the output device 720, and the transceiver 725.

[0096] In various embodiments, the user equipment device 700 (e.g., via the transceiver 725) receives a first allocation of uplink resources in a mobile communication network and receives a second allocation of uplink resources in the mobile communication network. Here, the second allocation overlaps at least partially in time with the first allocation, and the second allocation is received at a time later than the first allocation.

[0097] The processor 705 determines whether the second allocation is associated with a higher-priority service than the first allocation, and in response to the second allocation being associated with a higher-priority service than the first allocation, preempts the first allocation to generate a transport block (TB) according to the second allocation.

[0098] In some embodiments, DCI is used to indicate a second allocation, where the DCI includes a parameter indicating that the second allocation is a high-priority allocation. Here, the first allocation can be a dynamic grant indicated by DCI, or can be a configured grant. In certain embodiments, the parameter indicating a high-priority allocation can be a specific RNTI. In certain embodiments, the parameter indicating a high-priority allocation can be an SRS request field set to a predetermined value. In certain embodiments, the parameter indicating a high-priority allocation can be a UL-SCH indicator field set to a first predetermined value together with a CSI request field set to a second predetermined value.

[0099] In some embodiments, the processor 705 delays processing of the first allocation until a predetermined time before a transmission opportunity corresponding to the uplink resources of the first allocation.

[0100] In some embodiments, pre-empting the first allocation to generate a TB according to the second allocation includes: the processor 705 interrupting the generation of a first TB corresponding to the first allocation to generate a second TB corresponding to the second allocation and, in response to completion of the generation of the second TB, resuming the generation of the first TB.

[0101] In some embodiments, pre-empting the first allocation to generate a TB according to the second allocation includes the processor 705 determining whether the first allocation corresponds to an initial transmission of data or a retransmission of data, and in response to the first allocation corresponding to a retransmission of data, generating a retransmission TB according to the first allocation and delivering the retransmission TB to the transmit buffer.

[0102] In one embodiment, pre-empting the first allocation to generate a TB according to the second allocation includes: the processor 705 ignoring the first allocation in response to the first allocation corresponding to an initial transmission of data. In certain embodiments, the retransmission TB and the TB corresponding to the second allocation belong to different HARQ processes. In certain embodiments, a first DCI is used to indicate the first allocation, and determining whether the first allocation corresponds to an initial transmission of data or a retransmission of data includes: checking the NDI field of the first DCI.

[0103] In one embodiment, the memory 710 is a computer-readable storage medium. In some embodiments, the memory 710 includes a volatile computer storage medium. For example, the memory 710 can include RAM, which includes dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). In some embodiments, the memory 710 includes a non-volatile computer storage medium. For example, the memory 710 can include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. In some embodiments, the memory 710 includes both volatile and non-volatile computer storage media.

[0104] In some embodiments, the memory 710 stores data related to preemptive uplink resource allocation. For example, the memory 710 may store data related to configured grants, dynamic grants, priorities, etc. In certain embodiments, the memory 710 also stores program code and related data, such as an operating system or other controller algorithms operating on the user equipment device 700.

[0105] In one embodiment, the input device 715 may include any known computer input device, including a touch panel, buttons, a keyboard, a stylus, a microphone, etc. In some embodiments, the input device 715 may be integrated with the output device 720, for example, as a touch screen or a similar touch-sensitive display. In some embodiments, the input device 715 includes a touch screen such that a virtual keyboard displayed on the touch screen and / or text can be input by handwriting on the touch screen. In some embodiments, the input device 715 includes two or more different devices, such as a keyboard and a touch panel.

[0106] In one embodiment, the output device 720 is designed to output visual, auditory, and / or tactile signals. In some embodiments, the output device 720 includes an electrically controlled display or a display device capable of outputting visual data to a user. For example, the output device 720 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or a similar display device capable of outputting images, text, etc. to a user. As another non-limiting example, the output device 720 may include a wearable display that is separate from the rest of the user equipment device 700, such as a smart watch, smart glasses, a head-up display, etc., but is communicatively coupled to the rest of the user equipment device 700. In addition, the output device 720 may be a component of a smart phone, a personal digital assistant, a television, a desktop computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, etc.

[0107] In certain embodiments, the output device 720 includes one or more speakers for generating sound. For example, the output device 720 may generate an auditory alert or notification (e.g., a beep or a prompt tone). In some embodiments, the output device 720 includes one or more tactile devices for generating vibration, movement, or other tactile feedback. In some embodiments, all or part of the output device 720 may be integrated with the input device 715. For example, the input device 715 and the output device 720 may form a touch screen or a similar touch-sensitive display. In other embodiments, the output device 720 may be located near the input device 715.

[0108] The transceiver 725 communicates with one or more network functions of a mobile communication network via one or more access networks. The transceiver 725 operates under the control of the processor 705 to transmit messages, data, and other signals, and also to receive messages, data, and other signals. For example, the processor 705 can selectively activate the transceiver (or a portion thereof) at a particular time to send and receive messages.

[0109] The transceiver 725 can include one or more transmitters 730 and one or more receivers 735. Although only one transmitter 730 and one receiver 735 are shown, the user equipment device 700 can have any suitable number of transmitters 730 and receivers 735. Additionally, the transmitters 730 and receivers 735 can be any suitable type of transmitters and receivers. In one embodiment, the transceiver 725 includes a first transmitter / receiver pair for communicating with the mobile communication network on a licensed radio spectrum, and a second transmitter / receiver pair for communicating with the mobile communication network on an unlicensed radio spectrum.

[0110] In certain embodiments, the first transmitter / receiver pair for communicating with the mobile communication network on a licensed radio spectrum and the second transmitter / receiver pair for communicating with the mobile communication network on an unlicensed radio spectrum can be combined into a single transceiver unit, e.g., a single chip that performs functions for use with both licensed and unlicensed radio spectrums. In some embodiments, the first transmitter / receiver pair and the second transmitter / receiver pair can share one or more hardware components. For example, certain transceivers 725, transmitters 730, and receivers 735 can be implemented as physically separate components that access shared hardware resources and / or software resources, such as the network interface 740.

[0111] In various embodiments, one or more transmitters 730 and / or one or more receivers 735 can be implemented and / or integrated into a single hardware component, such as a multi-transceiver chip, a system-on-chip, an ASIC, or other types of hardware components. In certain embodiments, one or more transmitters 730 and / or one or more receivers 735 can be implemented and / or integrated into a multi-chip module. In some embodiments, other components, such as the network interface 740 or other hardware components / circuits, can be integrated with any number of transmitters 730 and / or receivers 735 into a single chip. In such embodiments, the transmitters 730 and receivers 735 can be logically configured as a transceiver 725 that uses one or more common control signals, or as modular transmitters 730 and receivers 735 implemented in the same hardware chip or multi-chip module.

[0112] Figure 8FIG. 800 depicts a method for supporting edge data network discovery according to an embodiment of the present disclosure. In some embodiments, method 800 is performed by a UE such as remote unit 105, UE 205, and / or user equipment device 700. In certain embodiments, method 800 may be performed by a processor (e.g., a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, etc.) executing program code.

[0113] Method 800 begins and receives a first allocation of uplink resources in a mobile communication network (805). Method 800 includes receiving a second allocation of uplink resources (810). Here, the second allocation at least partially overlaps with the first allocation in time, and the second allocation is received at a time later than the first allocation.

[0114] Method 800 includes determining whether the second allocation is associated with a higher priority service than the first allocation (815). Method 800 includes preempting the first allocation to generate a TB according to the second allocation in response to the second allocation being associated with a higher priority service than the first allocation. Method 800 ends.

[0115] According to an embodiment of the present disclosure, a first apparatus for preempting an uplink resource allocation is disclosed herein. The first apparatus may be implemented by a UE such as remote unit 105, UE 205, and / or user equipment device 700. The first device includes a processor and a transceiver that receives a first allocation of uplink resources in a mobile communication network and receives a second allocation of uplink resources. Here, the second allocation is received at a time later than the first allocation, where the second allocation at least partially overlaps with the first allocation in time. The processor determines whether the second allocation is associated with a higher priority service than the first allocation, and in response to the second allocation being associated with a higher priority service than the first allocation, preempts the first allocation to generate a TB according to the second allocation.

[0116] In some embodiments, the second allocation is indicated using DCI, where the DCI includes a parameter indicating that the second allocation is a high-priority allocation. In such a determined case, the parameter indicating that the second allocation is a high-priority allocation may be a specific RNTI. In certain embodiments, the parameter indicating that the second allocation is a high-priority allocation may be an SRS request field set to a predetermined value. In certain embodiments, the parameter indicating that the second allocation is a high-priority allocation may be a UL-SCH indicator field set to a first predetermined value together with a CSI request field set to a second predetermined value.

[0117] In some embodiments, the processor defers processing of the first allocation until a predetermined time before a transmission occasion corresponding to the uplink resources of the first allocation.

[0118] In some embodiments, pre-empting a first allocation to generate a transport block (TB) according to a second allocation includes: a processor interrupting the generation of a first TB corresponding to the first allocation to generate a second TB corresponding to the second allocation, and in response to completion of the generation of the second TB, resuming the generation of the first TB.

[0119] In some embodiments, pre-empting a first allocation to generate a TB according to a second allocation includes: the processor determining whether the first allocation corresponds to an initial transmission of data or a retransmission of data, and in response to the first allocation corresponding to a retransmission of data, generating a retransmission TB according to the first allocation and delivering the retransmission TB to a transmit buffer.

[0120] In one embodiment, pre-empting a first allocation to generate a TB according to a second allocation further includes: ignoring the first allocation in response to the first allocation corresponding to an initial transmission of data. In certain embodiments, the retransmission TB and the TB corresponding to the second allocation belong to different hybrid automatic repeat request (HARQ) processes. In certain embodiments, a first downlink control information (DCI) is used to indicate the first allocation, and determining whether the first allocation corresponds to an initial transmission of data or a retransmission of data includes: checking a new data indicator (NDI) field of the first DCI.

[0121] According to an embodiment of the present disclosure, a first method for pre-empting an uplink resource allocation is disclosed herein. The first method may be performed by a user equipment (UE) such as remote unit 105, UE 205, and / or user equipment device 700. The first method includes receiving a first allocation of uplink resources in a mobile communication network, and receiving a second allocation of uplink resources. Herein, the second allocation at least partially overlaps the first allocation in time, and the second allocation is received at a time later than the first allocation. The first method includes determining whether the second allocation is associated with a higher-priority service than the first allocation, and in response to the second allocation being associated with a higher-priority service than the first allocation, pre-empting the first allocation to generate a TB according to the second allocation.

[0122] In some embodiments, a DCI is used to indicate the second allocation, where the DCI includes a parameter indicating that the second allocation is a high-priority allocation. Herein, the first allocation may be a dynamic grant indicated by a DCI, or may be a configured grant. In certain embodiments, the parameter indicating that the second allocation is a high-priority allocation may include a specific radio radio network temporary identifier (RNTI). In certain embodiments, the parameter indicating that the second allocation is a high-priority allocation may include a sounding reference signal (SRS) request field set to a predetermined value. In certain embodiments, the parameter indicating that the second allocation is a high-priority allocation may include a UL-SCH indicator field set to a first predetermined value together with a CSI request field set to a second predetermined value.

[0123] In some embodiments, the first method includes delaying the processing of the first allocation until a predetermined time before a transmission opportunity corresponding to the uplink resources of the first allocation.

[0124] In some embodiments, pre-empting the first allocation to generate a TB according to a second allocation includes: interrupting the generation of a first TB corresponding to the first allocation to generate a second TB corresponding to the second allocation, and resuming the generation of the first TB in response to completion of the generation of the second TB.

[0125] In some embodiments, pre-empting the first allocation to generate a TB according to a second allocation includes determining whether the first allocation corresponds to an initial transmission of data or a retransmission of data, generating a retransmission TB according to the first allocation in response to the first allocation corresponding to a retransmission of data, and delivering the retransmission TB to a transmit buffer.

[0126] In such an embodiment, pre-empting the first allocation to generate a TB according to a second allocation further includes: ignoring the first allocation in response to the first allocation corresponding to an initial transmission of data. In certain embodiments, the retransmission TB and the TB corresponding to the second allocation belong to different HARQ processes. In certain embodiments, a first DCI is used to indicate the first allocation, and determining whether the first allocation corresponds to an initial transmission of data or a retransmission of data includes checking the NDI field of the first DCI.

[0127] Embodiments may be practiced in other specific forms. The described embodiments should be considered illustrative rather than restrictive in all respects. Accordingly, the scope of the present invention is indicated by the appended claims rather than the foregoing description. All changes that fall within the meaning and range of equivalents of the claims should be included within their scope.

Claims

1. A remote unit (UE) for wireless communication, comprising: At least one memory; And At least one processor, the at least one processor being coupled to the at least one memory and configured to cause the UE to: Receive a first uplink grant associated with a first set of uplink resources, wherein the first uplink grant is a configured uplink grant; Receive a second uplink grant associated with a second set of uplink resources, wherein one or more uplink resources in the second set of uplink resources at least partially overlap with one or more uplink resources in the first set of uplink resources, and wherein the second uplink grant is a dynamic uplink grant; Determine a first priority associated with the first uplink grant based on a first set of data available for transmission using the first uplink grant; Determine a second priority associated with the second uplink grant based on a second set of data available for transmission using the second uplink grant; In response to the second priority being higher than the first priority, prioritize the second uplink grant and deprioritize the first uplink grant; Generate a first transport block ("TB") based on the second uplink grant; and Transmit the first TB using the second set of uplink resources.

2. The UE according to claim 1, wherein, The at least one processor is further configured to cause the UE to: Identify the first set of data available for transmission using the first uplink grant, the first set of data being stored in a buffer of the UE; And Identify the second set of data available for transmission using the second uplink grant, the second set of data being stored in the buffer.

3. The UE according to claim 2, wherein, To identify the first set of data, the at least one processor is configured to cause the UE to perform a logical channel prioritization process to map the first set of data to the first uplink grant, and wherein, to identify the second set of data, the at least one processor is configured to cause the UE to perform a logical channel prioritization process to map the second set of data to the second uplink grant.

4. The UE according to claim 1, wherein, Use downlink control information ("DCI") to indicate the second uplink grant.

5. The UE according to claim 1, wherein, The at least one processor is further configured to cause the UE to: Postpone processing of the first uplink grant until a predetermined time before a transmission opportunity corresponding to the first set of uplink resources of the first uplink grant.

6. The UE according to claim 1, wherein, To deprioritize the first uplink grant, the at least one processor is configured to cause the UE to: Interrupt generation of a second TB corresponding to the first uplink grant to generate the first TB; and Resume generation of the second TB in response to completion of generation of the first TB.

7. The UE according to claim 1, wherein To deprioritize the first uplink grant, the at least one processor is configured to cause the UE to: Determine whether the first uplink grant corresponds to an initial transmission of data or a retransmission of data; In response to the first uplink grant corresponding to a retransmission of data, generate a retransmission transport block (TB) according to the first uplink grant; and deliver the retransmission TB to a transmission buffer.

8. The UE according to claim 7, wherein, To deprioritize the first uplink grant, the at least one processor is configured to cause the UE to: in response to the first uplink grant corresponding to an initial transmission of data, ignore the first uplink grant.

9. The UE according to claim 7, wherein, The retransmission TB and the first TB corresponding to the second uplink grant belong to different hybrid automatic repeat request (HARQ) processes.

10. The UE according to claim 7, wherein, Use first downlink control information (DCI) to indicate the first uplink grant, and wherein, to determine whether the first uplink grant corresponds to an initial transmission of data or a retransmission of data, the at least one processor is configured to cause the UE to: check the new data indicator (NDI) field of the first DCI.

11. A processor for wireless communication, comprising: at least one controller coupled to at least one memory and configured to cause the processor to: Receive a first uplink grant associated with a first set of uplink resources, wherein the first uplink grant is a configured uplink grant; Receive a second uplink grant associated with a second set of uplink resources, wherein one or more uplink resources in the second set of uplink resources at least partially overlap with one or more uplink resources in the first set of uplink resources, and wherein the second uplink grant is a dynamic uplink grant; Determine a first priority associated with the first uplink grant based on a first set of data available for transmission using the first uplink grant; Determine a second priority associated with the second uplink grant based on a second set of data available for transmission using the second uplink grant; In response to the second priority being higher than the first priority, prioritize the second uplink grant and deprioritize the first uplink grant; Generate a first transport block (TB) based on the second uplink grant; and Transmit the first TB using the second set of uplink resources.

12. The processor according to claim 11, wherein the at least one controller is further configured to cause the processor to: Identify the first set of data available for transmission using the first uplink grant, the first set of data being stored in a buffer of the UE; and Identify the second set of data available for transmission using the second uplink grant, the second set of data being stored in the buffer.

13. The processor according to claim 12, wherein, To identify the first set of data, the at least one controller is configured to cause the processor to perform a logical channel prioritization process to map the first set of data to the first uplink grant, and wherein, to identify the second set of data, the at least one processor is configured to cause the UE to perform a logical channel prioritization process to map the second set of data to the second uplink grant.

14. The processor according to claim 11, wherein, Use downlink control information ("DCI") to indicate the second uplink grant.

15. The processor according to claim 11, wherein, The at least one controller is further configured to cause the processor to: defer processing of the first uplink grant until a predetermined time before a transmission occasion corresponding to the first uplink resource set of the first uplink grant.

16. The processor according to claim 11, wherein, To deprioritize the first uplink grant, the at least one controller is configured to cause the processor to: Interrupt generation of a second transport block (TB) corresponding to the first uplink grant to generate a first TB; and Resume generation of the second TB in response to completion of generation of the first TB.

17. The processor according to claim 11, wherein, To deprioritize the first uplink grant, the at least one controller is configured to cause the processor to: Determine whether the first uplink grant corresponds to an initial transmission of data or a retransmission of data; In response to the first uplink grant corresponding to a retransmission of data, generate a retransmission TB according to the first uplink grant; And Deliver the retransmission TB to a transmit buffer.

18. The processor according to claim 17, wherein, Use first downlink control information ("DCI") to indicate the first uplink grant, and wherein, to determine whether the first uplink grant corresponds to an initial transmission of data or a retransmission of data, the at least one controller is configured to cause the processor to: check a new data indicator ("NDI") field of the first DCI, and wherein, to deprioritize the first uplink grant, the at least one controller is configured to cause the processor to: ignore the first uplink grant in response to the first uplink grant corresponding to an initial transmission of data.

19. The processor according to claim 17, wherein, The retransmission TB and the first TB corresponding to the second uplink grant belong to different hybrid automatic repeat request ("HARQ") processes.

20. A method performed by a remote unit (UE), the method comprising: Receiving a first uplink grant associated with a first uplink resource set, wherein the first uplink grant is a configured uplink grant; Receiving a second uplink grant associated with a second uplink resource set, wherein one or more uplink resources in the second uplink resource set at least partially overlap with one or more uplink resources in the first uplink resource set, and wherein the second uplink grant is a dynamic uplink grant; Determining a first priority associated with the first uplink grant based on a first data set available for transmission using the first uplink grant; Determining a second priority associated with the second uplink grant based on a second data set available for transmission using the second uplink grant; In response to the second priority being higher than the first priority, prioritizing the second uplink grant and deprioritizing the first uplink grant; Generating a first transport block ("TB") based on the second uplink grant; and Transmitting the first TB using the second uplink resource set.

Images