Systems and methods for reduced capability user equipment in non-terrestrial networks for handling downlink / uplink channel collisions

Abstract

Systems and methods for reduced capability (RedCap) user equipment (UE) in non-terrestrial networks (NTNs) for handling downlink (DL) / uplink (UL) channel collisions are discussed herein. In some cases, a RedCap UE identifies that a configured grant small data transmission (CG-SDT) scheduled in a UL collides with a semi-statically configured reception scheduled in a DL, determines that a performance of one of the CG-SDT and the semi-statically configured reception will not prevent the RedCap UE from monitoring a system information (SI) change indication during a current modification period; and performing one of the CG-SDT and the semi-statically configured reception in response to identifying that the CG-SDT collides with the semi-statically configured reception and determining that the performance of the one of the CG-SDT and the semi-statically configured reception will not prevent the RedCap UE from the monitoring of the SI change indication. Various other cases involving other collision types are also discussed.

Description

SYSTEMS AND METHODS FOR REDUCED CAPABILITY USER EQUIPMENT IN NON-TERRESTRIAL NETWORKS FOR HANDLING DOWNLINK / UPLINK CHANNEL COLLISIONSTECHNICAL FIELD

[0001] This application relates generally to wireless communication systems, including wireless communication systems implementing non-terrestrial network (NTN) communications for reduced capability (RedCap) user equipments (UEs) .BACKGROUND

[0002] Wireless mobile communication technology uses various standards and protocols to transmit data between a base station and a wireless communication device. Wireless communication system standards and protocols can include, for example, 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) (e.g., 4G) , 3GPP New Radio (NR) (e.g., 5G) , and Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard for Wireless Local Area Networks (WLAN) (commonly known to industry groups as  ) .

[0003] As contemplated by the 3GPP, different wireless communication systems'standards and protocols can use various radio access networks (RANs) for communicating between a base station of the RAN (which may also sometimes be referred to generally as a RAN node, a network node, or simply a node) and a wireless communication device known as a user equipment (UE) . 3GPP RANs can include, for example, Global System for Mobile communications (GSM) , Enhanced Data Rates for GSM Evolution (EDGE) RAN (GERAN) , Universal Terrestrial Radio Access Network (UTRAN) , Evolved Universal Terrestrial Radio Access Network (E-UTRAN) , and / or Next-Generation Radio Access Network (NG-RAN) .

[0004] Each RAN may use one or more radio access technologies (RATs) to perform communication between the base station and the UE. For example, the GERAN implements GSM and / or EDGE RAT, the UTRAN implements Universal Mobile Telecommunication System (UMTS) RAT or other 3GPP RAT, the E-UTRAN implements LTE RAT (sometimes simply referred to as LTE) , and NG-RAN implements NR RAT (sometimes referred to herein as 5G RAT, 5G NR RAT, or simply NR) . In certain deployments, the E-UTRAN may also implement NR RAT. In certain deployments, NG-RAN may also implement LTE RAT.

[0005] A base station used by a RAN may correspond to that RAN. One example of an E-UTRAN base station is an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly denoted as evolved Node B, enhanced Node B, eNodeB, or eNB) . One example of an NG-RAN base station is a next generation Node B (also sometimes referred to as a g Node B or gNB) .

[0006] A RAN provides its communication services with external entities through its connection to a core network (CN) . For example, E-UTRAN may utilize an Evolved Packet Core (EPC) while NG-RAN may utilize a 5G Core Network (5GC) .

[0007] Frequency bands for 5G NR may be separated into two or more different frequency ranges. For example, Frequency Range 1 (FR1) may include frequency bands operating in sub-6 gigahertz (GHz) frequencies, some of which are bands that may be used by previous standards, and may potentially be extended to cover new spectrum offerings from 410 megahertz (MHz) to 7125 MHz. Frequency Range 2 (FR2) may include frequency bands from 24.25 GHz to 52.6 GHz. Note that in some systems, FR2 may also include frequency bands from 52.6 GHz to 71 GHz (or beyond) . Bands in the millimeter wave (mmWave) range of FR2 may have smaller coverage but potentially higher available bandwidth than bands in FR1. Skilled persons will recognize these frequency ranges, which are provided by way of example, may change from time to time or from region to region.BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0008] To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced.

[0009] FIG. 1 illustrates a non-terrestrial network (NTN) architecture of a wireless communication system, according to an embodiment.

[0010] FIG. 2 illustrates an NTN architecture of a wireless communication system, according to an embodiment.

[0011] FIG. 3 illustrates an example schedule involving multiple collisions at a RedCap UE.

[0012] FIG. 4 illustrates an example schedule involving a collision at a RedCap UE between a CSS scheduled PDSCH and a DG PUSCH.

[0013] FIGS. 5A through 5D illustrate various sub-scenarios of a first scenario where a semi-statically configured DL reception collides with two UL transmissions.

[0014] FIGS. 6A through 6D illustrate various sub-scenarios of a second scenario where a dynamically scheduled DL reception collides with two UL transmissions.

[0015] FIGS. 7A through 7E illustrate various sub-scenarios of a third scenario where a semi-statically configured UL transmission collides with two DL receptions.

[0016] FIGS. 8A through 8E illustrate various sub-scenarios of a fourth scenario where a dynamically scheduled UL transmission collides with two DL receptions.

[0017] FIG. 9 illustrates various a fifth scenario illustrating a schedule having a collision profile as between four different channels.

[0018] FIG. 10 illustrates a method of a RedCap UE, according to embodiments discussed herein.

[0019] FIG. 11 illustrates a method of a RedCap UE, according to embodiments discussed herein.

[0020] FIG. 12 illustrates a method of a RedCap UE, according to embodiments discussed herein.

[0021] FIG. 13 illustrates a method of a RedCap UE, according to embodiments discussed herein.

[0022] FIG. 14 illustrates a method of a RedCap UE, according to embodiments discussed herein.

[0023] FIG. 15 illustrates a method of a RedCap UE, according to embodiments discussed herein.

[0024] FIG. 16 illustrates a method of a RedCap UE, according to embodiments discussed herein.

[0025] FIG. 17 illustrates a method of a RedCap UE, according to embodiments discussed herein.

[0026] FIG. 18 illustrates a method of a RedCap UE, according to embodiments discussed herein.

[0027] FIG. 19 illustrates a method of a RedCap UE, according to embodiments discussed herein.

[0028] FIG. 20 illustrates a method of a RedCap UE, according to embodiments discussed herein.

[0029] FIG. 21 illustrates a method of a RedCap UE, according to embodiments discussed herein.

[0030] FIG. 22 illustrates a method of a RedCap UE, according to embodiments discussed herein.

[0031] FIG. 23 illustrates an example architecture of a wireless communication system, according to embodiments disclosed herein.

[0032] FIG. 24 illustrates a system for performing signaling between a wireless device and a RAN device connected to a core network of a CN device, according to embodiments disclosed herein.DETAILED DESCRIPTION

[0033] Various embodiments are described with regard to a UE. However, reference to a UE is merely provided for illustrative purposes. The example embodiments may be utilized with any electronic component that may establish a connection to a network and is configured with the hardware, software, and / or firmware to exchange information and data with the network. Therefore, the UE as described herein is used to represent any appropriate electronic component.

[0034] FIG. 1 illustrates a non-terrestrial network (NTN) architecture 100 of a wireless communication system, according to an embodiment. The NTN architecture 100 includes a core network (CN) 102, a terrestrial base station 104, a satellite gateway 106, a satellite 108, and a UE 110. The terrestrial base station 104, the satellite gateway 106, and the satellite 108 may be included in a RAN 112.

[0035] In some embodiments, the RAN 112 includes E-UTRAN, the CN 102 includes an EPC, and the terrestrial base station 104 includes an eNB. In these cases, the CN link 114 connecting the CN 102 and the terrestrial base station 104 may include an S1 interface.

[0036] In some embodiments, RAN 112 includes NG-RAN, the CN 102 includes a 5GC, and the terrestrial base station 104 includes a gNB or a next generation eNB (ng-eNB) . In such cases, the CN link 114 connecting the CN 102 and the terrestrial base station 104 may include an NG interface.

[0037] The NTN architecture 100 illustrates a “bent-pipe” or “transparent” satellite based architecture. In such bent-pipe systems, the terrestrial base station 104 uses the satellite gateway 106 to communicate with the satellite 108 over a feeder link 116. The satellite 108 may be equipped with one or more antennas capable of broadcasting a cell according to the RAN 112, and the UE 110 may be equipped with one or more antennas (e.g., a moving parabolic antenna, an omni-directional phased-array antenna, etc. ) capable of communicating with the satellite 108 via a Uu interface on that cell (such communications may be said to use the illustrated service link 118) . A payload sited on the satellite 108 then transparently forwards data between the satellite gateway 106 and the UE 110 using the feeder link 116 between the satellite gateway 106 and the satellite 108 and the service link 118 between the satellite 108 and the UE 110. The payload may perform radio frequency (RF) conversion and / or amplification in both uplink (UL) and downlink (DL) to enable this communication.

[0038] In the embodiment shown in FIG. 1, the terrestrial base station 104 is illustrated without the capability of terrestrial wireless communication directly with a UE. However, it is contemplated that in other embodiments, such a terrestrial base station using the satellite gateway 106 to communicate with the satellite 108 could (also) have this functionality (i.e., as in the terrestrial base station 2312 and the terrestrial base station 2314 of FIG. 23, to be described below) .

[0039] It may be understood that, in alternative embodiments to FIG. 1, the satellite 108 may instead be a non-satellite NTN vehicle (e.g., an airplane, an unmanned aerial vehicle (UAV) , an unmanned aircraft system (UAS) , an airship, a balloon, etc. ) . Further, it may be understood in such alternative embodiments that the satellite gateway 106 may instead be a gateway for or corresponding to the applicable NTN vehicle type.

[0040] FIG. 2 illustrates an NTN architecture 200 of a wireless communication system, according to an embodiment. The NTN architecture 200 includes a CN 202, a satellite gateway 204, a satellite base station 206, and a UE 208. The satellite gateway 204 and the satellite base station 206 may be included in the RAN 210.

[0041] In some embodiments, the RAN 210 includes E-UTRAN and the CN 202 includes an EPC. In these cases, the CN link 212 connecting the CN 202 and the satellite gateway 204 may include an S1 interface.

[0042] In some embodiments, RAN 210 includes NG-RAN and the CN 202 includes a 5GC. In such cases, the CN link 212 connecting the CN 202 and the satellite gateway 204 may include an NG interface.

[0043] The NTN architecture 100 implements a “regenerative" satellite based architecture. In such regenerative systems, the functionalities of a base station are sited on the satellite base station 206, and the communications between these base station functions and the CN 202 occur through a forwarding of interface (s) (e.g., a S1 interface and / or an NG interface) found on the CN link 212 through the satellite gateway 204 and a feeder link 214 to the satellite base station 206. The satellite base station 206 may be equipped with one or more antennas capable of broadcasting a cell according to the RAN 210, and the UE 208 may be equipped with one or more antennas (e.g., a moving parabolic antenna, an omni-directional phased-array antenna, etc. ) capable of communicating with the satellite base station 206 via a Uu interface on that cell (such communications may be said to use the illustrated service link 216) . A payload sited on the satellite base station 206 then forwards data between the satellite gateway 204 and the UE 208 using the feeder link 214 between the satellite gateway 204 and the satellite base station 206 and the service link 216 between the satellite base station 206 and the UE 208. The payload may perform RF conversion and / or amplification in both uplink (UL) and downlink (DL) to enable this communication, as well as implement the functionalities of the base station (e.g., as an eNB, ng-eNB or a gNB, as corresponding to the type of the RAN 210) as these have been sited on the satellite base station 206.

[0044] In embodiments of NTN architectures comprising NG-RAN that also use integrated access and backhaul (IAB) , it is possible that a gNB control unit functionality (CU) could be sited terrestrially and may use a satellite gateway to communicate with a satellite that hosts a corresponding gNB donor unit functionality (DU) , with the F1 interface (s) between the CU and the DU underpinned by the feeder link 214. In such cases, the CU and the DU may each be understood to be part of the NG-RAN.

[0045] It may be understood that, in alternative embodiments to FIG. 2, the satellite base station 206 may instead be a non-satellite NTN base station (e.g., an airplane, a UAV, a UAS, an airship, a balloon, etc. ) . Further, it may be understood in such alternative embodiments that the satellite gateway 204 may instead be a gateway for or corresponding to the applicable NTN vehicle type.

[0046] Reduced capability (RedCap) UEs may be used in various wireless communication systems. A RedCap UE is a UE that operates accordingly to fewer than all possible capabilities for UEs within the system. For example, a RedCap UE may operate with smaller bandwidths, fewer multiple input multiple output (MIMO) layers, relatively less complex DL modulations, and / or relatively limited duplex operational modes (such as, for example, implementing half duplex frequency division duplex (HD-FDD) ) as compared to higher / more advanced such capabilities that are supportable within the system for UEs generally. In this way, the RedCap UE uses relatively fewer resources (fewer communication resources in the channel, fewer power resources at the UE, fewer manufacturing resources in the creation of the UE) than a comparatively more fully-featured UE that may operate within the system.

[0047] Note that in some wireless communication systems, definitions / categories for enhanced RedCap (eRedCap) UEs that operate according to still further reduced maximum capabilities than those as may be defined for “regular” RedCap UEs generally may be implemented. References herein to a “RedCap UE” should be understood to include / incorporate the notion of such eRedCap UEs as well, unless context requires otherwise.

[0048] Some RedCap UEs operate according to an HD-FDD mode, in which the RedCap UE performs only one of transmit (Tx) or receive (Rx) at any given time, switching between these functions as necessary. The hardware requirements for implementing such an HD-FDD mode are less than those for implementing other duplexing modes that allow for simultaneous Tx and Rx, thereby making the RedCap UE relatively less complex than UEs using these other duplexing modes.

[0049] As the HD-FDD RedCap UE can perform only one of Tx or Rx at any given time, any scheduling for the RedCap UE that calls for simultaneous uplink (UL) transmission and downlink (DL) reception represents a collision case for which the HD-FDD RedCap UE may perform at most one of the called-for behaviors. Possibilities for such collision cases may be classified into collision cases as follows: ● Case 1: A dynamically scheduled DL reception collides with a semi-statically  configured UL transmission; ● Case 2: A semi-statically configured DL reception collides with a dynamically  scheduled UL transmission; ● Case 3: A semi-statically configured DL reception collides with a semi-statically  configured UL transmission; ● Case 4: A dynamically scheduled DL reception collides with a dynamically  scheduled UL transmission; ● Case 5: A configured synchronization signal block (SSB) collides with a  dynamically scheduled or configured UL transmission; ● Case 6: A dynamically scheduled or semi-statically configured DL transmission  collides with a valid random access channel (RACH) occasion (RO) ; and ● Case 7: A collision due to direction switching.

[0050] Note that with respect to Case 3, the semi-statically configured DL reception may be, for example, any of a physical downlink control channel (PDCCH) , a physical downlink shared channel (PDSCH) , a channel state information reference signal (CSI-RS) , and / or a DL positioning reference signal (PRS) . Further, the semi-statically configured UL transmission may be, for example, any of a physical uplink control channel (PUCCH) , a physical uplink shared channel (PUSCH) and / or a sounding reference signal (SRS) .

[0051] Note also that with respect to Case 4, the dynamically scheduled DL reception may be, for example, any of a physical downlink shared channel (PDSCH) that is scheduled by downlink control information (DCI) and / or a CSI-RS. Further, the dynamically scheduled UL transmission may be, for example, a PUSCH scheduled by DCI, a PUCCH, a physical random access channel (PRACH) , and / or an SRS.

