Preventing Transmissions When Switching Active Uplink Bandwidth Parts

Abstract

Apparatus, method, and system for handling autonomous retransmissions are disclosed. A device (600) includes a transceiver (625) operating on a first BWP. The device (600) includes a processor (605) that generates (805) a first MAC PDU for transmission on a first CG associated with a first HARQ process. The processor (605) deprioritizes (810) the first CG in response to detecting a higher-priority UL transmission that overlaps with the first CG. After deprioritizing the first CG, the processor (605) switches (815) the active BWP from the first BWP to a second BWP. In response to determining that the first CG associated with the first HARQ process is on a BWP different from the second BWP, the processor (605) prevents (825) the first HARQ process from triggering transmission of the first MAC PDU on a second CG associated with the first HARQ process on the second BWP.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit of priority of U.S. Provisional Patent Application No. 62 / 966,957, filed on January 28, 2020, by Joachim Loehr, Ravi Kuchibhotla, and Prateek Basu Mallick, entitled "AUTONOMOUS RETRANSMISSION HANDLING FOR I-IOT DEVICES", which is hereby incorporated by reference. Technical Field

[0003] The subject matter disclosed herein generally relates to wireless communications and, more particularly, to autonomous (i.e., UE - initiated) retransmission handling, e.g., for industrial Internet of Things ("I - IoT") devices. Background Art

[0004] The following abbreviations are defined herein, at least some of which are mentioned in the following description: 3rd Generation Partnership Project (“3GPP”), 5th Generation Core Network (“5GC”), 5th Generation System (“5GS”), Authentication, Authorization and Accounting (“AAA”), Acknowledgment (“ACK”), Access and Mobility Management Function (“AMF”), Antenna Panel (“AP”), Application Programming Interface (“API”), Access Stratum (“AS”), Base Station (“BS”), Code Division Multiple Access (“CDMA”), Core Network (“CN”), Downlink Control Information (“DCI”), Downlink (“DL”), Demodulation Reference Signal (“DM-RS”), Data Radio Bearer (“DRB”), Discontinuous Transmission (“DTX”), Evolved Node-B (“eNB”), Evolved Packet Core (“EPC”), New Generation (i.e., 5G) Node-B (“gNB”), General Packet Radio Service (“GPRS”), Global System for Mobile Communications (“GSM”), Hybrid Automatic Repeat reQuest (“HARQ”), Home Subscriber Server (“HSS”), Identifier (“ID”), Industrial Internet of Things (“IIoT”), Internet of Things (“IoT”), Layer-1 (“L1”, also known as the Physical Layer), Layer 1 Identifier (“L1 ID”), Layer-2 (“L2”, also known as the Link Layer), Layer 2 Identifier (“L2 ID”), Layer-3 (“L3”, also known as the Network Layer), Logical Channel (“LCH”), LCH Priority (“LCP”), Long Term Evolution (“LTE”), Mobility Management Entity (“MME”), Negative Acknowledgment (“NACK” or “NAK”), Non-Access Stratum (“NAS”), Network Slice Selection Assistance Information (“NSSAI”, e.g., a vector value including one or more S-NSSAI values), New Radio (“NR”, 5G radio access technology; also known as “5G NR”), Packet Data Network (“PDN”), Packet Data Unit (“PDU”, used in conjunction with “PDU session”), Packet Data Network Gateway (“P-GW”), Public Land Mobile Network (“PLMN”), Quality of Service (“QoS”), Radio Access Network (“RAN”), Receive (“RX”), Serving Gateway (“S-GW”), Session Management Function (“SMF”), Single Network Slice Selection Assistance Information (“S-NSSAI”), Transport Block (“TB”), Transmit (“TX”), Uplink Control Information (“UCI”), Unified Data Management (“UDM”), User Data Repository (“UDR”), User Entity / Device (mobile terminal) (“UE”), Uplink (“UL”), User Plane (“UP”), Universal Mobile Telecommunications System (“UMTS”), and Worldwide Interoperability for Microwave Access (“WiMAX”).As used herein, "HARQ-ACK" means that HARQ feedback can jointly represent an acknowledgement ("ACK") and a negative acknowledgement ("NACK") as well as a discontinuous transmission ("DTX"). An ACK means that the transport block (TB) has been correctly received, while a NACK (or NAK) means that the TB has been incorrectly received. A DTX means that no TB has been detected.

[0005] In some wireless communication systems, certain logical channels can be deprioritized to support another logical channel. This can result in a situation where a packet (e.g., a TB) is generated for the deprioritized channel but not transmitted. For the case of data for an uplink grant with a low period (e.g., a semi-persistent allocation of uplink resources), this can result in a long delay before transmitting the data on the uplink. Summary of the Invention

[0006] Disclosed are procedures for autonomous (i.e., UE-initiated) (re)transmissions. A method of a UE includes generating a first MAC PDU for transmission on a first UL CG associated with a first HARQ process, the first UL CG being for a first UL BWP. The method includes deprioritizing the first UL CG and not performing the transmission of the generated MAC PDU in response to detecting a higher-priority UL transmission overlapping with the first UL CG. The method includes switching the active UL BWP from the first UL BWP to a second UL BWP after deprioritizing the first UL CG and receiving a second UL CG associated with the first HARQ process on the second UL BWP. In response to determining that the first UL CG associated with the first HARQ process is on a UL BWP different from the second UL BWP, the method includes preventing the first HARQ process from triggering the transmission of the first MAC PDU on the second UL CG. Brief Description of the Drawings

[0007] A more specific description of the embodiments briefly described above will be presented by reference to specific embodiments illustrated in the drawings. Understanding 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 specificity and detail by using the drawings, wherein:

[0008] Figure 1 is a schematic block diagram showing one embodiment of a wireless communication system for handling autonomous retransmissions;

[0009] Figure 2 is a diagram illustrating one embodiment of checking conditions for triggering autonomous retransmissions;

[0010] Figure 3A is a diagram illustrating one embodiment of handling dynamic retransmission grants and autonomous retransmission opportunities;

[0011] Figure 3B is a diagram of an embodiment of the modified HARQ entity behavior;

[0012] Figure 4 is a diagram of an embodiment of handling autonomous retransmission in combination with switching an active bandwidth part;

[0013] Figure 5 is a block diagram of an embodiment of the NR protocol stack;

[0014] Figure 6 is a diagram of an embodiment of a user equipment device;

[0015] Figure 7 is a diagram of an embodiment of a network equipment device; and

[0016] Figure 8 is a flowchart of an embodiment of a method for handling autonomous retransmission. Detailed Description

[0017] As will be understood by those 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.

[0018] For example, the disclosed embodiments can be implemented as hardware circuits, including custom very large scale integration ("VLSI") circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed embodiments can also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, etc. As another example, the disclosed embodiments can include one or more physical or logical blocks of executable code, which can be organized, for example, as objects, procedures, or functions.

[0019] In addition, the embodiments can take the form of a program product embodied in one or more computer-readable storage devices that store 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 contain signals. In certain embodiments, the storage device only uses signals for accessing the code.

[0020] Any combination of one or more computer-readable media may be used. The computer-readable media may be a computer-readable storage medium. The computer-readable storage medium may be a storage device that stores code. The storage device may be, by way of example but not limitation, 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 storage devices would include the following: an electrical connection having one or more wires, a portable computer floppy disk, 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 conventional procedural programming languages such as the “C” programming language, and / or machine languages such as assembly language. The code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the latter case, the remote computer may be connected to the user's computer through any type of network connection including a local area network (“LAN”) or a wide area network (“WAN”), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0023] Furthermore, the described features, structures, or characteristics of the embodiments may be combined in any suitable manner. In the following description, numerous specific details are provided, such as programming examples, 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 with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the embodiments.

