Preempting allocation of uplink resources

Abstract

The invention relates to preempting allocation of uplink resources. Apparatuses, methods, and systems for preempting uplink resource allocations are disclosed. An apparatus (700) includes a processor (705) and a transceiver (725) that receives (805) a first allocation of uplink resources in a mobile communication network and receives (810) a second allocation of uplink resources. In this case, the second assignment at least partially overlaps with the first assignment in time, and the second assignment is received at a later time than the first assignment. The processor (505) determines (815) whether the second allocation is associated with higher priority traffic than the first allocation, and in response to the second allocation being associated with higher priority traffic than the first allocation, preempts (820) the first allocation to generate a TB from the second allocation.

Description

[0001] This application is a divisional application of an application which entered the Chinese national phase on March 29, 2021, with PCT application number PCT / IB2019 / 001176, international application date October 31, 2019, Chinese application number 201980064099.2, and invention name “Allocation of preempted uplink resources”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0004] The subject matter disclosed herein relates generally 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 (“5CG”), Access and Mobility Management Function (“AMF”), Positive 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) General System (“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”), Next Generation (5G) Node B (“gNB”), Next Generation Radio Access Network (“NG-RAN”, 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 conjunction 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 procedures and states), Reception ("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"), Transmission ("TX"), Unified Data Management ("UDM"), User Data Repository ("UDR"), Uplink Control Information ("UCI"), User Entity / Equipment (Mobile Terminal) ("UE"), Uplink ("UL"), User Plane ("UP"), Ultra Reliability and Low Latency Communications ("URLLC"), and Worldwide Interoperability for Microwave Access ("WiMAX"). As used herein, "HARQ-ACK" may collectively represent a positive acknowledgement ("ACK") and a negative acknowledgement ("NACK"). ACK means that the TB has been correctly received, while NACK (or NAK) means that the TB has been received in error. ;

[0006] In NR Rel-15, it is not possible to preempt a dynamic uplink grant allocation with another dynamic grant received via DCI, i.e., uplink preemption is not supported. In other words, within a single cell, "out-of-order" scheduling is not supported in Rel-15 for the case of two dynamic grants. Instead, once a DCI for a PUSCH transmission is first received, subsequently received DCIs should correspond to PUSCH transmissions at a later time. Furthermore, for resource conflicts between configured grant resources and dynamically allocated resources, a UE according to the currently specified NR Rel-15 behavior will always give priority to a dynamic grant over a 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 operation for cases of UL prioritization within a UE. For the uplink, a UE may be scheduled with two dynamic uplink grants that allocate overlapping PUSCH resources for data at different priority levels. For example, a gNB may schedule an emergency / critical URLLC PUSCH transmission, e.g., using a high-reliability MCS for transmissions, to preempt a previously scheduled PUSCH transmission intended for lower priority eMBB data. Several embodiments of the present disclosure are related to detailed UE behavior for UL preemption.

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

[0009] Other embodiments involve supporting packets of different priority / urgency levels within a radio bearer or QoS flow. For example, an industrial IoT service flow can support critical packets, such as emergency stop packets, within a radio bearer or QoS flow. These critical data packets have a higher priority than other data packets in the same radio bearer or QoS flow. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] A more particular description of the embodiments briefly described above will be presented by reference to specific embodiments illustrated in the accompanying drawings. Understanding that these drawings depict only some embodiments and are therefore not to be considered limiting of scope, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0011] Figure 1 is a schematic block diagram illustrating one embodiment of a wireless communication system for uplink preemption;

[0012] Figure 2 is a diagram illustrating one embodiment of a network process for uplink preemption;

[0013] Figure 3 is a diagram illustrating one embodiment of the timing of uplink preemption;

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

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

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

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

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

[0019] As will be appreciated by those skilled in the art, aspects of the embodiments may be embodied as systems, devices, methods or program products. Thus, the embodiments may take the form of a complete hardware embodiment, a complete software embodiment (including firmware, resident software, microcode, etc.), or a combination of software and hardware aspects, which may generally be referred to herein as a "circuit," "module," or "system." In addition, the embodiments may take the form of a program product embodied in one or more computer-readable storage devices stored in machine-readable code, computer-readable code, and / or program code, hereinafter referred to as code. The storage device may be tangible, non-temporary, and / or non-transmitting. The storage device may not embody a signal. In a certain embodiment, the storage device employs only a signal for accessing the code.

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

[0021] More specific examples of storage devices (a non-exhaustive list) 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 may be any number of lines and may be written in any combination of one or more programming languages ​​including object-oriented programming languages ​​such as Python, Ruby, Java, Smalltalk, C++, and the like, and traditional procedural programming languages ​​such as the "C" programming language, and / or machine languages ​​such as assembly languages. The code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer, partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network ("LAN") or a wide area network ("WAN"), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0023] References to "one embodiment", "embodiment" or similar language in this specification mean that the specific features, structures or characteristics described in conjunction with the embodiment are included in at least one embodiment. Therefore, unless otherwise expressly stated, the phrases "in one embodiment", "in an embodiment" and similar language appearing throughout the specification may but do not necessarily all refer to the same embodiment, but mean "one or more but not all embodiments". Unless otherwise expressly stated, the terms "including", "comprising", "having" and their variations mean "including but not limited to". Unless otherwise expressly stated, the list of items listed does not imply that any or all items are mutually exclusive. Unless otherwise expressly stated, the terms "one", "an" and "the" also refer to "one or more".