[0052] The use of a RedCap UE according to NTN operation within a wireless communication system may be useful, in that NTN operation opens up improved / expanded coverage areas for the RedCap UE. In particular, support of RedCap UE operation in FR1-NTN bands may be contemplated. In the case of HD-FDD RedCap UEs, there are issues of feasibility / support within the NTN network, for which additional RF and / or radio resource management (RRM) requirements may be established (see discussion to follow) . Further, note that global navigation satellite system (GNSS) capabilities and simultaneous GNSS and NR-NTN operation may be supported for RedCap UEs.

[0053] In some cases, it may be that timing advance (TA) reporting is implemented in an attempt to mitigate a TA mismatch between an actual TA used by RedCap UE and an assumed TA for the RedCap UE at the base station in cases of HD-FDD RedCap UE operation in NTN networks. However, even the case of UEs that have (and use) such a TA reporting capability, a TA mismatch between the UE and base station may still ultimately exist. For example, it may be that a TA reporting granularity is, for example, 1 millisecond (ms) , while a TA report threshold (e.g., a a offsetThresholdTA value) , falls within a range of / is one of, for example, {0.5 ms, 1 ms, 2 ms, …15 ms} . In a case with the 1 ms TA reporting granularity and where a TA report threshold is configured at 15 ms, when TA report is triggered, there can be a maximum 16 ms difference between a base station assumed TA and a UE reported TA.

[0054] With respect to various wireless communication systems that do not use NTN operations with HD-FDD RedCap UEs, it may be that some relevant collision cases (e.g., Case 3 and Case 4) are outright avoided by the network during scheduling, such that schedules implicating these collision cases are not ultimately presented to the HD-FDD RedCap UE. In these non-NTN environments, the network is capable of identifying and avoiding these potential collision cases because it is aware of, among other things, the TA used by the HD-FDD RedCap UE.

[0055] However, under NTN operation, the network does not know the actual TA used by the HD-FDD RedCap UE. Instead, there is a TA mismatch between the actual TA used by the UE and an assumed TA for the UE at the network. Accordingly, it has been identified that, with respect to an NTN operation case for an HD-FDD RedCap UE, the network may not be capable of ensuring that its scheduling avoids Case 3 and Case 4 collisions at the HD-FDD RedCap UE. Accordingly, frameworks for resolving collisions of Case 3 and Case 4 at the HD-FDD RedCap UE (instead of at the network scheduler) may be used at least when the HD-FDD RedCap UE operates according to NTN operation.

[0056] With respect to the use of an HD-FDD RedCap UE in a radio resource connection (RRC) connected mode in NTN operation, for collision Case 3, a handling of a collision with a PDCCH of one of type-0, type-0A, type-1, or type-2 that is in a common search space (CSS) while in the RRC connected mode is left to UE implementation as to whether to prioritize UL or prioritize DL. The use of this UE implementation mechanism may be subject to a constraint that that the UE's selected resolution shall not prevent the UE from monitoring for a system information (SI) change indication in any paging occasion at least once per modification period in the event that the UE is provided with a CSS (including, e.g., pagingSearchSpace, searchSpaceSIB1 and searchSpaceOtherSystemInformation as may be defined in various 3GPP wireless communication systems) on an active bandwidth part (BWP) to monitor paging.

[0057] For other situations (e.g., instances not involving a collision with a PDCCH of one of type-0, type-0A, type-1, or type-2 that is in a CSS) , a default priority rule for collision Case 3 with the HD-FDD RedCap UE in the RRC connected mode may be that DL is prioritized. Note that the network is allowed to indicate that UL instead overrides DL for these other use cases, as may be signaled by, for example, an RRC configuration message.

[0058] Further, it may be that, with respect to the use of an HD-FDD RedCap UE in an RRC connected mode in NTN operation, collision Case 4 is not considered as an error case. Accordingly, it has been identified that it is useful to establish prioritization rules as between DL and UL for such cases.

[0059] Embodiments discussed herein describe solutions for the use of RedCap UEs under NTN operation in scenarios that remain undefined. Note that the provided solutions may provide mechanisms for a prioritization between colliding channels at the RedCap UE. In such circumstances, this prioritization includes the notion that a prioritized channel remains scheduled for use at the RedCap UE, while a non-prioritized channel is dropped (e.g., the scheduling for the use of the non-prioritized channel at the RedCap UE is canceled and / or ignored) .

[0060] Embodiments for the resolution of channel collisions at a RedCap UE under NTN operation as described herein may correspond to, for example, cases where the RedCap UE is not intended to perform Tx and Rx simultaneously (e.g., cases where the RedCap UE is an HD-FDD RedCap UE) .

[0061] Various solutions discussed herein relate to instances where a RedCap UE under NTN operation has been configured for configured grant small data transmission (CG-SDT) operation while in an RRC inactive state. These solutions relate to the establishment of priority rules for resolving Case 3 collisions between DL and UL in such CG-SDT circumstances.

[0062] Various solutions discussed herein relate to the establishment of substantive priority rules for resolving Case 4 collisions between DL and UL for a RedCap UE under NTN operation.

[0063] Various solutions discussed herein relate to the establishment of priority rules for use in instances of multiple collisions as between three or more signals. FIG. 3 illustrates an example schedule 300 involving multiple collisions at a RedCap UE. As can be seen, a PDCCH in CSS 302 collides with a configured grant (CG) PUSCH 304. This is a Case 3 collision between a semi-statically configured DL reception and a semi-statically configured UL transmission. Further, the PDCCH in CSS 302 also collides with a DG PUSCH 306 (for example, the CSS given by way of example above also collides with a dynamic grant (DG) PUSCH) . This is a Case 2 collision between a a semi-statically configured DL reception and a dynamically scheduled configured UL transmission.

[0064] It is noted that for a RedCap UE not operating in NTN, the Case 3 collision is an error case that is avoided by the scheduler at the network, so this schedule 300 having both the collision between the PDCCH in CSS 302 and the CG PUSCH 304 and the collision between the PDCCH in CSS 302 and the DG PUSCH 306 will not be scheduled at the RedCap UE in the first instance.

[0065] However, for cases of a RedCap UE that is under NTN operation, collision Case 3 is not an error case, and thus the effective presentation of the schedule 300 at / to the RedCap UE is possible. Accordingly, priority rule (s) for use at the RedCap UE for resolving this multiple collision case when under NTN operation may be defined (e.g., as described herein) .Embodiments for RedCap UE Priority Rule Use for Collision Case 3 when using CG-SDT

[0066] In some instances, a Case 3 collision occurs at a RedCap UE that is in an in RRC inactive state when a CG-SDT UL transmission collides with a semi-statically configured DL reception.

[0067] In a first option for resolving a Case 3 collision between a CG-SDT UL transmission and a semi-statically configured DL reception at a RedCap UE, prioritization of one of the CG-SDT UL transmission or the DL reception may be left up to a (e.g., vendor-set) implementation of the RedCap UE. The use of this option may be subject to a constraint that the UE's selected prioritization shall not prevent the UE from monitoring for a system information (SI) change indication in any paging occasion at least once per modification period in the event that the initial BWP on which the small data transmission (SDT) procedure is ongoing is associated with a cell-defining synchronization signal block (CD-SSB) .

[0068] In a second option for resolving this Case 3 collision between a CG-SDT UL transmission and a semi-statically configured DL reception at a RedCap UE, prioritization of one of the CG-SDT UL transmission or the DL reception may be left up to a (e.g., vendor-set) implementation of the RedCap UE in the event that the semi-statically configured DL reception is a PDCCH of one of type-0, type-0A, type-1, or type-2 that is in a CSS. The use of this second option may be subject to a constraint that the UE's selected prioritization shall not prevent the UE from monitoring for an SI change indication in any paging occasion at least once per modification period in the event that the initial BWP on which the SDT procedure is ongoing is associated with a CD-SSB.

[0069] Further, when the second option is used, for instances not involving a collision with a PDCCH of one of type-0, type-0A, type-1, or type-2 that is in a CSS, a priority rule for Case 3 that is otherwise configured for use at the UE (e.g., that is otherwise configured for use outside of this particular case of CG-SDT under NTN operation) may be applied.

[0070] In some such cases, it may be that the priority rule so used indicates that the semi-statically scheduled DL reception takes priority. However, it may further be that the network may can alternatively indicate that the CG-SDT UL transmission has priority over the semi-statically scheduled DL reception. This may be signaled using, for example, an RRC configuration message.

[0071] In a third option for resolving a Case 3 collision between a CG-SDT UL transmission and a semi-statically configured DL reception at a RedCap UE, it may be that the CG-SDT UL transmission is prioritized across all circumstances.

[0072] In a fourth option for resolving a Case 3 collision between a CG-SDT UL transmission and a semi-statically configured DL reception at a RedCap UE, it may be that the base station configures a priority of UL transmission and DL reception that is applied by the RedCap UE. In the event that the base station has not configured such a priority, a predefined default behavior may be used (e.g., the CG-SDT UL transmission is prioritized) .

[0073] Note that combinations of the above options are also contemplated.Embodiments for RedCap UE Priority Rule Use for Collision Case 4

[0074] Priority rules for use by a RedCap UE under NTN operation in resolving Case 4 collisions, where a dynamically scheduled DL reception collides with a dynamically scheduled UL transmission, are now discussed. FIG. 4 illustrates an example schedule 400 involving a collision at a RedCap UE between a PDSCH scheduled by PDCCH in CSS 404 and a DG PUSCH 406. Note that the PDSCH scheduled by PDCCH in CSS 404 has been dynamically scheduled 408 by a PDCCH in CSS 402, as shown. Accordingly, the collision between the PDSCH scheduled by PDCCH in CSS 404 and the DG PUSCH 406 is a Case 4 collision.

[0075] A first option for resolving a Case 4 collision between a dynamically scheduled UL transmission and a dynamically scheduled DL reception at a RedCap UE relates to, specifically, examples where the UE performs collision resolution based on whether the dynamically scheduled DL reception is (or is not) a PDSCH that has been scheduled by a PDCCH of one of type-0, type-0A, type-1, or type-2 that is in a CSS while the RedCap UE is in an RRC connected mode

[0076] Under a first approach of the first option, it may be that the RedCap UE prioritizes a PDSCH that has been scheduled by a PDCCH of one of type-0, type-0A, type-1, or type-2 that is in a CSS over a dynamically scheduled UL transmission. The use of this first approach may be subject to a constraint that that the RedCap UE's selected resolution shall not prevent the RedCap UE from monitoring for an SI change indication in any paging occasion at least once per modification period in the event that the RedCap UE is provided with a CSS (including, e.g., pagingSearchSpace, searchSpaceSIB1 and searchSpaceOtherSystemInformation as may be defined in various 3GPP wireless communication systems) on an active BWP to monitor paging.

[0077] Under a second approach of the first option, prioritization of one of a PDSCH that has been scheduled by a PDCCH of one of type-0, type-0A, type-1, or type-2 that is in a CSS or dynamically scheduled UL transmission may be left up to a (e.g., vendor-set) implementation of the RedCap UE. The use of this first approach may be subject to a constraint that that the RedCap UE's selected resolution shall not prevent the RedCap UE from monitoring for an SI change indication in any paging occasion at least once per modification period in the event that the RedCap UE is provided with a CSS (including, e.g., pagingSearchSpace, searchSpaceSIB1 and searchSpaceOtherSystemInformation as may be defined in various 3GPP wireless communication systems) on an active BWP to monitor paging.

[0078] Under a third approach for the first option, prioritization follows details with respect to the RedCap UE's implementation with respect to the PDCCH of one of type-0, type-0A, type-1, or type-2 in the CSS. If the RedCap UE is configured to receive within the CSS, a PDSCH that has been scheduled by the PDCCH of one of type-0, type-0A, type-1, or type-2 that is in the CSS will be prioritized over the dynamically scheduled UL transmission. Otherwise, the PDSCH may instead be dropped.

[0079] Note that with respect to the first option for resolving a Case 4 collision between a dynamically scheduled UL transmission and a dynamically scheduled DL reception, in cases where the dynamically scheduled DL reception is not a PDSCH that has been scheduled by the PDCCH of one of type-0, type-0A, type-1, or type-2 that is in a CSS, a default priority rule at the UE may be used. In some cases, the default priority rule may be that the dynamically scheduled DL reception is prioritized.

[0080] However, for such cases, it may further be that the network can alternatively indicate that the dynamically scheduled UL transmission has priority over the dynamically scheduled DL reception. This may be signaled using, for example, an RRC configuration message.

[0081] In some alternatives, the indication that the dynamically scheduled UL transmission has priority over the dynamically scheduled DL reception may be a joint indication that also indicates a priority resolution rule for collision Case 3. For example, one single bit may be used to indicate the prioritization UL transmission for both collision Case 3 and relevant instances of collision Case 4 as here described.

[0082] In some alternatives, the indication that the dynamically scheduled UL transmission has priority over the dynamically scheduled DL reception may be a separable indication of priority from an indication of priority for collision Case 3. For example, the RRC configuration message may include each of a first bit that indicates that UL transmission is prioritized for collision case 3, and a second bit that makes the indication that the dynamically scheduled UL transmission has priority over the dynamically scheduled DL reception in relevant instances of collision Case 4 as here described.

[0083] In a second option for resolving a Case 4 collision between a dynamically scheduled UL transmission and a dynamically scheduled DL reception at a RedCap UE, for each possible pair of UL and DL channel types, a priority rule laying out relative priority between those channel types defined at the UE is used to resolve the collision. Options for results indicated by these priority rules can include an indication that, based on the channel types under consideration, the dynamically scheduled UL transmission has priority, an indication that the dynamically scheduled DL reception has priority, or that the prioritization between the dynamically scheduled UL transmission and the dynamically scheduled DL reception has been left up to a (e.g., vendor-set) implementation of the RedCap UE. In some of these cases, the network may use RRC signaling to override these priority rules for one or more pairs of channel types.

[0084] In a third option for resolving a Case 4 collision between a dynamically scheduled UL transmission and a dynamically scheduled DL reception at a RedCap UE, a single priority rule defined at the UE is applied to all collision use cases under Case 4 (e.g., all possible pairs of pair of UL and DL channel types) . In such cases, it is contemplated that the network may use RRC signaling to override the existing priority rule for such collision use cases.Embodiments for Multiple Collision Scenarios

[0085] FIGS. 5A through 5D illustrate various sub-scenarios of a first scenario where a semi-statically configured DL reception collides with two UL transmissions.

[0086] FIG. 5A illustrates a first sub-scenario where a schedule 502 at a RedCap UE involves a PDCCH in CSS 504 that is in both a first collision with a first CG PUSCH 506 and a second collision with a second CG PUSCH 508. Each of the first collision with the first CG PUSCH 506 and the second collision with the second CG PUSCH 508 are Case 3 collisions.

[0087] In such case, it may be that a Case 3 priority rule at the RedCap UE gives the same priority to each of the first CG PUSCH 506 and the second CG PUSCH 508 relative to the PDCCH in CSS 504 and thus resolves the first collision and the second collision in the same way. In such cases, this Case 3 priority rule is sufficient to fully define a resolution for this sub-scenario.

[0088] FIG. 5B illustrates a second sub-scenario where a schedule 510 at a RedCap UE involves a PDCCH in CSS 512 that is in both a first collision with a CG PUSCH 514 and a second collision with a DG PUSCH 516. The first collision with the CG PUSCH 514 is a Case 3 collision, while the second collision with the DG PUSCH 516 is a Case 2 collision.

[0089] In a first option for resolving this sub-scenario, it may be left to a (e.g., vendor-set) implementation of the RedCap UE to prioritize either the DL reception (the PDCCH in CSS 512) or the UL transmissions (the CG PUSCH 514 and the DG PUSCH 516) .

