WO2025071640A1

WO2025071640A1 - Controlling bandwidth part (bwp) usage by a user equipment device

Info

Publication number: WO2025071640A1
Application number: PCT/US2023/078671
Authority: WO
Inventors: Peter Pui Lok ANG; Zhong Fan; Ko-Feng Chen
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2023-09-26
Filing date: 2023-11-03
Publication date: 2025-04-03
Anticipated expiration: 2026-03-26
Also published as: WO2025071639A1

Abstract

A user equipment device (UE) detects that a predefined threshold amount of time has passed since the UE last received from its serving access node an air-interface scheduling directive. Responsive to at least the detecting, the UE tests to determine if a scheduling request transmitted from the UE to the access node in an inactive BWP of the UE results in the UE receiving from the access node an associated scheduling directive. Further, responsive to the testing establishing that the scheduling request transmitted from the UE to the access node in the inactive BWP of the UE results in the UE receiving from the access node the associated scheduling directive, the UE reconfigures itself to have the inactive BWP be an active BWP of the UE.

Description

Controlling Bandwidth Part (BWP) Usage by a User Equipment Device

REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. Provisional Patent Application No. 63/585,470, filed September 26, 2023, the entirety of which is hereby incorporated by reference.

BACKGROUND

[0002] A typical wireless communication network includes multiple access nodes configured to serve user equipment devices (UEs) such as cell phones, tracking devices, wirelessly equipped personal computers, gaming devices, Internet of Things (loT) devices, and other wirelessly-equipped devices.

[0003] Each such access node may include an antenna structure and associated equipment that enables the access node to provide one or more cells each defining wireless coverage in which to serve UEs over a respective air-interface. Further, each access node may be coupled with a core network that includes infrastructure configured to support the access node’s service of UEs and that provides connectivity with a transport network such as the Internet. With this arrangement, when a UE is positioned within coverage of an access node, the UE may be able to engage in air-interface communication with the access node and may thereby be able to communicate through the access node, the core network, and the transport network with various remote servers and/or other entities.

[0004] A representative wireless communication network could operate in accordance with one or more radio access technologies (RATs), which may define the physical structure of the air interface between access nodes and UEs and may also define associated procedures for handling service of UEs.

[0005] The wireless industry has evolved over the years to define various generations of RATs and continues to evolve to define new generations of RATs. Recent examples of these RATs include, without limitation, (i) “4G” Long Term Evolution (LTE), which facilitates mobile broadband service using technologies such as orthogonal frequency division multiplexing (OFDM) and multiple input multiple output (MIMO), (ii) “5G NR” (5G New Radio), which may use a more scalable OFDM air interface and other advanced features to support higher data rates and advanced applications, and (iii) “6G”, which might support even higher data rates, possibly by making use of millimeter wave and Terahertz spectrum. [0006] Under such a RAT, the access node may be configured to provide each of its one or more cells on a respective radio frequency (RF) carrier that defines a downlink channel for carrying communications from the access node to UEs and an uplink channel for carrying communications from UEs to the access node. Each such carrier, and thus each such cell, may be either frequency division duplex (FDD), with separate frequency channels defined respectively for downlink and uplink use, or time division duplex (TDD), with a single frequency channel multiplexed over time between downlink and uplink use. Further, each such frequency channel could be defined as a specific range of frequency having a bandwidth that defines how wide the carrier is in RF spectrum, extending from a low-end frequency to a high- end frequency.

[0007] Further, the downlink and uplink channels of each cell on which an access node provides service may be structured in a manner that defines physical air-interface resources for carrying both control signaling and user-plane communications between the access node and UEs. For instance, the air interface may be divided over time into frames, subframes, timeslots (slots), and symbol time segments (symbols), and over frequency into subcarriers, so as to define an array of resource elements each occupying a respective subcarrier and spanning a respective symbol time segment. Each resource element may then serve to carry data (user-plane or control -plane) through modulation of the resource element’ s subcarrier with an applicable modulation-and-coding scheme. Further, the air interface may be divided over time and channel bandwidth into physical resource blocks (PRBs), each of which may span a certain number of subcarriers (e.g., 12) in frequency and a certain duration (e.g., half of a timeslot) in time. In addition, certain resource elements in these PRBs may be reserved for particular use, such as to carry control signaling or to carry user-plane data communications.

[0008] On the downlink, for instance, certain resource elements may cooperatively carry signaling from the access node that UEs could measure as a basis to gauge cell coverage strength. Further, other resource elements may cooperatively define a physical downlink control channel (PDCCH) for carrying downlink control signaling such as scheduling directives from the access node to UEs. Still further, other resource elements may cooperatively define a physical downlink shared channel (PDSCH), and the access node could schedule use of the PDSCH on a PRB basis for use to carry user-plane data from the access node to served UEs.

[0009] On the uplink, on the other hand, certain resource elements may cooperatively define an access channel for carrying access requests from UEs to the access node. Further, other resource elements may cooperatively define a physical uplink control channel (PUCCH) for carrying various uplink signaling such as measurement reports and scheduling requests from UEs to the access node. Still further, other resource elements may cooperatively define a physical uplink shared channel (PUSCH), and the access node could schedule use of the PUSCH on a per PRB basis to carry user-plane data from served UEs to the access node.

SUMMARY

[0010] Disclosed are methods and systems for controlling bandwidth part (BWP) usage by a UE served by an access node.

[0011] In one respect, disclosed is an example method that could be implemented by the UE. The example method includes the UE detecting that a predefined threshold amount of time has passed since the UE last received from the access node an air-interface scheduling directive. Further, the example method includes, responsive to at least the detecting, the UE testing to determine if a scheduling request transmitted from the UE to the access node in an inactive BWP of the UE results in the UE receiving from the access node an associated scheduling directive. Still further, the method includes, responsive to the testing establishing that the scheduling request transmitted from the UE to the access node in the inactive BWP of the UE results in the UE receiving from the access node the associated scheduling directive, reconfiguring the UE to transition the inactive BWP to be an active BWP of the UE.

[0012] In another respect, disclosed is an example UE configured to carry out such a method. The example UE includes a processor, non-transitory data storage, and program instructions stored in the non-transitory data storage and executable by the processor to cause the UE to carry out operations for controlling BWP usage by the UE when the UE is served by an access node. The operations include detecting that a predefined threshold amount of time has passed since the UE last received from the access node an air-interface scheduling directive. Further, the operations include, responsive to at least the detecting, testing to determine if a scheduling request transmitted from the UE to the access node in an inactive BWP of the UE results in the UE receiving from the access node an associated scheduling directive. Yet further, the operations include, responsive to the testing establishing that the scheduling request transmitted from the UE to the access node in the inactive BWP of the UE results in the UE receiving from the access node the associated scheduling directive, reconfiguring the UE to transition the inactive BWP to be an active BWP of the UE. [0013] In yet another respect, disclosed is at least one non-transitory computer- readable medium having stored thereon program instructions executable by at least one processor of a device to cause the device to carry out operations such as those described above.

[0014] These, as well as other aspects, advantages, and alternatives will become apparent to those of ordinary skill in the art by reading the following detailed description, with reference where appropriate to the accompanying drawings. Further, it should be understood that the descriptions provided in this summary and below are intended to illustrate the invention by way of example only and not by way of limitation.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 is a simplified block diagram of an example wireless communication system in which various disclosed features could be implemented.

[0016] Figure 2 is a simplified illustration of an air-interface configuration.

[0017] Figure 3 is a simplified illustration of example BWP configurations.

[0018] Figure 4 is an illustration of an example BWP-out-of-sync problem with compatible CORESETs.

[0019] Figure 5 is an illustration of an example BWP-out-of-sync problem with incompatible CORESETs.

[0020] Figure 6 is a flow chart illustrating an example method.

[0021] Figure 7 is a flow chart illustrating another example method.

[0022] Figure 8 is a simplified block diagram of an example UE.

DETAILED DESCRIPTION