[0024] As used herein, a list with the conjunction "and / or" includes any single item in the list or combination of items in the list. For example, a list of A, B, and / or C includes only A; only B; only C; a combination of A and B; a combination of B and C; a combination of A and C; or a 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 combination of items in the list. For example, one or more of A, B, and C includes only A; only B; only C; a combination of A and B; a combination of B and C; a combination of A and C; or a 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 a combination of A, B, and C. As used herein, "a member selected from the group consisting of A, B, and C" includes one of A, B, or C or only one of them, and excludes a combination of A, B, and C. As used herein, “a member selected from the group consisting of A, B and C and combinations thereof” includes only A; only B; only C; a combination of A and B; a combination of B and C; a combination of A and C; or a combination of A, B and C.

[0025] In addition, the features, structures or characteristics of the described embodiments may be combined in any suitable manner. In the following description, many 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 may be practiced without one or more of the specific details, or 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] Various aspects of the embodiments are described below with reference to schematic flow charts and / or schematic block diagrams of the methods, devices, systems, and program products according to the embodiments. It will be understood that each frame of the schematic flow charts and / or schematic block diagrams and the combination of frames in the schematic flow charts 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, so 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 schematic flow charts and / or schematic block diagram frames.

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

[0028] The code may also be loaded onto a computer, other programmable data processing apparatus, or other device so that a series of operational steps are performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, so 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 block diagram.

[0029] The schematic flow charts and / or schematic block diagrams in the accompanying drawings illustrate possible implementation architectures, functions, and operations of devices, systems, methods, and program products according to various embodiments. In this regard, each box in the schematic flow charts and / or schematic block diagrams may represent a module, segment, or portion of a code, which includes one or more executable instructions of a code for implementing a specified logical function.

[0030] It should also be noted that in some alternative implementations, the functions annotated in the blocks may not occur in the order annotated in the drawings. For example, two blocks shown in succession may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order, depending on the functions involved. Other steps and methods are contemplated that are equivalent in function, logic, or effect to one or more blocks or portions thereof of the illustrated drawings.

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

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

[0033] In general, the present disclosure describes systems, methods, and apparatus for efficient protocol operation for uplink preemption. For the case of UL prioritization within a UE, the present disclosure provides efficient protocol operation. For the uplink ("UL"), a UE may be scheduled with two dynamic uplink grants that allocate overlapping PUSCH resources for data at different priority levels. For example, a gNB may schedule an emergency / critical URLLC PUSCH transmission, e.g., using a highly reliable MCS for transmissions, 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 when there is a conflict in the allocated UL resources. For the UL, the UE may send high priority data (e.g., URLLC) on resources allocated by the configured grant. In addition, the UE may be scheduled by a dynamic UL grant, for example, for transmission of lower priority data such as eMBB, which may result in UL resource conflicts, i.e., the UE has two allocated UL resources when transmitting in the uplink. Recall that a UE according to the currently specified NRRel-15 behavior will always prioritize a dynamic grant (here, associated with lower priority data) over a configured grant (here, associated with higher priority data).

[0035] Other embodiments relate to supporting packets of different priority / urgency levels within one radio bearer or QoS flow. For example, an Industrial IoT ("IIoT") traffic flow may support critical packets, such as emergency stop packets, within a radio bearer or QoS flow. These critical data packets have a higher priority than other data packets in the same radio bearer or QoS flow.

[0036] 3GPP has not yet addressed the first issue mentioned above, i.e., the detailed UE / protocol behavior for UL preemption. Recall that in NR Rel-15, it is not possible to preempt a dynamic uplink grant allocation with another dynamic DCI, i.e., uplink preemption is 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 a PUSCH transmission is received, a later DCI will correspond to a later PUSCH transmission.

[0037] For the second issue mentioned above, i.e., resource conflict between configured grant resources and dynamically allocated resources, a UE according to the currently specified NR Rel-15 behavior will prioritize dynamic grants over configured grants. As mentioned above, this may lead to the problem that the UE will have to use grants that are not suitable for transmitting critical / high urgency packets. In addition, in the currently specified NR Rel-15, there is no support so far for supporting packets of different priorities within the same radio bearer / QoS flow.

[0038] Figure 1 An embodiment of a wireless communication system 100 for efficient protocol operation for uplink preemption according to various embodiments of the present disclosure is depicted. In one embodiment, the wireless communication system 100 includes a remote unit 105, a base unit 110, and a communication link 115. Even in Figure 1 While a specific number of remote units 105, base units 110, and communication links 115 are depicted in the wireless communication system 100, those skilled in the art will recognize that any number of remote units 105, base 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 specification and / or the LTE system specified in the 3GPP. However, more generally, the wireless communication system 100 may implement some other open or proprietary communication network among other networks, such as WiMAX. The present disclosure is not intended to be limited to any particular wireless communication system architecture or protocol implementation.