[0090] In a second option of this sub-scenario, it may be that the RedCap UE applies collision rules according to the in-time ordering of the two collisions. For example, as the first collision between the PDCCH in CSS 512 and the CG PUSCH 514 occurs first, the RedCap UE may first apply a Case 3 collision rule to prioritize one of the PDCCH in CSS 512 and the CG PUSCH 514 and drop the other of the PDCCH in CSS 512 and the CG PUSCH 514. In the event that the result of the application of the Case 3 collision rule is that the CG PUSCH 514 is prioritized and the PDCCH in CSS 512 is dropped, the RedCap UE will subsequently also perform the reception of the DG PUSCH 516 (as the dropping of the PDCCH in CSS 512 also inherently resolves the second collision between the PDCCH in CSS 512 and the DG PUSCH 516) .

[0091] In the event that the result of the Case 3 collision rule is that the PDCCH in CSS 512 is prioritized and the CG PUSCH 514 is dropped, the UE may proceed to resolve the second collision between the PDCCH in CSS 512 and the DG PUSCH 516 that occurs next by applying a Case 2 collision rule to prioritize one of the PDCCH in CSS 512 and the DG PUSCH 516 and drop the other of the PDCCH in CSS 512 and the DG PUSCH 516.

[0092] In a third option of this sub-scenario, it may be that the RedCap UE applies the multiple collision rules for the two collisions in a joint matter. In such a case, the UE analyzes the result of both of applying the Case 3 collision rule between the PDCCH in CSS 512 and the CG PUSCH 514 and applying the Case 2 collision rule between the PDCCH in CSS 512 and the DG PUSCH 516. If either of these results calls for the PDCCH in CSS 512 to be dropped, then the PDCCH in CSS 512 is dropped and both of the CG PUSCH 514 and the DG PUSCH 516 are transmitted. Otherwise, the PDCCH in CSS 512 is received and the CG PUSCH 514 and the DG PUSCH 516 are dropped.

[0093] Note that this third option resolves an aspect of the second option where only the DG PUSCH 516 is ultimately used at the RedCap UE because the CG PUSCH 514 is dropped as a result of first applying the Case 3 collision rule between the CG PUSCH 514 and the PDCCH in CSS 512 and then the PDCCH in CSS 512 is dropped as a result of later applying the Case 2 collision rule between the PDCCH in CSS 512 and the DG PUSCH 516.

[0094] In a fourth option of this sub-scenario, it may be that the RedCap UE applies a priority rule that applies specifically to instances of collisions involving dynamically scheduled PUSCHs such as the DG PUSCH 516 (instead of, for example, another rule that is defined in terms of one of the Cases described herein) .

[0095] FIG. 5C illustrates a third sub-scenario where a schedule 518 at a RedCap UE involves a semi-statically configured PDSCH 520 that is in both a first collision with a first CG PUSCH 522 and a second collision with a second CG PUSCH 524. Each of the first collision with the first CG PUSCH 522 and the second collision with the second CG PUSCH 524 are Case 3 collisions.

[0096] In such case, it may be that a Case 3 priority rule at the RedCap UE gives the same priority to each of the first CG PUSCH 506 and the second CG PUSCH 508 relative to the semi-statically configured PDSCH 520, and thus resolves the first collision and the second collision in the same way. In such cases, this Case 3 priority rule is sufficient to fully define a resolution for this sub-scenario.

[0097] FIG. 5D illustrates a fourth sub-scenario where a schedule 526 at a RedCap UE involves a semi-statically configured PDSCH 528 that is in both a first collision with a CG PUSCH 530 and a second collision with a DG PUSCH 532. The first collision with the CG PUSCH 530 is a Case 3 collision, while the second collision with the DG PUSCH 532 is a Case 2 collision.

[0098] In a first option for resolving this sub-scenario, it may be left to a (e.g., vendor-set) implementation of the RedCap UE to prioritize either the DL reception (the semi-statically configured PDSCH 528) or the UL transmissions (the CG PUSCH 530 and the DG PUSCH 532) .

[0099] In a second option of this sub-scenario, it may be that the RedCap UE applies collision rules according to the in-time ordering of the two collisions. For example, as the first collision between the semi-statically configured PDSCH 528 and the CG PUSCH 530 occurs first, the RedCap UE may first apply a Case 3 collision rule to prioritize one of the semi-statically configured PDSCH 528 and the CG PUSCH 530 and drop the other of the semi-statically configured PDSCH 528 and the CG PUSCH 530. In the event that the result of the application of the Case 3 collision rule is that the CG PUSCH 530 is prioritized and the semi-statically configured PDSCH 528 is dropped, the RedCap UE will subsequently also perform the reception of the DG PUSCH 532 (as the dropping of the semi-statically configured PDSCH 528 also inherently resolves the second collision between the semi-statically configured PDSCH 528 and the DG PUSCH 532) .

[0100] In the event that the result of the Case 3 collision rule is that the semi-statically configured PDSCH 528 is prioritized and the CG PUSCH 530 is dropped, the UE may proceed to resolve the second collision between the semi-statically configured PDSCH 528 and the DG PUSCH 532 that occurs next by applying a Case 2 collision rule to prioritize one of the semi-statically configured PDSCH 528 and the DG PUSCH 532 and drop the other of the semi-statically configured PDSCH 528 and the DG PUSCH 532.

[0101] In a third option of this sub-scenario, it may be that the RedCap UE applies the multiple collision rules for the two collisions in a joint matter. In such a case, the UE analyzes the result of both of applying the Case 3 collision rule between the semi-statically configured PDSCH 528 and the CG PUSCH 530 and applying the Case 2 collision rule between the semi-statically configured PDSCH 528 and the DG PUSCH 532. If either of these results calls for the semi-statically configured PDSCH 528 to be dropped, then the semi-statically configured PDSCH 528 is dropped and both of the CG PUSCH 530 and the DG PUSCH 532 are transmitted. Otherwise, the semi-statically configured PDSCH 528 is received and the CG PUSCH 530 and the DG PUSCH 532 are dropped.

[0102] Note that this third option resolves an aspect of the second option where only the DG PUSCH 532 is ultimately used at the RedCap UE because the CG PUSCH 530 is dropped as a result of first applying the Case 3 collision rule between the CG PUSCH 530 and the semi-statically configured PDSCH 528 and then the semi-statically configured PDSCH 528 is dropped as a result of later applying the Case 2 collision rule between the semi-statically configured PDSCH 528 and the DG PUSCH 532.

[0103] In a fourth option of this sub-scenario, it may be that the RedCap UE applies a priority rule that applies specifically to instances of collisions involving dynamically scheduled PUSCHs such as the DG PUSCH 532 (instead of, for example, another rule that is defined in terms of one of the Cases described herein) .

[0104] FIGS. 6A through 6D illustrate various sub-scenarios of a second scenario where a dynamically scheduled DL reception collides with two UL transmissions.

[0105] FIG. 6A illustrates a first sub-scenario where a schedule 602 at a RedCap UE involves a PDSCH scheduled by PDCCH in CSS 604 (e.g., a PDSCH that is scheduled by a PDCCH of one of type-0, type-0A, type-1, or type-2 that is in a CSS) that is in both a first collision with a first DG PUSCH 606 and a second collision with a second DG PUSCH 608. Each of the first collision with the first DG PUSCH 606 and the second collision with the second DG PUSCH 608 are Case 4 collisions.

[0106] In such case, it may be that a Case 4 priority rule at the RedCap UE gives the same priority to each of the first DG PUSCH 606 and the second DG PUSCH 608 relative to the PDSCH scheduled by PDCCH in CSS 604, and thus resolves the first collision and the second collision in the same way. In such cases, this Case 4 priority rule is sufficient to fully define a resolution for this sub-scenario.

[0107] FIG. 6B illustrates a second sub-scenario where a schedule 610 at a RedCap UE involves a PDSCH scheduled by PDCCH in CSS 612 (e.g., a PDSCH that is scheduled by a PDCCH of one of type-0, type-0A, type-1, or type-2 that is in a CSS) that is in both a first collision with a DG PUSCH 614 and a second collision with a CG PUSCH 616. The first collision with the DG PUSCH 614 is a Case 4 collision, while the second collision with the CG PUSCH 616 is a Case 1 collision.

[0108] In a first option for resolving this sub-scenario, it may be left to a (e.g., vendor-set) implementation of the RedCap UE to prioritize either the DL reception (the PDSCH scheduled by PDCCH in CSS 612) or the UL transmissions (the DG PUSCH 614 and the CG PUSCH 616) .

[0109] In a second option of this sub-scenario, it may be that the RedCap UE applies collision rules according to the in-time ordering of the two collisions. For example, as the first collision between the PDSCH scheduled by PDCCH in CSS 612 and the DG PUSCH 614 occurs first, the RedCap UE may first apply a Case 4 collision rule to prioritize one of the PDSCH scheduled by PDCCH in CSS 612 and the DG PUSCH 614 and drop the other of the PDSCH scheduled by PDCCH in CSS 612 and the DG PUSCH 614. In the event that the result of the application of the Case 4 collision rule is that the DG PUSCH 614 is prioritized and the PDSCH scheduled by PDCCH in CSS 612 is dropped, the RedCap UE will subsequently also perform the reception of the CG PUSCH 616 (as the dropping of the PDSCH scheduled by PDCCH in CSS 612 also inherently resolves the second collision between the PDSCH scheduled by PDCCH in CSS 612 and the CG PUSCH 616) .

[0110] In the event that the result of the Case 4 collision rule is that the dynamically scheduled PDSCH 628 is prioritized and the DG PUSCH 630 is dropped, the UE may proceed to resolve the second collision between the dynamically scheduled PDSCH 628 and the CG PUSCH 632 that occurs next by applying a Case 1 collision rule to prioritize one of the dynamically scheduled PDSCH 628 and the CG PUSCH 632 and drop the other of the dynamically scheduled PDSCH 628 and the CG PUSCH 632.

[0111] In a third option of this sub-scenario, it may be that the RedCap UE applies the multiple collision rules for the two collisions in a joint matter. In such a case, the UE analyzes the result of both of applying the Case 4 collision rule between the dynamically scheduled PDSCH 628 and the DG PUSCH 630 and applying the Case 1 collision rule between the dynamically scheduled PDSCH 628 and the CG PUSCH 632. If either of these results calls for the dynamically scheduled PDSCH 628 to be dropped, then the dynamically scheduled PDSCH 628 is dropped and both of the DG PUSCH 630 and the CG PUSCH 632 are transmitted. Otherwise, the dynamically scheduled PDSCH 628 is received and the DG PUSCH 630 and the CG PUSCH 632 are dropped.

[0112] Note that this third option resolves an aspect of the second option where only the CG PUSCH 632 is ultimately used at the RedCap UE because the DG PUSCH 630 is dropped as a result of first applying the Case 4 collision rule between the DG PUSCH 630 and the dynamically scheduled PDSCH 628 and then the dynamically scheduled PDSCH 628 is dropped as a result of later applying the Case 1 collision rule between the dynamically scheduled PDSCH 628 and the CG PUSCH 632.

[0113] In a fourth option of this sub-scenario, it may be that the RedCap UE applies a priority rule that applies specifically to instances of collisions involving dynamically scheduled PUSCHs such as the DG PUSCH 630 (instead of, for example, another rule that is defined in terms of one of the Cases described herein) .

[0114] FIG. 6C illustrates a third sub-scenario where a schedule 618 at a RedCap UE involves a dynamically scheduled PDSCH 620 that is in both a first collision with a first DG PUSCH 622 and a second collision with a second DG PUSCH 624. Each of the first collision with the first DG PUSCH 622 and the second collision with the second DG PUSCH 624 are Case 4 collisions.

[0115] In such case, it may be that a Case 4 priority rule at the RedCap UE gives the same priority to each of the first DG PUSCH 622 and the second DG PUSCH 624 relative to the dynamically scheduled PDSCH 620, and thus resolves the first collision and the second collision in the same way. In such cases, this Case 4 priority rule is sufficient to fully define a resolution for this sub-scenario.

[0116] FIG. 6D illustrates a second sub-scenario where a schedule 626 at a RedCap UE involves a dynamically scheduled PDSCH 628 that is in both a first collision with a DG PUSCH 630 and a second collision with a CG PUSCH 632. The first collision with the DG PUSCH 630 is a Case 4 collision, while the second collision with the CG PUSCH 632 is a Case 1 collision.

[0117] In a first option for resolving this sub-scenario, it may be left to a (e.g., vendor-set) implementation of the RedCap UE to prioritize either the DL reception (the dynamically scheduled PDSCH 628) or the UL transmissions (the DG PUSCH 630 and the CG PUSCH 632) .

[0118] In a second option of this sub-scenario, it may be that the RedCap UE applies collision rules according to the in-time ordering of the two collisions. For example, as the first collision between the dynamically scheduled PDSCH 628 and the DG PUSCH 630 occurs first, the RedCap UE may first apply a Case 4 collision rule to prioritize one of the dynamically scheduled PDSCH 628 and the DG PUSCH 630 and drop the other of the dynamically scheduled PDSCH 628 and the DG PUSCH 630. In the event that the result of the application of the Case 4 collision rule is that the DG PUSCH 630 is prioritized and the dynamically scheduled PDSCH 628 is dropped, the RedCap UE will subsequently also perform the reception of the CG PUSCH 632 (as the dropping of the dynamically scheduled PDSCH 628 also inherently resolves the second collision between the dynamically scheduled PDSCH 628 and the CG PUSCH 632) .

[0119] In the event that the result of the Case 4 collision rule is that the PDSCH scheduled by PDCCH in CSS 612 is prioritized and the DG PUSCH 614 is dropped, the UE may proceed to resolve the second collision between the PDSCH scheduled by PDCCH in CSS 612 and the CG PUSCH 616 that occurs next by applying a Case 1 collision rule to prioritize one of the PDSCH scheduled by PDCCH in CSS 612 and the CG PUSCH 616 and drop the other of the PDSCH scheduled by PDCCH in CSS 612 and the CG PUSCH 616.

[0120] In a third option of this sub-scenario, it may be that the RedCap UE applies the multiple collision rules for the two collisions in a joint matter. In such a case, the UE analyzes the result of both of applying the Case 4 collision rule between the PDSCH scheduled by PDCCH in CSS 612 and the DG PUSCH 614 and applying the Case 1 collision rule between the PDSCH scheduled by PDCCH in CSS 612 and the CG PUSCH 616. If either of these results calls for the PDSCH scheduled by PDCCH in CSS 612 to be dropped, then the PDSCH scheduled by PDCCH in CSS 612 is dropped and both of the DG PUSCH 614 and the CG PUSCH 616 are transmitted. Otherwise, the PDSCH scheduled by PDCCH in CSS 612 is received and the DG PUSCH 614 and the CG PUSCH 616 are dropped.

[0121] Note that this third option resolves an aspect of the second option where only the CG PUSCH 616 is ultimately used at the RedCap UE because the DG PUSCH 614 is dropped as a result of first applying the Case 4 collision rule between the DG PUSCH 614 and the PDSCH scheduled by PDCCH in CSS 612 and then the PDSCH scheduled by PDCCH in CSS 612 is dropped as a result of later applying the Case 1 collision rule between the PDSCH scheduled by PDCCH in CSS 612 and the CG PUSCH 616.

[0122] In a fourth option of this sub-scenario, it may be that the RedCap UE applies a priority rule that applies specifically to instances of collisions involving dynamically scheduled PUSCHs such as the DG PUSCH 614 (instead of, for example another rule that is defined in terms of one of the Cases described herein) .

[0123] FIGS. 7A through 7E illustrate various sub-scenarios of a third scenario where a semi-statically configured UL transmission collides with two DL receptions.