[0023] For sake of illustration, this description will discuss example implementation in the context of 5G NR. However, it will be understood that the disclosed features could apply in the context of other RATs. Further, it will be understood that various disclosed embodiments are not necessarily to be construed as preferred or advantageous over other embodiments unless stated as such. Further, variations from the specific arrangements and processes disclosed are possible. For instance, various disclosed entities, components, connections, operations, and other elements could be added, omitted, distributed, replicated, re-located, re-ordered, combined, or changed in other ways. In addition, it will be understood that various disclosed technical operations could be implemented at least in part by one or more processing units programmed to carry out the operations or to cause one or more other entities to carry out the operations.

1. Cellular Wireless Communications

[0024] Referring to the drawings, as noted above, Figure 1 is a simplified block diagram of an example wireless communication system in which various disclosed features could be implemented. As shown in Figure 1, the example wireless communication system a radio access network (RAN) 100 and a core network 102, each of which may be operated by and/or for a mobile network operator (MNO), also known as a cellular wireless service provider.

[0025] The RAN 100 is shown including at least one access node 104, which could include an antenna and a cell site modem (neither shown) enabling the access node 104 to serve UEs such as a representative UE 106 over an air interface 108 in accordance with an agreed RAT. For instance, the access node 104 could be a 5G NR next generation Node-B (gNB) configured to serve UEs over a 5G NR air interface defining a cell as discussed above, among other possibilities. The access node 104 could take various forms, such as a macro access node, a small-cell access node, or a relay access node, for instance.

[0026] The core network 102 may be a 5G Core (5GC) network having a servicebased architecture including a user-plane subsystem 110 and a control-plane subsystem 112, the details of which are not shown. In a representative 5GC for instance, the user-plane subsystem may include a user-plane function (UPF) configured to provide user-plane connectivity with a packet data transport network 114, to facilitate UE communication with application servers and/or other remote endpoints 118. The control-plane subsystem 112 may then include various more control-plane functions, such as an access and mobility function (AMF) and a session management function (SMF) for instance, configured to support UE authentication, mobility management, and service-flow management, for instance.

[0027] The example UE 106 could take any of the forms noted above, among other possibilities. The UE 106 could be equipped with various components (not shown) such as a 5G NR radio, an antenna structure, and associated circuitry and logic to support being served by the access node 104 over the air interface 108.

[0028] When such a UE enters into coverage of this example network, the UE may detect coverage of the access node’s cell. If the coverage is strong enough, the UE may then engage in signaling with the access node in order to establish an air-interface connection through which the access node could then serve the UE in that cell. For instance, the UE may engage in random-access signaling and connection signaling, such as Radio Resource Control (RRC) signaling, with the access node to establish an air-interface connection (e.g., an RRC connection) between the access node and the UE in the cell, transitioning the UE from an idle mode to a connected mode.

[0029] If the UE is not already registered for service with the core network, the UE may further engage in registration signaling to register for service. For instance, the UE may send a registration request to the access node, which the access node may forward into the control-plane subsystem for processing. After authenticating the UE, the control-plane subsystem may then engage in a process to set up for the UE one or more quality of service (QoS) flows for carrying user-plane traffic to and from the UE.

[0030] Once the UE has an established air-interface connection with the access node and has one or more assigned service flows, the access node may then serve the UE with packetdata communications on the downlink and on the uplink of the access node’s cell.

[0031] As to the downlink, for instance, when packet data on the transport network arrives at the core network for transmission to the UE, the data may flow to the access node, which may buffer the data pending transmission of the data over the air of the UE. The access node may then assign one or more downlink PRBs of the UE’s serving cell to carry the data to the UE, and the access node may transmit to the UE a downlink control information (DCI) message defining a scheduling directive that specifies the assigned downlink PRB(s) and may transmit the data to the UE by modulating the data onto subcarriers of resource elements within the assigned downlink PRBs.

[0032] As to the uplink, on the other hand, when the UE has packet data to transmit on the transport network, the UE may buffer the data in a queue pending transmission of the data over the air to the access node, and the UE may transmit to the access node a scheduling request that includes a buffer status report (BSR) indicating how much data the UE has buffered for uplink transmission. The access may then assign one or more uplink PRBs of the UE’s serving cell to carry the data from the UE, and the access node may transmit to the UE a DCI message specifying the assigned uplink PRBs. The UE may then transmit the data to the access node by modulating the data onto subcarriers of the resource elements within the assigned uplink PRBs, and the access node may forward the data through the core network for ultimate output onto the transport network.

[0033] As noted above, the air interface of the access node’s cell may define downlink and uplink channels, which may span separate frequency ranges on an FDD carrier or be multiplexed over time on a common frequency range on a TDD carrier. Further, the air interface may be divided over time into timeslots, and over both frequency and time into an array of resource elements. As further noted above, certain resource elements on the downlink may define a PDCCH for carrying downlink control signaling, other resource elements on the downlink may define a PDSCH for carrying scheduled downlink communications, certain resource elements on the uplink may define a PUCCH for carrying uplink control signaling, and other resource elements on the uplink may define a PUSCH for carrying scheduled uplink communications.

[0034] 5G NR supports a flexible air-interface configuration, with the placement, size, and periodicity of some of these channels being dynamically configurable. Therefore, numerous air-interface configurations are possible.

[0035] Without limitation, Figure 2 is a simplified illustration of an example airinterface configuration, depicting an FDD arrangement with separate downlink and uplink frequency ranges to help illustrate respective downlink and uplink operation. In particular, Figure 2 depicts the example downlink and uplink channels each over frequency and time, with frequency on the vertical axis and time on the horizontal axis. The range of frequency shown for each of these channels may represent the full carrier bandwidth on the respective channel or may represent just a portion of that carrier bandwidth. Further, in line with the discussion above, each channel is shown divided overtime into timeslots, each downlink timeslot is shown divided into example PDCCH and PDSCH, and each uplink timeslot is shown divided into example PUCCH and PUSCH. In example variations, the placement, size, and periodicity of the PDCCH and of the PUCCH may be different from that shown and may vary over time, among other possibilities.

[0036] With this or another air-interface configuration, each DCI that the access node sends to the UE may span a particular set of resource elements on the PDCCH in a given timeslot and may include a cyclic redundancy check (CRC) that is masked (scrambled) with an identifier (e.g., cell radio network temporary identifier (C-RNTI)) assigned to the UE, so that the UE can identify and read the DCI message. Further, the DCI message may be modulated using quadrature phase shift keying (QPSK) modulation.

[0037] In practice, the UE may monitor the PDCCH in search of a DCI message destined to the UE. In particular, the UE may engage in a “blind decoding” process in which the UE reads various candidate groups of resource elements on the PDCCH in search of a DCI message masked with the UE’s identifier. If the UE finds such a DCI message, the UE may then read that DCI message and proceed as indicated. For instance, if the DCI message schedules downlink communication of user-plane data to the UE in particular downlink PRBs, the UE may then read the data carried by the PDSCH resource elements of the indicated PRB(s), to receive that data. Likewise, if the DCI message schedules uplink communication of user-plane data from the UE in particular uplink PRBs, the UE may transmit the data in the indicated uplink PRBs of the PUSCH.

[0038] Further, a DCI message that the access node sends to the UE may also include a timeslot-offset value that indicates the timeslot (or transmission time interval (TTI)) in which the data communication is scheduled to occur. Namely, starting with the timeslot in which the DCI message is transmitted to the UE (a “scheduling timeslot”), this timeslot-offset value may be a count of the quantity of timeslots ahead where the data communication is scheduled to occur (as a “designated timeslot”). For downlink scheduling, this offset value may be referred to as “kO”, and for uplink communication, this offset value may be referred to as “k2”.

[0039] This timeslot-offset value can be an integer that is at least zero. For instance, to schedule communication to occur in the same timeslot where the DCI message is sent, the access node may specify in the DCI message a timeslot-offset value of zero. Whereas, to schedule communication to occur in a timeslot that is four timeslots after the scheduling timeslot, the access node may specify in the DCI message a timeslot-offset value of four.