[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 home appliance (e.g., a home appliance connected to the Internet), a set-top box, a game console, a security system (including a security camera), a car 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. In addition, 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 can communicate directly with one or more base units 110 via uplink (“UL”) and downlink (“DL”) communication signals. In addition, the UL and DL communication signals can 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, the data path for the PDU session may be established on one of a plurality of network slices 138 supported by the mobile core network 130. The particular network slice 138 used by 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 for determining how to route the requested PDU session.

[0042] The base station units 110 may be distributed over a geographic area. In some embodiments, the base station units 110 may also be referred to as RAN nodes, access terminals, base stations, base stations, node Bs, eNBs, gNBs, home node Bs, relay nodes, femtocells, access points, devices, or any other terminology used in the art. The base station units 110 are typically 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 a 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 a “mobile network” or a “mobile communication network”.

[0043] The base station unit 110 can serve multiple remote units 105 within a service area (e.g., a cell or cell sector) via wireless communication links. The base station unit 110 can communicate directly with one or more remote units 105 via communication signals. Typically, the base station unit 110 sends 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 can be carried on the communication link 115. The communication link 115 can be any suitable carrier in a 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") that can be coupled to a data network 150, such as the Internet and a private data network, among other data networks. In some embodiments, the remote unit 105 communicates with an application function ("AF") (external to the mobile core network 130) via a network connection with 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 any particular wireless communication system architecture or protocol implementation. For example, other embodiments of the mobile core network 130 include an enhanced packet core ("EPC") or a multi-service core as described by the Broadband Forum ("BBF").

[0045] The mobile core network 130 includes several network functions ("NFs") and a plurality of 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"). Figure 1 A specific number of NFs are depicted, but 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 plurality of 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 plurality of network slices 138 may implement its own AMF.

[0046] UDM / UDR 132 includes unified data management ("UDM") and its internal component user data repository ("UDR"). UDR stores subscription data including policy data. Specifically, the policy data stored by UDM / UDR 132 includes NSSP. UDM / UDR 132, PCF 134, AMF 136 and SMF (not shown) are examples of control plane network functions of 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, UPF provides data transmission services to remote unit 105.

[0047] Multiple network slices 138 are logical networks within the mobile core network 130. A network slice 138 is a partitioning of 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 communications ("mMTC"), and ultra-reliability and low latency communications ("URLLC"). The mobile core network 130 may 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 called a "slice discriminator") associated with the instance.

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

[0049] In some embodiments, the remote unit 105 may receive a dynamic grant for PUSCH resources that conflicts with (e.g., overlaps) 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 typically has a higher priority than the configured grant, the remote unit 105 here recognizes that the configured grant is associated with higher urgency traffic than the dynamic grant, and therefore preempts the dynamic grant (associated with the lower priority traffic) in order to process and implement the configured grant (associated with the higher priority traffic).