[0124] FIG. 7A illustrates a first sub-scenario where a schedule 702 at a RedCap UE involves a CG PUSCH 704 that is in both a first collision with a PDCCH in CSS 706 and a second collision with a semi-statically configured PDSCH 708. Each of the first collision with the first PDCCH in CSS 706 and the second collision with the semi-statically configured PDSCH 708 are Case 3 collisions.

[0125] In such case, it may be that a Case 3 priority rule (e.g., as applied for PDCCHs of one of type-0, type-0A, type-1, or type-2 that are in a CSS) at the RedCap UE gives the same priority to each of the PDCCH in CSS 706 and the semi-statically configured PDSCH 708 relative to the CG PUSCH 704, and thus resolves the first collision and the second collision in the same way. In such cases, this Case 3 priority rule is sufficient to fully define a resolution for this sub-scenario.

[0126] FIG. 7B illustrates a second sub-scenario where a schedule 710 at a RedCap UE involves a CG PUSCH 712 that is in both a first collision with a PDCCH in CSS 714 and a second collision with a PDSCH scheduled by PDCCH in CSS 716. For this sub-scenario, it should be understood that the PDSCH scheduled by PDCCH in CSS 716 is scheduled 718 by the PDCCH in CSS 714. The first collision with the PDCCH in CSS 714 is a Case 3 collision, while the second collision with the PDSCH scheduled by PDCCH in CSS 716 is a Case 1 collision.

[0127] In such sub-scenarios, it may be that a RedCap UE re-uses a result of a Case 3 priority rule as applied between a case of a CSS having a PDCCH of one of type-0, type-0A, type-1, or type-2 and a semi-statically configured UL transmission for any follow-on collisions between a PDSCH that is scheduled by that CSS / PDCCH and the semi-statically configured UL transmission. Accordingly, while the second collision between the CG PUSCH 712 and the PDSCH scheduled by PDCCH in CSS 716 is nominally a Case 1 collision, the RedCap UE may actually resolve the second collision between the CG PUSCH 712 and the PDSCH scheduled by PDCCH in CSS 716 according to the result of an application of a Case 3 priority rule to the first collision between the CG PUSCH 712 and the PDCCH in CSS 714. Accordingly, for such sub-scenarios, the relative prioritization of the CG PUSCH 712 and the PDSCH scheduled by PDCCH in CSS 716 will ultimately follow the result of the relative prioritization between the CG PUSCH 712 and the PDCCH in CSS 714, according to the application of the Case 3 priority rule between the CG PUSCH 712 and the PDCCH in CSS 714.

[0128] FIG. 7C illustrates a third sub-scenario where a schedule 720 at a RedCap UE involves a CG PUSCH 722 that is in both a first collision with a semi-statically configured PDSCH 724 and a second collision with a PDSCH scheduled by PDCCH in CSS 726. The first collision with the CG PUSCH 722 is a Case 3 collision, while the second collision with the PDSCH scheduled by PDCCH in CSS 726 is a Case 1 collision.

[0129] In a first option for resolving this sub-scenario, it may be left to a (e.g., vendor-set) implementation of the RedCap UE to prioritize either the DL receptions (the semi-statically configured PDSCH 724 and the PDSCH scheduled by PDCCH in CSS 726) or the UL transmission (the CG PUSCH 722) .

[0130] In a second option of this sub-scenario, it may be that the RedCap UE applies collision rules according to the in-time ordering of the two collisions. For example, as the first collision between the CG PUSCH 722 and the semi-statically configured PDSCH 724 occurs first, the RedCap UE may first apply a Case 3 collision rule to prioritize one of the CG PUSCH 722 and the semi-statically configured PDSCH 724 and drop the other of the CG PUSCH 722 and the semi-statically configured PDSCH 724. In the event that the result of the application of the Case 3 collision rule is that the semi-statically configured PDSCH 724 is prioritized and the CG PUSCH 722 is dropped, the RedCap UE will subsequently also perform the transmission of the PDSCH scheduled by PDCCH in CSS 726 (as the dropping of the CG PUSCH 722 also inherently resolves the second collision between the CG PUSCH 722 and the PDSCH scheduled by PDCCH in CSS 726) .

[0131] In the event that the result of the Case 3 collision rule is that the CG PUSCH 722 is prioritized and the semi-statically configured PDSCH 724 is dropped, the UE may proceed to resolve the second collision between the CG PUSCH 722 and the PDSCH scheduled by PDCCH in CSS 726 that occurs next by applying a Case 1 collision rule to prioritize one of the CG PUSCH 722 and the PDSCH scheduled by PDCCH in CSS 726 and drop the other of the CG PUSCH 722 and the PDSCH scheduled by PDCCH in CSS 726.

[0132] In a third option of this sub-scenario, it may be that the RedCap UE applies the multiple collision rules for the two collisions in a joint matter. In such a case, the UE analyzes the result of both of applying the Case 3 collision rule between the CG PUSCH 722 and the semi-statically configured PDSCH 724 and applying the Case 1 collision rule between the CG PUSCH 722 and the PDSCH scheduled by PDCCH in CSS 726. If either of these results calls for the CG PUSCH 722 to be dropped, then the CG PUSCH 722 is dropped and both of the semi-statically configured PDSCH 724 and the PDSCH scheduled by PDCCH in CSS 726 are received. Otherwise, the CG PUSCH 722 is transmitted and the semi-statically configured PDSCH 724 and the PDSCH scheduled by PDCCH in CSS 726 are dropped.

[0133] Note that this third option resolves an aspect of the second option where only the PDSCH scheduled by PDCCH in CSS 726 is ultimately used at the RedCap UE because the semi-statically configured PDSCH 724 is dropped as a result of first applying the Case 3 collision rule between the CG PUSCH 722 and the semi-statically configured PDSCH 724 and then the CG PUSCH 722 is dropped as a result of later applying the Case 1 collision rule between the CG PUSCH 722 and the PDSCH scheduled by PDCCH in CSS 726.

[0134] In a fourth option of this sub-scenario, it may be that the RedCap UE applies a priority rule that applies specifically to instances of collisions involving dynamically scheduled PDSCHs such as the PDSCH scheduled by PDCCH in CSS 726 (instead of, for example, another rule that is defined in terms of one of the Cases described herein) .

[0135] FIG. 7D illustrates a fourth sub-scenario where a schedule 728 at a RedCap UE involves a CG PUSCH 730 that is in both a first collision with a PDCCH in CSS 732 and a second collision with a dynamically scheduled PDSCH 734. The first collision with the PDCCH in CSS 732 is a Case 3 collision, while the second collision with the dynamically scheduled PDSCH 734 is a Case 1 collision.

[0136] In a first option for resolving this sub-scenario, it may be left to a (e.g., vendor-set) implementation of the RedCap UE to prioritize either the DL receptions (the PDCCH in CSS 732 and the dynamically scheduled PDSCH 734) or the UL transmission (the CG PUSCH 730) .

[0137] In a second option of this sub-scenario, it may be that the RedCap UE applies collision rules according to the in-time ordering of the two collisions. For example, as the first collision between the CG PUSCH 730 and the PDCCH in CSS 732 occurs first, the RedCap UE may first apply a Case 3 collision rule to prioritize one of the CG PUSCH 730 and the PDCCH in CSS 732 and drop the other of the CG PUSCH 730 and the PDCCH in CSS 732. In the event that the result of the application of the Case 3 collision rule is that the PDCCH in CSS 732 is prioritized and the CG PUSCH 730 is dropped, the RedCap UE will subsequently also perform the transmission of the dynamically scheduled PDSCH 734 (as the dropping of the CG PUSCH 730 also inherently resolves the second collision between the CG PUSCH 730 and the dynamically scheduled PDSCH 734) .

[0138] In the event that the result of the Case 3 collision rule is that the CG PUSCH 730 is prioritized and the PDCCH in CSS 732 is dropped, the UE may proceed to resolve the second collision between the CG PUSCH 730 and the dynamically scheduled PDSCH 734 that occurs next by applying a Case 1 collision rule to prioritize one of the CG PUSCH 730 and the dynamically scheduled PDSCH 734 and drop the other of the CG PUSCH 730 and the dynamically scheduled PDSCH 734.

[0139] In a third option of this sub-scenario, it may be that the RedCap UE applies the multiple collision rules for the two collisions in a joint matter. In such a case, the UE analyzes the result of both of applying the Case 3 collision rule between the CG PUSCH 730 and the PDCCH in CSS 732 and applying the Case 1 collision rule between the CG PUSCH 730 and the dynamically scheduled PDSCH 734. If either of these results calls for the CG PUSCH 730 to be dropped, then the CG PUSCH 730 is dropped and both of the PDCCH in CSS 732 and the dynamically scheduled PDSCH 734 are received. Otherwise, the CG PUSCH 730 is transmitted and the PDCCH in CSS 732 and the dynamically scheduled PDSCH 734 are dropped.

[0140] Note that this third option resolves an aspect of the second option where only the dynamically scheduled PDSCH 734 is ultimately used at the RedCap UE because the PDCCH in CSS 732 is dropped as a result of first applying the Case 3 collision rule between the CG PUSCH 730 and the PDCCH in CSS 732 and then the CG PUSCH 730 is dropped as a result of later applying the Case 1 collision rule between the CG PUSCH 730 and the dynamically scheduled PDSCH 734.

[0141] In a fourth option of this sub-scenario, it may be that the RedCap UE applies a priority rule that applies specifically to instances of collisions involving dynamically scheduled PDSCHs such as the dynamically scheduled PDSCH 734 (instead of, for example, another rule that is defined in terms of one of the Cases described herein) .

[0142] FIG. 7E illustrates a fifth sub-scenario where a schedule 736 at a RedCap UE involves a CG PUSCH 738 that is in both a first collision with a semi-statically configured PDSCH 740 and a second collision with a dynamically scheduled PDSCH 742. The first collision with the semi-statically configured PDSCH 740 is a Case 3  collision, while the second collision with the dynamically scheduled PDSCH 742 is a Case 1 collision.

[0143] In a first option for resolving this sub-scenario, it may be left to a (e.g., vendor-set) implementation of the RedCap UE to prioritize either the DL receptions (the semi-statically configured PDSCH 740 and the dynamically scheduled PDSCH 742) or the UL transmission (the CG PUSCH 738) .

[0144] In a second option of this sub-scenario, it may be that the RedCap UE applies collision rules according to the in-time ordering of the two collisions. For example, as the first collision between the CG PUSCH 738 and the semi-statically configured PDSCH 740 occurs first, the RedCap UE may first apply a Case 3 collision rule to prioritize one of the CG PUSCH 738 and the semi-statically configured PDSCH 740 and drop the other of the CG PUSCH 738 and the semi-statically configured PDSCH 740. In the event that the result of the application of the Case 3 collision rule is that the semi-statically configured PDSCH 740 is prioritized and the CG PUSCH 738 is dropped, the RedCap UE will subsequently also perform the transmission of the dynamically scheduled PDSCH 742 (as the dropping of the CG PUSCH 738 also inherently resolves the second collision between the CG PUSCH 738 and the dynamically scheduled PDSCH 742) .

[0145] In the event that the result of the Case 3 collision rule is that the CG PUSCH 738 is prioritized and the semi-statically configured PDSCH 740 is dropped, the UE may proceed to resolve the second collision between the CG PUSCH 738 and the dynamically scheduled PDSCH 742 that occurs next by applying a Case 1 collision rule to prioritize one of the CG PUSCH 738 and the dynamically scheduled PDSCH 742 and drop the other of the CG PUSCH 738 and the dynamically scheduled PDSCH 742.

[0146] In a third option of this sub-scenario, it may be that the RedCap UE applies the multiple collision rules for the two collisions in a joint matter. In such a case, the UE analyzes the result of both of applying the Case 3 collision rule between the CG PUSCH 738 and the semi-statically configured PDSCH 740 and applying the Case 1 collision rule between the CG PUSCH 738 and the dynamically scheduled PDSCH 742. If either of these results calls for the CG PUSCH 738 to be dropped, then the CG PUSCH 738 is dropped and both of the semi-statically configured PDSCH 740 and the dynamically scheduled PDSCH 742 are received. Otherwise, the CG PUSCH 738 is transmitted and the semi-statically configured PDSCH 740 and the dynamically scheduled PDSCH 742 are dropped.

[0147] Note that this third option resolves an aspect of the second option where only the dynamically scheduled PDSCH 742 is ultimately used at the RedCap UE because the semi-statically configured PDSCH 740 is dropped as a result of first applying the Case 3 collision rule between the CG PUSCH 738 and the semi-statically configured PDSCH 740 and then the CG PUSCH 738 is dropped as a result of later applying the Case 1 collision rule between the CG PUSCH 738 and the dynamically scheduled PDSCH 742.

[0148] In a fourth option of this sub-scenario, it may be that the RedCap UE applies a priority rule that applies specifically to instances of collisions involving dynamically scheduled PDSCHs such as the dynamically scheduled PDSCH 742 (instead of, for example, another rule that is defined in terms of one of the Cases described herein) .

[0149] FIGS. 8A through 8E illustrate various sub-scenarios of a fourth scenario where a dynamically scheduled UL transmission collides with two DL receptions.

[0150] FIG. 8A illustrates a first sub-scenario where a schedule 802 at a RedCap UE involves a DG PUSCH 804 that is in both a first collision with a PDSCH scheduled by PDCCH in CSS 806 and a second collision with a dynamically scheduled PDSCH 808. Each of the first collision with the first PDSCH scheduled by PDCCH in CSS 806 and the second collision with the dynamically scheduled PDSCH 808 are Case 4 collisions.

[0151] In a first option for this sub-scenario, it may be that a Case 4 priority rule defines a relative priority between a PDSCH that is scheduled by a PDCCH of one of type-0, type-0A, type-1, or type-2 that is in a CSS (such as the PDSCH scheduled by PDCCH in CSS 806) and the DG PUSCH 804. In such a case, that Case 4 priority rule is used to resolve whether to receive each of the PDSCH scheduled by PDCCH in CSS 806 and the dynamically scheduled PDSCH 808, or whether to transmit the DG PUSCH 804.

[0152] In a second option for this sub-scenario, it may be that the UE is configured to drop the PDSCH scheduled by PDCCH in CSS 806 and the dynamically scheduled PDSCH 808 and to transmit the DG PUSCH 804.

[0153] FIG. 8B illustrates a second sub-scenario where a schedule 810 at a RedCap UE involves a DG PUSCH 812 that is in both a first collision with a PDCCH in CSS 814 and a second collision with a PDSCH scheduled by PDCCH in CSS 816. For this sub-scenario, it should be understood that the PDSCH scheduled by PDCCH in CSS 816 is scheduled 818 by the PDCCH in CSS 814. The first collision with the PDCCH in CSS 814 is a Case 4 collision, while the second collision with the PDSCH scheduled by PDCCH in CSS 716 is a Case 2 collision.

[0154] In a first option for this sub-scenario, it may be that the PDCCH in CSS 814 and the PDSCH scheduled by PDCCH in CSS 816 are prioritized, and the DG PUSCH 812 is dropped.

[0155] In a second option for this sub-scenario, it may be that the DG PUSCH 812 is prioritized, and each of the PDCCH in CSS 814 and the PDSCH scheduled by PDCCH in CSS 816 is dropped.

[0156] FIG. 8C illustrates a third sub-scenario where a schedule 820 at a RedCap UE involves a DG PUSCH 822 that is in both a first collision with a PDCCH in CSS 824 and a second collision with a dynamically scheduled PDSCH 826. The first collision with the PDCCH in CSS 824 is a Case 4 collision, while the second collision with the dynamically scheduled PDSCH 826 is a Case 2 collision.