[0040] In accordance with this specified timeslot-offset value on the downlink, the access node would then communicate the data to the UE in the indicated timeslot, and the UE would receive the data in that timeslot. Likewise, in accordance with the specified timeslotoffset value on the uplink, the UE would then communicate the data to the access node in the indicated timeslot, and the access node would receive the data in that timeslot.

[0041] The access node and UE may also engage in an acknowledgement and retransmission process to help ensure successful receipt of scheduled data communications. This is typically a hybrid automatic repeat request (HARQ) process, with specifics for both uplink and downlink transmissions.

[0042] With uplink HARQ, when the access node schedules uplink transmission from the UE, (i) the access node may include in its DCI message to the UE a HARQ process number, (ii) the access node may then determine whether the access node successfully receives the scheduled uplink transmission from the UE, and (iii) if the access node does not successfully receive the scheduled uplink transmission, the access node may direct the UE to retransmit the data, by sending to the UE a new DCI message that designates the same HARQ process number.

[0043] With downlink HARQ, similarly, when the access node schedules downlink transmission to the UE, (i) the access node may likewise include in its DCI message to the UE a HARQ process number, (ii) the UE may then determine whether the UE successfully receives the scheduled downlink transmission from the access node, and (iii) the UE may then transmit a HARQ positive or negative acknowledgement accordingly to the access node. If the UE successfully receives the data transmission, then the UE may send a positive acknowledgement (ACK). Whereas, if the UE does not successfully receive the data transmission, then the UE may send a negative acknowledgement (NACK), in response to which the access node may then engage in re-transmission, likewise sending to the UE a new DCI message that designates the same HARQ process number.

[0044] In addition, when the access node serves the UE, the access node and UE may engage in an uplink power-control process to help control the transmission power that the UE uses for the UE’s uplink transmissions to the access node. In an example power-control process, the UE may engage in transmission to the access node, and the access node may compare received strength of that transmission with a defined set point. If the received strength is greater than the set point, then the access node may direct the UE to decrease the UE’s transmission power level. Whereas, if the received strength is less than the set point, then the access node may direct the UE to increase the UE’s transmission power level.

[0045] The UE may also have a maximum allowed transmission power level, possibly defined by a power class of the UE. As the UE and access node engage in the powercontrol process, the UE may also keep track of a “power headroom” value that represents the difference between the UE’s currently set transmission power and the UE’s maximum allowed transmission power. In poor RF conditions, the power-control process may cause the UE to operate at its maximum transmission power level, at which point the UE would have zero power headroom (or possibly negative power headroom in a situation where the UE has received power-up commands when the UE is already at its maximum power level).

2. Bandwidth Part (BWP) and associated Control Resource Set (CORESET)

[0046] A representative RAT, such as but not limited to 5G NR, may further make use of a “bandwidth part” (BWP) construct, along with an associated “control resource set” (CORESET) construct, to cooperatively help limit the extent to which the UE would operate on the UE’s serving carrier, which may thereby help conserve the UE’s power (e.g., battery power, if applicable).

[0047] As its name suggests, a BWP defines a part of the carrier’s full bandwidth, which may be smaller than or equal to the full carrier bandwidth. On a given carrier, separate BWPs could be defined on the downlink channel and the uplink channel. Further, a given BWP can be defined as a contiguous set of PRBs starting with a particular PRB in the channel bandwidth and having a BWP bandwidth that spans a particular quantity of the carrier’s PRBs.

[0048] A downlink BWP then includes at least one CORESET, which defines physical resources that make up the PDCCH for carrying downlink control information such as scheduling directives. A CORESET in a given BWP may be localized to a specific frequency range within the BWP, such as a certain contiguous set of PRBs (e.g., a multiple of six contiguous PRBs) and to a certain number of symbol time segments (e.g., one, two, or three). Further, a search space can be associated with a CORESET, and the search space can have a particular periodicity that defines how often the CORESET is repeated (e.g., every slot, every other slot, every five slots, etc.)

[0049] In an earlier-generation RAT such as LTE, the PDCCH would span largely the full downlink carrier bandwidth at the start of each subframe, so a UE would need to engage in blind decoding through that full carrier bandwidth in each subframe, in search of any DCI message directed to the UE. The BWP/CORESET construct provides much more flexibility for defining the PDCCH, including not requiring the PDCCH to span the carrier bandwidth. As newer RAT s also have much wider carrier bandwidth, this flexibility can make UE decoding of the PDCCH far more efficient.

[0050] Figure 3 is a simplified illustration of some possible BWP configurations. In part A, the figure illustrates examples of BWPs having different bandwidth than each other. Namely, the figure illustrates one BWP spanning relatively narrow bandwidth, which may be appropriate when there is very little data to communicate, and the figure illustrates another BWP spanning a relatively wide bandwidth, which may be appropriate when there is a lot of data to communicate. Further, the figure shows each of these BWPs as having PDCCH defined in every slot. Whereas, in part B, Figure 3 illustrates examples of BWPs with the same bandwidth as each other but with CORESETs defining different PDCCH-monitoring periodicity. Namely, the figure illustrates one BWP with PDCCH monitoring in every slot, which may be appropriate when there is a lot of data to communicate, and the figure illustrates another BWP with PDCCH monitoring in every other slot, which might be appropriate when there is very little data to communicate. Numerous other arrangements could be possible as well.

[0051] When the UE is served by the access node on a given carrier, the UE may be configured to operate with multiple different BWPs, which may have different bandwidth and possibly different frequency positions than each other within the carrier bandwidth and may have different CORESETs than each other. In particular, the UE may be configured to operate with multiple different downlink BWPs and multiple different uplink BWPs.

[0052] For instance, the UE may be provisioned with data defining each downlink BWP and associated CORESET and each uplink BWP where applicable, and the UE may be configured to operate selectively on each of these BWPs by being able to refer to the provisioned data and operating accordingly within a given BWP with a given CORESET. Further, each of the UE’ s BWPs respectively on the carrier’ s downlink channel and the carrier’ s uplink channel may have a respective BWP index that distinguishes the BWP from the UE’s other BWPs on that channel.

[0053] On an FDD carrier, the UE’s downlink BWPs and uplink BWPs may be configured separately. Whereas, on a TDD carrier, the UE may have downlink-uplink BWP pairs, with the downlink and uplink BWPs in each pair having the same BWP index as each other and the same center frequency as each other, but possibly different bandwidths than each other.

[0054] In a representative system, respectively on the downlink and the uplink, the UE would have just one of the UE’s multiple BWPs set as “active” at any given time, and the UE would have each other of the UE’s multiple BWPs set as inactive. For instance, if the UE is configured to operate with four downlink BWPs, then at any given time the UE would have just one of those downlink BWPs set as active and would have the other three downlink BWPs set as inactive. Likewise, if the UE is configured to operate with four uplink BWPs, then at any given time the UE would have just one of those uplink BWPs set as active and would have the other three uplink BWPs set as inactive.

[0055] On a TDD carrier, the UE’s active downlink and uplink BWPs may be tied together by BWP index, such that when the UE has a downlink BWP of a given BWP index set as the UE’s active downlink BWP, the UE would have an uplink BWP of the same BWP index set as the UE’s active uplink BWP.

[0056] The UE could store data that designates which of the UE’ s configured BWPs is active and which of the UE’s configured BWPs is inactive. For instance, as to the downlink, the UE may store an index of the UE’s currently active downlink BWP, which may establish that each other of the UE’s multiple downlink BWPs is inactive. Likewise, as to the uplink, the UE may store an index of the UE’s currently active uplink BWP, which may establish that each other of the UE’s multiple uplink BWPs is inactive. Alternatively, the UE may be otherwise configured to treat a given BWP as either inactive or active. The UE may then operate according to this configuration.