[0024] References throughout 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 otherwise expressly specified, appearances of the phrases "in one embodiment", "in an embodiment", and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment, but rather mean "one or more but not all embodiments". Unless otherwise expressly specified, the terms "comprising", "including", "having", and their variants mean "including but not limited to". Unless otherwise expressly specified, a list of items does not mean that any or all of the items are mutually exclusive. Unless otherwise expressly stated, the terms "a", "an", and "the" also mean "one or more".

[0025] As used herein, a list with the conjunction "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 does not include the combination of A, B, and C. As used herein, "a member selected from the group consisting of A, B, and C" includes one and only one of A, B, or C and does not include the 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, 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.

[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 should be understood that each block in the flowchart and / or schematic block diagram, and combinations of blocks in the flowchart and / or schematic block diagram, can be implemented by code. This code can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce 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 / actions specified in the flowchart and / or block diagram.

[0027] The code can also be stored in a storage device that can direct a computer, other programmable data processing device, or other device to operate in a specific manner, such that the instructions stored in the storage device produce instructions that include implementing the functions / actions specified in the schematic flowchart and / or the schematic block diagram.

[0028] The code can also be loaded onto a computer, other programmable data processing device, or other device, so that a series of operation steps are executed on the computer, other programmable device, or other device, thereby producing a computer-implemented process, such that the code executed on the computer or other programmable device provides a process for implementing the functions / actions specified in the flowchart and / or the block diagram.

[0029] The flowcharts and / or block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of devices, systems, methods, and program products according to various embodiments. In this regard, each box in the flowchart and / or block diagram may represent a module, segment, or part of code that includes one or more executable instructions for implementing the specified logical function(s).

[0030] It should also be noted that in some alternative implementations, the functions marked in the boxes may not occur in the order marked in the figures. For example, two consecutive boxes shown may actually be executed substantially simultaneously, or these boxes may sometimes be executed in the reverse order, depending on the functionality involved. Other steps and methods equivalent in function, logic, or effect to one or more boxes or portions thereof shown in the figures may be conceived.

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

[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 element.

[0033] Generally, this disclosure describes systems, methods, and apparatuses for supporting autonomous retransmission. In the context of I-IoT, the term "autonomous retransmission" refers to a situation where a MAC PDU / TB for a CG PUSCH is generated but not transmitted due to de-prioritization of the CG PUSCH. In such a case, the UE can use a subsequent CG PUSCH to transmit the generated / deprioritized MAC PDU without the need for an explicit indication from the network (e.g., DCI for scheduling a retransmission). Although the following discussion uses I-IoT as an exemplary use case, the techniques described herein are applicable to other types of UEs and other use cases.

[0034] According to current 3GPP standards, an I-IoT device (i.e., UE) configured for autonomous retransmission - also referred to as a MAC entity configured with the parameter AutonomousReTx - checks whether autonomous retransmission is triggered on a configured grant (i.e., among other criteria) based on the priority status (deprioritized uplink grant vs. prioritized uplink grant) of the immediately preceding configured uplink grant (i.e., for the same HARQ process). When considering processing time requirements, the immediately preceding configured uplink grant does not necessarily have to be the grant that completed the last transmission attempt.

[0035] Additionally, for the case where two grants have overlapping PUSCH durations due to equal priority of the two grants (the same MAC PDU is scheduled for transmission via both grants), the UE can prioritize the dynamic retransmission grant or the configured uplink grant - for use in autonomous retransmission. The predefined behavior for this case should be that the I-IoT device follows the dynamic uplink grant for scheduling a retransmission.

[0036] Furthermore, the UE behavior in the following situation is not currently explicitly defined in the specification: i.e., when the active bandwidth part changes / switches after the time when the configured uplink grant is deprioritized and before the time instance when autonomous retransmission is in progress. A bandwidth part ("BWP") is a continuous set of physical resource blocks ("PRBs") on a given carrier. These RBs are selected from a continuous subset of the common resource blocks of a given parameter set.

[0037] In some embodiments, the UE can implement autonomous retransmission functionality at the HARQ entity as follows:

[0038] For each uplink grant, the HARQ entity will identify the HARQ process associated with this grant and use it for each identified HARQ process. If the uplink grant is part of a bundle of configured uplink grants and can be used for initial transmission and if no MAC PDU has been obtained for this bundle yet, then if the MAC entity is configured with the parameter autonomousReTx, if the uplink grant is a configured grant of a prioritized uplink grant, and if the previously configured uplink grant for this HARQ process has been deprioritized, the UE obtains a MAC PDU for the HARQ process if the transmission of the obtained MAC PDU has not been performed.

[0039] Note that the UE MAC entity includes a HARQ entity for each serving cell with a configured uplink (including the case when it is configured with supplementaryUplink), which maintains a number of parallel HARQ processes. The number of parallel UL HARQ processes per HARQ entity can be as specified in 3GPP TS 38.214. Each HARQ process supports one TB and each HARQ process is associated with a HARQ process identifier.

[0040] The timeline requirements in TS 38.214 also apply to grants for scheduling retransmissions. The UE autonomous (re)transmission of a deprioritized CG PDU needs to perform almost all actions associated with the retransmission grant (including PHY processes like UCI multiplexing) in addition to DCI processing. Therefore, it is assumed that similar / same timeline requirements also apply to the UE autonomous transmission of deprioritized CG PDUs.

[0041] The UE PUSCH preparation time is described in clause 6.4 of TS 38.214, which is incorporated herein by reference. If the first uplink symbol (including DM-RS) in the PUSCH allocation for the transport block, as defined by the slot offset K2 and the start and length indicator SLIV of the scheduling DCI and including the impact of the timing advance, is not earlier than at symbol L2, where L2 is defined as the symbol whose CP ends after the last symbol of the PDCCH carrying the DCI scheduling the PUSCH proc,2 = max((N2 + d 2,1 )(2048 + 144)·κ2 -μ ·T C , d 2,2)For the next uplink symbol starting from [[ID=]], the UE will transmit a transport block. Note that the UE may ignore scheduling DCI that does not meet the requirement of the preparation time. In addition, some CG period values supported in Release 15 (e.g., sym2, sym7, sym1x14, sym2x14) can be lower than the PUSCH preparation time specified in TS 38.214 (which can be up to 36 symbols). Therefore, in the case of a low CG period, the duration between the deprioritized CG PUSCH and the CG PUSCH for UE autonomous transmission can be short and may not provide sufficient UE processing time.

[0042] To support autonomous retransmission, various solutions are disclosed. In various embodiments, the UE also considers the processing time for preparing for autonomous retransmission to check whether to perform autonomous retransmission. In some embodiments, the condition for triggering autonomous retransmission is that the previously configured uplink grant for the same HARQ process for which a transmission attempt has been made is deprioritized. In some embodiments, for the case when the (multiple) PUSCH durations of two grants overlap, the UE gives priority to the dynamically scheduled retransmission of the deprioritized MAC PDU over the autonomous retransmission on the configured uplink grant.

[0043] In various embodiments, for the case when the retransmission of the deprioritized MAC PDU / TB is dynamically scheduled on a PUSCH resource that is occurring after the configured uplink grant PUSCH on which autonomous retransmission would otherwise be performed (when the PDCCH for scheduling the retransmission is not received), the UE does not perform or cancels the autonomous retransmission on the configured uplink grant. Here, it is assumed that the PDCCH for scheduling the retransmission is not received until a certain predefined time before the first symbol of the PUSCH associated with the configured uplink grant that provides a transmission opportunity for the autonomous retransmission.

[0044] In addition, described herein is the UE behavior for the case when the BWP changes / switches after the time when the configured uplink grant is deprioritized and before the time instance when the autonomous retransmission is in progress. In some embodiments, the autonomous retransmission is cancelled / not performed in the case of a BWP switch. In one implementation, the UE sets the priority status of the configured uplink grant to prioritized when activating the UL BWP. In another specific implementation of this embodiment, the UE clears the HARQ transmission buffer - at least the HARQ buffer of the HARQ process associated with the configured grant - when deactivating the UL BWP.

[0045] In other embodiments, the UE may perform autonomous retransmission for a deprioritized uplink grant / MAC PDU on the newly activated uplink BWP after the BWP has changed. In one implementation, the UE stores the priority status (prioritized / deprioritized) of the configured uplink grant when switching / changing the UL BWP. In another implementation, the HARQ buffer content of the HARQ process associated with the configured grant is maintained.

[0046] A method for a UE device to handle autonomous retransmission includes identifying a first configured uplink grant, determining the priority status of a previously configured uplink grant for which a last transmission attempt was made, and autonomously retransmitting data packets of the previously configured uplink grant during the first configured grant in response to the previously configured uplink grant being deprioritized.

[0047] In some embodiments, the method further includes generating data packets before the previously configured uplink grant, wherein, due to the deprioritization of the previously configured uplink grant, the data packets are not transmitted during the previously configured uplink grant. In certain embodiments, the configured grant period is less than the UE processing time of the UE. In such embodiments, an intermediate configured uplink grant may be scheduled between the first configured uplink grant and the previously configured uplink grant. In some embodiments, the previously configured uplink grant is at least a preconfigured time before the first configured uplink grant, wherein the preconfigured time is greater than or equal to the UE processing time of the UE.

[0048] Another method for a UE device for autonomous retransmission includes identifying a first configured uplink grant, receiving a control signal indicating a dynamic grant for retransmitting a previously configured uplink grant, and retransmitting data packets of the previously configured uplink grant during the dynamic grant instead of during the first configured grant. In some embodiments, the control signal is received before the transmission opportunity corresponding to the first configured uplink grant. In some embodiments, the control signal is received at least a preconfigured time before the first configured uplink grant.

[0049] Figure 1 A wireless communication system 100 for handling autonomous retransmission according to an embodiment of the present disclosure is depicted, e.g., a wireless device for supporting configured grant transmission 130. In one embodiment, the wireless communication system 100 includes at least one remote unit 105, a radio access network (“RAN”) 120, and a mobile core network 140. The RAN 120 and the mobile core network 140 form a mobile communication network. The RAN 120 may be composed of base station units 121, and the remote unit 105 communicates with the base station units 121 using wireless communication links 115. Although in Figure 1A specific number of remote units 105, base station units 121, wireless communication links 115, RAN 120, and mobile core network 140 are depicted, and those skilled in the art will recognize that any number of remote units 105, base station units 121, wireless communication links 115, RAN 120, and mobile core network 140 can be included in the wireless communication system 100.

[0050] In one implementation, the wireless communication system 100 conforms to the 5G system specified in the 3GPP specifications. However, more generally, the wireless communication system 100 can implement some other open or proprietary communication networks, such as LTE or WiMAX, and other networks. The present disclosure is not intended to be limited to the implementation of any specific wireless communication system architecture or protocol.

[0051] In one embodiment, the remote unit 105 can include computing devices such as desktop computers, laptop computers, personal digital assistants (“PDAs”), tablet computers, smart phones, smart TVs (e.g., Internet-connected TVs), smart devices (e.g., Internet-connected devices), set-top boxes, gaming consoles, security systems (including security cameras), in-vehicle computers, network devices (e.g., routers, switches, modems), etc. In some embodiments, the remote unit 105 includes wearable devices such as smart watches, fitness bands, optical head-mounted displays, etc. Additionally, the remote unit 105 can be referred to as a UE, subscriber unit, mobile device, mobile station, user, terminal, mobile terminal, fixed terminal, subscriber station, user terminal, wireless transmit / receive unit (“WTRU”), device, or by other terms used in the art.

[0052] The remote unit 105 can communicate directly with one or more base station units 121 in the RAN 120 via uplink (“UL”) and downlink (“DL”) communication signals. Additionally, the UL and DL communication signals can be carried over the wireless communication link 115. Here, the RAN 120 is an intermediate network that provides the remote unit 105 with access to the mobile core network 140.

[0053] In some embodiments, the remote unit 105 communicates with the application server 151 via a network connection to the mobile core network 140. For example, an application 107 (e.g., a web browser, a media client, a phone / VoIP application) in the remote unit 105 may trigger the remote unit 105 to establish a PDU session (or other data connection) with the mobile core network 140 via the RAN 120. The mobile core network 140 then uses the PDU session to relay traffic between the remote unit 105 and the application server 151 in the packet data network 150. The PDU session represents a logical connection between the remote unit 105 and the UPF 141. To establish a PDU session, the remote unit 105 must register with the mobile core network. Note that the remote unit 105 may establish one or more PDU sessions (or other data connections) with the mobile core network 140. Thus, the remote unit 105 may simultaneously have at least one PDU session for communicating with the packet data network 150 and at least one PDU session for communicating with another data network (not shown).

[0054] The base station units 121 may be distributed over a geographical area. In certain embodiments, the base station units 121 may also be referred to as access terminals, access points, bases, base stations, Node Bs, eNBs, gNBs, home Node Bs, relay nodes, or any other term used in the art. The base station units 121 are typically part of a radio access network (“RAN”), such as the RAN 120, which may include one or more controllers communicatively coupled to one or more respective base station units 121. These and other elements of the radio access network are not shown, but are generally known to those of ordinary skill in the art. The base station units 121 are connected to the mobile core network 140 via the RAN 120.

[0055] The base station unit 121 may serve multiple remote units 105 within a service area, such as a cell or a cell sector, via a wireless communication link 115. The base station unit 121 may communicate directly with one or more remote units 105 via communication signals. Generally, the base station unit 121 transmits DL communication signals to serve the remote units 105 in the time domain, frequency domain, and / or spatial domain. Additionally, the DL communication signals may be carried on the wireless communication link 115. The wireless communication link 115 may be any suitable carrier in licensed or unlicensed radio spectrum. The wireless communication link 115 facilitates communication between one or more remote units 105 and / or one or more base station units 121.

[0056] In one embodiment, the mobile core network 140 is a 5G Core (“5GC”) or an Evolved Packet Core (“EPC”), which may be coupled to packet data networks 150, such as the Internet and private data networks, as well as other data networks. The remote unit 105 may have a subscription or other account with the mobile core network 140. Each mobile core network 140 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.

[0057] The mobile core network 140 includes a number of network functions (“NFs”). As shown, the mobile core network 140 includes one or more User Plane Functions (“UPFs”) 141. The mobile core network 140 also includes multiple control plane functions, including but not limited to an Access and Mobility Management Function (“AMF”) 143 serving the RAN 120, a Session Management Function (“SMF”) 145, a Policy Control Function (“PCF”) 147, and a Unified Data Management Function (“UDM”) 149. In various embodiments, the mobile core network 140 may also include an Authentication Server Function (“AUSF”), a Network Repository Function (“NRF”) (used by various NFs to discover and communicate with each other via APIs), a Network Exposure Function (“NEF”), or other NFs defined for the 5GC. In certain embodiments, the UDM is quasi-collocated with a User Data Repository (“UDR”), shown as a combined element “UDM / UDR” 149.

[0058] In various embodiments, the mobile core network 140 supports different types of mobile data connections and different types of network slices, where each mobile data connection utilizes a specific network slice. Here, a “network slice” refers to a portion of the mobile core network 140 optimized for a specific traffic type or communication service. Each network slice includes a set of CP and / or UP network functions. A network instance may be identified by an S-NSSAI, while the set of network slices that the remote unit 105 is authorized to use is identified by an NSSAI. In certain embodiments, various network slices may include separate instances of network functions, such as the SMF 145 and the UPF 141. In some embodiments, different network slices may share some common network functions, such as the AMF 143. Figure 1 The different network slices are not shown but are assumed to be supported.

[0059] Although Figure 1A specific number and type of network functions are depicted, but those skilled in the art will recognize that any number and type of network functions may be included in the mobile core network 140. Additionally, in the case where the mobile core network 140 is an EPC, the depicted network functions may be replaced with appropriate EPC entities, such as an MME, S-GW, P-GW, HSS, etc. In some embodiments, the mobile core network 140 may include an AAA server.

[0060] In various embodiments, the remote unit 105 may be configured with one or more configured grants ("CGs"), e.g., a single grant that allocates multiple non-consecutive resources. In some embodiments, a CG is a semi-persistent allocation of uplink resources, where the UL resources are allocated according to a certain period. The remote unit 105 with a configured grant may still receive one or more dynamic grants. In some embodiments, a CG is only used for a certain LCH or set of LCHs. Here, data for other LCHs will use other uplink resources such as, for example, dynamic grants to communicate. Additionally, each remote unit 105 may be configured with one or more bandwidth parts ("BWPs").

[0061] As discussed above, the currently defined autonomous retransmission functionality does not consider processing timing requirements for retransmission preparation / transmission. Thus, the currently specified behavior by 3GPP may result in situations where autonomous retransmission is not triggered due to some misdefined condition / criterion. Additionally, the UE behavior in response to receiving a PDCCH that schedules retransmission of a de-prioritized TB has not been fully discussed / specified. As another issue, for the case where a BWP switch occurs after a CG has been de-prioritized, the UE behavior with respect to autonomous retransmission has not been defined / discussed.

[0062] As a first solution, the remote unit 105 considers processing timing requirements for retransmission preparation when determining whether to trigger an autonomous retransmission. One criterion for triggering an autonomous retransmission is that a previously configured uplink grant for the same HARQ process for which a transmission attempt of a MAC PDU was made is de-prioritized, e.g., not prioritized. By checking the status (prioritized / deprioritized grant) of the configured grant for which the last transmission attempt of a MAC PDU was made, the processing timing requirements are implicitly considered. The earlier configured uplink grant whose prioritization status (prioritized or de-prioritized) is checked should be at least a pre-configured time, e.g., T proc,2 (as defined in TS38.214).

[0063] By considering the processing time requirements in the preparation for retransmission among other criteria for triggering autonomous retransmission, the remote unit 105 avoids the situation where autonomous retransmission is not triggered due to a misdefined condition / criterion. Additionally, if the previously configured uplink grant for the same HARQ process for which a transmission attempt has been made is deprioritized, the remote unit 105 inherently takes into account the processing timing requirements of the transmission attempt.

[0064] As a second solution, the remote unit 105 prioritizes the dynamic scheduling of retransmission of the deprioritized MAC PDU over the autonomous retransmission of the deprioritized MAC PDU. This applies to the case where two granted PUSCH resources overlap, and also applies to the case where the PDCCH - received until a certain preconfigured time before the configured uplink grant PUSCH for autonomous retransmission - is scheduling the PUSCH resource for a retransmission that occurs after the configured uplink grant PUSCH on which autonomous retransmission will be performed.

[0065] As a third solution, for the case where a handover occurs after the configured uplink BWP has been deprioritized and before autonomous retransmission is performed, the remote unit 105 cancels / does not perform autonomous retransmission. In a first implementation of the third solution, the remote unit 105 flushes the corresponding HARQ buffer when deactivating the old active BWP. In an alternative implementation of the third solution, the remote unit 105 can store the priority status (prioritized / deprioritized) of the configured uplink grant when switching / changing the UL BWP, and then can perform autonomous retransmission for the deprioritized uplink grant / MAC PDU on the newly activated uplink BWP after the BWP has changed.

[0066] Although Figure 1 depicting the components of 5G RAN and 5G core network, the described embodiments for handling autonomous retransmission are applicable to other types of communication networks, including IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA2000, Bluetooth, ZigBee, Sigfox, etc. For example, in an LTE variant involving EPC, the AMF 143 can be mapped to the MME, the SMF can be mapped to the control plane part of the PGW and / or mapped to the MME, the UPF is mapped to the user plane parts of the SGW and PGW, the UDM / UDR is mapped to the HSS, etc.

[0067] In the following description, the term RAN node is used for a base station, but it may be replaced by any other radio access node such as a BS, eNB, gNB, AP, NR, etc. Furthermore, the operations are mainly described in the context of 5G NR. However, the proposed solution / method is equally applicable to other mobile communication systems that support autonomous (i.e., UE-initiated) (re)transmissions.

[0068] Figure 2 Depict a protocol stack 200 according to an embodiment of the present disclosure. Although Figure 2 A UE 205, a RAN node 211, and a 5G core network 207 are shown, but they represent a collection of remote units 105 that interact with a base station unit 121 and a mobile core network 140. The 5G core network 207 includes one or more 5G network functions such as an AMF 143. As depicted, the protocol stack 200 includes a user plane protocol stack 201 and a control plane protocol stack 203. The user plane protocol stack 201 includes a physical (“PHY”) layer 215, a media access control (“MAC”) sublayer 220, a radio link control (“RLC”) sublayer 225, a packet data convergence protocol (“PDCP”) sublayer 230, and a service data adaptation protocol (“SDAP”) layer 235. The control plane protocol stack 203 also includes the physical layer 215, the MAC sublayer 220, the RLC sublayer 225, and the PDCP sublayer 230. The control plane protocol stack 210 also includes a radio resource control (“RRC”) layer and a non-access stratum (“NAS”) layer 245.

[0069] The AS protocol stack for the control plane protocol stack 203 is composed of at least the RRC, PDCP, RLC, and MAC sublayers and the physical layer. The AS protocol stack for the user plane protocol stack 201 is composed of at least the SDAP, PDCP, RLC, and MAC sublayers and the physical layer. The second layer (“L2”) is divided into the SDAP, PDCP, RLC, and MAC sublayers. The third layer (“L3”) includes the RRC sublayer 240 and the NAS layer 245 for the control plane, and includes, for example, an internet protocol (“IP”) layer or a PDU layer (as depicted) for the user plane. L1 and L2 are referred to as “lower layers”, whereas L3 and higher layers (e.g., transport layer, application layer) are referred to as “higher layers” or “upper layers”.

[0070] The physical layer 215 provides a transport channel to the MAC sublayer 220. The MAC sublayer 220 provides a logical channel to the RLC sublayer 225. The RLC sublayer 225 provides an RLC channel to the PDCP sublayer 230. The PDCP sublayer 230 provides a radio bearer to the SDAP sublayer 235 and / or the RRC layer 240. The SDAP sublayer 235 provides a QoS flow to the mobile core network 140 (e.g., 5GC). The RRC layer 240 provides addition, modification, and release for carrier aggregation and / or dual connectivity. The RRC layer 240 also manages the establishment, configuration, maintenance, and release of signaling radio bearers ("SRB") and data radio bearers ("DRB"). The NAS layer 245 is used to convey non-radio signaling between the UE 205 and, for example, the AMF in the 5G core network 207 (or the MME for LTE / EPS scenarios).

[0071] Figure 3A Depict a first scenario 300 for handling autonomous retransmission according to an embodiment of the present disclosure. The first scenario 300 involves a UE 205 configured for autonomous retransmission (i.e., the MAC entity is configured with the parameter autonomousReTx), which may be an implementation of the aforementioned remote unit 105. As previously discussed, the UE 205 may be an I-IoT device. However, the first solution is not limited to I-IoT devices, but may also be performed by other types of UEs configured for autonomous retransmission.

[0072] In the first scenario 300, the UE 205 has a first UL-configured grant ("CG") associated with a first HARQ process. The UE 205 uses the first CG to prepare (e.g., generate) a TB (i.e., a MAC PDU) for transmission at time t1. As depicted, the first resource 320 of the first CG may overlap in time with the first dynamic grant 315, e.g., the two grants may have an overlapping PUSCH duration, i.e., at time t1. In the depicted embodiment, the first occurrence of the configured grant (i.e., the first resource 320) is deprioritized to support the dynamic grant ("DG") 315 that overlaps with the first CG.

[0073] As discussed above, the current standard requires a UE configured for autonomous retransmission to check whether an autonomous retransmission is triggered on a configured grant based on the priority status (deprioritized uplink grant / prioritized uplink grant) of the previously configured uplink grant for the same HARQ process. However, the duration between the deprioritized configured grant and the next available configured grant for the same HARQ process may not provide sufficient UE processing time.

[0074] According to the first solution, when checking the conditions for triggering an autonomous retransmission, UE 205 checks whether a previously configured uplink for which UE 205 has made a transmission attempt has been deprioritized.

[0075] As pointed out above, considering the processing time T of UE 205 proc,2 , i.e., the time required to prepare for an autonomous retransmission, the duration between the deprioritized configured grant 320 and the next available configured grant 325 for the same HARQ process may not provide sufficient UE processing time. Therefore, the autonomous retransmission of the deprioritized MAC PDU will not occur on the next configured grant PUSCH 325 following the deprioritized configured uplink grant (i.e., at time t2), but potentially on the subsequently configured grant PUSCH 330, i.e., at least T after the deprioritized CG PUSCH 320 proc,2 at the first available time (i.e., at time t3).

[0076] As Figure 3A depicted in, when checking the conditions for triggering an autonomous retransmission, UE 205 does not check whether a previously configured uplink grant for this HARQ process has been deprioritized, but instead checks whether a previously configured uplink for which UE 205 has made a transmission attempt has been deprioritized. Note that in scenario 300, the configured grant (“CG1”) period is less than the UE processing time; thus, the last CG opportunity may not be the deprioritized UL grant 320. However, by checking the last transmission attempt, UE 205 is able to determine that the first occurrence of the configured grant resource 320 has been deprioritized.

[0077] According to the first solution, one of the conditions for triggering an autonomous retransmission is that a previously configured uplink grant for the same HARQ process for which a transmission attempt has been made has been deprioritized. According to one implementation of the first solution, UE205, e.g., a MAC entity configured with autonomousReTx, checks whether a previously configured uplink grant for the same HARQ process for which a transmission attempt has been made has been deprioritized to determine whether to trigger an autonomous retransmission. The earlier configured uplink grant 320 whose prioritization status (prioritized or deprioritized) is being checked should be at least a preconfigured time, e.g., T, before the configured uplink grant 330 to be used for the autonomous retransmission. proc,2 .

[0078] Figure 3BShows an example of a modified HARQ entity behavior 350 according to an embodiment of the present disclosure. In one embodiment, the modified HARQ entity behavior 350 includes a modification 355 to the HARQ entity behavior described in clause 5.4.2.1 of 3GPP TS 38.321. In some embodiments, a first solution can be implemented in 3GPP by modifying the MAC entity behavior to specify whether the previously configured uplink grant for this HARQ process, which is considered the last transmission attempt for which the MAC PDU was made, is deprioritized, rather than considering whether the previously configured uplink grant for this HARQ process is deprioritized.

[0079] In an alternative implementation of the first solution, the UE 205 determines that the symbol immediately following the last symbol of the PUSCH for it is at least some preconfigured time (e.g., at least T proc,2 ) before the first symbol of the currently configured granted PUSCH (i.e., for the same HARQ process), which is the earliest of the previously configured uplink grants (for the same HARQ process) when moving backwards in time from the currently configured uplink grant for the same HARQ process. The UE 205 further checks whether the determined previously configured uplink grant is deprioritized. Only when this previously configured uplink is deprioritized does the UE 205 consider triggering an autonomous retransmission, i.e., depending on other defined criteria for triggering an autonomous retransmission.

[0080] Figure 4 Depicts a second scenario 400 for autonomous retransmission according to an embodiment of the present disclosure. The second scenario 400 involves a UE 205 configured for autonomous retransmission, which can be an implementation of the aforementioned remote unit 105. As previously discussed, the UE 205 can be an I-IoT device. However, the second solution is not limited to I-IoT devices but can also be performed by other types of UEs configured for autonomous retransmission.

[0081] In the second scenario 400, the UE 205 has a first UL configured grant (“CG1”). The UE 205 uses the first GC to prepare (e.g., generate) a TB (i.e., a MAC PDU) for transmission at time t1. As depicted, the first resource 320 of the first CG can overlap in time with the first dynamic grant 315, e.g., the two grants can have an overlapping PUSCH duration, i.e., at time t1. As discussed above, the current standard does not define the UE behavior for the case where a dynamic retransmission grant and a configured uplink grant - for autonomous retransmission - have an overlapping PUSCH duration.

[0082] According to the second solution, for the case where the durations of two permitted (multiple) PUSCHs overlap and the priorities of the two permits are equal (e.g., in the case of scheduling the same MAC PDU for transmission through two permits), UE 205 will prioritize dynamically scheduled retransmissions (i.e., retransmissions scheduled by the PDCCH) over autonomous retransmissions on the configured uplink permit. Therefore, UE 205 prioritizes the dynamic uplink permit 315 that schedules the dynamic retransmission permit over the configured uplink permit 320 for autonomous retransmission. In the case where the priorities of the permits are not equal, UE 205 may follow whichever permit has a higher priority. In the depicted embodiment, the first-occurring configured permit (i.e., the first resource 320) is deprioritized to support the dynamic permit ("DG") 315 that overlaps with the first CG.

[0083] At time t2, UE 205 receives - via the PDCCH 405 - DCI that schedules a retransmission of a data packet (e.g., MAC PDU) generated for the first CG. This corresponds to the DG 415 with UL resources at time t4. However, note that the second occurrence 410 of the first CG at time t3 provides an autonomous retransmission opportunity - i.e., for transmitting the deprioritized MAC PDU / TB. The second occurrence 410 of the first CG (also referred to as the configured uplink permit PUSCH 410) occurs at a specified time (i.e., according to the CG period) after the first-occurring configured permit resource 320.

[0084] According to one implementation of the second solution, for the case where the (multiple) PUSCH durations overlap and the HARQ processes scheduled by the two permits are the same, UE 205 - i.e., a MAC entity configured with lch-basedPrioritization - prioritizes the dynamic permit for retransmission over, for example, the configured permit for autonomous retransmission.

[0085] According to another implementation of the second solution, for the case where a retransmission of a MAC PDU / TB is dynamically scheduled on the PUSCH resource 415 that is occurring after the configured uplink permit PUSCH 410 on which autonomous retransmission would otherwise be performed (when no PDCCH scheduling the retransmission is received), UE 205 does not perform (e.g., cancels) the autonomous retransmission on the configured uplink permit. Here, it is assumed that the PDCCH 405 scheduling the retransmission is received at least some predefined time (e.g., T override ) before the first symbol of the PUSCH 410 associated with the configured uplink permit that provides a transmission opportunity for the autonomous retransmission.

[0086] As Figure 4As shown, the PDCCH 405 for scheduling the retransmission of the deprioritized MAC PDU (i.e., HARQ process) is received before the deadline (i.e., the preconfigured time T before the start of the configured uplink grant PUSCH 410 for autonomous retransmission). override Therefore, the UE 205 does not use the configured uplink grant PUSCH 410 to perform an autonomous retransmission (e.g., cancels the autonomous retransmission), which would otherwise be performed in the absence of a PDCCH.

[0087] Figure 5 Depicts a third scenario 500 for autonomous retransmission according to an embodiment of the present disclosure. The third scenario 500 relates to a UE 205 configured for autonomous retransmission, which may be an implementation of the aforementioned remote unit 105. As previously discussed, the UE 205 may be an I-IoT device. However, the third solution is not limited to I-IoT devices, but may also be performed by other types of UEs configured for autonomous retransmission.

[0088] In the third scenario 500, the UE 205 has a first UL CG for a first UL BWP 503. The UE 205 uses the first GC to prepare (e.g., generate) a TB (i.e., MAC PDU) for transmission at time t1. As depicted, the first resource 320 of the first CG may overlap in time with the first dynamic grant 315. As described above, the two grants may have overlapping PUSCH durations, e.g., at time t1. As discussed above, the UE behavior in the following situation is not currently defined in the specification: i.e., when the BWP changes / switches after the time when the configured uplink grant is deprioritized and before the time instance when the autonomous retransmission occurs.

[0089] According to the third solution, for the case where the active uplink BWP changes after the time instance when the configured uplink grant is deprioritized and before the autonomous retransmission is performed, the UE 205 does not perform an autonomous retransmission.

[0090] In the depicted scenario 300, the UE 205 prioritizes the dynamic uplink grant 315 that schedules the dynamic retransmission grant over the configured uplink grant 320, e.g., due to the detection of a higher-priority UL transmission (i.e., the dynamic uplink grant 315) that overlaps in time with the first resource 320 of the first CG. Here, it is assumed that the first CG is associated with the first HARQ process.

[0091] At time t2, after time instance t1 when the configured uplink grant 320 is deprioritized (and not transmitted) and before time t3 of the second resource 515 of the first CG for the autonomous retransmission opportunity, the UE 205 switches 510 its active UL BWP, for example, from the first BWP 503 to the second BWP 505. Here, each BWP 503, 505 is a subset of the overall carrier bandwidth 501. Switching the active UL BWP means deactivating the first BWP 503 and activating the second BWP 505, such that the second BWP 505 becomes the active UL BWP.

[0092] In the depicted scenario 300, the UE 205 does not use the second resource 515 of the first CG for the autonomous retransmission opportunity to transmit the previously generated MAC PDU / TB because the first BWP 503 is no longer active. Additionally, a second UL configured grant (depicted as "CG2") for the second uplink BWP 505 associated with the first HARQ process has been allocated for the UE 205. Here, it is assumed that the BWP switch 510 occurs sufficiently before the next occurring UL resource 520 of the second CG to allow for the preparation of the TB.

[0093] However, in response to determining that the previous UL CG associated with the first HARQ process is on a UL BWP different from the second UL BWP, the UE 205 does not consider that the MAC PDU has been obtained, i.e., does not perform an autonomous transmission of the deprioritized MAC PDU / TB. In other words, the UE 205 does not indicate that the first HARQ process triggers the transmission of the MAC PDU, thereby preventing the transmission of the MAC PDU on the PUSCH resource 520 of the second CG.

[0094] According to some embodiments of the third solution, the UE 205 resets / initiates the priority status (prioritized / deprioritized) of each uplink configured grant when switching the UL BWP. In one particular implementation, the UE 205 sets the priority status of the configured uplink grant to prioritized when activating the UL BWP. In another particular implementation, the UE 205 clears the HARQ transmission buffer - at least the HARQ buffer of the HARQ process associated with the configured grant - when deactivating the UL BWP. Additionally, the UE 205 may further stop the CG-timer (configured grant timer).

[0095] According to an alternative embodiment, the criterion for triggering / executing an autonomous retransmission is evaluated between the configured uplink grant at the current time and the deprioritized previously configured uplink grant, regardless of whether the BWP has changed between them. Following this alternative embodiment, the UE 205 can perform an autonomous retransmission for the deprioritized uplink grant / MAC PDU on the newly activated uplink BWP after the BWP has changed. Note that the autonomous retransmission can only be performed when the newly active BWP has the same uplink grant configuration as the CG configuration, since the previously active BWP for the configured uplink grant is deprioritized. For example, the first CG and the second CG have the same transport block size (“TBS”).

[0096] According to one implementation of the alternative embodiment, the UE 205 stores the priority status (prioritized / deprioritized) of the configured uplink grant when switching / changing the UL BWP. According to one implementation of the alternative embodiment, the UE 205 maintains the HARQ buffer content of the HARQ process associated with the configured uplink grant when switching / changing the UL BWP.

[0097] Figure 6 A user equipment device 600 that can be used to handle autonomous retransmissions according to an embodiment of the present disclosure is depicted. In various embodiments, the user equipment device 600 is used to implement one or more of the above solutions. The user equipment device 600 can be an embodiment of the remote unit 105 and / or the UE 205 as described above. Additionally, the user equipment device 600 can include a processor 605, a memory 610, an input device 615, an output device 620, and a transceiver 625.

[0098] In some embodiments, the input device 615 and the output device 620 are combined into a single device, such as a touch screen. In certain embodiments, the user equipment device 600 may not include any input device 615 and / or output device 620. In various embodiments, the user equipment device 600 can include one or more of the following: the processor 605, the memory 610, and the transceiver 625, and may not include the input device 615 and / or the output device 620.

[0099] As depicted, transceiver 625 includes at least one transmitter 630 and at least one receiver 635. Here, transceiver 625 communicates with one or more cells supported by one or more base station units 121. Additionally, transceiver 625 may support at least one network interface 640 and / or application interface 645. The (multiple) application interfaces 645 may support one or more APIs. The (multiple) network interfaces 640 may support 3GPP reference points such as Uu and PC5. As would be understood by one of ordinary skill in the art, other network interfaces 640 may be supported.

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

[0101] In various embodiments, processor 605 controls user equipment device 600 to implement the above-described UE behavior. For example, when transceiver 625 operates on a first BWP, processor 605 generates a first MAC PDU for transmission on a first UL CG associated with a first HARQ process, where the first UL CG is for the first UL BWP. Here, the first BWP may include a first UL BWP and a first DL BWP.

[0102] Processor 605 deprioritizes the first UL CG in response to detecting a higher-priority UL transmission that overlaps with the first UL CG. Here, deprioritizing the first UL CG includes not performing the transmission of the generated MAC PDU. After deprioritizing the first UL CG, processor 605 switches the active UL BWP from the first UL BWP to a second UL BWP. Here, switching from the first UL BWP to the second UL BWP includes deactivating the first UL BWP and also activating the second UL BWP. Note that switching the active BWP may include processor 605 retuning and / or reconfiguring transceiver 625 from operating on the first UL BWP to operating on the second UL BWP. Via transceiver 625, processor 605 receives a second UL CG associated with the first HARQ process on the second UL BWP. In certain embodiments, the first UL CG and the second UL CG have the same transport block size.

[0103] The processor 605 prevents the first HARQ process from triggering the transmission of the first MAC PDU on the second UL CG in response to determining that the first UL CG associated with the first HARQ process is on a UL BWP different from the second UL. In some embodiments, preventing the first HARQ process from triggering the transmission of the first MAC PDU on the second UL CG may include the processor 605 not indicating that the HARQ process triggers the transmission of the MAC PDU. Additionally, in response to determining that the first UL CG associated with the first HARQ process is on a UL BWP different from the second UL BWP, the processor 605 may disregard that the MAC PDU has been obtained.

[0104] In some embodiments, the processor 605 clears the HARQ buffer for the HARQ process associated with the first UL CG when deactivating the first BWP. In some embodiments, the processor 605 stops the CG timer associated with the first UL CG in response to switching from the first BWP to the second BWP. Note that the BWP may include a UL BWP and a DL BWP. In some embodiments, the processor 605 activates the second UL CG, which was previously associated with the second BWP, in response to switching from the first BWP to the second BWP.

[0105] In some embodiments, the processor 605 associates the HARQ buffer of the first UL CG with the second UL CG when receiving the second UL CG. In some embodiments, the processor 605 prioritizes the second UL CG in response to switching from the first BWP to the second BWP. In some embodiments, the processor 605 transfers the deprioritized state of the first UL CG to the second UL CG in response to switching from the first BWP to the second BWP.

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

[0107] In some embodiments, the memory 610 stores data related to handling autonomous retransmissions. For example, the memory 610 may store MAC PDUs, BWP configurations, UL resource configurations, CG configurations, etc. In certain embodiments, the memory 610 also stores program code and related data, such as an operating system or other controller algorithms running on the device 600.

[0108] In one embodiment, the input device 615 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 615 may be integrated with the output device 620, for example, as a touch screen or a similar touch-sensitive display. In some embodiments, the input device 615 includes a touch screen such 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, the input device 615 includes two or more different devices, such as a keyboard and a touch panel.

[0109] In one embodiment, the output device 620 is designed to output visual, auditory, and / or tactile signals. In some embodiments, the output device 620 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 620 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 620 may include a wearable display separated from the rest of the user equipment device 600 but communicatively coupled thereto, such as a smartwatch, smart glasses, a heads-up display, and so on. Additionally, the output device 620 may be a component of a smartphone, a personal digital assistant, a television, a desktop computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, etc.

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

[0111] The transceiver 625 includes at least a transmitter 630 and at least one receiver 635. One or more transmitters 630 can be used to provide UL communication signals, such as the UL transmissions described herein, to the base station unit 121. Similarly, as described herein, one or more receivers 635 can be used to receive DL communication signals from the base station unit 121. Although only one transmitter 630 and one receiver 635 are illustrated, the user equipment device 600 can have any suitable number of transmitters 630 and receivers 635. Additionally, the (multiple) transmitters 630 and the (multiple) receivers 635 can be any suitable type of transmitter and receiver. In one embodiment, the transceiver 625 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 the mobile communication network on an unlicensed radio spectrum.

[0112] In some embodiments, the first transmitter / receiver pair for communicating with a 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, such as a single chip that performs functions for both the 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 625, transmitters 630, and receivers 635 can be implemented as physically separate components that access shared hardware resources and / or software resources, such as the network interface 640.

[0113] In various embodiments, one or more transmitters 630 and / or one or more receivers 635 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 some embodiments, one or more transmitters 630 and / or one or more receivers 635 can be implemented and / or integrated into a multi-chip module. In some embodiments, other components, such as the network interface 640, or other hardware components / circuits can be integrated with any number of transmitters 630 and / or receivers 635 into a single chip. In such embodiments, the transmitters 630 and receivers 635 can be logically configured as a transceiver 625 that uses a more common control signal, or implemented as modular transmitters 630 and receivers 635 that are implemented in the same hardware chip or multi-chip module.

[0114] Figure 7Depicts an embodiment of a network device apparatus 700 that can be used to handle autonomous retransmissions according to an embodiment of the present disclosure. In some embodiments, the network device apparatus 700 can be an embodiment of a RAN node and its supporting hardware, such as the base station unit 121, RAN node 211, and / or gNB as described above. Additionally, the network device apparatus 700 can include a processor 705, a memory 710, an input device 715, an output device 720, and a transceiver 725. In certain embodiments, the network device apparatus 700 does not include any input device 715 and / or output device 720.

[0115] As depicted, the transceiver 725 includes at least one transmitter 730 and at least one receiver 735. Here, the transceiver 725 communicates with one or more remote units 105. Additionally, the transceiver 725 can support at least one network interface 740 and / or application interface 745. The (multiple) application interfaces 745 can support one or more APIs. The (multiple) network interfaces 740 can support 3GPP reference points, such as Uu, N1, N2, and N3. As will be understood by those of ordinary skill in the art, other network interfaces 740 can be supported.

[0116] In one embodiment, the processor 705 can include any known controller capable of executing computer-readable instructions and / or capable of performing logical operations. For example, the processor 705 can 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.

[0117] In various embodiments, the processor 705 controls the network device apparatus 700 to implement the RAN node behavior described above. For example, the processor 705 can support one or more serving cells for a UE. In various embodiments, the transceiver 725 can configure a CG for the UE as described herein. Additionally, the processor 705 can configure one or more BWPs for the UE as described herein.

[0118] 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, including 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 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.

[0119] In some embodiments, the memory 710 stores data related to processing autonomous retransmissions, such as storing UE identifiers, BWP configurations, UL resource configurations, CG configurations, etc. In certain embodiments, the memory 710 also stores program code and related data, such as an operating system (“OS”) or other controller algorithms running on the network device apparatus 700, as well as one or more software applications.

[0120] 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 text can be input using a virtual keyboard displayed on the touch screen and / or 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.

[0121] In one embodiment, the output device 720 may include any known electronically controllable display or display device. The output device 720 may be designed to output visual, auditory, and / or tactile signals. In some embodiments, the output device 720 includes an electronic display capable of outputting visual data to a user. Additionally, 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.

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

[0123] As discussed above, transceiver 725 can communicate with one or more remote units and / or with one or more network functions providing access to one or more PLMNs. Transceiver 725 operates under the control of processor 705 to transmit messages, data, and other signals and also to receive messages, data, and other signals. For example, processor 705 can selectively activate transceiver (or a portion thereof) at a particular time to facilitate sending and receiving messages.

[0124] Transceiver 725 can include one or more transmitters 730 and one or more receivers 735. In certain embodiments, one or more transmitters 730 and / or one or more receivers 735 can share transceiver hardware and / or circuitry. For example, one or more transmitters 730 and / or one or more receivers 735 can share (multiple) antennas, (multiple) antenna tuners, (multiple) amplifiers, (multiple) filters, (multiple) oscillators, (multiple) mixers, (multiple) modulator / demodulators, power supplies, etc. In one embodiment, transceiver 725 implements multiple logical transceivers using different communication protocols or protocol stacks while using common physical hardware.

[0125] Figure 8 An embodiment of a method 800 for handling autonomous retransmission in accordance with embodiments of the present disclosure is depicted. In various embodiments, method 800 is performed by a UE such as remote unit 105, UE 205, and / or user equipment device 600 described above. In some embodiments, method 800 is performed by a processor such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0126] Method 800 begins and generates 805 a first MAC PDU for transmission on a first UL CG associated with a first HARQ process, the first UL CG being for a first UL BWP. Method 800 includes deprioritizing 810 the first UL CG in response to detecting a higher-priority UL transmission that overlaps with the first UL CG and not performing the transmission of the generated MAC PDU. Here, deprioritizing 810 the first UL CG in response to detecting a higher-priority UL transmission that overlaps with the first UL CG includes not performing the transmission of the generated MAC PDU.

[0127] Method 800 includes switching 815 the active UL BWP from the first UL BWP to a second UL BWP after deprioritizing the first UL CG. Method 800 includes receiving 820 a second UL CG associated with the first HARQ process on the second UL BWP. In response to determining that the first UL CG associated with the first HARQ process is on a UL BWP different from the second UL BWP, the first method includes preventing 825 the first HARQ process from triggering the transmission of the first MAC PDU on the second UL CG. Method 800 ends.

[0128] Disclosed herein is a first apparatus for handling autonomous retransmission according to an embodiment of the present disclosure. The first apparatus may be implemented by a UE such as the aforementioned remote unit 105, UE 205, and / or user equipment apparatus 600. The first apparatus includes a transceiver operating on a first BWP. Here, the first BWP may include a first UL BWP and a first DL BWP. The first apparatus includes a processor that generates a first MAC PDU for transmission on a first UL CG associated with a first HARQ process, the first UL CG being for a first UL BWP. The processor deprioritizes the first UL CG in response to detecting a higher-priority UL transmission that overlaps with the first UL CG. Here, deprioritizing the first UL CG includes not performing the transmission of the generated MAC PDU (i.e., the first MAC PDU). The processor switches the active UL BWP from the first UL BWP to a second UL BWP after deprioritizing the first UL CG and receives a second UL CG associated with the first HARQ process on the second UL BWP. The processor prevents triggering the transmission of the first MAC PDU on the second UL CG in response to determining that the first UL CG associated with the first HARQ process is on a UL BWP different from the second UL BWP.

[0129] In some embodiments, the processor clears the HARQ buffer for the HARQ process associated with the first UL CG when deactivating the first UL BWP. In some embodiments, the processor stops the CG timer associated with the first UL CG in response to a handover from the first UL BWP to the second UL BWP. In some embodiments, the processor activates the second UL CG, which was previously associated with the second UL BWP, in response to a handover from the first UL BWP to the second UL BWP. In certain embodiments, the first UL CG and the second UL CG have the same transport block size.

[0130] In some embodiments, the processor associates the HARQ buffer of the first UL CG with the second UL CG when receiving the second UL CG. In some embodiments, the processor prioritizes the second UL CG in response to a handover from the first UL BWP to the second UL BWP. In some embodiments, the processor transfers the deprioritized state of the first UL CG to the second UL CG in response to a handover from the first UL BWP to the second UL BWP.

[0131] Disclosed herein is a first method for handling an autonomous retransmission according to an embodiment of the present disclosure. The first method may be performed by a UE such as the remote unit 105, UE 205, and / or user equipment device 600 described above. The first method includes generating a first MAC PDU for transmission on a first UL CG associated with a first HARQ process, the first UL CG being for a first UL BWP. The first method includes deprioritizing the first UL CG and not performing the transmission of the generated MAC PDU (i.e., the first MAC PDU) in response to detecting a higher-priority UL transmission overlapping with the first UL CG. The first method includes switching the active UL BWP from the first UL BWP to the second UL BWP after deprioritizing the first UL CG and receiving a second UL CG associated with the first HARQ process on the second UL BWP. In response to determining that the first UL CG associated with the first HARQ process is on a UL BWP different from the second UL BWP, the first method includes preventing the first HARQ process from triggering the transmission of the first MAC PDU on the second UL CG.

[0132] In some embodiments, the first method includes clearing the HARQ buffer for the HARQ processes associated with the first UL CG when deactivating the first UL BWP. In some embodiments, the first method includes stopping the CG timer associated with the first UL CG in response to a handover from the first UL BWP to the second UL BWP. In some embodiments, the first method includes activating a second UL CG, which was previously associated with the second UL BWP, in response to a handover from the first UL BWP to the second UL BWP. In certain embodiments, the first UL CG and the second UL CG have the same transport block size.

[0133] In some embodiments, the first method includes associating the HARQ buffer of the first UL CG with the second UL CG when receiving the second UL CG. In some embodiments, the first method includes prioritizing the second UL CG in response to a handover from the first UL BWP to the second UL BWP. In some embodiments, the first method includes transferring the deprioritized state of the first UL CG to the second UL CG in response to a handover from the first UL BWP to the second UL BWP.

[0134] Embodiments may be practiced in other specific forms. The described embodiments are to be considered in all respects only illustrative and not restrictive. Thus, the scope of the present invention is indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

1. A method for a remote unit, comprising: generating a first MAC PDU for transmission on a grant CG of a first uplink UL configuration associated with a first HARQ process, the first UL CG for a first UL bandwidth part BWP; deprioritizing the first UL CG and not performing the transmission of the first MAC PDU in response to detecting a higher-priority UL transmission overlapping with the first UL CG; switching an active UL BWP from the first UL BWP to a second UL BWP after deprioritizing the first UL CG; receiving a second UL CG associated with the first HARQ process on the second UL BWP; and preventing the first HARQ process from triggering the transmission of the first MAC PDU on the second UL CG in response to determining that the first UL CG associated with the first HARQ process is on a UL BWP different from the second UL BWP.

2. The method according to claim 1, further comprising clearing a hybrid automatic repeat request HARQ buffer for a HARQ process associated with the first UL CG when deactivating the first UL BWP.

3. The method according to claim 1, further comprising stopping a CG timer associated with the first UL CG in response to switching from the first UL BWP to the second UL BWP.

4. The method according to claim 1, further comprising activating the second UL CG, which was previously associated with the second UL BWP, in response to switching from the first UL BWP to the second UL BWP.

5. The method according to claim 1, wherein, The first UL CG and the second UL CG have the same transport block size.

6. The method according to claim 1, further comprising associating a hybrid automatic repeat request HARQ buffer of the first UL CG with the second UL CG when receiving the second UL CG.

7. The method according to claim 1, further comprising prioritizing the second UL CG in response to switching from the first UL BWP to the second UL BWP.

8. The method according to claim 1, further comprising transferring a deprioritized state of the first UL CG to the second UL CG in response to switching from the first UL BWP to the second UL BWP.

9. An apparatus, comprising: a transceiver that operates on a first uplink UL bandwidth part BWP; and a processor, wherein the processor: generates a first MAC PDU for transmission on a grant CG of a first UL configuration associated with a first HARQ process, the first UL CG for the first UL BWP; deprioritizes the first UL CG and does not perform the transmission of the first MAC PDU in response to detecting a higher-priority UL transmission overlapping with the first UL CG; After deprioritizing the first UL CG, switch the active UL BWP from the first UL BWP to the second UL BWP; Receive, on the second UL BWP, a second UL CG associated with the first HARQ process; and In response to determining that the first UL CG associated with the first HARQ process is on a UL BWP different from the second UL BWP, prevent the first HARQ process from triggering transmission of the first MAC PDU on the second UL CG.

10. The device according to claim 9, wherein, When deactivating the first UL BWP, the processor further clears the hybrid automatic repeat request (HARQ) buffer for the HARQ process associated with the first UL CG.

11. The apparatus according to claim 9, wherein, In response to switching from the first UL BWP to the second UL BWP, the processor further stops the CG timer associated with the first UL CG.

12. The device according to claim 9, wherein, In response to switching from the first UL BWP to the second UL BWP, the processor further activates the second UL CG, which was previously associated with the second UL BWP.

13. The apparatus according to claim 9, wherein, The first UL CG and the second UL CG have the same transport block size.

14. The apparatus according to claim 9, wherein, When receiving the second UL CG, the processor further associates the HARQ buffer of the first UL CG with the second UL CG.

15. The apparatus according to claim 9, wherein, In response to switching from the first UL BWP to the second UL BWP, the processor further prioritizes the second UL CG.

16. The apparatus according to claim 9, wherein, In response to switching from the first UL BWP to the second UL BWP, the processor further transfers the deprioritized state of the first UL CG to the second UL CG.

Images