[0157] In a first option for resolving this sub-scenario, it may be left to a (e.g., vendor-set) implementation of the RedCap UE to prioritize either the DL receptions (the PDCCH in CSS 824 and the dynamically scheduled PDSCH 826) or the UL transmission (the DG PUSCH 822) .

[0158] In a second option of this sub-scenario, it may be that the RedCap UE applies collision rules according to the in-time ordering of the two collisions. For example, as the first collision between the DG PUSCH 822 and the PDCCH in CSS 824 occurs first, the RedCap UE may first apply a Case 4 collision rule to prioritize one of the DG PUSCH 822 and the PDCCH in CSS 824 and drop the other of the DG PUSCH 822 and the PDCCH in CSS 824. In the event that the result of the application of the Case 4 collision rule is that the PDCCH in CSS 824 is prioritized and the DG PUSCH 822 is dropped, the RedCap UE will subsequently also perform the transmission of the dynamically scheduled PDSCH 826 (as the dropping of the DG PUSCH 822 also inherently resolves the second collision between the DG PUSCH 822 and the dynamically scheduled PDSCH 826) .

[0159] In the event that the result of the Case 4 collision rule is that the DG PUSCH 822 is prioritized and the PDCCH in CSS 824 is dropped, the UE may proceed to resolve the second collision between the DG PUSCH 822 and the dynamically scheduled PDSCH 826 that occurs next by applying a Case 2 collision rule to prioritize one of the DG PUSCH 822 and the dynamically scheduled PDSCH 826 and drop the other of the DG PUSCH 822 and the dynamically scheduled PDSCH 826.

[0160] In a third option of this sub-scenario, it may be that the RedCap UE applies the multiple collision rules for the two collisions in a joint matter. In such a case, the UE analyzes the result of both of applying the Case 4 collision rule between the DG PUSCH 822 and the PDCCH in CSS 824 and applying the Case 2 collision rule between the DG PUSCH 822 and the dynamically scheduled PDSCH 826. If either of these results calls for the DG PUSCH 822 to be dropped, then the DG PUSCH 822 is dropped and both of the PDCCH in CSS 824 and the dynamically scheduled PDSCH 826 are received. Otherwise, the DG PUSCH 822 is transmitted and the PDCCH in CSS 824 and the dynamically scheduled PDSCH 826 are dropped.

[0161] Note that this third option resolves an aspect of the second option where only the dynamically scheduled PDSCH 826 is ultimately used at the RedCap UE because the PDCCH in CSS 824 is dropped as a result of first applying the Case 4 collision rule between the DG PUSCH 822 and the PDCCH in CSS 824 and then the DG PUSCH 822 is dropped as a result of later applying the Case 2 collision rule between the DG PUSCH 822 and the dynamically scheduled PDSCH 826.

[0162] In a fourth option of this sub-scenario, it may be that the RedCap UE applies a priority rule that applies specifically to instances of collisions involving dynamically scheduled PDSCHs such as the dynamically scheduled PDSCH 826 (instead of, for example, another rule that is defined in terms of one of the Cases described herein) .

[0163] FIG. 8D illustrates a third sub-scenario where a schedule 828 at a RedCap UE involves a DG PUSCH 830 that is in both a first collision with a semi-statically configured PDSCH 832 and a second collision with a dynamically scheduled PDSCH 834. The first collision with the semi-statically configured PDSCH 832 is a Case 4 collision, while the second collision with the dynamically scheduled PDSCH 834 is a Case 2 collision.

[0164] In a first option for resolving this sub-scenario, it may be left to a (e.g., vendor-set) implementation of the RedCap UE to prioritize either the DL receptions (the semi-statically configured PDSCH 832 and the dynamically scheduled PDSCH 834) or the UL transmission (the DG PUSCH 830) .

[0165] In a second option of this sub-scenario, it may be that the RedCap UE applies collision rules according to the in-time ordering of the two collisions. For example, as the first collision between the DG PUSCH 830 and the semi-statically configured PDSCH 832 occurs first, the RedCap UE may first apply a Case 4 collision rule to prioritize one of the DG PUSCH 830 and the semi-statically configured PDSCH 832 and drop the other of the DG PUSCH 830 and the semi-statically configured PDSCH 832. In the event that the result of the application of the Case 4 collision rule is that the semi-statically configured PDSCH 832 is prioritized and the DG PUSCH 830 is dropped, the RedCap UE will subsequently also perform the transmission of the dynamically scheduled PDSCH 834 (as the dropping of the DG PUSCH 830 also inherently resolves the second collision between the DG PUSCH 830 and the dynamically scheduled PDSCH 834) .

[0166] In the event that the result of the Case 4 collision rule is that the DG PUSCH 830 is prioritized and the semi-statically configured PDSCH 832 is dropped, the UE may proceed to resolve the second collision between the DG PUSCH 830 and the dynamically scheduled PDSCH 834 that occurs next by applying a Case 2 collision rule to prioritize one of the DG PUSCH 830 and the dynamically scheduled PDSCH 834 and drop the other of the DG PUSCH 830 and the dynamically scheduled PDSCH 834.

[0167] In a third option of this sub-scenario, it may be that the RedCap UE applies the multiple collision rules for the two collisions in a joint matter. In such a case, the UE analyzes the result of both of applying the Case 4 collision rule between the DG PUSCH 830 and the semi-statically configured PDSCH 832 and applying the Case 2 collision rule between the DG PUSCH 830 and the dynamically scheduled PDSCH 834. If either of these results calls for the DG PUSCH 830 to be dropped, then the DG PUSCH 830 is dropped and both of the semi-statically configured PDSCH 832 and the dynamically scheduled PDSCH 834 are received. Otherwise, the DG PUSCH 830 is transmitted and the semi-statically configured PDSCH 832 and the dynamically scheduled PDSCH 834 are dropped.

[0168] Note that this third option resolves an aspect of the second option where only the dynamically scheduled PDSCH 834 is ultimately used at the RedCap UE because the semi-statically configured PDSCH 832 is dropped as a result of first applying the Case 4 collision rule between the DG PUSCH 830 and the semi-statically configured PDSCH 832 and then the DG PUSCH 830 is dropped as a result of later applying the Case 2 collision rule between the DG PUSCH 830 and the dynamically scheduled PDSCH 834.

[0169] In a fourth option of this sub-scenario, it may be that the RedCap UE applies a priority rule that applies specifically to instances of collisions involving dynamically scheduled PDSCHs such as the dynamically scheduled PDSCH 834 (instead of, for example, another rule that is defined in terms of one of the Cases described herein) .

[0170] FIG. 8E illustrates a third sub-scenario where a schedule 836 at a RedCap UE involves a DG PUSCH 838 that is in both a first collision with a semi-statically configured PDSCH 840 and a second collision with a PDSCH scheduled by PDCCH in CSS 842. The first collision with the semi-statically configured PDSCH 840 is a Case 4 collision, while the second collision with the PDSCH scheduled by PDCCH in CSS 842 is a Case 2 collision.

[0171] In a first option for resolving this sub-scenario, it may be left to a (e.g., vendor-set) implementation of the RedCap UE to prioritize either the DL receptions (the semi-statically configured PDSCH 840 and the PDSCH scheduled by PDCCH in CSS 842) or the UL transmission (the DG PUSCH 838) .

[0172] In a second option of this sub-scenario, it may be that the RedCap UE applies collision rules according to the in-time ordering of the two collisions. For example, as the first collision between the DG PUSCH 838 and the semi-statically configured PDSCH 840 occurs first, the RedCap UE may first apply a Case 4 collision rule to prioritize one of the DG PUSCH 838 and the semi-statically configured PDSCH 840 and drop the other of the DG PUSCH 838 and the semi-statically configured PDSCH 840. In the event that the result of the application of the Case 4 collision rule is that the semi-statically configured PDSCH 840is prioritized and the DG PUSCH 838 is dropped, the RedCap UE will subsequently also perform the transmission of the PDSCH scheduled by PDCCH in CSS 842 (as the dropping of the DG PUSCH 838 also inherently resolves the second collision between the DG PUSCH 838 and the PDSCH scheduled by PDCCH in CSS 842) .

[0173] In the event that the result of the Case 4 collision rule is that the DG PUSCH 838 is prioritized and the semi-statically configured PDSCH 840 is dropped, the UE may proceed to resolve the second collision between the DG PUSCH 838 and the PDSCH scheduled by PDCCH in CSS 842 that occurs next by applying a Case 2 collision rule to prioritize one of the DG PUSCH 838 and the PDSCH scheduled by PDCCH in CSS 842 and drop the other of the DG PUSCH 838 and the PDSCH scheduled by PDCCH in CSS 842.

[0174] In a third option of this sub-scenario, it may be that the RedCap UE applies the multiple collision rules for the two collisions in a joint matter. In such a case, the UE analyzes the result of both of applying the Case 4 collision rule between the DG PUSCH 838 and the semi-statically configured PDSCH 840 and applying the Case 2 collision rule between the DG PUSCH 838 and the PDSCH scheduled by PDCCH in CSS 842. If either of these results calls for the DG PUSCH 838 to be dropped, then the DG PUSCH 838 is dropped and both of the semi-statically configured PDSCH 840 and the PDSCH scheduled by PDCCH in CSS 842 are received. Otherwise, the DG PUSCH 838 is transmitted and the semi-statically configured PDSCH 840 and the PDSCH scheduled by PDCCH in CSS 842 are dropped.

[0175] Note that this third option resolves an aspect of the second option where only the PDSCH scheduled by PDCCH in CSS 842 is ultimately used at the RedCap UE because the semi-statically configured PDSCH 840 is dropped as a result of first applying the Case 4 collision rule between the DG PUSCH 838 and the semi-statically configured PDSCH 840 and then the DG PUSCH 838 is dropped as a result of later applying the Case 2 collision rule between the DG PUSCH 838 and the PDSCH scheduled by PDCCH in CSS 842.

[0176] In a fourth option of this sub-scenario, it may be that the RedCap UE applies a priority rule that applies specifically to instances of collisions involving dynamically scheduled PDSCHs such as the PDSCH scheduled by PDCCH in CSS 842 (instead of, for example, another rule that is defined in terms of one of the Cases described herein) .

[0177] FIG. 9 illustrates various a fifth scenario illustrating a schedule 902 having a collision profile as between four different channels. This scenario is a case where a PDCCH of one of type-0, type-0A, type-1, or type-2 that is in a CSS collides with a with semi-statically configured UL transmission, and where a PDSCH scheduled by that PDCCH (adynamically scheduled UL transmission) collides with a dynamically scheduled UL transmission.

[0178] In particular, FIG. 9 illustrates that a PDCCH in CSS 904 (e.g., a PDCCH of one of type-0, type-0A, type-1, or type-2 in the CSS) is in a first collision with a CG PUSCH 906, and that an associated PDSCH scheduled by PDCCH in CSS 908 (e.g., that is scheduled 912 by the PDCCH of type-0, type-0A, type-1, or type-2 in the PDCCH in CSS 904) is in a second collision with a DG PUSCH 910.

[0179] The first collision between the PDCCH in CSS 904 and the CG PUSCH 906 is a Case 3 collision. The second collision between the PDSCH scheduled by PDCCH in CSS 908 and the DG PUSCH 910 is a Case 4 collision.

[0180] In such case, it may be that a Case 3 priority rule (e.g., as applied for PDCCHs of one of type-0, type-0A, type-1, or type-2 that are in a CSS) at the RedCap UE gives the same priority to each of the PDCCH in CSS 904 and the PDSCH scheduled by PDCCH in CSS 908 that is scheduled by the PDCCH in CSS 904 relative to the CG PUSCH 906 and the PDSCH scheduled by PDCCH in CSS 908, and thus resolves both the first collision and the second collision in the same way. In such cases, this Case 3 priority rule is sufficient to fully define a resolution for this scenario.

[0181] FIG. 10 illustrates a method 1000 of a RedCap UE, according to embodiments discussed herein. The method 1000 includes identifying 1002 that a CG-SDT scheduled in a UL collides with a semi-statically configured reception scheduled in a DL. The method 1000 further includes determining 1004 that a performance of one of the CG-SDT and the semi-statically configured reception will not prevent the RedCap UE from monitoring an SI change indication during a current modification period. The method 1000 further includes performing 1006 one of the CG-SDT and the semi-statically configured reception in response to the identifying that the CG-SDT collides with the semi-statically configured reception and the determining that the performance of the one of the CG-SDT and the semi-statically configured reception will not prevent the RedCap UE from the monitoring of the SI change indication during the current modification period.

[0182] In some embodiments, the method 1000 further includes determining that the semi-statically configured reception is for a PDCCH of one of type-0, type-0A, type-1, and type-2 that is in a CSS, wherein the performing the one of the CG-SDT and the semi-statically configured reception is further in response to determining that the semi-statically configured reception is for the PDCCH of the one of type-0, type-0A, type-1, and type-2 in the CSS.

[0183] In some embodiments of the method 1000, an initial DL BWP on which the CG-SDT is to be sent is associated with a CD-SSB.

[0184] FIG. 11 illustrates a method 1100 of a RedCap UE, according to embodiments discussed herein. The method 1100 includes identifying 1102 that a semi-statically configured reception scheduled in a DL that collides with a CG-SDT scheduled in an UL is not a PDCCH that is one of type-0, type-0A, type-1, and type-2 that is in a CSS. The method 1100 further includes performing 1104 the semi-statically configured reception in response to the identifying that the semi-statically configured reception that collides with the CG-SDT is not the PDCCH that is of one of type-0, type-0A, type-1, and type-2 in the CSS.

[0185] FIG. 12 illustrates a method 1200 of a RedCap UE, according to embodiments discussed herein. The method 1200 includes identifying 1202 that a semi-statically configured reception scheduled in a DL that collides with a CG-SDT scheduled in a UL is not a PDCCH that is one of type-0, type-0A, type-1, and type-2 that is in a CSS. The method 1200 further includes performing 1204 one of the CG-SDT and the semi-statically configured reception based on an indication received from a base station that indicates performance of one of the CG-SDT scheduled in the UL and the semi-statically configured reception when the CG-SDT scheduled in the UL collides with the semi-statically configured reception that is not the PDCCH of one of type-0, type-0A, type-1, and type-2 in the CSS.

[0186] FIG. 13 illustrates a method 1300 of a RedCap UE, according to embodiments discussed herein. The method 1300 includes identifying 1302 that a CG-SDT scheduled in a UL collides with a semi-statically configured reception scheduled in a DL. The method 1300 further includes performing 1304 one of the CG-SDT and the semi-statically configured reception based on an indication received from a base station that indicates a prioritization of one of the he CG-SDT and the semi-statically configured reception over the other of the CG-SDT and the semi-statically configured reception.

[0187] FIG. 14 illustrates a method 1400 of a RedCap UE, according to embodiments discussed herein. The method 1400 includes block 1402 that a dynamically scheduled UL transmission collides with a reception of a PDSCH scheduled by a PDCCH of one of type-0, type-0A, type-1, and type-2 that is in a CSS. The method 1400 further includes determining 1404 that a performance of one of the dynamically scheduled UL transmission and the reception of the PDSCH will not prevent the RedCap UE from monitoring an SI change indication during a current modification period. The method 1400 further includes performing 1406 the one of the dynamically scheduled UL transmission and the reception of the PDSCH in response to the identifying that the dynamically scheduled UL transmission collides with the reception of the PDSCH and the determining that the performance of the one of the dynamically scheduled UL transmission and the reception of the PDSCH will not prevent the RedCap UE from performing the monitoring of the SI change indication during the current modification period.

[0188] In some embodiments, the method 1400 further includes identifying that the RedCap UE is configured to monitor the CSS; and identifying the reception of the PDSCH as the one of the dynamically scheduled UL transmission and the reception of the PDSCH that is performed by the RedCap UE in response to the identifying that the RedCap UE is configured to monitor the CSS.