[0057] When the UE first engages in signaling to connect with the access node, the UE may make use of an initial uplink BWP and initial downlink BWP defined for at least this purpose. Once the UE connects with the access node, the access node may then configure the UE with multiple BWPs that could be subject to activation and use. For instance, the access node may transmit to the UE one or more RRC connection reconfiguration messages that carry data defining each of the various BWPs, including the respective BWP indexes, and the UE may read those messages and store the indicated BWP definitions. This data may also designate one of the UE’s downlink BWPs as a default BWP, which may apply after a period of inactivity.

[0058] Further, the access node may also store the list of these BWPs that the UE is thus configured to use, and the UE and access node will each store an indication of which of the UE’ s BWPs is active versus inactive, so that the UE and access node can communicate with each other on a common BWP (respectively on the downlink and the uplink).

[0059] With this arrangement, when the access node sends a DCI message to the UE to schedule data communication on the downlink or uplink, the access node would specify in the DCI message which BWP will be used to carry the scheduled data communication. To do so, the access node may include in the DCI message a BWP indicator that specifies the BWP index of the BWP that will carry the communication.

[0060] Absent any change in which of the UE’s BWPs is active, the UE’s initial uplink BWP and initial downlink BWP may be the UE’s active BWPs. However, from time to time, there may be a change in which of the UE’s BWPs (on the downlink and/or uplink) is active. The act of changing which of the UE’s BWPs is active is known as a BWP switch.

[0061 ] Three example mechanisms for BWP switching are (i) BWP inactivity timer, (ii) RRC messaging, and (iii) DCI messaging.

[0062] The BWP inactivity timer may trigger switching to the UE’s default downlink BWP in response to absence of any communication from the access node to the UE on the UE’s currently active BWP for a monitored inactivity period; in normal operation, when this inactivity timer expires, the UE and access node may each update their records to indicate that the UE’s default downlink BWP is now active, so that subsequent DCI messaging from the access node to the UE would occur on that default downlink BWP. RRC messaging from the access node to the UE may also direct the UE to switch from having one of the UE’s configured BWPs being active to instead having another of the UE’s BWPs be active, and the UE and access node may update their records accordingly as well, so that the UE and access node can then communicate with each other on the newly active BWP.

[0063] DCI-based BWP switching involves the access node specifying, as the BWP- indicator value in a DCI message to the UE, the BWP index of one of the UE’s configured BWPs that the UE does not currently have set as the UE’s active BWP. In particular, this designation in the DCI message of a BWP that is not the UE’s currently active BWP would serve to inform the UE of a BWP switch to the designated BWP. When the access node thereby directs the UE to engage in this BWP switch, the UE and access node may each also likewise update their records to indicate that the designated BWP is now the UE’s active BWP, so that the UE and access node can then communicate with each other on the newly active BWP.

[0064] Accordingly, if the UE is configured with a set of downlink BWPs as {BWP- 1, BWP-2, BWP-3, and BWP-4}, and if the UE has downlink BWP-1 set as the UE’s active downlink BWP, the access node could transmit to the UE in the defined CORESET of BWP-1 a DCI message that schedules downlink communication to the UE in a different one of the UE’s downlink BWPs, BWP-2. That DCI message would have the effect of not only scheduling the downlink communication to occur in BWP-2 but also triggering a downlink BWP switch for the UE to BWP-2 (and possibly a corresponding uplink BWP switch, if TDD). Thus, the UE and access node could update their records to indicate that the UE’s newly active downlink BWP is BWP-2, so that, until a further BWP switch, DCI messages to the UE would then be sent on BWP-2.

[0065] When a UE engages in a BWP switch, the UE may need to retune its RF circuitry and/or engage in other processing to switch to the newly active BWP. To help accommodate this or for other reasons, the UE and access node may be configured to require a minimum “blanking period” as a timeslot-offset after a DCI message directs a BWP switch. Without limitation, this minimum blanking period may be a quantity of timeslots in the range of three to five timeslots.

[0066] For example, the minimum blanking period may be five timeslots. With this example, if the UE has downlink BWP-1 as the UE’s active downlink BWP and the access node transmits to the UE in a scheduling timeslot on BWP-1 a DCI message that schedules downlink data communication to or from the UE on BWP-2, thus directing a downlink BWP switch from BWP-1 to BWP-2, the access would need to specify a timeslot-offset value (e.g., kO) of at least five to designate when the downlink communication will occur. If the access node specifies a timeslot-offset value of five, that would mean that the scheduled downlink data transmission to the UE on the newly active BWP-2 will occur five timeslots after the scheduling timeslot. In that designated timeslot, the access node would thus transmit the data to the UE on BWP-2, and the UE would receive that transmission.

[0067] With this policy to require the minimum blanking interval, if the access node transmits to the UE a DCI message that directs a BWP switch and the access node specifies in that DCI message a timeslot-offset value that is too low (i.e., designating a communication timeslot that is not at least the required minimum quantity of timeslots after the scheduling timeslot), the UE may detect that as a policy violation and may disregard the DCI message altogether. In that situation, the UE may thus not engage in the directed BWP switch and may therefore keep its currently active BWP, i.e., the old BWP, rather than switching to the new BWP. Further, the UE may accordingly not engage in the scheduled data communication.

3. Technical Problem: BWP Out-of-Sync

[0068] Unfortunately, a problem that can occur in practice with BWP switching is that, for one reason or another, a UE may not detect an access-node transmitted DCI message that directs the UE to engage in a BWP switch. For instance, due to noise and/or other issues on the air interface or perhaps issues with the access node or UE, when the access node transmits to the UE a DCI message that directs a BWP switch, the UE may not receive that DCI message. (Failure to receive a DCI message may occur where the DCI message does not arrive at the UE or where the DCI message arrives at the UE but the UE is unable to properly or successfully decode and understand the DCI message.)

[0069] When this happens, the access node may assume that the BWP switch will occur as directed from an old BWP (e.g., BWP-1) to a new BWP (e.g., BWP-2), but the UE would not implement that BWP switch per the DCI message since the UE would not have received the DCI message directing the UE to engage in the BWP switch. As a result, the UE and access node would be in a BWP out-of-sync state.

[0070] This BWP-out-of-sync state may cause various problems.

[0071] One BWP-out-of-sync problem may arise in a situation where the CORESET defined for the new BWP is compatible with the CORESET defined for the old BWP. Since CORESETs can be defined at various frequency positions and with various bandwidth and search spaces of various periodicity, and since BWPs can be defined with various bandwidths within the carrier bandwidth, there is a chance that the CORESET defined for one BWP may overlap in time and frequency with, and thus be compatible with, the CORESET defined for another BWP. If the CORESET defined for the new BWP is compatible with the CORESET defined for the old BWP, then, even though the UE misses the DCI that directed that BWP switch from the old BWP to the new BWP, the UE may still be able to receive a DCI that the access node sends to the UE in the CORESET of the new BWP, since the UE may receive that DCI in the overlapping CORESET of the old BWP.

[0072] A problem that may occur in this compatible-CORESET scenario, is that, after the UE has failed to receive a DCI that directed the UE to switch from the old BWP to the new BWP, the UE may deem a later-received DCI message to violate the timeslot-offset policy for a BWP switch, and the UE may therefore ignore that later-received DCI message.

[0073] In particular, the DCI message that directed the BWP switch from the old BWP to the new BWP may specify a proper timeslot-offset value that provides an expected or required blanking interval to accommodate the BWP switch, but in this example, the UE would not receive that DCI message. After that blanking interval, the access node would assume that the BWP switch occurred and may then transmit to the UE on the new BWP a DCI message that schedules data communication but that does not include the minimum blanking-interval timeslot-offset value, since the DCI message is not intended to direct a BWP switch. The UE, on the other hand, would be operating with the old BWP set as the UE’s active BWP, since the UE did not receive the directive to switch to the new BWP.