[0050] In some embodiments, the remote unit 105 may support different priorities within the same radio bearer or QoS flow. Here, the remote unit 105 prioritizes higher priority (eg, 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 can be stored in the HARQ transmit buffer for retransmission (similar processing to measurement gaps). However, if the preempted DCI is used to schedule an initial transmission, the remote unit 105 can ignore the preempted DCI and only follow the preempting DCI, e.g., no TB is generated for the preempted lower priority DCI. Note that if processing of the preempted DCI has already begun, the remote unit can suspend (e.g., interrupt) processing of the preempted (low priority) DCI to follow the preempting (high 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, a UL-SCH indicator (e.g., a 1-bit field) in a 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 remote unit's buffer, the remote unit 105 may be allowed to use the scheduled resources for transmission of the high urgency / reliable data. In some embodiments, the remote unit 105 uses a different MCS / TB size than the scheduled MCS / TB size for transmission of the high urgency data. Therefore, the remote unit 105 may also include some UCI (uplink control information) in the allocated resources indicating the MCS for gNB detection.

[0054] Here, UCI includes will be completed at the PHY layer entity. In addition, the UCI position can be fixed so that the base station unit 110 can detect UCI based on CRC check. In some embodiments, UCI is located at the beginning of the PUSCH resource, for example, after the first DM-RS. In some embodiments, the modulation scheme of UCI can be predefined or fixed (for example, always QPSK). In addition, the remote unit 105 can modify the power control parameters. For example, the remote unit 105 can set some predefined power settings (Po, α) to transmit high urgency data. In addition, 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 the required number of allocated RBs is defined for different TB sizes. In the case where the allocated RB size of the low priority license supports the packet size of the 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 code rate for transmitting high urgency data. In the event that the determined code rate is below a predetermined threshold, the remote unit 105 transmits data on the allocated UL resources.

[0055] For the case where the remote unit 105 has a configured grant and dynamically scheduled resources and needs to transmit critical / high urgency data, the remote unit 105 determines which UL resources are used to transmit the critical data, depending on certain defined criteria. For example, if the high urgency data packet size is only suitable for dynamically scheduled UL resources, the remote unit 105 uses the dynamically scheduled UL resources. If the high urgency data packet size is only suitable for the configured UL resources, the remote unit 105 uses the configured UL resources. If the high urgency data packet size is suitable for both dynamically scheduled UL resources and configured UL resources, the remote unit 105 decides based on further criteria. If the high urgency data packet size is neither suitable for dynamically scheduled UL resources nor for 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] Furthermore, protocol behavior for the case of supporting packets of different priorities within one bearer / QoS flow may include a remote unit 105 having one PDCP entity mapped to several RLC entities / LCHs without duplication.

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

[0058] The RAN node 210 sends a first UL grant 215 to the UE 205. At a later point in time, but before the UE 205 transmits in accordance with 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 that involves 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. A configured grant differs from a dynamically scheduled grant in that the resources in the configured grant are periodically and semi-permanently scheduled. In some embodiments, multiple devices can share periodic resources. In contrast, a dynamic grant is a one-time grant of (non-periodic) resources. Typically, resources scheduled by a dynamic grant are not shared between multiple devices.

[0059] To efficiently handle UL transmissions, the UE 205 identifies the traffic types 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 higher priority grant types in order to act on the highest priority traffic type (see box 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 event that 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 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 typically acts on a dynamic UL grant before acting on a configured UL grant (e.g., a dynamic grant has a higher priority than a configured grant). However, in the event that 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, the UE 205 transmits a PUSCH 230 associated with a higher priority traffic type to the RAN node 210. In the first example above, the 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, the UE 205 transmits a PUSCH 230 associated with a configured UL grant because it is associated with a higher priority traffic in a dynamic UL grant.

[0063] Figure 3 A timing diagram of an UL preemption scenario 300 according to an embodiment of the present disclosure is depicted. The UL preemption scenario 300 may 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. Figure 3 In the embodiment of , 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 uplink resources can be a dynamic grant received via DCI. As depicted, the allocated uplink resources (PUSCH resources) start at time "t2". Therefore, the UE sends 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 the PDCCH. The second grant is also associated with an initial transmission for the first HARQ process (HARQ#1). Here, the allocation of uplink resources can be a dynamic grant received via DCI. As depicted, the allocated uplink resources (PUSCH resources) begin at time "t5".

[0065] At time "t4" (e.g., after receiving an allocation of uplink resources, but before time "t5"), the UE receives a preemptive DCI allocation of resources for high urgency (or critical) data that at least partially overlaps with the resource allocation scheduled by the grant received at time "t3". Figure 3 In the embodiment of , 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 sends the high urgency / critical data in the PUSCH resources scheduled at "t5".

[0066] According to a first solution for efficient uplink preemption, a UE is scheduled with two dynamic grants (DCI) allocating overlapping PUSCH resources, whereby a 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 allocating 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 previously scheduled PUSCH transmission (by the first DCI). In one example, the gNB schedules URLLC PUSCH transmissions with the aid of DCI to preempt previously scheduled PUSCH transmissions for eMBB traffic.

[0067] According to this first solution, the UE - for example, the MAC entity of the UE - processes and uses 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 when the first received DCI (referred to as "preemption grant") is scheduling PUSCH resources for retransmission, that is, when the NDI is not switched, 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 transmission block size indicated in the grant (assuming that 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, that is, 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 a retransmission of the TB because the high urgency grant has a higher priority than the preempted retransmission grant (i.e., the physical layer performs the transmission based on the preempted grant), from the perspective of the MAC layer / HARQ protocol, the transmission (retransmission) occurs (the behavior is similar to the case where a PUSCH transmission collides with a measurement gap). It should be noted that the assumption for the described behavior is that the HARQ process indicated by the preempted grant is different from the HARQ process addressed by the preempted grant.

[0069] According to one embodiment of the first solution, the UE, such as the MAC entity of the UE, can process and execute the second (later) received DCI for scheduling PUSCH resources for high urgency / priority / reliability services, i.e., "preemptive grant / DCI", and ignore the first received uplink grant, i.e., "preempted grant", for the situation where the preempted grant is scheduling an initial new transmission, i.e., in the case of switching NDI. More specifically, the MAC entity identifies the HARQ process associated with the preempted grant, generates a MAC PDU according to the transmission block size indicated in the grant (assuming that the preempted 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., the preempted grant is regarded as not yet received.

[0070] One consequence of ignoring a 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 a 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 transport blocks or channel coding / rate matching according to the first received DCI, except for the generation / transmission of high urgency TBs.

[0071] According to another embodiment of the first solution, the UE, such as the MAC entity of the UE, processes / executes the preemption grant and also processes the first received uplink grant, i.e., the "preemption grant", for the situation where the preempted grant is scheduling a new initial transmission, i.e., in the case of switching the NDI. According to this embodiment, the UE will still follow / process the preempted uplink grant, but the generation / processing of the transport block can be interrupted while executing / processing the preempted grant. It is assumed 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., the LCP has been started. When the UE has sufficient available processing resources, once the generation of high urgency / critical TBs (and channel coding / rate matching, etc.) is completed respectively, the processing of the preempted grant can be resumed, for example, the generation of the MAC PDU is completed and stored in the corresponding HARQ buffer.

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

[0073] In various embodiments, the MAC entity is aware of the received DCI that preempts an earlier scheduled PUSCH allocation so as to act according to the specific behavior described above, e.g., ignoring the preempted grant if the UE has not started processing it (the UE has not started forming the corresponding MAC TB), or interrupting processing of the preempted grant after the preempted grant has been processed and resuming processing at the next available opportunity. In various embodiments, the physical layer indicates to the MAC entity whether the received grant is a high urgency or preemptive DCI, e.g., in addition to traditional grant information such as TBS, NDI, numerology, RV, etc. Therefore, 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 that 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 legacy NR specification is also used to indicate UL preemption. According to another embodiment of the second embodiment, one or more fields or 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 - for example, DCI format 0-1 - is used together with the "CSI request" field to indicate 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 implementation of the second solution, the SRS request field set to a predefined value / codepoint indicates a high urgency / preemption grant, ie in this case the UE shall not perform SRS transmission.

[0076] According to a third solution for efficient uplink preemption, the UE determines whether to use configured grant allocation or 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 fits both the dynamically scheduled UL resource and the configured UL resource, the UE determines the UL resource for transmission based on at least one of the options defined below: In a first option, the UE is configured which resource to use (or fixed by the specification). According to a second option, the UE uses a resource with a lower resulting code rate. According to a third option, the UE uses a resource with a modulation level of a lower rate and returns to option 2 if the modulation levels are the same. According to a fourth option, the UE uses a resource with a lower resulting spectral efficiency. According to a fifth option, the UE uses a resource with a larger resulting power headroom.

[0079] If the high urgency data packet size does not fit into the dynamically scheduled UL resources nor the configured UL resources, the UE sends some "high urgency BSR" along with eMBB (or other non-high urgency) data on the dynamically allocated UL resources, indicating the size of the high urgency data. Here, "high urgency BSR" indicates the size (amount) of high urgency / critical data.

[0080] Figure 4 A timing diagram of an UL preemption scenario 400 according to an embodiment of the present disclosure is depicted. The UL preemption scenario 400 may 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. Figure 4 In the embodiment of , 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 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 the 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 send the high urgency / critical data at time "t3" using the previously scheduled PUSCH resources.

[0082] According to the fourth solution, the UE may send high urgency / critical data on PUSCH resources allocated for lower priority data. There may be a situation where, when high urgency / critical data arrives at the UE buffer, the UE has already been allocated PUSCH resources intended for low priority services such as eMBB - 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 very reliable transmission, for example, successful decoding should be possible without any HARQ retransmissions to meet the delay requirements.

[0083] According to one implementation of the fourth solution, the UE may use the allocated PUSCH resources for the transmission of critical / urgent data. In order to meet the reliability / QoS requirements of critical data, the UE may use different uplink transmission parameters, such as modulation scheme, code rate, TB size, redundancy version, etc., as parameters scheduled (by DCI) for PUSCH. In order to facilitate decoding at the gNB and avoid increased blind decoding, when transmission parameters different from those allocated by the scheduler are used for uplink transmission, the UE may 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 by, for example, rate matching. The position of UCI within the PUSCH resource may be fixed. In some embodiments, the gNB may detect the presence of UCI based on some CRC attached to the UCI. In some embodiments, the UCI may be positioned, for example, at the beginning of the PUSCH resource, for example, after the first DM-RS, so as to allow fast detection of UCI at the gNB side. The modulation scheme used for the transmission of UCI may be predefined / configured or fixed in the specification, for example, always using QPSK.

[0084] According to an embodiment of the fourth solution, when adjusting the transmission parameters scheduled for PUSCH resources, such as TBS, MCS, RV, etc., the UE may also use different transmission power control parameters than 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 transmissions, such as P0 or α, may be different than the power control parameters for lower priority data transmissions (eMBB). In some embodiments, the power control parameters for high urgency / critical data transmissions 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 a possible embodiment, the UE is configured with a table indicating 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 #RB given in the table for the required TB size 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 a modulation scheme scheduled for the allocated (low priority) PUSCH resources and calculates a code rate for the transmission of high urgency / critical data based on the number of allocated RBs. In the case where the calculated code 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 case the UE determines that it is not allowed to send high urgency / critical data on the dynamically allocated UL resources, for example, the determined code rate is too high or the number of RBs is too small, the UE may send a "critical data BSR" along with other non-critical data on the dynamically allocated UL resources. This new type of buffer status report ("BSR") indicates the size of the pending high urgency / critical data. A new BSR MAC CE format may 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 configured grants, for high urgency / critical data, there may be a resource conflict between the configured grant resources and the additional dynamic UL allocation (intended for other lower priority data) in case they overlap in the time domain. 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, the UE behavior needs to be defined. According to the legacy NR Rel-15 specifications, the configured grant allocations are always preempted / overwritten by dynamic grants (DCI / PDCCH).

[0088] Figure 5 A network process 500 for uplink preemption according to an embodiment of the present disclosure is depicted. The network process 500 involves a UE 205 and a RAN node 210. As depicted, the UE receives a configured UL grant 505 shared by multiple 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 high urgency / critical data including a C-RNTI. In addition, the UE 205 sends a PUSCH transmission 520 of higher priority data (e.g., high urgency / critical data).

[0089] According to a fifth solution, for high priority / critical data shared by several UEs, the UE may send high urgency / critical data on PUSCH resources semi-statically allocated, for example, with the help of configured grants. Whenever urgent / critical data arrives in the UE buffer, the UE uses those configured UL resources for the transmission of critical data. Because the configured resources are not allocated to only one UE in a dedicated manner, but are shared among a group of UEs, the UE includes an identifier, such as 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 grants, i.e., MCS, number of RBs, etc., may not always be appropriate for the transmission of high urgency / critical data, i.e., there may be different packet sizes. Therefore, the UE may use different uplink transmission parameters such as modulation scheme, code rate, TB size, redundancy version, etc. as uplink transmission parameters scheduled for PUSCH (e.g., allocated by the configured grants). In order 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 as well as 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 by, for example, rate matching. The position of the UCI within the PUSCH resource 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 positioned at the beginning of the PUSCH resource (e.g., after the first DM-RS) to allow fast detection of the UCI at the gNB side. The modulation scheme used for transmission of UCI may be predefined / configured or fixed in the specification, for example, QPSK may always be used.

[0091] Figure 6 A protocol stack 600 for use with UL preemption according to an embodiment of the present disclosure is depicted. The protocol stack 600 can 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 multiple RLC entities, here 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). Here, 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) may be mapped to multiple RLC entities / logical channels to support packets of different priority / urgency levels within one radio bearer or QoS flow. For example, an IIoT service flow may support critical packets within a radio bearer or QoS flow, such as emergency stop packets. These critical packets have a higher priority than other packets within the same radio bearer or QoS flow. The PDCP entity in the UE receives an SDU with a mark indicating whether a particular SDU is considered critical / high urgency. Such packet marking may be done by a higher layer such as an application layer or an IP layer. The PDCP PDU containing these SDUs will be submitted to another RLC entity (an RLC entity other than an RLC entity for "normal" packets) that processes these critical packets. If there are different levels of criticality / urgency levels, the PDCP PDU containing these SDUs will be submitted to the RLC entity that processes the corresponding criticality / urgency level, for example, an RLC entity / LCH that supports one level of urgency.

[0093] In order to enable efficient scheduling of uplink transmissions by making the uplink transmission parameters (including parameter sets, PUSCH transmission duration, MCS, etc.) for PUSCH transmissions more closely match the logical channel (LCH) requirements, the NR system can indicate to the gNB early the type of traffic on the logical channel that triggers SR by using multiple single and SR configurations. The SR configuration can consist of a set of PUCCH resources for SR across different bandwidth parts (BWPs) and serving cells. According to an embodiment of the sixth solution, each LCH of a bearer supporting packets of 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., a certain priority / urgency level of the data.

[0094] Figure 7A user equipment device 700 that can be used for operation of uplink preemption according to an embodiment of the present disclosure is depicted. The user equipment device 700 is an embodiment of a remote unit 105 or UE as described above. In addition, 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 some 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”), an auxiliary 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 receives a first allocation of uplink resources in a mobile communication network (e.g., via the transceiver 725), and receives a second allocation of uplink resources in the mobile communication network, wherein the second allocation at least partially overlaps with the first allocation in time, and the second allocation is received at a later time than the first allocation.

[0097] Processor 705 determines whether the second allocation is associated with higher priority traffic than the first allocation, and in response to the second allocation being associated with higher priority traffic than the first allocation, preempts the first allocation to generate a TB according to the second allocation.

[0098] In some embodiments, the second allocation is indicated using DCI, wherein the DCI includes a parameter indicating that the second allocation is a high priority allocation. Here, the first allocation may be a dynamic grant indicated using the DCI, or may be a configured grant. In some embodiments, the parameter indicating the high priority allocation may be a specific RNTI. In some embodiments, the parameter indicating the high priority allocation may be an SRS request field set to a predetermined value. In some embodiments, the parameter indicating the 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.

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

[0100] In some embodiments, preempting the first allocation to generate a TB according to the second allocation includes: the processor 705 interrupts generation of a first TB corresponding to the first allocation to generate a second TB corresponding to the second allocation and resumes generation of the first TB in response to completing generation of the second TB.

[0101] In some embodiments, preempting 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, generating a retransmission TB according to the first allocation in response to the first allocation corresponding to the retransmission of data, and passing the retransmission TB to the send buffer.

[0102] In one embodiment, preempting the first allocation to generate a TB according to the second allocation includes: the processor 705 ignores the first allocation in response to the first allocation corresponding to an initial transmission of data. In some embodiments, the retransmission TB and the TB corresponding to the second allocation belong to different HARQ processes. In some embodiments, the first allocation is indicated using a first DCI, and wherein determining whether the first allocation corresponds to an initial transmission of data or a retransmission of data includes: checking an 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 volatile computer storage media. For example, the memory 710 may include RAM, which includes dynamic RAM ("DRAM"), synchronous dynamic RAM ("SDRAM"), and / or static RAM ("SRAM"). In some embodiments, the memory 710 includes non-volatile computer storage media. For example, the memory 710 may include a hard drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, the memory 710 includes volatile and non-volatile computer storage media.

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

[0105] In one embodiment, input device 715 may include any known computer input device, including a touch panel, button, keyboard, stylus, microphone, etc. In some embodiments, input device 715 may be integrated with output device 720, for example, as a touch screen or similar touch-sensitive display. In some embodiments, input device 715 includes a touch screen so that text can be input using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. In some embodiments, 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 electronically controlled display or 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 device apparatus 700, such as a smart watch, smart glasses, a head-up display, etc., but is communicatively coupled to the rest of the user device apparatus 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 some embodiments, the output device 720 includes one or more speakers for generating sounds. For example, the output device 720 can generate an audible alarm 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 vibrations, motions, or other tactile feedback. In some embodiments, all or part of the output device 720 can be integrated with the input device 715. For example, the input device 715 and the output device 720 can form a touch screen or a similar touch-sensitive display. In other embodiments, the output device 720 can be located near the input device 715.

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

[0109] The transceiver 725 may 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 may have any suitable number of transmitters 730 and receivers 735. In addition, the transmitter 730 and the receiver 735 may be any suitable type of transmitter and receiver. In one embodiment, the transceiver 725 includes a first transmitter / receiver pair for communicating with a mobile communication network on a licensed radio spectrum, and a second transmitter / receiver pair for communicating with a mobile communication network on an unlicensed radio spectrum.

[0110] In some embodiments, a first transmitter / receiver pair for communicating with a mobile communication network on a licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network on an unlicensed radio spectrum can be combined into a single transceiver unit, for example, 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, some transceivers 725, transmitters 730, and receivers 735 can be implemented as physically separated components that access shared hardware resources and / or software resources, such as a network interface 740.

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

[0112] Figure 8A method 800 for supporting edge data network discovery according to an embodiment of the present disclosure is depicted. In some embodiments, the method 800 is performed by a UE such as a remote unit 105, a UE 205, and / or a user equipment device 700. In certain embodiments, the 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.) that executes 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 later time than the first allocation.

[0114] Method 800 includes determining whether the second allocation is associated with higher priority traffic 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 higher priority traffic than the first allocation (820). Method 800 ends.

[0115] According to an embodiment of the present disclosure, a first device for preempting uplink resource allocation is disclosed herein. The first device can be implemented by a UE such as a remote unit 105, a UE 205 and / or a user equipment device 700. The first device includes a processor and a transceiver, and the transceiver 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 later time than the first allocation, wherein the second allocation overlaps the first allocation at least partially 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, the first allocation is preempted to generate a TB according to the second allocation.

[0116] In some embodiments, the second allocation is indicated using a DCI, wherein 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 some 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 some 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 opportunity corresponding to the uplink resources of the first allocation.

[0118] In some embodiments, preempting the first allocation to generate a TB according to the second allocation includes: the processor interrupting generation of a first TB corresponding to the first allocation to generate a second TB corresponding to the second allocation, and in response to completing generation of the second TB, resuming generation of the first TB.

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

[0120] In one embodiment, preempting the first allocation to generate a TB according to the second allocation further includes: ignoring the first allocation in response to the first allocation corresponding to an initial transmission of data. In some embodiments, the retransmission TB and the TB corresponding to the second allocation belong to different HARQ processes. In some embodiments, the first allocation is indicated using a first DCI, and wherein determining whether the first allocation corresponds to an initial transmission of data or a retransmission of data includes: checking an NDI field of the first DCI.

[0121] According to an embodiment of the present disclosure, a first method for preempting uplink resource allocation is disclosed herein. The first method can be performed by a UE such as a remote unit 105, a UE 205 and / or a 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. Here, the second allocation overlaps at least partially with the first allocation in time, and the second allocation is received at a later time 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, preempting the first allocation to generate a TB according to the second allocation.

[0122] In some embodiments, the second allocation is indicated using DCI, wherein the DCI includes a parameter indicating that the second allocation is a high priority allocation. Here, the first allocation may be a dynamic grant indicated using the DCI, or may be a configured grant. In some embodiments, the parameter indicating that the second allocation is a high priority allocation may include a specific radio RNTI. In some embodiments, the parameter indicating that the second allocation is a high priority allocation may include an SRS request field set to a predetermined value. In some 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 comprises deferring 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, preempting the first allocation to generate a TB according to the second allocation includes interrupting generation of a first TB corresponding to the first allocation to generate a second TB corresponding to the second allocation, and resuming generation of the first TB in response to completing generation of the second TB.

[0125] In some embodiments, preempting the first allocation to generate a TB according to the 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 the retransmission of data, and delivering the retransmission TB to a send buffer.

[0126] In such embodiments, preempting the first allocation to generate a TB according to the second allocation further includes: ignoring the first allocation in response to the first allocation corresponding to an initial transmission of data. In some embodiments, the retransmission TB and the TB corresponding to the second allocation belong to different HARQ processes. In some embodiments, the first allocation is indicated using a first DCI, and wherein determining whether the first allocation corresponds to an initial transmission of data or a retransmission of data includes checking an NDI field of the first DCI.

[0127] Embodiments may be practiced in other specific forms. The described embodiments should be considered in all respects only as illustrative and not restrictive. Therefore, the scope of the present invention is indicated by the appended claims rather than the preceding description. All changes falling within the equivalent meaning and scope of the claims should be included within their scope.

Claims

1. A method comprising: receiving a first allocation of uplink resources in a mobile communications network; receiving a second allocation of uplink resources, wherein the second allocation at least partially overlaps in time with the first allocation, wherein the second allocation is received at a later time than the first allocation; determining whether the second allocation is associated with higher priority traffic than the first allocation; and In response to the second allocation being associated with a higher priority traffic than the first allocation, preempting the first allocation to generate a transport block ("TB") according to the second allocation Wherein, the parameter indicating that the second allocation is a high priority allocation comprises a specific Radio Network Temporary Identifier ("RNTI").

2. The method according to claim 1, further comprising: Processing of the first allocation is deferred until a predetermined time before a transmission opportunity corresponding to the uplink resource of the first allocation.

3. The method according to claim 1, wherein: Preempting the first allocation to generate the TB according to the second allocation includes: interrupting generation of a first TB corresponding to the first allocation to generate a second TB corresponding to the second allocation; and In response to completing the generation of the second TB, resuming the generation of the first TB.

4. The method according to claim 1, wherein: Preempting the first allocation to generate the TB according to the second allocation includes: determining whether the first allocation corresponds to an initial transmission of data or a retransmission of data; In response to the first allocation corresponding to retransmission of data, generating a retransmission TB according to the first allocation; and The retransmitted TB is transferred to the send buffer.

5. The method according to claim 4, wherein: Preempting the first allocation to generate the TB according to the second allocation further includes: ignoring the first allocation in response to the first allocation corresponding to an initial transmission of data.

6. The method according to claim 4, wherein: The retransmission TB and the TB corresponding to the second allocation belong to different hybrid automatic repeat request ("HARQ") processes.

7. The method according to claim 4, wherein: The first allocation is indicated using first downlink control information ("DCI"), and wherein determining whether the first allocation corresponds to an initial transmission of data or a retransmission of data comprises examining a new data indicator ("NDI") field of the first DCI.

8. An apparatus comprising: A transceiver, the transceiver: receiving a first allocation of uplink resources in a mobile communications network; receiving a second allocation of uplink resources, wherein the second allocation at least partially overlaps in time with the first allocation, wherein the second allocation is received at a later time than the first allocation; and A processor, the processor: determining whether the second allocation is associated with higher priority traffic than the first allocation; and In response to the second allocation being associated with higher priority traffic than the first allocation, preempting the first allocation to generate a transport block ("TB") according to the second allocation, wherein the parameter indicating that the second allocation is a high priority allocation includes a specific radio network temporary identifier ("RNTI").

9. The apparatus according to claim 8, further comprising: Processing of the first allocation is deferred until a predetermined time before a transmission opportunity corresponding to the uplink resource of the first allocation.

10. The device according to claim 8, wherein: Preempting the first allocation to generate the TB according to the second allocation includes: interrupting generation of a first TB corresponding to the first allocation to generate a second TB corresponding to the second allocation; and In response to completing the generation of the second TB, resuming the generation of the first TB.

11. The device according to claim 8, wherein: Preempting the first allocation to generate the TB according to the second allocation includes: determining whether the first allocation corresponds to an initial transmission of data or a retransmission of data; In response to the first allocation corresponding to retransmission of data, generating a retransmission TB according to the first allocation; and The retransmitted TB is transferred to the send buffer.

12. The device according to claim 11, wherein Preempting the first allocation to generate the TB according to the second allocation further includes: ignoring the first allocation in response to the first allocation corresponding to an initial transmission of data.

13. The device according to claim 11, wherein: The retransmission TB and the TB corresponding to the second allocation belong to different hybrid automatic repeat request ("HARQ") processes.

14. The device according to claim 11, wherein: The first allocation is indicated using first downlink control information ("DCI"), and wherein determining whether the first allocation corresponds to an initial transmission of data or a retransmission of data comprises examining a new data indicator ("NDI") field of the first DCI.

Images