[0189] FIG. 15 illustrates a method 1500 of a RedCap UE, according to embodiments discussed herein. The method 1500 includes identifying 1502 that a dynamically scheduled DL reception that collides with a dynamically scheduled UL transmission is not a PDSCH that is scheduled by a PDCCH of one of type-0, type-0A, type-1, and type-2 that is in a CSS. The method 1500 further includes performing 1504 the dynamically scheduled DL reception in response to the identifying that the dynamically scheduled DL reception that collides with a dynamically scheduled UL transmission is not the PDSCH that is scheduled by the PDCCH of one of type-0, type-0A, type-1, and type-2 in the CSS.

[0190] FIG. 16 illustrates a method 1600 of a RedCap UE, according to embodiments discussed herein. The method 1600 includes identifying 1602 that a dynamically scheduled DL reception that collides with a dynamically scheduled UL transmission is not a PDSCH that is scheduled by a PDCCH of one of type-0, type-0A, type-1, and type-2 that is in a CSS. The method 1600 further includes performing 1604 one of the dynamically scheduled UL transmission and the dynamically scheduled DL reception based on an indication received from a base station that indicates performance of one of the dynamically scheduled UL transmission and the dynamically scheduled DL reception when the dynamically scheduled UL transmission collides with the dynamically scheduled DL reception that is not the PDSCH that is scheduled by the PDCCH of one of type-0, type-0A, type-1, and type-2 in the CSS.

[0191] In some embodiments of the method 1600, the indication comprises a joint indication that also indicates performance of one of a semi-statically configured UL transmission and a semi-statically configured DL reception when the semi-statically configured UL transmission collides with the semi-statically configured DL reception.

[0192] FIG. 17 illustrates a method 1700 of a RedCap UE, according to embodiments discussed herein. The method 1700 includes identifying 1702 that a dynamically scheduled DL reception collides with a dynamically scheduled UL transmission. The method 1700 further includes identifying 1704 a first channel type of the dynamically scheduled DL reception and a second channel type of the dynamically scheduled UL transmission. The method 1700 further includes performing 1706 one of the dynamically scheduled DL reception and the dynamically scheduled UL transmission based on a priority rule that indicates a prioritization of one of the first channel type and the second channel type over the other of the first channel type and the second channel type.

[0193] FIG. 18 illustrates a method 1800 of a RedCap UE, according to embodiments discussed herein. The method 1800 includes identifying 1802 that a dynamically scheduled DL reception collides with a dynamically scheduled UL transmission. The method 1800 further includes performing 1804 one of the dynamically scheduled DL reception and the dynamically scheduled UL transmission based on an indication received from a base station that indicates a prioritization of one of the dynamically scheduled DL reception and the dynamically scheduled UL transmission over the other of the dynamically scheduled DL reception and the dynamically scheduled UL transmission.

[0194] FIG. 19 illustrates a method 1900 of a RedCap UE, according to embodiments discussed herein. The method 1900 includes identifying 1902 a first collision between a DL reception and a first UL transmission and a second collision between the DL reception and a second UL transmission that occurs after the first UL transmission. The method 1900 further includes determining 1904, based on a DL channel type of the DL reception, a first UL channel type of the first UL transmission, and a second UL channel type of the second UL transmission, to resolve the first collision prior to any resolving of the second collision. The method 1900 further includes resolving 1906, method 1900 resolves the first collision.

[0195] In some embodiments of the method 1900, resolving the first collision comprises dropping the DL reception.

[0196] In some embodiments of the method 1900, resolving the first collision comprises dropping the first UL transmission, and the method 1900 further includes resolving the second collision after resolving the first collision.

[0197] In some embodiments of the method 1900, the DL channel type of the DL reception comprises a PDCCH of one of type-0, type-0A, type-1, and type-2 that is in a CSS channel type; the first UL channel type of the first UL transmission comprises a semi-statically configured PUSCH channel type; and the second UL channel type of the second UL transmission comprises a dynamically scheduled PUSCH channel type.

[0198] In some embodiments of the method 1900, the DL channel type of the DL reception comprises a semi-statically configured PDSCH channel type; the first UL channel type of the first UL transmission comprises a semi-statically configured PUSCH channel type; and the second UL channel type of the second UL transmission comprises a dynamically scheduled PUSCH channel type.

[0199] In some embodiments of the method 1900, the DL channel type of the DL reception comprises a PDSCH scheduled by a PDCCH of one of type-0, type-0A, type-1, and type-2 that is in a CSS channel type; the first UL channel type of the first UL transmission comprises a dynamically scheduled PUSCH channel type; and the second UL channel type of the second UL transmission comprises a semi-statically configured PUSCH channel type.

[0200] In some embodiments of the method 1900, the DL channel type of the DL reception comprises a dynamically scheduled PDSCH channel type; the first UL channel type of the first UL transmission comprises a dynamically scheduled PUSCH channel type; and the second UL channel type of the second UL transmission comprises a semi-statically configured PUSCH channel type.

[0201] FIG. 20 illustrates a method 2000 of a RedCap UE, according to embodiments discussed herein. The method 2000 includes identifying 2002 a first collision between a DL reception and a first UL transmission and a second collision between the DL reception and a second UL transmission that occurs after the first UL transmission. The method 2000 further includes jointly resolving 2004 the first collision and the second collision by determining, based on a DL channel type of the DL reception, a first UL channel type of the first UL transmission, and a second UL channel type of the second UL transmission, whether either of the first UL transmission or the second UL transmission takes priority over the DL reception.

[0202] In some embodiments of the method 2000, the DL channel type of the DL reception comprises a PDCCH of one of type-0, type-0A, type-1, and type-2 that is in a CSS channel type; the first UL channel type of the first UL transmission comprises a semi-statically configured PUSCH channel type; and the second UL channel type of the second UL transmission comprises a dynamically scheduled PUSCH channel type.

[0203] In some embodiments of the method 2000, the DL channel type of the DL reception comprises a semi-statically configured PDSCH channel type; the first UL channel type of the first UL transmission comprises a semi-statically configured PUSCH channel type; and the second UL channel type of the second UL transmission comprises a dynamically scheduled PUSCH channel type.

[0204] In some embodiments of the method 2000, the DL channel type of the DL reception comprises a PDSCH scheduled by a PDCCH of one of type-0, type-0A, type-1, and type-2 that is in a CSS channel type; the first UL channel type of the first UL transmission comprises a dynamically scheduled PUSCH channel type; and the second UL channel type of the second UL transmission comprises a semi-statically configured PUSCH channel type.

[0205] In some embodiments of the method 2000, the DL channel type of the DL reception comprises a dynamically scheduled PDSCH channel type; the first UL channel type of the first UL transmission comprises a dynamically scheduled PUSCH channel type; and the second UL channel type of the second UL transmission comprises a semi-statically configured PUSCH channel type.

[0206] FIG. 21 illustrates a method 2100 of a RedCap UE, according to embodiments discussed herein. The method 2100 includes identifying 2102 a first collision between a UL transmission and a first DL reception and a second collision between the UL transmission and a second DL reception that occurs after the first DL reception. The method 2100 further includes determining 2104, based on a UL channel type of the UL transmission, a first DL channel type of the first DL reception, and a second DL channel type of the second DL reception, to resolve the first collision prior to any resolving of the second collision. The method 2100 further includes resolving 2106 the first collision.

[0207] In some embodiments of the method 2100, resolving the first collision comprises dropping the UL transmission.

[0208] In some embodiments of the method 2100, resolving the first collision comprises dropping the first DL reception, and further comprising resolving the second collision after resolving the first collision.

[0209] In some embodiments of the method 2100, the UL channel type of the UL transmission comprises a semi-statically configured PUSCH channel type the first DL channel type of the first DL reception comprises a semi-statically configured PDSCH channel type; and the second DL channel type of the second DL reception comprises a PDSCH scheduled by a PDCCH in a CSS channel type.

[0210] In some embodiments of the method 2100, the UL channel type of the UL transmission comprises a semi-statically configured PUSCH channel type; the first DL reception type of the first DL reception comprises a PDCCH in a CSS channel type; and the second DL channel type of the second DL reception comprises a dynamically scheduled PDSCH channel type.

[0211] In some embodiments of the method 2100, the UL channel type of the UL transmission comprises a semi-statically configured PUSCH channel type; the first DL channel type of the first DL reception comprises a semi-statically configured PDCCH channel type; and the second DL channel type of the second DL reception comprises a dynamically scheduled PDSCH channel type.

[0212] In some embodiments of the method 2100, the UL channel type of the UL transmission comprises a dynamically scheduled PUSCH channel type; the first DL channel type of the first DL reception comprises a PDCCH in a CSS channel type; and the second DL channel type of the second DL reception comprises a dynamically scheduled PDSCH channel type.

[0213] In some embodiments of the method 2100, the UL channel type of the UL transmission comprises a dynamically scheduled PUSCH channel type; the first DL channel type of the first DL reception comprises a semi-statically configured PDSCH channel type; and the second DL channel type of the second DL reception comprises a dynamically scheduled PDSCH channel type.

[0214] In some embodiments of the method 2100, the UL channel type of the UL transmission comprises a dynamically scheduled PUSCH channel type; the first DL channel type of the first DL reception comprises a semi-statically configured PDSCH channel type; and the second DL channel type of the second DL reception comprises a PDSCH scheduled by a PDCCH that is in a CSS channel type.

[0215] FIG. 22 illustrates a method 2200 of a RedCap UE, according to embodiments discussed herein. The method 2200 includes identifying 2202 a first collision between a UL transmission and a first DL reception and a second collision between the UL transmission and a second DL reception that occurs after the first DL reception. The method 2200 further includes jointly resolving 2204 the first collision and the second collision by determining, based on a UL channel type of the UL transmission, a first DL channel type of the first DL reception, and a second DL channel type of the second DL reception, whether either of the first DL reception or the second DL reception takes priority over the UL transmission.

[0216] In some embodiments of the method 2200, the UL channel type of the UL transmission comprises a semi-statically configured PUSCH channel type; the first DL channel type of the first DL reception comprises a semi-statically configured PDSCH channel type; and the second DL channel type of the second DL reception comprises a PDSCH scheduled by a PDCCH in a CSS channel type.

[0217] In some embodiments of the method 2200, the UL channel type of the UL transmission comprises a semi-statically configured PUSCH channel type; the first DL channel type of the first DL reception comprises a PDCCH in a CSS channel type; and the second DL channel type of the second DL reception comprises a dynamically scheduled PDSCH channel type.

[0218] In some embodiments of the method 2200, the UL channel type of the UL transmission comprises a semi-statically configured PUSCH channel type; the first DL channel type of the first DL reception comprises a semi-statically configured PDCCH channel type; and the second DL channel type of the second DL reception comprises a dynamically scheduled PDSCH channel type.

[0219] In some embodiments of the method 2200, the UL channel type of the UL transmission comprises a dynamically scheduled PUSCH channel type; the first DL channel type of the first DL reception comprises a PDCCH in a CSS channel type; and the second DL channel type of the second DL reception comprises a dynamically scheduled PDSCH channel type.

[0220] In some embodiments of the method 2200, the UL channel type of the UL transmission comprises a dynamically scheduled PUSCH channel type; the first DL channel type of the first DL reception comprises a semi-statically configured PDSCH channel type; and the second DL channel type of the second DL reception comprises a dynamically scheduled PDSCH channel type.

[0221] In some embodiments of the method 2200, the UL channel type of the UL transmission comprises a dynamically scheduled PUSCH channel type; the first DL channel type of the first DL reception comprises a semi-statically configured PDSCH channel type; and the second DL channel type of the second DL reception comprises a PDSCH scheduled by a PDCCH that is in a CSS channel type.

[0222] FIG. 23 illustrates an example architecture of a wireless communication system 2300, according to embodiments disclosed herein. The following description is provided for an example wireless communication system 2300 that operates in conjunction with the LTE system standards and / or 5G or NR system standards as provided by 3GPP technical specifications and other 3GPP documents.

[0223] As shown by FIG. 23, the wireless communication system 2300 includes UE 2302 and UE 2304 (although any number of UEs may be used) . In this example, the UE 2302 and the UE 2304 are illustrated as smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more cellular networks) , but may also comprise any mobile or non-mobile computing device configured for wireless communication.

[0224] The UE 2302 and UE 2304 may be configured to communicatively couple with a RAN 2306. In embodiments, the RAN 2306 may be NG-RAN, E-UTRAN, etc. The UE 2302 and UE 2304 utilize connections (or channels) (shown as connection 2308 and connection 2310, respectively) with the RAN 2306, each of which comprises a physical communications interface. The RAN 2306 can include one or more base stations (such as terrestrial base station 2312, the terrestrial base station 2314 the satellite base station 2336 and the satellite base station 2338) and / or other entities (e.g., the satellite 2342, which may not have base station functionality) that enable the connection 2308 and connection 2310. One or more satellite gateways 2334 may integrate the satellite base station 2336, satellite base station 2338, and / or the satellite 2342 into the RAN 2306, in the manners (and with the appropriate elements) described in relation to the NTN architecture 100 of FIG. 1 and the NTN architecture 200 of FIG. 2.

[0225] It may be understood that, in alternative embodiments to FIG. 23, the satellite base station 2336, the satellite base station 2338, and / or the satellite 2342 may instead comprise a non-satellite NTN vehicle (e.g., an airplane, a UAV, a UAS, an airship, a balloon, etc. ) . Further, it may be understood in such alternative embodiments that any satellite gateway 2334 may be a gateway for or corresponding to that applicable NTN vehicle type.

[0226] In this example, the connection 2308 and connection 2310 are air interfaces to enable such communicative coupling, and may be consistent with RAT (s) used by the RAN 2306, such as, for example, an LTE and / or NR. It is contemplated that the connection 2308 and connection 2310 may include, in some embodiments, service links between their respective UE 2302, UE 2304 and one or more of the satellite base station 2336, the satellite base station 2338, and the satellite 2342.

[0227] In some embodiments, the UE 2302 and UE 2304 may also directly exchange communication data via a sidelink interface 2316.

[0228] The UE 2304 is shown to be configured to access an access point (shown as AP 2318) via connection 2320. By way of example, the connection 2320 can comprise a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, wherein the AP 2318 may comprise a router. In this example, the AP 2318 may be connected to another network (for example, the Internet) without going through a CN 2324.

[0229] In embodiments, the UE 2302 and UE 2304 can be configured to communicate using orthogonal frequency division multiplexing (OFDM) communication signals with each other, with the terrestrial base station 2312, the terrestrial base station 2314, the satellite base station 2336, the satellite base station 2338, and / or the satellite 2342 over a multicarrier communication channel in accordance with various communication techniques, such as, but not limited to, an orthogonal frequency division multiple access (OFDMA) communication technique (e.g., for downlink communications) or a single carrier frequency division multiple access (SC-FDMA) communication technique (e.g., for uplink and ProSe or sidelink communications) , although the scope of the embodiments is not limited in this respect. The OFDM signals can comprise a plurality of orthogonal subcarriers.

[0230] In some embodiments, all or parts of the terrestrial base station 2312, terrestrial base station 2314, the satellite base station 2336 and / or the satellite base station 2338 may be implemented as one or more software entities running on server computers as part of a virtual network.

[0231] In addition, or in other embodiments, the terrestrial base station 2312 or terrestrial base station 2314 may be configured to communicate with one another via interface 2322. In embodiments where the wireless communication system 2300 is an LTE system (e.g., when the CN 2324 is an EPC) , the interface 2322 may be an X2 interface. The X2 interface may be defined between two or more base stations (e.g., two or more eNBs and the like) that connect to an EPC, and / or between two eNBs connecting to the EPC. It is contemplated than an inter-satellite link (ISL) may carry the X2 interface between in the case of two satellite base stations.