[0074] Given the CORESET compatibility between the new BWP and old BWP in this example, as the UE monitors the CORESET of the old BWP, the UE may detect the DCI message that the access node transmitted on the CORESET of the new BWP. However, the UE may see (i) that that DCI message designates the new BWP, which the UE may therefore understand to constitute a BWP switch directive since the UE currently has the old BWP as the UE’s active BWP, and (ii) that the timeslot-offset value in that DCI message is too low for that BWP switch, since the timeslot-offset value does not allow for the minimum required blanking interval. Given this, the UE may therefore disregard the DCI. Because this would mean that the scheduled data communication would not occur, HARQ retransmission may occur, with the access node sending a new DCI seeking to schedule the communication again. Further, this HARQ retransmission may recur multiple times, which may inefficiently burden air-interface resources and result in a poor user experience if applicable.

[0075] Figure 4 illustrates an example of this problem, over the course of an example series of timeslots 1-10 on the downlink. This example illustrates a scenario where the UE currently has BWP-0 active, where the access node directs a BWP switch to BWP-1, where the minimum blanking period is k0=5, and where the CORESETs of BWP-0 and BWP-1 are compatible with each other.

[0076] In the example of Figure 4, in slot 1, the access node transmits to the UE a DCI on the UE’s active BWP-0, scheduling downlink communication on BWP-0 with k0=0 and thus in slot 1, and the UE successfully receives that DCI and accordingly receives the scheduled downlink communication on BWP-0 in slot 1.

[0077] In slot 3, the access node then transmits to the UE a BWP-switch-triggering DCI on the UEs active BWP-0. In particular, this DCI on BWP-0 schedules downlink communication on BWP-1 with k0=5 and thus in slot 8. The designation of BWP-1 in this DCI constitutes a BWP-switch instruction, since the UE’s active BWP is not currently BWP-1, and the designation in this DCI of k0=5 satisfies the minimum blanking-interval requirement for a BWP-switch. As shown in Figure 4, however, the UE misses this DCI. Namely, the UE does not successfully receive this DCI sent in slot 3. Therefore, from the UE’s perspective, the UE’s active BWP as of slot 8 is still BWP-0, but from the access node’s perspective, the UE’s active BWP as of slot 8 is BWP-1.

[0078] In slot 9, the access node then transmits to the UE a DCI on BWP-1, which the access node believes to be the UE’s active BWP. This DCI schedules downlink communication on BWP-1 with k0=0 and thus in slot 9. Due to the CORESET compatibility, even though the access node sent this DCI on a BWP that the UE does not have set as active, the UE receives this DCI on the UE’s active BWP, BWP-0. Upon receipt of this DCI, however, the UE deems the DCI to be invalid, because, from the UE’s perspective, the DCI directs a BWP-switch from BWP-0 to BWP-1 but specifies a scheduling offset that is less than the minimum blanking interval of k0=5. Therefore, the UE may disregard this DCI and will thus not receive the scheduled downlink communication in slot 9, which may lead to HARQ retransmission an associated inefficiency.

[0079] Further, this problem may repeat in slot 10 as shown. Namely, in slot 10, the access node may transmit to the UE a DCI on BWP-1, scheduling downlink communication on BWP-1 with k0=0 and thus in slot 10. Due to the CORESET compatibility, the UE may then receive this DCI on the UE’s active BWP, BWP-0. However, the UE may disregard this DCI as well on grounds that it directs a BWP switch but specifies an insufficient scheduling offset, thus also leading to HARQ retransmission.

[0080] Another BWP-out-of-sync problem may arise in a situation where the CORESET defined for the new BWP is not compatible with the CORESET defined for the old BWP. Namely, the CORESET defined for the new BWP may not overlap in time and frequency, and may thus be incompatible with, the CORESET defined for the old BWP. In this case, the UE would not be able to receive a DCI that the access node sends to the UE in the CORESET of the new BWP, since the UE would be monitoring the incompatible CORESET of the old BWP.

[0081] A problem that may occur in this incompatible-CORESET scenario is that, after the UE has failed to receive a DCI that directed the UE to switch from the old BWP to the new BWP, the UE may not receive one or more later-transmitted DCI messages from the access node. Namely, after directing the BWP switch and after the blanking interval, the access node may transmit to the UE on the new BWP a new DCI message that schedules data communication. However, because the UE would be operating on the old BWP with an incompatible CORESET, the UE would not receive that new DCI message. Consequently, the newly scheduled data communication between the access node and the UE would fail, which may likewise result in HARQ retransmission with associated inefficiency and poor user experience if applicable.

[0082] Figure 5 illustrates an example of this problem, likewise over the course of an example series of timeslots 1-10 on the downlink. This example illustrates a scenario where the UE currently has BWP-0 active, where the access node directs a BWP switch to BWP-1, where the minimum blanking period is k0=5, but where the CORESETs of BWP-0 and BWP- 1 are not compatible with each other.

[0083] In the example of Figure 5, in slot 1, the access node transmits to the UE a DCI on the UE’s active BWP-0, scheduling downlink communication on BWP-0 with k0=0 and thus in slot 1, and the UE successfully receives that DCI and accordingly receives the scheduled downlink communication on BWP-0 in slot 1. Further, in slot 2, the access node transmits to the UE a DCI on the UE’s active BWP-0, scheduling downlink communication on BWP-0 with k0=0 and thus in slot 2, and the UE successfully receives that DCI and accordingly receives the scheduled downlink communication on BWP-0 in slot 2. [0084] In slot 3, the access node then transmits to the UE a BWP-switch-triggering DCI on the UEs active BWP-0. In particular, this DCI on BWP-0 schedules downlink communication on BWP-1 with k0=5 and thus in slot 8. As with the example above, the designation of BWP-1 in this DCI constitutes a BWP-switch instruction, since the UE’s active BWP is not currently BWP-1, and the designation in this DCI of k0=5 satisfies the minimum blanking-interval requirement for a BWP-switch. As shown in Figure 4, however, here too, the UE misses this DCI. Namely, the UE does not successfully receive this DCI sent in slot 3. Therefore, from the UE’s perspective, the UE’s active BWP as of slot 8 is still BWP-0, but from the access node’s perspective, the UE’s active BWP as of slot 8 is BWP-1.

[0085] In slot 9 in this example, the access node then transmits to the UE a DCI on BWP-1, which the access node believes to be the UE’s active BWP. This DCI schedules downlink communication on BWP-1 with k0=0 and thus in slot 9. Due to the CORESET incompatibility here, though, as shown, the UE will not receive this DCI. Therefore, the UE will not receive the scheduled downlink communication in slot 9, which may lead to HARQ retransmission and associated inefficiency.

[0086] Further, this problem may repeat in slot 10 as shown. Namely, in slot 10, the access node may transmit to the UE a DCI on BWP-1, scheduling downlink communication on BWP-1 with k0=0 and thus in slot 10. Due to the CORESET incompatibility here too, as shown, the UE would not receive this DCI and therefore would not receive the scheduled downlink communication in slot 10, also leading to HARQ retransmission.

4. Technical Solution for BWP Out-of-Sync with Compatible CORESETs

[0087] In accordance with the present disclosure, the UE could engage in a process to help overcome the BWP-out-of-sync situation with compatible CORESETs. In particular, the UE could help to overcome this problem by keeping track of how many DCI messages the UE receives that each seem to direct a BWP switch but that each provide an insufficient timeslot-interval for the BWP switch, and when the UE detects at least a predefined threshold number of such non-compliant DCI messages (the threshold number being at least two), the UE may then responsively engage in the directed BWP switch.

[0088] More particularly, when the UE receives from the UE’s serving access node in a scheduling timeslot a DCI message and the UE finds that that DCI message specifies for scheduled communication (i) a BWP that the UE currently has set as inactive (e.g., a BWP that the UE does not have set as active) and (ii) a timeslot-offset that is shorter than the minimum blanking-interval threshold after the scheduling timeslot, the UE will then start a counter to count how many such non-compliant DCI messages the UE receives from the access node one after another (in sequence, not necessarily in back to back timeslots).