[0232] In embodiments where the wireless communication system 2300 is an NR system (e.g., when CN 2324 is a 5GC) , the interface 2322 may be an Xn interface. An Xn interface is defined between two or more base stations that connect to 5GC (e.g., CN 2324) . For example, the Xn interface may be between two or more gNBs that connect to 5GC, a gNB connecting to 5GC and an eNB, between two eNBs connecting to 5GC, and / or two or more satellite base stations via an ISL (as in, e.g., the interface 2340 between the satellite base station 2336 and the satellite base station 2338) .

[0233] The RAN 2306 is shown to be communicatively coupled to the CN 2324. The CN 2324 may comprise one or more network elements 2326, which are configured to offer various data and telecommunications services to customers / subscribers (e.g., users of UE 2302 and UE 2304) who are connected to the CN 2324 via the RAN 2306. The components of the CN 2324 may be implemented in one physical device or separate physical devices including components to read and execute instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) . For example, the components of the CN 2324 may be implemented in one or more processors and / or one or more associated memories.

[0234] In embodiments, the CN 2324 may be an EPC, and the RAN 2306 may be connected with the CN 2324 via an S1 interface 2328. In embodiments, the S1 interface 2328 may be split into two parts, an S1 user plane (S1-U) interface, which carries traffic data between the terrestrial base station 2312, terrestrial base station 2314, the satellite base station 2336, or the interface 2340 and a serving gateway (S-GW) , and the S1-MME interface, which is a signaling interface between the terrestrial base station 2312, the terrestrial base station 2314 the satellite base station 2336, or the interface 2340 and mobility management entities (MMEs) .

[0235] In embodiments, the CN 2324 may be a 5GC, and the RAN 2306 may be connected with the CN 2324 via an NG interface 2328. In embodiments, the NG interface 2328 may be split into two parts, an NG user plane (NG-U) interface, which carries traffic data between the terrestrial base station 2312, terrestrial base station 2314, satellite base station 2336, or satellite base station 2338 and a user plane function (UPF) , and the S1 control plane (NG-C) interface, which is a signaling interface between the terrestrial base station 2312, terrestrial base station 2314 satellite base station 2336, or satellite base station 2338 and access and mobility management functions (AMFs) .

[0236] Generally, an application server 2330 may be an element offering applications that use internet protocol (IP) bearer resources with the CN 2324 (e.g., packet switched data services) . The application server 2330 can also be configured to support one or more communication services (e.g., VoIP sessions, group communication sessions, etc. ) for the UE 2302 and UE 2304 via the CN 2324. The application server 2330 may communicate with the CN 2324 through an IP communications interface 2332.

[0237] FIG. 24 illustrates a system 2400 for performing signaling 2432 between a wireless device 2402 and a RAN device 2418, according to embodiments disclosed herein. The system 2400 may be a portion of a wireless communications system as herein described. The wireless device 2402 may be, for example, a UE of a wireless communication system. The RAN device 2418 may be, for example, a base station (e.g., an eNB or a gNB) of a wireless communication system that is a terrestrial base station or that is a non-terrestrial base station sited on an NTN vehicle. In the case of a RAN device 2418 that is a terrestrial base station, the RAN device 2418 may be in communication with an NTN vehicle that directly provides radio access connectivity to a UE, in the manner described herein.

[0238] The wireless device 2402 may include one or more processor (s) 2404. The processor (s) 2404 may execute instructions such that various operations of the wireless device 2402 are performed, as described herein. The processor (s) 2404 may include one or more baseband processors implemented using, for example, a central processing unit (CPU) , a digital signal processor (DSP) , an application specific integrated circuit (ASIC) , a controller, a field programmable gate array (FPGA) device, another hardware device, a firmware device, or any combination thereof configured to perform the operations described herein.

[0239] The wireless device 2402 may include a memory 2406. The memory 2406 may be a non-transitory computer-readable storage medium that stores instructions 2408 (which may include, for example, the instructions being executed by the processor (s) 2404) . The instructions 2408 may also be referred to as program code or a computer program. The memory 2406 may also store data used by, and results computed by, the processor (s) 2404.

[0240] The wireless device 2402 may include one or more transceiver (s) 2410 that may include radio frequency (RF) transmitter and / or receiver circuitry that use the antenna (s) 2412 of the wireless device 2402 to facilitate signaling (e.g., the signaling 2432) to and / or from the wireless device 2402 with other devices (e.g., the RAN device 2418) according to corresponding RATs. In some embodiments, the antenna (s) 2412 may include a moving parabolic antenna, an omni-directional phased-array antenna, or some other antenna suitable for communication with an NTN vehicle, (e.g., as described above in relation to the UE 110 of FIG. 1 and the UE 208 of FIG. 2) .

[0241] For a RAN device 2418 that is a terrestrial base station, the network device signaling 2432 may occur on a service link between the wireless device 2402 and an NTN vehicle and a feeder link between the NTN vehicle and the RAN device 2418 (e.g., as described in relation to FIG. 1) . For a RAN device 2418 that is a base station sited on an NTN vehicle, the signaling 2432 may occur on a service link between the wireless device 2402 and the RAN device 2418 (e.g., as described in relation to FIG. 2) .

[0242] The wireless device 2402 may include one or more antenna (s) 2412 (e.g., one, two, four, or more) . For embodiments with multiple antenna (s) 2412, the wireless device 2402 may leverage the spatial diversity of such multiple antenna (s) 2412 to send and / or receive multiple different data streams on the same time and frequency resources. This behavior may be referred to as, for example, multiple input multiple output (MIMO) behavior (referring to the multiple antennas used at each of a transmitting device and a receiving device that enable this aspect) . MIMO transmissions by the wireless device 2402 may be accomplished according to precoding (or digital beamforming) that is applied at the wireless device 2402 that multiplexes the data streams across the antenna (s) 2412 according to known or assumed channel characteristics such that each data stream is received with an appropriate signal strength relative to other streams and at a desired location in the spatial domain (e.g., the location of a receiver associated with that data stream) . Certain embodiments may use single user MIMO (SU-MIMO) methods (where the data streams are all directed to a single receiver) and / or multi user MIMO (MU-MIMO) methods (where individual data streams may be directed to individual (different) receivers in different locations in the spatial domain) .

[0243] In certain embodiments having multiple antennas, the wireless device 2402 may implement analog beamforming techniques, whereby phases of the signals sent by the antenna (s) 2412 are relatively adjusted such that the (joint) transmission of the antenna (s) 2412 can be directed (this is sometimes referred to as beam steering) .

[0244] The wireless device 2402 may include one or more interface (s) 2414. The interface (s) 2414 may be used to provide input to or output from the wireless device 2402. For example, a wireless device 2402 that is a UE may include interface (s) 2414 such as microphones, speakers, a touchscreen, buttons, and the like in order to allow for input and / or output to the UE by a user of the UE. Other interfaces of such a UE may be made up of made up of transmitters, receivers, and other circuitry (e.g., other than the transceiver (s) 2410 / antenna (s) 2412 already described) that allow for communication between the UE and other devices and may operate according to known protocols (e.g.,  and the like) .

[0245] The wireless device 2402 may include a RedCap channel prioritization module 2416. The RedCap channel prioritization module 2416 may be implemented via hardware, software, or combinations thereof. For example, the RedCap channel prioritization module 2416 may be implemented as a processor, circuit, and / or instructions 2408 stored in the memory 2406 and executed by the processor (s) 2404. In some examples, the RedCap channel prioritization module 2416 may be integrated within the processor (s) 2404 and / or the transceiver (s) 2410. For example, the RedCap channel prioritization module 2416 may be implemented by a combination of software components (e.g., executed by a DSP or a general processor) and hardware components (e.g., logic gates and circuitry) within the processor (s) 2404 or the transceiver (s) 2410.

[0246] The RedCap channel prioritization module 2416 may be used for various aspects of the present disclosure, for example, aspects of any one or more of FIG. 10 through FIG. 22. For example, the RedCap channel prioritization module 2416 may configure the wireless device 2402 to perform one or more aspects of any one or more of the method 1000, the method 1100, the method 1200, the method 1300, the method 1400, the method 1500, the method 1600, the method 1700, the method 1800, the method 1900, the method 2000, the method 2100, and / or the method 2200 as described in these figures.

[0247] The RAN device 2418 may include one or more processor (s) 2420. The processor (s) 2420 may execute instructions such that various operations of the RAN device 2418 are performed, as described herein. The processor (s) 2404 may include one or more baseband processors implemented using, for example, a CPU, a DSP, an ASIC, a controller, an FPGA device, another hardware device, a firmware device, or any combination thereof configured to perform the operations described herein.

[0248] The RAN device 2418 may include a memory 2422. The memory 2422 may be a non-transitory computer-readable storage medium that stores instructions 2424 (which may include, for example, the instructions being executed by the processor (s) 2420) . The instructions 2424 may also be referred to as program code or a computer program. The memory 2422 may also store data used by, and results computed by, the processor (s) 2420.

[0249] The RAN device 2418 may include one or more transceiver (s) 2426 that may include RF transmitter and / or receiver circuitry that use the antenna (s) 2428 of the RAN device 2418 to facilitate signaling (e.g., the signaling 2432) to and / or from the RAN device 2418 with other devices (e.g., the wireless device 2402) according to corresponding RATs.

[0250] The RAN device 2418 may include one or more antenna (s) 2428 (e.g., one, two, four, or more) . In embodiments having multiple antenna (s) 2428, the RAN device 2418 may perform MIMO, digital beamforming, analog beamforming, beam steering, etc., as has been described.

[0251] For a RAN device 2418 that is a terrestrial base station, one or more of the transceiver (s) 2426 and / or the antenna (s) 2428 may instead be present on a satellite gateway (or a gateway for another applicable NTN vehicle type) associated with the base station (e.g., as shown in reference to the terrestrial base station 104 and the satellite gateway 106 of FIG. 1) . For a RAN device 2418 that is a base station sited on an NTN vehicle, the transceiver (s) 2426 and / or the antenna (s) 2428 may be present on the NTN vehicle, and one or more of those antenna (s) 2428 may be antenna (s) appropriate for non-terrestrial communication (such as a moving parabolic antenna, an omni-directional phased-array antenna, etc. )

[0252] The RAN device 2418 may include one or more interface (s) 2430. The interface (s) 2430 may be used to provide input to or output from the RAN device 2418. For example, a RAN device 2418 that is a base station may include interface (s) 2430 made up of transmitters, receivers, and other circuitry (e.g., other than the transceiver (s) 2426 / antenna (s) antenna (s) 2428 already described) that enables the base station to communicate with other equipment in a CN, and / or that enables the base station to communicate with external networks, computers, databases, and the like for purposes of operations, administration, and maintenance of the base station or other equipment operably connected thereto.

[0253] Embodiments contemplated herein include an apparatus comprising means to perform one or more elements of any one or more of the method 1000, the method 1100, the method 1200, the method 1300, the method 1400, the method 1500, the method 1600, the method 1700, the method 1800, the method 1900, the method 2000, the method 2100, and / or the method 2200. This apparatus may be, for example, an apparatus of a UE (such as a wireless device 2402 that is a UE, as described herein) .

[0254] Embodiments contemplated herein include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of any one or more of the method 1000, the method 1100, the method 1200, the method 1300, the method 1400, the method 1500, the method 1600, the method 1700, the method 1800, the method 1900, the method 2000, the method 2100, and / or the method 2200. This non-transitory computer-readable media may be, for example, a memory of a UE (such as a memory 2406 of a wireless device 2402 that is a UE, as described herein) .

[0255] Embodiments contemplated herein include an apparatus comprising logic, modules, or circuitry to perform one or more elements of any one or more of the method 1000, the method 1100, the method 1200, the method 1300, the method 1400, the method 1500, the method 1600, the method 1700, the method 1800, the method 1900, the method 2000, the method 2100, and / or the method 2200. This apparatus may be, for example, an apparatus of a UE (such as a wireless device 2402 that is a UE, as described herein) .

[0256] Embodiments contemplated herein include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of any one or more of the method 1000, the method 1100, the method 1200, the method 1300, the method 1400, the method 1500, the method 1600, the method 1700, the method 1800, the method 1900, the method 2000, the method 2100, and / or the method 2200. This apparatus may be, for example, an apparatus of a UE (such as a wireless device 2402 that is a UE, as described herein) .

[0257] Embodiments contemplated herein include a signal as described in or related to one or more elements of any one or more of the method 1000, the method 1100, the method 1200, the method 1300, the method 1400, the method 1500, the method 1600, the method 1700, the method 1800, the method 1900, the method 2000, the method 2100, and / or the method 2200.

[0258] Embodiments contemplated herein include a computer program or computer program product comprising instructions, wherein execution of the program by a processor is to cause the processor to carry out one or more elements of any one or more of the method 1000, the method 1100, the method 1200, the method 1300, the method 1400, the method 1500, the method 1600, the method 1700, the method 1800, the method 1900, the method 2000, the method 2100, and / or the method 2200. The processor may be a processor of a UE (such as a processor (s) 2404 of a wireless device 2402 that is a UE, as described herein) . These instructions may be, for example, located in the processor and / or on a memory of the UE (such as a memory 2406 of a wireless device 2402 that is a UE, as described herein) .

[0259] For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, and / or methods as set forth herein. For example, a baseband processor as described herein in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth herein. For another example, circuitry associated with a UE, base station, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth herein.

[0260] Any of the above described embodiments may be combined with any other embodiment (or combination of embodiments) , unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

[0261] Embodiments and implementations of the systems and methods described herein may include various operations, which may be embodied in machine-executable instructions to be executed by a computer system. A computer system may include one or more general-purpose or special-purpose computers (or other electronic devices) . The computer system may include hardware components that include specific logic for performing the operations or may include a combination of hardware, software, and / or firmware.

[0262] It should be recognized that the systems described herein include descriptions of specific embodiments. These embodiments can be combined into single systems, partially combined into other systems, split into multiple systems or divided or combined in other ways. In addition, it is contemplated that parameters, attributes, aspects, etc. of one embodiment can be used in another embodiment. The parameters, attributes, aspects, etc. are merely described in one or more embodiments for clarity, and it is recognized that the parameters, attributes, aspects, etc. can be combined with or substituted for parameters, attributes, aspects, etc. of another embodiment unless specifically disclaimed herein.

[0263] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

[0264] Although the foregoing has been described in some detail for purposes of clarity, it will be apparent that certain changes and modifications may be made without departing from the principles thereof. It should be noted that there are many alternative ways of implementing both the processes and apparatuses described herein. Accordingly, the present embodiments are to be considered illustrative and not restrictive, and the description is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims

1.A method of a reduced capability (RedCap) user equipment (UE) , comprising:identifying that a configured grant small data transmission (CG-SDT) scheduled in an uplink (UL) collides with a semi-statically configured reception scheduled in a downlink (DL) ;determining that a performance of one of the CG-SDT and the semi-statically configured reception will not prevent the RedCap UE from monitoring a system information (SI) change indication during a current modification period; andperforming one of the CG-SDT and the semi-statically configured reception in response to:the identifying that the CG-SDT collides with the semi-statically configured reception; andthe determining that the performance of the one of the CG-SDT and the semi-statically configured reception will not prevent the RedCap UE from the monitoring of the SI change indication during the current modification period.2.The method of claim 1, further comprising determining that the semi-statically configured reception is for a physical downlink control channel (PDCCH) of one of type-0, type-0A, type-1, and type-2 that is in a common search space (CSS) , wherein the performing the one of the CG-SDT and the semi-statically configured reception is further in response to determining that the semi-statically configured reception is for the PDCCH of the one of type-0, type-0A, type-1, and type-2 in the CSS.3.The method of claim 1, wherein an initial DL bandwidth part (BWP) on which the CG-SDT is to be sent is associated with a cell-defining synchronization signal block (CD-SSB) .4.A method of a reduced capability (RedCap) user equipment (UE) , comprising:identifying that a semi-statically configured reception scheduled in a downlink (DL) that collides with a configured grant small data transmission (CG-SDT) scheduled in an uplink (UL) is not a physical downlink control channel (PDCCH) that is one of type-0, type-0A, type-1, and type-2 that is in a common search space (CSS) ; andperforming the semi-statically configured reception in response to the identifying that the semi-statically configured reception that collides with the CG-SDT is not the PDCCH that is of one of type-0, type-0A, type-1, and type-2 in the CSS.5.A method of a reduced capability (RedCap) user equipment (UE) , comprising:identifying that a semi-statically configured reception scheduled in a downlink (DL) that collides with a configured grant small data transmission (CG-SDT) scheduled in an uplink (UL) is not a physical downlink control channel (PDCCH) that is one of type-0, type-0A, type-1, and type-2 that is in a common search space (CSS) ; andperforming one of the CG-SDT and the semi-statically configured reception based on an indication received from a base station that indicates performance of one of the CG-SDT scheduled in the UL and the semi-statically configured reception when the CG-SDT scheduled in the UL collides with the semi-statically configured reception that is not the PDCCH of one of type-0, type-0A, type-1, and type-2 in the CSS.6.A method of a reduced capability (RedCap) user equipment (UE) , comprising:identifying that a configured grant small data transmission (CG-SDT) scheduled in an uplink (UL) collides with a semi-statically configured reception scheduled in a downlink (DL) ; andperforming one of the CG-SDT and the semi-statically configured reception based on an indication received from a base station that indicates a prioritization of one of the he CG-SDT and the semi-statically configured reception over the other of the CG-SDT and the semi-statically configured reception.7.A method of a reduced capability (RedCap) user equipment (UE) , comprising:identifying that a dynamically scheduled uplink (UL) transmission collides with a reception of a physical downlink shared channel (PDSCH) scheduled by a physical downlink control channel (PDCCH) of one of type-0, type-0A, type-1, and type-2 that is in a common search space (CSS) ;determining that a performance of one of the dynamically scheduled UL transmission and the reception of the PDSCH will not prevent the RedCap UE from monitoring a system information (SI) change indication during a current modification period; andperforming the one of the dynamically scheduled UL transmission and the reception of the PDSCH in response to:the identifying that the dynamically scheduled UL transmission collides with the reception of the PDSCH; andthe determining that the performance of the one of the dynamically scheduled UL transmission and the reception of the PDSCH will not prevent the RedCap UE from performing the monitoring of the SI change indication during the current modification period.8.The method of claim 7, further comprising:identifying that the RedCap UE is configured to monitor the CSS; andidentifying the reception of the PDSCH as the one of the dynamically scheduled UL transmission and the reception of the PDSCH that is performed by the RedCap UE in response to the identifying that the RedCap UE is configured to monitor the CSS.9.A method of a reduced capability (RedCap) user equipment (UE) , comprising:identifying that a dynamically scheduled downlink (DL) reception that collides with a dynamically scheduled uplink (UL) transmission is not a physical downlink shared channel (PDSCH) that is scheduled by a physical downlink control channel (PDCCH) of one of type-0, type-0A, type-1, and type-2 that is in a common search space (CSS) ; andperforming the dynamically scheduled DL reception in response to the identifying that the dynamically scheduled DL reception that collides with a dynamically scheduled UL transmission is not the PDSCH that is scheduled by the PDCCH of one of type-0, type-0A, type-1, and type-2 in the CSS.10.A method of a reduced capability (RedCap) user equipment (UE) , comprising:identifying that a dynamically scheduled downlink (DL) reception that collides with a dynamically scheduled uplink (UL) transmission is not a physical downlink shared channel (PDSCH) that is scheduled by a physical downlink control channel (PDCCH) of one of type-0, type-0A, type-1, and type-2 that is in a common search space (CSS) ; andperforming one of the dynamically scheduled UL transmission and the dynamically scheduled DL reception based on an indication received from a base station that indicates performance of one of the dynamically scheduled UL transmission and the dynamically scheduled DL reception when the dynamically scheduled UL transmission collides with the dynamically scheduled DL reception that is not the PDSCH that is scheduled by the PDCCH of one of type-0, type-0A, type-1, and type-2 in the CSS.11.The method of claim 10, wherein the indication comprises a joint indication that also indicates performance of one of a semi-statically configured UL transmission and a semi-statically configured DL reception when the semi-statically configured UL transmission collides with the semi-statically configured DL reception.12.A method of a reduced capability (RedCap) user equipment (UE) , comprising:identifying that a dynamically scheduled downlink (DL) reception collides with a dynamically scheduled uplink (UL) transmission;identifying a first channel type of the dynamically scheduled DL reception and a second channel type of the dynamically scheduled UL transmission;performing one of the dynamically scheduled DL reception and the dynamically scheduled UL transmission based on a priority rule that indicates a prioritization of one of the first channel type and the second channel type over the other of the first channel type and the second channel type.13.A method of a reduced capability (RedCap) user equipment (UE) , comprising:identifying that a dynamically scheduled downlink (DL) reception collides with a dynamically scheduled uplink (UL) transmission; andperforming one of the dynamically scheduled DL reception and the dynamically scheduled UL transmission based on an indication received from a base station that indicates a prioritization of one of the dynamically scheduled DL reception and the dynamically scheduled UL transmission over the other of the dynamically scheduled DL reception and the dynamically scheduled UL transmission.14.A method of a reduced capability (RedCap) UE, comprising:identifying a first collision between a downlink (DL) reception and a first uplink (UL) transmission and a second collision between the DL reception and a second UL transmission that occurs after the first UL transmission;determining, based on a DL channel type of the DL reception, a first UL channel type of the first UL transmission, and a second UL channel type of the second UL transmission, to resolve the first collision prior to any resolving of the second collision; andresolving the first collision.15.The method of claim 14, wherein resolving the first collision comprises dropping the DL reception.16.The method of claim 14, wherein resolving the first collision comprises dropping the first UL transmission, and further comprising resolving the second collision after resolving the first collision.17.The method of claim 14, wherein:the DL channel type of the DL reception comprises a physical downlink control channel (PDCCH) of one of type-0, type-0A, type-1, and type-2 that is in a common search space (CSS) channel type;the first UL channel type of the first UL transmission comprises a semi-statically configured physical uplink shared channel (PUSCH) channel type; andthe second UL channel type of the second UL transmission comprises a dynamically scheduled PUSCH channel type.18.The method of claim 14, wherein:the DL channel type of the DL reception comprises a semi-statically configured physical downlink shared channel (PDSCH) channel type;the first UL channel type of the first UL transmission comprises a semi-statically configured physical uplink shared channel (PUSCH) channel type; andthe second UL channel type of the second UL transmission comprises a dynamically scheduled PUSCH channel type.19.The method of claim 14, wherein:the DL channel type of the DL reception comprises a physical downlink shared channel (PDSCH) scheduled by a physical downlink control channel (PDCCH) of one of type-0, type-0A, type-1, and type-2 that is in a common search space (CSS) channel type;the first UL channel type of the first UL transmission comprises a dynamically scheduled physical uplink shared channel (PUSCH) channel type; andthe second UL channel type of the second UL transmission comprises a semi-statically configured PUSCH channel type.20.The method of claim 14, wherein:the DL channel type of the DL reception comprises a dynamically scheduled physical downlink shared channel (PDSCH) channel type;the first UL channel type of the first UL transmission comprises a dynamically scheduled physical uplink shared channel (PUSCH) channel type; andthe second UL channel type of the second UL transmission comprises a semi-statically configured PUSCH channel type.21.A method of a reduced capability (RedCap) UE, comprising:identifying a first collision between a downlink (DL) reception and a first uplink (UL) transmission and a second collision between the DL reception and a second UL transmission that occurs after the first UL transmission; andjointly resolving the first collision and the second collision by determining, based on a DL channel type of the DL reception, a first UL channel type of the first UL transmission, and a second UL channel type of the second UL transmission, whether either of the first UL transmission or the second UL transmission takes priority over the DL reception.22.The method of claim 21, wherein:the DL channel type of the DL reception comprises a physical downlink control channel (PDCCH) of one of type-0, type-0A, type-1, and type-2 that is in a common search space (CSS) channel type;the first UL channel type of the first UL transmission comprises a semi-statically configured physical uplink shared channel (PUSCH) channel type; andthe second UL channel type of the second UL transmission comprises a dynamically scheduled PUSCH channel type.23.The method of claim 21, wherein:the DL channel type of the DL reception comprises a semi-statically configured physical downlink shared channel (PDSCH) channel type;the first UL channel type of the first UL transmission comprises a semi-statically configured physical uplink shared channel (PUSCH) channel type; andthe second UL channel type of the second UL transmission comprises a dynamically scheduled PUSCH channel type.24.The method of claim 21, wherein:the DL channel type of the DL reception comprises a physical downlink shared channel (PDSCH) scheduled by a physical downlink control channel (PDCCH) of one of type-0, type-0A, type-1, and type-2 that is in a common search space (CSS) channel type;the first UL channel type of the first UL transmission comprises a dynamically scheduled physical uplink shared channel (PUSCH) channel type; andthe second UL channel type of the second UL transmission comprises a semi-statically configured PUSCH channel type.25.The method of claim 21, wherein:the DL channel type of the DL reception comprises a dynamically scheduled physical downlink shared channel (PDSCH) channel type;the first UL channel type of the first UL transmission comprises a dynamically scheduled physical uplink shared channel (PUSCH) channel type; andthe second UL channel type of the second UL transmission comprises a semi-statically configured PUSCH channel type.26.A method of a reduced capability (RedCap) UE, comprising:identifying a first collision between an uplink (UL) transmission and a first downlink (DL) reception and a second collision between the UL transmission and a second DL reception that occurs after the first DL reception;determining, based on a UL channel type of the UL transmission, a first DL channel type of the first DL reception, and a second DL channel type of the second DL reception, to resolve the first collision prior to any resolving of the second collision; andresolving the first collision.27.The method of claim 26, wherein resolving the first collision comprises dropping the UL transmission.28.The method of claim 26, wherein resolving the first collision comprises dropping the first DL reception, and further comprising resolving the second collision after resolving the first collision.29.The method of claim 26, wherein:the UL channel type of the UL transmission comprises a semi-statically configured physical uplink shared channel (PUSCH) channel type;the first DL channel type of the first DL reception comprises a semi-statically configured physical downlink shared channel (PDSCH) channel type; andthe second DL channel type of the second DL reception comprises a PDSCH scheduled by a physical downlink control channel (PDCCH) in a common search space (CSS) channel type.30.The method of claim 26, wherein:the UL channel type of the UL transmission comprises a semi-statically configured physical uplink shared channel (PUSCH) channel type;the first DL reception type of the first DL reception comprises a physical downlink control channel (PDCCH) in a common search space (CSS) channel type; andthe second DL channel type of the second DL reception comprises a dynamically scheduled physical downlink shared channel (PDSCH) channel type.31.The method of claim 26, wherein:the UL channel type of the UL transmission comprises a semi-statically configured physical uplink shared channel (PUSCH) channel type;the first DL channel type of the first DL reception comprises a semi-statically configured physical downlink control channel (PDCCH) channel type; andthe second DL channel type of the second DL reception comprises a dynamically scheduled physical downlink shared channel (PDSCH) channel type.32.The method of claim 26, wherein:the UL channel type of the UL transmission comprises a dynamically scheduled physical uplink shared channel (PUSCH) channel type;the first DL channel type of the first DL reception comprises a physical downlink control channel (PDCCH) in a common search space (CSS) channel type; andthe second DL channel type of the second DL reception comprises a dynamically scheduled physical downlink shared channel (PDSCH) channel type.33.The method of claim 26, wherein:the UL channel type of the UL transmission comprises a dynamically scheduled physical uplink shared channel (PUSCH) channel type;the first DL channel type of the first DL reception comprises a semi-statically configured physical downlink shared channel (PDSCH) channel type; andthe second DL channel type of the second DL reception comprises a dynamically scheduled PDSCH channel type.34.The method of claim 26, wherein:the UL channel type of the UL transmission comprises a dynamically scheduled physical uplink shared channel (PUSCH) channel type;the first DL channel type of the first DL reception comprises a semi-statically configured physical downlink shared channel (PDSCH) channel type; andthe second DL channel type of the second DL reception comprises a PDSCH scheduled by a physical downlink control channel (PDCCH) that is in a common search space (CSS) channel type.35.A method of a reduced capability (RedCap) UE, comprising:identifying a first collision between an uplink (UL) transmission and a first downlink (DL) reception and a second collision between the UL transmission and a second DL reception that occurs after the first DL reception ; andjointly resolving the first collision and the second collision by determining, based on a UL channel type of the UL transmission, a first DL channel type of the first DL reception, and a second DL channel type of the second DL reception, whether either of the first DL reception or the second DL reception takes priority over the UL transmission.36.The method of claim 35, wherein:the UL channel type of the UL transmission comprises a semi-statically configured physical uplink shared channel (PUSCH) channel type;the first DL channel type of the first DL reception comprises a semi-statically configured physical downlink shared channel (PDSCH) channel type; andthe second DL channel type of the second DL reception comprises a PDSCH scheduled by a physical downlink control channel (PDCCH) in a common search space (CSS) channel type.37.The method of claim 35, wherein:the UL channel type of the UL transmission comprises a semi-statically configured physical uplink shared channel (PUSCH) channel type;the first DL channel type of the first DL reception comprises a physical downlink control channel (PDCCH) in a common search space (CSS) channel type; andthe second DL channel type of the second DL reception comprises a dynamically scheduled physical downlink shared channel (PDSCH) channel type.38.The method of claim 35, wherein:the UL channel type of the UL transmission comprises a semi-statically configured physical uplink shared channel (PUSCH) channel type;the first DL channel type of the first DL reception comprises a semi-statically configured physical downlink control channel (PDCCH) channel type; andthe second DL channel type of the second DL reception comprises a dynamically scheduled physical downlink shared channel (PDSCH) channel type.39.The method of claim 35, wherein:the UL channel type of the UL transmission comprises a dynamically scheduled physical uplink shared channel (PUSCH) channel type;the first DL channel type of the first DL reception comprises a physical downlink control channel (PDCCH) in a common search space (CSS) channel type; andthe second DL channel type of the second DL reception comprises a dynamically scheduled physical downlink shared channel (PDSCH) channel type.40.The method of claim 35, wherein:the UL channel type of the UL transmission comprises a dynamically scheduled physical uplink shared channel (PUSCH) channel type;the first DL channel type of the first DL reception comprises a semi-statically configured physical downlink shared channel (PDSCH) channel type; andthe second DL channel type of the second DL reception comprises a dynamically scheduled PDSCH channel type.41.The method of claim 35, wherein:the UL channel type of the UL transmission comprises a dynamically scheduled physical uplink shared channel (PUSCH) channel type;the first DL channel type of the first DL reception comprises a semi-statically configured physical downlink shared channel (PDSCH) channel type; andthe second DL channel type of the second DL reception comprises a PDSCH scheduled by a physical downlink control channel (PDCCH) that is in a common search space (CSS) channel type.42.An apparatus comprising means to perform the method of any of claim 1 to claim 41.43.A computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform the method of any of claim 1 to claim 41.44.An apparatus comprising logic, modules, or circuitry to perform the method of any of claim 1 to claim 41.45.A baseband processor for a user equipment (UE) that is configured to cause the UE to perform one or more elements of any one of claim 1 to claim 41.

Images