[0089] This count may start with the just-received non-compliant DCI message, and the UE may increment the counter each time the UE receives from the access node another DCI message that specifies for scheduled communication an inactive BWP of the UE (e.g., the same inactive BWP of the UE) and a timeslot-offset that is shorter than the minimum blankinginterval threshold. (Alternatively, the count could start with a next received non-compliant DCI message, among other possibilities.) The access node may repeatedly send such a DCI to the UE, for instance to facilitate retransmissions in a HARQ process or in other scenarios. Thus, each time the UE receives a next such non-compliant DCI message (without receiving in the interim a compliant DCI message that either specifies the UE’s active BWP or specifies an inactive BWP with a long enough timeslot-interval), the UE could increment its counter of non-compliant DCI messages.

[0090] The UE could then keep track of the level of this counter. Upon determining that this counter reaches a predefined threshold level (which may be set to a value of two to ten (perhaps three), among other possibilities), the UE may respond to that threshold high count of such non-compliant messages by then engaging in the BWP switch - even though the UE’ s normal process may be to disregard such non-compliant messages. For instance, in response to the threshold high count of received DCI messages that specify an inactive BWP of the UE and an insufficient timeslot-interval, the UE may then reconfigure itself to have the inactive BWP become an active BWP of the UE. Namely, the UE may then responsively switch from the old BWP to the new BWP.

[0091] Upon making this switch, perhaps then after enough of a wait time, the UE may then be able to successfully receive and respond to DCI messages that designate the new BWP. For instance, thereafter, when the access node transmits to the UE a DCI message that schedules communication on the new BWP, the UE could then rightly engage in that scheduled communication.

[0092] In an implementation of this solution, the UE may carry out this process only if the UE has first not received a DCI message from the access node for at least the blanking interval of time. In particular, the UE could detect that at least that blanking-interval threshold number of timeslots have passed without the UE receiving a DCI message from the access node and then that the UE starts to receive the non-compliant DCI messages from the access node. This implementation takes into account that, for the likely missed DCI message, the access node would have set the timeslot-interval to at least that blanking interval period before the access node then sends a next DCI message to the UE.

[0093] Further, note that the DCIs in this scenario could be to schedule downlink communication or to schedule uplink communication. Further, the DCIs counted by the UE may or may not be for the same data communication as each other.

[0094] Accordingly, Figure 6 is a flow chart illustrating an example method for controlling BWP usage by a UE that is served by an access node.

[0095] As shown in Figure 6, at block 600, the example method includes the UE receiving from the access node, in a scheduling timeslot, a scheduling directive that provides the UE with a grant of air-interface resources, the scheduling directive designating (i) a BWP in which the air-interface resources are defined and (ii) a timeslot-offset defining how many timeslots after the scheduling timeslot the air-interface resources are defined, the timeslotoffset being at least zero. At block 602, the example method then includes the UE determining, responsive to receiving the scheduling directive, that (i) the UE has the designated BWP set as inactive, which may mean that the scheduling directive therefore directs the UE to engage in a BWP switch from a currently active BWP of the UE to the designated BWP as an active BWP of the UE, and (ii) the designated timeslot-offset is too low for the BWP switch. Further, at block 604 the example method includes, responsive to at least the determining, (a) the UE counting a quantity of scheduling directives that the UE receives from the access node that each designate the designated BWP and that each designate a respective timeslot-offset that is too low for the BWP switch, and (b) responsive to the UE counting the quantity to be at least a predefined threshold quantity that is at least two (e.g., a quantity from two to ten, among other possibilities), the UE engaging in the BWP switch.

[0096] In line with the discussion above, the act of the UE determining that the designated timeslot-offset is too low for the BWP switch could involve the UE determining that the designated timeslot-offset is less than a predefined threshold number of timeslots, perhaps threshold being set to a number of timeslots from three to five, among other possibilities.

[0097] Further, as discussed above, the act of the UE determining that the designated timeslot-offset is too low for the BWP switch could involve the UE determining that the UE did not receive from the access node any scheduling directive within the predefined threshold number of timeslots before the scheduling timeslot. [0098] In addition, as discussed above, the act of the UE receiving from the access node the scheduling directive could follow the UE failing to detect from the access node an earlier scheduling directive that designated the designated BWP and that designated a timeslotoffset that was at least as high as the predefined threshold number of timeslots. For instance, this process could follow the UE missing receipt of a DCI message directing the BWP switch, which may have put the UE and access node in a BWP out-of-sync state.

[0099] Still further, as discussed above, the act of counting the quantity of scheduling directives that the UE receives from the access node that each designate the designated BWP and that each designate a respective timeslot-offset that is too low for the BWP switch could involve counting a quantity of the scheduling directives that the UE receives one after another from access node without the UE receiving from the access node any intervening scheduling directive that designates the currently active BWP of the UE.

[00100] In another respect, disclosed is an example UE that includes a processor, non- transitory data storage, and program instructions stored in the non-transitory data storage and executable by the by the processor to cause the UE to carry out operations for controlling BWP usage by the UE when the UE is served by an access node. Here, the operations could be in line with those discussed above as to the example method, among other possibilities.

[00101] Further, note that the example UE may also include a wireless communication interface, and the process may be part of that wireless communication interface. For instance, the UE may include a chipset designed to engage in cellular wireless communication according to a defined RAT, and that chipset may include a processor that executes instructions to carry out these operations. Alternatively or additionally, a host processor of the UE may carry out some or all of these operations, interworking as applicable with a wireless communication interface of the UE.

[00102] In yet another respect, disclosed is an example non-transitory computer- readable medium having stored thereon instructions executable by a processor to cause a UE to carry out operations for controlling BWP usage by the UE when the UE is served by an access node. The operations here could also be in line with those discussed above as to the example method, among other possibilities.

5. Technical Solution for BWP Out-of-Sync with Incompatible CORESETs

[00103] Further in accordance with the present disclosure, the UE could engage in a process to help overcome the BWP-out-of-sync situation with incompatible CORESETs. In particular, the UE could help to overcome this problem by detecting when the UE has not received a DCI from the access node for a threshold period of time and then responsively testing one or more other of the UE’s configured BWPs in an effort to find a BWP that may work - i.e., to find the BWP that the access node views as the UE’s currently active BWP.

[00104] In this solution, the UE may first detect that the UE has not received a DCI message from the access node for at least a threshold time period. This threshold time period could be predefined by engineering design, possibly set long enough to be deemed problematic. Alternatively, this threshold time period could be predefined in real time based on context. For instance, if the UE sends a scheduling request message to the access node to elicit an uplink scheduling grant, the UE may expect to responsively receive within a threshold time period from the access node a DCI message scheduling that uplink communication. The UE may thus treat that threshold time period to be the threshold time period for detecting non-receipt of a DCI message from the access node. Alternatively, if the UE is engaged in a particular type of communication where the UE may expect to receive downlink scheduling grants with a certain periodicity or other basis, that expectation may similarly define a threshold time period for the UE detecting non-receipt of a DCI message from the access node. Examples of this threshold time period may be on the order of two to fifty frames, among other possibilities.

[00105] In response to detecting that the UE has not received a DCI message from the access node for at least a threshold time period, the UE may then test one or more of the UE’s inactive BWPs to determine if one of those BWPs may work - on grounds that the access node may have directed a switch to that BWP and that the UE may have missed that BWP switch directive. For instance, the UE may sequence through each of the UE’s inactive BWPs, testing each to see if it will work, until the UE finds one that works, at which point the UE may reconfigure itself to have that one be the UE’s currently active BWP. Alternatively, the UE may so test just a single one of the UE’s inactive BWPs and, upon finding that it will work, reconfigure itself to make that BWP an active BWP.

[00106] Without limitation, this testing process may work particularly well on a TDD carrier, where each of the UE’s downlink BWPs is tied to an uplink BWP of the same BWP index. To test a given one of the UE’s inactive BWPs in this scenario to see if it will work, the UE may transmit a scheduling-request to the access node on the inactive uplink BWP and could wait a threshold time period to see if the UE receives in response from the access node on the correspondingly inactive downlink BWP a DCI that provides an uplink scheduling grant.

[00107] If, by expiration of this threshold time period, the UE receives from the access node the DCI providing the uplink scheduling grant, then the UE may reasonably conclude that the inactive BWP (uplink and downlink) is the BWP that the access node considers to be the UE’s active BWP. Therefore, the UE may engage in a BWP switch to make that inactive BWP the UE’s new active BWP moving forward. Whereas, if, by the expiration of this threshold time period, the UE does not receive from the access node the DCI providing the uplink scheduling grant, then the UE may reasonably conclude that the inactive BWP under test is not the BWP that the access node considers to be the UE’s active BWP. Therefore, the UE may then proceed to test a next one of the UE’s inactive BWPs if any and may proceed accordingly.

[00108] This testing process may also work on an FDD carrier where the UE’s uplink and downlink BWPs are different frequency ranges. In this scenario, the UE may test an inactive uplink BWP, seeing if a scheduling request on that inactive uplink BWP will result in the UE receiving from the access node a DCI message on the UE’s active downlink BWP. If this test fails (i.e., if the UE does not receive the DCI message in response), then the UE may responsively proceed to test an inactive downlink BWP, seeing if a scheduling request on the UE’s active uplink BWP will result in the UE receiving from the access node a DCI message on the inactive downlink BWP. Ultimately, the UE may thereby or otherwise sequence through testing various uplink-downlink combinations of the UE’s configured uplink BWPs with the UE’s configured downlink BWPs until the UE hopefully finds a combination that works. Upon finding a combination that will work, the UE may then switch to make that combination the UE’s active combination of uplink BWP and downlink BWP.

[00109] In this process, the scheduling request that the UE sends to the access node on the BWP under test could be a fake scheduling request, in that the scheduling request may not correspond with uplink data that the UE has buffered for transmission. One way to do this is for the UE to include a non-zero but token BSR in the scheduling request. For instance, even if the UE may have a large quantity of data buffered for transmission or may have no data buffered for transmission, the UE may include in the scheduling request a BSR that designates a very small amount of data, for test purposes. Alternatively, particularly where the UE has data buffered for transmission, the UE may send a real scheduling request, as successful testing may then enable the UE to proceed with uplink transmission of that data on the new BWP.

[00110] In an implementation of this solution, the UE may carry out this process only if the UE has at least a predefined threshold minimum level of power headroom, which may establish that the UE is not power limited and that the UE may, at least theoretically, be able to successfully transmit a scheduling request that would reach the access node. For instance, the UE may carry out this process, perhaps responding to the detecting that the UE has not received a DCI message from the access node for at least a threshold time period, only if the UE is not currently operating at the UE’s maximum transmission power level (which may be zero power headroom or, worse, negative power headroom).

[00111] Accordingly, Figure 7 is another flow chart of another example method for controlling BWP usage by a UE that is served by an access node.

[00112] As shown in Figure 7, at block 700, the example method includes the UE detecting that a predefined threshold amount of time has passed since the UE last received from the access node an air-interface scheduling directive. At block 702, the example method then includes, responsive to at least the detecting, the UE testing to determine if a scheduling request transmitted from the UE to the access node in an inactive BWP of the UE results in the UE receiving from the access node an associated scheduling directive. Further, at block 704, the example method includes, responsive to the testing establishing that the scheduling request transmitted from the UE to the access node in the inactive BWP of the UE results in the UE receiving from the access node the associated scheduling directive, reconfiguring the UE to transition the inactive BWP to be an active BWP of the UE.

[00113] In line with the discussion above, the act of the UE detecting that the predefined threshold amount of time has passed since the UE last received from the access node an air-interface scheduling directive could involve the UE detecting that the predefined threshold amount of time has passed since the sent a first uplink scheduling request to the access node (i.e., a given such uplink scheduling request) and that the UE has not received from the access node an uplink scheduling grant in response to that first uplink scheduling request.

[00114] As further discussed above, the act of the UE testing to determine if the scheduling request transmitted from the UE to the access node in the inactive BWP of the UE results in the UE receiving from the access node an associated scheduling directive could involve the UE transmitting the scheduling request in the inactive BWP and the UE then determining whether the UE receives from the access node, in response to the transmitted scheduling request, the associated scheduling directive.

[00115] In addition, as discussed above, the UE may have multiple inactive BWPs including a first inactive BWP and including the inactive BWP noted above as a second inactive BWP. In that case, the method may include, responsive to the UE detecting that the predefined threshold amount of time has passed since the UE last received from the access node an airinterface scheduling directive, (i) the UE first testing to determine if a scheduling request transmitted from the UE to the access node in the first inactive BWP results in the UE receiving from the access node a first associated scheduling directive, and (ii) responsive to the first testing establishing that the scheduling request transmitted from the UE to the access node in the first inactive BWP does not result in the UE receiving from the access node the first associated scheduling directive, the UE then testing to determine if a scheduling request transmitted from the UE to the access node in the second inactive BWP results in the UE receiving from the access node a second associated scheduling directive.

[00116] Still further, as discussed above, in an example implementation, the UE may carry out this example method if and only if the UE has at least a predefined threshold nonzero level of power headroom, i.e., power headroom that indicates the UE’s uplink transmission power is set to a level less than the UE’s maximum allowed uplink transmission power.

[00117] In addition, as discussed above, the scheduling request that the UE sends in this method could be a fake scheduling request that is not for uplink data buffered by the UE.

[00118] Further, as discussed above, this process may work well in a TDD scenario, where the inactive BWP of the UE is defined in a TDD carrier. However, the process may also work in an FDD scenario, in which case a variation on the method may also be applied, possibly testing various combinations of the UE’s uplink and downlink BWPs until finding one that works.

[00119] As to this solution as well, disclosed is an example UE that includes a processor, non-transitory data storage, and program instructions stored in the non-transitory data storage and executable by the by the processor to cause the UE to carry out operations for controlling BWP usage by the UE when the UE is served by an access node. Likewise, the operations could be in line with those discussed above as to the example method, among other possibilities.

[00120] Further, this example UE may also include a wireless communication interface, and the process may be part of that wireless communication interface. For instance, the UE may include a chipset designed to engage in cellular wireless communication according to a defined RAT, and that chipset may include a processor that executes instructions to carry out these operations. Alternatively or additionally, a host processor of the UE may carry out some or all of these operations, interworking as applicable with a wireless communication interface of the UE.

[00121] Still further, also disclosed as to this solution is an example non-transitory computer-readable medium having stored thereon instructions executable by a processor to cause a UE to carry out operations for controlling BWP usage by the UE when the UE is served by an access node. The operations here could also be in line with those discussed above as to the example method, among other possibilities.

6. Example UE and Associated Structure

[00122] Figure 8 is a simplified block diagram of an example UE, showing some of the components that the example UE may include. As shown, the UE may include a wireless communication interface 800, a processor 802, and non-transitory data storage 804. These components could be integrated together and/or communicatively linked together in various ways. For instance, the components could be linked together through a system bus, network, or other connection mechanism 806. Alternatively, various integrations and other arrangements are possible. For instance, the processor 802 could be a component of the wireless communication interface 800.

[00123] The wireless communication interface 800 could comprise one or more modules (e.g., one or more chipsets) configured to facilitate wireless communication between the UE and access nodes according to one or more RATs, such as 4G LTE, 5GNR, and/or one or more other protocols. As shown, for instance, the wireless communication interface 202 may include one or more radios 808, one or more amplifiers 810, and one or more antennas 812. The one or more radios 808 may include one or more radio transmitters configured to modulate baseband signals onto radio frequency RF carriers and one or more radio receivers configured to demodulate baseband signals from one or more RF carriers. The one or more amplifiers 810 may be configured to amplify outbound signals for transmission and/or inbound signals for processing. And the one or more antennas 812 may be configured to transmit and/or receive RF signals. The wireless communication interface 800 may further include various circuitry and/or other logic to facilitate operation according to one or more RATs.

[00124] The processor 802 could comprise one or more general purpose processors (e.g., one or more microprocessors, etc.) and/or one or more special-purpose processors (e.g., digital signal processors, application-specific integrated circuits, etc.) Further, the non- transitory data storage 804 could comprise one or more volatile and/or non-volatile storage components (e.g., optical, magnetic, or flash storage, RAM, ROM, EPROM, EEPROM, cache memory, and/or other computer-readable media, etc.), possibly integrated in whole or in part with the processor 802. As shown, the non-transitory data storage 804 may store program instructions 814, which may be executable by the processor 802 to carry out various operations described herein. Further, the non-transitory data storage 804 may store reference data 816, such as BWP configuration data, among other possibilities.

[00125] Various features described herein could be implemented in this context as well, and vice versa.

[00126] In addition, the present disclosure also contemplates a non-transitory computer-readable medium (e.g., optical, magnetic, or flash storage, RAM, ROM, EPROM, EEPROM, etc.) having stored thereon program instructions executable by a processor of a UE to cause the UE to carry out various operations described herein, such as the various operations of the example methods discussed above.

[00127] Example embodiments have been described above. Those skilled in the art will understand, however, that changes and modifications may be made to these embodiments without departing from the true scope and spirit of the invention.

Claims

CLAIMS What is claimed is:

1. A method for controlling bandwidth part (BWP) usage by a user equipment device (UE) served by an access node, the method comprising: detecting by the UE that a predefined threshold amount of time has passed since the UE last received from the access node an air-interface scheduling directive; responsive to at least the detecting, testing by the UE to determine if a scheduling request transmitted from the UE to the access node in an inactive BWP of the UE results in the UE receiving from the access node an associated scheduling directive; and responsive to the testing establishing that the scheduling request transmitted from the UE to the access node in the inactive BWP of the UE results in the UE receiving from the access node the associated scheduling directive, reconfiguring the UE to transition the inactive BWP to be an active BWP of the UE.

2. The method of claim 1, wherein detecting by the UE that the predefined threshold amount of time has passed since the UE last received from the access node an airinterface scheduling directive comprises detecting by the UE that the predefined threshold amount of time has passed since the sent a first uplink scheduling request to the access node and that the UE has not received from the access node an uplink scheduling grant in response to the first uplink scheduling request.

3. The method of claim 1, wherein testing to determine if the scheduling request transmitted from the UE to the access node in the inactive BWP of the UE results in the UE receiving from the access node an associated scheduling directive comprises: transmitting by the UE the scheduling request in the inactive BWP; and determining by the UE whether the UE receives from the access node, in response to the transmitted scheduling request, the associated scheduling directive.

4. The method of claim 1, wherein the UE has a plurality of inactive BWPs including a first inactive BWP and including the inactive BWP as a second inactive BWP, the method further comprising: responsive to the detecting, first testing by the UE to determine if a scheduling request transmitted from the UE to the access node in the first inactive BWP results in the UE receiving from the access node a first associated scheduling directive, wherein the testing and responsive reconfiguring of claim 21 are responsive to the first testing establishing that the scheduling request transmitted from the UE to the access node in the first inactive BWP does not result in the UE receiving from the access node the first associated scheduling directive.

5. The method of claim 1, wherein the UE carries out the method if and only if the UE has at least a predefined nonzero threshold level of power headroom.

6. The method of claim 1, wherein the predefined threshold amount of time is from two to fifty frames.

7. The method of claim 1, wherein the scheduling request of the testing is a fake scheduling request that is not for uplink data buffered by the UE.

8. The method of claim 1, wherein the inactive BWP of the UE is defined in a time division duplex (TDD) carrier.

9. A user equipment device (UE) comprising: a processor; non-transitory data storage; and program instructions stored in the non-transitory data storage and executable by the processor to cause the UE to carry out operations for controlling bandwidth part (BWP) usage by the UE when the UE is served by an access node, the operations including: detecting that a predefined threshold amount of time has passed since the UE last received from the access node an air-interface scheduling directive, responsive to at least the detecting, testing to determine if a scheduling request transmitted from the UE to the access node in an inactive BWP of the UE results in the UE receiving from the access node an associated scheduling directive, and responsive to the testing establishing that the scheduling request transmitted from the UE to the access node in the inactive BWP of the UE results in the UE receiving from the access node the associated scheduling directive, reconfiguring the UE to transition the inactive BWP to be an active BWP of the UE.

10. The UE of claim 9, wherein detecting that the predefined threshold amount of time has passed since the UE last received from the access node an air-interface scheduling directive comprises detecting that the predefined threshold amount of time has passed since the sent a first uplink scheduling request to the access node and that the UE has not received from the access node an uplink scheduling grant in response to the first uplink scheduling request.

11. The UE of claim 9, wherein the UE has a plurality of inactive BWPs including a first inactive BWP and including the inactive BWP as a second inactive BWP, the operations further including: responsive to the detecting, first testing to determine if a scheduling request transmitted from the UE to the access node in the first inactive BWP results in the UE receiving from the access node a first associated scheduling directive, wherein the testing and responsive reconfiguring of claim 29 are responsive to the first testing establishing that the scheduling request transmitted from the UE to the access node in the first inactive BWP does not result in the UE receiving from the access node the first associated scheduling directive.

12. The UE of claim 9, wherein the program instructions are executable to carry out the operations responsive to the UE having at least a predefined nonzero threshold level of power headroom.

13. The UE of claim 9, wherein the predefined threshold amount of time is from two to fifty frames.

14. The UE of claim 9, wherein the scheduling request of the testing is a fake scheduling request that is not for uplink data buffered by the UE.

15. The UE of claim 9, wherein the inactive BWP of the UE is defined in a time division duplex (TDD) carrier.

16. The UE of claim 9, further comprising a wireless communication interface, wherein the processor is part of the wireless communication interface.

17. A non-transitory computer-readable medium having stored thereon instructions executable by a processor to cause a user equipment device (UE) to carry out operations for controlling bandwidth part (BWP) usage by the UE when the UE is served by an access node, the operations including: detecting that a predefined threshold amount of time has passed since the UE last received from the access node an air-interface scheduling directive; responsive to at least the detecting, testing to determine if a scheduling request transmitted from the UE to the access node in an inactive BWP of the UE results in the UE receiving from the access node an associated scheduling directive; and responsive to the testing establishing that the scheduling request transmitted from the UE to the access node in the inactive BWP of the UE results in the UE receiving from the access node the associated scheduling directive, reconfiguring the UE to transition the inactive BWP to be an active BWP of the UE.

18. The non-transitory computer-readable medium of claim 17, wherein detecting that the predefined threshold amount of time has passed since the UE last received from the access node an air-interface scheduling directive comprises detecting that the predefined threshold amount of time has passed since the sent a first uplink scheduling request to the access node and that the UE has not received from the access node an uplink scheduling grant in response to the first uplink scheduling request.

19. The non-transitory computer-readable medium of claim 17, wherein the UE has a plurality of inactive BWPs including a first inactive BWP and including the inactive BWP as a second inactive BWP, the operations further including: responsive to the detecting, first testing to determine if a scheduling request transmitted from the UE to the access node in the first inactive BWP results in the UE receiving from the access node a first associated scheduling directive, wherein the testing and responsive reconfiguring of claim 37 are responsive to the first testing establishing that the scheduling request transmitted from the UE to the access node in the first inactive BWP does not result in the UE receiving from the access node the first associated scheduling directive.

20. The non-transitory computer-readable medium of claim 17, wherein the program instructions are executable to carry out the operations responsive to the UE having at least a predefined nonzero threshold level of power headroom.