Optimizations for reduced capability user equipment

Abstract

Optimizations for reduced capability (RedCap) user equipment (UE) are disclosed herein. Various embodiments relate to cases of inter-radio-access-technology (RAT) handover to a RAT that uses RedCap, where the RedCap UE uses system information to determine whether or not a particular measurement object (MO) corresponds to / could correspond to a RedCap cell in the target RAT (or not). Various embodiments relate to manners of radio link failure (RLF) recovery after a failed handover attempt to a non-RedCap cell by a RedCap UE. Various embodiments relate to UE identification of and reaction to cases of handover to RedCap cells that have enabled network energy saving (NES). Various embodiments relate to UE-triggered switching to a RedCap cell. Various embodiments relate to condition-based UE switching to a RedCap cell. Various embodiments relate to slicing requests in a RedCap UE context. Various embodiments relate to PDU release optimizations within a RedCap UE context.

Description

OPTIMIZATIONS FOR REDUCED CAPABILITY USER EQUIPMENTTECHNICAL FIELD

[0001] This application relates generally to wireless communication systems, including wireless communication systems including user equipment (UE) that operated in a reduced capability (RedCap) mode.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.

[0008] BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0009] 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.

[0010] FIG. 1 illustrates a portion of a first SIB as may be used in wireless communications systems operating according to embodiments disclosed herein.

[0011] FIG. 2 illustrates a portion of a second SIB as may be used in wireless communications systems operating according to embodiments disclosed herein.

[0012] FIG. 3 illustrates a portion of a featureCombination IE as may be provided to a UE in wireless communications systems operating according to embodiments disclosed herein.

[0013] FIG. 4 illustrates a posSI-RequestConfigRedCap field as may be provided to a UE in wireless communications systems operating according to embodiments disclosed herein.

[0014] FIG. 5 illustrates a signaling diagram of a four-step RACH procedure in accordance with some embodiments.

[0015] FIG. 6 illustrates a signaling diagram of a two-step RACH procedure in accordance with some embodiments.

[0016] FIG. 7 illustrates a BWP-UplinkCommon IE that may be transmitted to a

[0017] RedCap UE by the network in some wireless communication systems.

[0018] FIG. 8 illustrates a method for the use of system information received at a RedCap UE from the network to determine whether the RedCap UE may connect to an NR cell according to its RedCap configuration, according to embodiments herein.

[0019] FIG. 9 illustrates a RedCap PCPCD as may be used by a RedCap UE in embodiments discussed herein.

[0020] FIG. 10A and FIG. 10B together illustrate a method of performing an inter-RAT handover of a RedCap UE, according to embodiments herein.

[0021] FIG. 11 illustrates a table describing various conditions under which it may be the case that a UE capable of optionally operating as a RedCap UE may be beneficially operated in a RedCap mode, according to embodiments herein.

[0022] FIG. 12A and FIG. 12B together illustrate a method for handover between non-RedCap NR SA to SA RedCap based on conditions, according to embodiments herein.

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

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

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

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

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

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

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

[0030] FIG. 20 illustrates a system for performing signaling between a wireless device and a network device, according to embodiments disclosed herein.DETAILED DESCRIPTION

[0031] 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.

[0032] Reduced Capability (RedCap) UEs

[0033] In the context of various wireless communication systems, a RedCap UE is a UE that operates according to a reduced capability (e.g., as compared to other, non-RedCap UEs that may operate in the wireless communication system) .

[0034] One example set of capabilities of a RedCap UE within an NR wireless communication system are now discussed. It may be that a maximum bandwidth useable by a RedCap UE is 20 MHz in FR1 and 100 MHz in FR2. In such circumstances, UE features and corresponding capabilities related to and / or using UE bandwidths wider than 20 MHz in FR1 and / or wider than 100 MHz in FR2 are not supported by the RedCap UE.

[0035] It may be that a maximum supported data radio bearer (DRB) number at a RedCap UE is 8. It may be that a supported packet data convergence protocol (PDCP) sequence number (SN) length at a RedCap UE is 12 bits (in some cases, a length of 18 bits may be optional) . It may be that a supported radio link control (RLC) acknowledge mode (AM) SN length supported at the RedCap UE is 12 bits (in some cases, a length of 18 bits may be optional) .

[0036] In FR1, a RedCap UE may support one downlink (DL) multiple input multiple output (MIMO) layer in cases where one receive (Rx) branch is supported, and two DL MIMO layers in the case that 2 Rx branches are supported. In FR2, either 1 or 2 DL MIMO layers can be supported (while 2 Rx branches are supported) . With respect to either / both of FR1 and FR2, UE features and corresponding capabilities related to more  than 2 UE Rx branches or more than 2 DL MIMO layers, as well as UE features and capabilities related to more than 1 UE Tx branch or more than 1 uplink (UL) MIMO layer, may not be supported by RedCap UEs.

[0037] Various UE features and corresponding UE capabilities related to carrier aggregation (CA) , multi-RAT dual connectivity (MR-DC) , dual active protocol stack (DAPS) , conditional PSCell addition and change (CPAC) , and / or integrated access and backhaul (IAB) (in the sense that the RedCap UE is not expected to act as IAB node) are not supported by RedCap UEs.

[0038] Table 1.1 lists one possible example of a UE capability for DRB support, according to some embodiments.

[0039] Table 1.1: UE Capability Constraints

[0040] In the context of Table 1.1, it may be noted that for one medium access control (MAC) entity, the maximum number of DRBs configured with PDCP duplication and with RLC entity (s) associated with the MAC entity is 8. Further, it may be noted that this requirement is applicable in NR standalone (SA) , NR dual connectivity (NR-DC) , and NR-E-UTRA dual connectivity (NE-DC) . Finally, note that the value of parameter “#DRBs” defines the total number of multicast radio bearers (MRBs) and DRBs (and where each split-MRB is counted as two radio bearers (RBs) for these purposes) .

[0041] Core Network Aspects for RedCap UEs

[0042] “NR RedCap” may be a 3GPP RAT type identifier used in a core network to identify, in the core network, the NG-RAN when used by a UE indicating NR RedCap. The NR RedCap RAT type may be understood to be a sub-type of an NR RAT type.

[0043] With respect to high latency communication: when an NR RedCap UE requests to use certain power saving functions (see 3GPP Technical Specification (TS) 23.501, version 18.1.10 (March 2023) (hereinafter “TS 23.501” ) , section 5.31.7) , then an access  and mobility management function (AMF) may, based on local policy, reroute the registration request to another AMF that supports high latency communication (see TS 23.501 section 6.5.3) .

[0044] With respect to NR RedCap UE differentiation: this functionality may be used by the network to identify traffic to / from UEs accessing over NR RedCap (e.g. for charging differentiation purposes) . An NR RedCap UE using NR shall provide an NR RedCap indication to the NG-RAN during a radio resource control (RRC) connection establishment procedure (see 3GPP TS 38.300, version 17.5.0 (June 2023) (hereinafter “TS 38.300” ) ) .

[0045] When the UE has provided an NR RedCap indication to the NG-RAN during an RRC connection establishment, the NG-RAN provides an NR RedCap indication to the AMF in an initial UE message (see section 4.2.2.2.1 of 3GPP TS 23.502, version 18.0.0 (December 2022) and 3GPP TS 38.413, version 17.6.0 (September 2023) .

[0046] When the AMF receives an NR RedCap indication from NG-RAN in an initial UE message, the AMF shall store the NR RedCap indication in the UE context, consider that the RAT type is NR RedCap, and signal it accordingly to the short message service function (SMSF) during a registration procedure for short message service (SMS) over non-access stratum (NAS) , and / or to the session management function (SMF) during protocol data unit (PDU) session establishment or during a PDU session modification procedure. The policy control function (PCF) also receives the NR RedCap RAT type indication, when applicable, from the SMF during session management (SM) policy association establishment or during an SM policy association modification procedure.

[0047] During handover from Evolved Universal Terrestrial Radio Access (E-UTRA) to NR, the target NG-RAN (e.g., a target gNB of the target NG-RAN) provides an NR RedCap indication to the AMF in an NG application protocol (NGAP) path switch request message during Xn handover, or in an NGAP handover request acknowledge message during N2 handover (including intra 5GS N2 handover and evolved packet system (EPS) to 5GS handover) , based on the UE capability information provided by the source RAN to the target RAN (see TS 38.300) .

[0048] The network functions (NFs) interacting with the charging function (CHF) include the NR RedCap as the RAT type. Upon an AMF change, a source AMF provides an NR RedCap indication to the target AMF.

[0049] RAN Aspects for RedCap UEs

[0050] As is discussed herein, a RedCap UE has reduced capabilities. This may be intended to allow the RedCap UE to operate according to a lower complexity and / or power use with respect to non-RedCap UEs. Accordingly, in some wireless communication systems, it may be that a RedCap UE supports a 20 MHz (maximum) UE channel bandwidth in FR1 and / or a 100 MHz (maximum) UE channel bandwidth in FR2.

[0051] With respect to capabilities of the RAN: Various CA, MR-DC, DAPS, CPA, conditional primary secondary cell group (SCG) cell (PSCell) change (CPC) and / or IAB-related capabilities may not be supported by RedCap UEs (e.g., as defined together with other aspects in 3GPP TS 38.306, version 17.5.0 (June 2023) ) . It may be up to the network to prevent RedCap UEs from using radio capabilities not intended for RedCap UEs.

[0052] With respect to identification, access and camping restrictions: A RedCap UE can be identified by the network during a random access procedure based on a Msg3 / MsgA that uses a RedCap-specific logical channel ID (s) (LCID (s) ) , and optionally based on a Msg1 / MsgA that uses a RedCap-specific a physical random access channel (PRACH) occasion and / or a RedCap-specific PRACH preamble. For RedCap UE identification via Msg1 / MsgA, a RedCap-specific random access configuration may be configured by the network. For Msg3 / MsgA, a RedCap UE may identified based on the dedicated LCID (s) indicated for common control channel (CCCH) identification (CCCH or CCCH1) , regardless of whether any RedCap specific random access configuration is / has been configured by the network.

[0053] RedCap UEs with 1 Rx branch and 2 Rx branches may be allowed / treated separately via system information. In addition, RedCap UEs in half-duplex frequency division duplex (FDD) mode can be allowed / treats separately via system information. Further, a RedCap specific intra frequency resolution indication (IFRI) can be provided in SIB1, and, when absent, RedCap UE access is not allowed. Information with respect to frequencies where RedCap UE access is allowed may be provided in system information.

[0054] A RedCap UE with 1 Rx branch applies an associated offset for broadcasted cell specific reference signal receive power (RSRP) thresholds for random access, small data transmission (SDT) , cell edge condition and / or cell (re) selection criterion in a specified manner (see 3GPP TS 38.133, version 18.2.0 (June 2023) ) .

[0055] It may be noted that it is up to the E-UTRA network, if possible, to avoid triggering handover attempts of a RedCap UE to a target NR cell not supporting RedCap. It is up to the RedCap UE implementation, if possible, to recover from handover attempts to a target NR cell not supporting RedCap.

[0056] With respect to radio resource management (RRM) measurement relaxations: RRM measurement relaxation may be enabled and / or disabled by the network. In an RRC idle mode ( "RRC_IDLE" ) and / or and RRC inactive mode ( "RRC_INACTIVE" ) a RedCap UE may be allowed to relax neighbor cell RRM measurements when stationary criterion are met or when both stationary criterion and not-at-cell-edge criterion are met. The network may configure the stationary criterion for a RedCap UE when the UE is in an RRC connected mode ( "RRC_CONNECTED" ) , and the UE may report its RRM measurement relaxation fulfilment status using UE assistance information when the stationarity criterion is met or no longer met.

[0057] With respect to bandwidth part (BWP) operation: A RedCap UE in RRC_IDLE or RRC_INACTIVE may monitor paging in an initial BWP (either a default initial BWP or RedCap-specific initial BWP) associated with a cell-defining synchronization signal block (CD-SSB) and perform cell (re) selection and related measurements on the CD-SSB. If a RedCap-specific initial UL BWP is configured and a normal uplink (NUL) carrier is selected, RedCap UEs in RRC_IDLE and RRC_INACTIVE may use only the RedCap-specific initial UL BWP to perform random access channel (RACH) procedures.

[0058] A RedCap UE may be configured with multiple non-cell-defining synchronization signal blocks (NCD-SSBs) , provided that each BWP is configured with at most one SSB. NCD-SSBs may be configured for a RedCap UE in RRC_CONNECTED to perform radio link management (RLM) , beam failure detection (BFD) , RRM measurements, and / or random access (RA) resource selection when the active BWP does not contain a CD-SSB.

[0059] RRC Aspects for RedCap UEs

[0060] FIG. 1 illustrates a portion of a first system information block (SIB) 102 as may be used in wireless communications systems operating according to embodiments disclosed herein. In some embodiments, the first SIB 102 may be a SIB1.

[0061] As illustrated, the first SIB 102 includes a redCap-ConfigCommon information element (IE) 104. The redCap-ConfigCommon IE 104 in the first SIB 102 may refer to or  use a RedCap-ConfigCommonSIB IE 106 and an intraFreqReselectionRedCap field 108, as illustrated.

[0062] The RedCap-ConfigCommonSIB IE 106 may include a halfDuplexRedCapAllowed field 110 and a cellBarredRedCap IE 112, as illustrated. The halfDuplexRedCapAllowed field 110, if present, indicates that the cell supports half-duplex FDD RedCap UEs.

[0063] The cellBarredRedCap IE 112 may include each of a cellBarredRedCap1Rx field 114 and / or a cellBarredRedCap2Rx field 116. A cellBarredRedCap1Rx field 114 that carries the value barred provides an indication that the cell is barred for a RedCap UE with 1 Rx branch. Any cellBarredRedCap1Rx field 114 is ignored by non-RedCap UEs. A cellBarredRedCap2Rx field 116 that carries the value barred provides an indication that the cell is barred for a RedCap UE with 2 Rx branches. Any cellBarredRedCap2Rx field 116 is ignored by non-RedCap UEs.

[0064] Finally, the intraFreqReselectionRedCap field 108 controls cell selection / reselection to intra-frequency cells for RedCap UEs when this cell is barred, or treated as barred by the RedCap UE. If this field is not present, a RedCap UE treats the cell as barred (the UE considers that the cell does not support RedCap) .

[0065] FIG. 2 illustrates a portion of a second SIB 202 as may be used in wireless communications systems operating according to embodiments disclosed herein. In some embodiments, the second SIB 202 may be a SIB4.

[0066] As illustrated, the second SIB 202 includes one or more interFreqCarrierFreqList IEs 204, and an interFreqCarrierFreqList IE 204 may include one or more interFreqCarrierFreqInfo IEs 206.

[0067] Finally, an interFreqCarrierFreqInfo IE 206 includes a redCapAccessAllowed field 208. The redCapAccessAllowed field 208 that indicates whether RedCap UEs are allowed to access the frequency corresponding to / identified by the interFreqCarrierFreqInfo IE 206 (e.g., in one or more other fields or IEs of the interFreqCarrierFreqInfo IE 206, which are not expressly illustrated) .

[0068] Note that a set of frequencies corresponding to multiple redCapAccessAllowed fields 208 found in the second SIB 202 may be considered a “RedCap frequency listing” as used herein.

[0069] FIG. 3 illustrates a portion of a featureCombination IE 302 as may be provided to a UE in wireless communications systems operating according to embodiments disclosed herein. The featureCombination IE 302 indicates a feature or a combination of features to be associated with a set of random access resource (e.g., an instance of featureCombinationPreambles) .

[0070] As illustrated, the featureCombination IE 302 may include a redCap field 304. If present, the redCap field 304 indicates that RedCap is part of this particular feature combination.

[0071] FIG. 4 illustrates a posSI-RequestConfigRedCap field 402 as may be provided to a UE in wireless communications systems operating according to embodiments disclosed herein. The posSI-RequestConfigRedCap field 402 may be provided to the UE in, for example, an information block corresponding to a positioning system used by the wireless communication system (e.g., in a PosSystemInformation IE) .

[0072] The posSI-RequestConfigRedCap field 402 indicates a configuration of Msg1 resources (see below) for a configuration (e.g., as may be found in an initialUplinkBWP-RedCap IE) that the RedCap UE uses for requesting system information messages for which, for example, a posSI-BroadcastStatus field is set to notBroadcasting.

[0073] As illustrated, the posSI-RequestConfigRedCap field 402 is optionally provided (Need R) to the UE according to a condition ( "REDCAP-Msg-1" ) that is true when initialUplinkBWP-RedCap is configured in an UplinkConfigCommonSIB IE, and if posSI-BroadcastStatus is set to notBroadcasting for any system information message included in a posSchedulingInfoList IE or if si-BroadcastStatus is set to notBroadcasting for any SI-message containing type2 SIB included in a schedulingInfoList2 IE. It is absent otherwise.

[0074] Embodiments of Four-Step RACH Procedures

[0075] A four-step RACH procedure may include at least a first message ( “Msg1” ) , a second message ( "Msg2" ) , a third message ( "Msg3" ) , and a fourth message ( "Msg4" ) between the UE and a network node (e.g., a base station) . The four-step RACH procedure may also be referred to as Type-1 RACH. For example, FIG. 5 is a signaling diagram illustrating a RACH procedure 500 by a UE 502 and a network node 504 (e.g., a base station) that may be used in certain embodiments. As shown, the UE 502 may send  a Msg1 transmission 506 to the network node 504. The Msg1 transmission 506 may include a PRACH preamble including timing information for uplink transmissions.

[0076] In response to receiving the Msg1 transmission 506, the network node 504 may transmit a Msg2 transmission 508 on a physical downlink control channel (PDCCH) or a physical downlink shared channel (PDSCH) . The Msg2 transmission 508 may also be referred to as a random access response (RAR) message. The Msg2 transmission 508 may include timing parameters or information, an uplink grant for the Msg3 transmission 510, a temporary cell radio network temporary identifier (TC-RNTI) , etc.

[0077] In response to the Msg3 transmission 510, the network node 504 may transmit a Msg4 PDSCH transmission 512 that includes a contention resolution message. After the UE 502 sends Msg3 transmission 510, a contention resolution timer starts. The network node 504 assists the UE 502 in contention resolution using a cell radio network temporary identifier (C-RNTI) on the PDCCH or using a contention resolution identity IE on the PDSCH. The UE 502 keeps monitoring the PDCCH before the timer expires and considers the contention resolution successful and stops the timer if the UE 502 obtains the C-RNTI over the PDCCH, or the UE obtains the temporary C-RNTI over the PDCCH and a MAC PDU is successfully decoded. If the contention resolution timer expires, the UE 502 considers the contention resolution failed.

[0078] To enhance coverage of the Msg4 PDSCH transmission 512, the network node 504 may apply repetition to the Msg4 PDSCH transmission 512. For example, the network node 504 may transmit one or more Msg4 PDSCH repetitions 514. Msg4 PDSCH repetition 514 allows the network node 504 to re-transmit the contention resolution information that was sent via the Msg4 PDSCH transmission 512 at a different time. That way, if the UE 502 fails to receive the Msg4 PDSCH transmission 512 due to interference, the UE 502 will have additional opportunities to receive the Msg4 information.

[0079] After the UE 502 receives the Msg4 PDSCH transmission 512 and any repetitions, the UE 502 may send a Msg4 HARQ-ACK 516 to the network node 504 in a physical uplink control channel (PUCCH) or a physical uplink shared channel (PUSCH) . The HARQ-ACK timing may be adjusted for Msg4 PDSCH repetitions. The Msg4 HARQ-ACK 516 allows the UE 502 to provide feedback regarding the Msg4 PDSCH transmission 512. To enhance the Msg4 HARQ-ACK 516, the wireless communication system may support the UE sending one or more Msg4 HARQ-ACK repetitions 518. The  Msg4 HARQ-ACK repetition 518 comprises the UE repeatedly transmitting the Msg4 HARQ-ACK on the PUCCH. That way, if the network node 504 fails to receive the Msg4 HARQ-ACK 516 due to interference, the network node 504 will have additional opportunities to receive the HARQ-ACK information.

[0080] In some embodiments, Msg4 HARQ-ACK repetition with demodulation reference signal (DMRS) bundling may be used to enhance Msg4. For DMRS, a time domain window (TDW) may be specified. During the TDW, a UE is expected to maintain power consistency and phase continuity among PUCCH repetitions as HARQ-ACK for Msg4.

[0081] Embodiments of Two-Step RACH Procedures

[0082] A two-step RACH procedure may reduce the latency of the four-step RACH procedure, and may include at least a first message (MsgA) and a second message (MsgB) . The two-step RACH procedure may also be referred to as Type-2 RACH. For example, FIG. 6 is a signaling diagram illustrating a two-step RACH procedure 600 by a UE 602 and a network node 604 (e.g., a base station) that may be used in certain embodiments. As shown, the UE 602 may send a MsgA transmission 606 to the network node 604. The MsgA transmission 606 may include the Msg1 transmission and the Msg3 transmission shown in FIG. 5. In response to receiving MsgA transmission 606, the network node 604 may transmit a MsgB transmission 608 on a PDCCH or a physical downlink shared channel (PDSCH) . The MsgB transmission 608 may include the Msg2 transmission and the Msg4 transmission shown in FIG. 5.

[0083] After the UE 602 receives the MsgB transmission 608 (and any repetitions of the MsgB transmission 608) , the UE 602 may send a PUCCH HARQ-ACK 610 to the network node 604. The PUCCH HARQ-ACK 610 allows the UE 602 to provide feedback regarding the MsgB transmission 608 (i.e., the Msg2 + Msg4 transmission) . To enhance the PUCCH HARQ-ACK 610, the wireless communication system may support the UE sending one or more PUCCH HARQ-ACK repetitions 612. The PUCCH HARQ-ACK repetition 612 comprises the UE 602 repeatedly transmitting the PUCCH HARQ-ACK to the network node 604. That way, if the network node 604 fails to receive the PUCCH HARQ-ACK 610 due to interference, the network node 604 will have additional opportunities to receive the HARQ-ACK information. As used herein, for simplicity, reference to Msg4 HARQ-ACK repetition may refer to PUCCH HARQ-ACK repetition for Type-2 RACH.

[0084] Embodiments of RedCap RACH Configurations

[0085] The network may provide a RedCap UE with information that enables the RedCap UE to determine whether or not a RACH configuration is a RedCap RACH configuration (aRACH configuration that corresponds to a cell that is RedCap compatible) .

[0086] The network can associate a set of RACH resources with feature (s) applicable to the random access procedure. One of these features may be a RedCap feature. Accordingly, a set of RACH resources that is so associated with a RedCap feature can be identified by the RedCap UE as corresponding to a RedCap RACH configuration. The RedCap UE may then select such a set of RACH resources for use after UL carrier (NUL or SUL) and BWP selection, and before selecting a RA type.

[0087] FIG. 7 illustrates a BWP-UplinkCommon IE 702 that may be transmitted to a RedCap UE by the network in some wireless communication systems. The BWP-UplinkCommon IE 702 includes an additionalRACH-ConfigList IE 704. The additionalRACH-ConfigList IE 704 may contain a list of feature of feature combination-specific RACH configurations (and note that these may be understood to be configured in addition to any RACH configuration in any rach-ConfigCommon IE or any msgA-ConfigCommon IE) . The network associates all possible preambles of such an additional RACH configurations to a feature or feature combination. In various embodiments, an additionalRACH-ConfigList IE 704 accordingly contains a RACH configuration that corresponds to a RedCap feature and / or to a feature combination that includes the RedCap feature.

[0088] Accordingly, the RedCap UE may be informed of both resources of a RACH configuration and a preamble for the RACH configuration.

[0089] Embodiments for RedCap UE Handover

[0090] Various RedCap UEs may support both LTE &NR. Hence, LTE-to-NR (L2NR) handover mechanisms should be supported. With respect to such L2NR handover mechanisms, it may be up to the E-UTRA to provide the RedCap UE with a handover command that instructs the handover to a cell in NR. However, the RedCap UE receiving the handover command might not be aware if the target NR cell supports RedCap UEs.

[0091] Specifications for some wireless communications systems state that it is up to the E-UTRA network, if possible, to avoid handover attempts of a RedCap UE to a target  NR cell that is not supporting RedCap, and / or that it is up to the RedCap UE implementation to recover from handover attempts to a target NR cell not supporting RedCap, where possible. Such a framework does not inherently require / anticipate that the network provides full assurance that an L2NR handover command provided to a RedCap UE will be for a target NR cell that is RedCap compatible. Accordingly, UE-side mechanisms for, for example, determining whether a target NR cell is RedCap compatible are beneficial.

[0092] FIG. 8 illustrates a method 802 for the use of system information received at a RedCap UE from the network to determine whether the RedCap UE may connect to an NR cell according to its RedCap configuration, according to embodiments herein.

[0093] The method 802 presupposes 804 that the UE in question is RedCap capable (that the UE is a RedCap UE) . Prior to camping on the NR cell, the RedCap UE receives a SIB1 as broadcast by the NR cell and determines 806 whether the SIB1 contains a redCap-ConfigCommon IE. If not, the RedCap UE determines 808 that the NR cell is not suitable for camping by the RedCap UE.

[0094] If the SIB1 does contain a redCap-ConfigCommon IE, the RedCap UE then determines 810 whether the redCap-ConfigCommon IE of the SIB1 contains a cellBarredRedCap IE. If so, the UE checks whether any cellBarredRedCap1Rx field indicates that the cell is barred for RedCap 1Rx configurations and whether any cellBarredRedCap2Rx field indicates that the cell is barred for RedCap 2Rx configurations.

[0095] If the SIB1 does not contain a cellBarredRedCap IE, or if information found in a cellBarredRedCap IE of the SIB1 does not indicate for barring that is applicable to a RedCap configuration used by the RedCap UE, the RedCap UE determines 814 that the NR cell is a suitable cell on which the RedCap UE may camp. The RedCap UE proceeds to camp on the NR cell.

[0096] After camping on the NR cell, the RedCap UE receives a SIB4 from the NR cell and determines 816 whether the SIB4 contains a redCapAccessAllowed field that indicates that the RedCap UE is allowed to access the frequency of the NR cell. If not, the RedCap UE determines 818 that the frequency of the NR cell is not available for the RedCap UE to access (and that the NR cell cannot be further used by the RedCap UE) .

[0097] In the case that the SIB4 does contain a redCapAccessAllowed field that indicates that the RedCap UE is allowed to access the frequency of the NR cell, the  RedCap UE determines 820 that the frequency is allowed for RedCap UE access purposes (and thus that the NR cell may be further used by the RedCap UE) .

[0098] FIG. 9 illustrates a RedCap preferred cell database (PCPCD) 902 as may be used by a RedCap UE in embodiments discussed herein. The RCPCD 902 stores RedCap-related information for one or more cells 904 (in FIG. 9, the physical cell identity (PCI) may be understood to denote the different cells 904) . The information of the RCPCD 902 may be gathered by the RedCap UE as it proceeds to connect to, or at some level attempt to connect to, the various cells 904, as the case may be (e.g., based on information about the various cells 904 gathered according to the various manners described herein and / or in other ways) .

[0099] The information about the cells 904 represented by the RCPCD 902 may be organized within the RCPCD 902 according to geographical locations 906 at which the cells are found / that are covered by the cells 904.

[0100] Priorities 908 of the cells 904 may be included. These priorities may comprise measurement report (MR) reporting priorities corresponding to the cells.

[0101] Information about the bands 910 and the frequencies 912 of the cells 904 may be included in the RCPCD 902.

[0102] RedCap configurations 914 for the cells 904 may be included in the RCPCD 902. The RedCap configurations 914 may indicate whether a cell is known to support RedCap, whether a cell is known not to support RedCap, and / or whether a cell is barred to RedCap UEs, as has been illustrated.

[0103] The RCPCD 902 further includes serving barred statuses 916 for the cells 904. The serving barred statuses 916 may relate to, for example, any barring information that may be received in a SIB1.

[0104] The RCPCD 902 further includes intra-frequency barred statuses 918 for the cells 904. The intra-frequency barred statuses 918 may be controlled by, for example, information of intraFreqReselectionRedCap fields received for the cells 904 (such as an intraFreqReselectionRedCap field 108 received in a SIB1, as discussed elsewhere herein in relation to FIG. 1) .

[0105] The RCPCD 902 further includes 1Rx barred statuses 920 for the cells 904. The 1Rx barred statuses 920 may be controlled by, for example, information of  cellBarredRedCap1Rx fields received for the cells 904 (such as a cellBarredRedCap1Rx field 114 received in a SIB1, as discussed elsewhere herein in relation to FIG. 1) .

[0106] The RCPCD 902 further includes 2Rx barred statuses 922 for the cells 904. The 2Rx barred statuses 922 may be controlled by, for example, information of cellBarredRedCap2Rx fields received for the cells 904 (such as a cellBarredRedCap2Rx field 116 received in a SIB1, as discussed elsewhere herein in relation to FIG. 1) .

[0107] The RCPCD 902 further includes half-duplex barred statuses 924 for the cells 904. The half-duplex barred statuses 924 may be controlled by, for example, information of cellBarredRedCap2Rx fields received for the cells 904 (such as a cellBarredRedCap2Rx field 116 received in a SIB1, as discussed elsewhere herein in relation to FIG. 1)

[0108] In some embodiments, the RCPCD 902 may be maintained in a memory of the RedCap UE. In other embodiments, the a RedCap UE may communicate with a network server to store, update, maintain, and / or read from an RCPCD 902 in a memory of the network server (which may enable the updating, maintenance, and / or use of the RCPCD 902 at the server by multiple RedCap UEs within the wireless communication system) .

[0109] In some embodiments, it may be that only RedCap supported cells with barred information are recorded in an RCPCD 902.

[0110] Based on its use of an RCPCD 902, a RedCap UE may avoid unnecessary handover attempts to a non-RedCap cell and / or may recover faster after failed handover attempts. For example, prior to performing an network-instructed handover found in a handover command, the RedCap UE may refer to an RCPCD 902 to determine whether the cell supports the RedCap configuration used by the RedCap UE (and thus whether a successful handover of the RedCap UE to the cell is possible) . If the reference to the RCPCD 902 informs the RedCap UE that the handover will not be successful (e.g., because information for the target cell in the RCPCD 902 indicates that the target cell does not use RedCap and / or that the target cell is barred in a manner that is incompatible with a RedCap configuration used by the RedCap UE) , the UE may drop the handover command without attempting the handover to the target cell.

[0111] As another example, after a failed handover attempt, and / or after dropping a handover command (as just described) , the RedCap UE may refer to the RCPCD 902 to identify a fallback cell to which to connect. In some embodiments, the RedCap UE will first attempt to fall back to one of the cells 904 for which the RCPCD 902 does not  indicate any type of barring. If there is no such cell, the RedCap UE may then attempt to fall back to one of the cells 904 for which the RCPCD 902 indicates only types of barring that do not impact a RedCap configuration used by the RedCap UE.

[0112] FIG. 10A and FIG. 10B together illustrate a method 1002 of performing an inter-RAT handover of a RedCap UE, according to embodiments herein.

[0113] The method 1002 presupposes 1004 that the UE in question is RedCap capable (that the UE is a RedCap UE) and that it is camped to an LTE cell of an LTE RAN.

[0114] The RedCap UE then determines 1006 whether an LTE base station (e.g., an eNB) has configured the RedCap UE with either and / or both of a B1 measurement reporting event and a B2 measurement reporting event.

[0115] A configured B1 measurement reporting event may be triggered at the RedCap UE based on a determination by the RedCap UE that a result of measuring a measurement object (MO) of an NR RAN is greater than a threshold. A configured B2 measurement reporting event may be triggered based on a first determination by the RedCap UE that a first result of measuring a current serving cell on the LTE RAN is worse than a first threshold and by a second determination by the RedCap UE that a second result of measuring an MO of the NR RAN is greater than a second threshold. Accordingly, because each of the B1 measurement reporting event and the B2 measurement reporting event relate to measurements on NR while the UE is camped in LTE, each represents an inter-RAT measurement reporting event.

[0116] If the LTE base station has configured the RedCap UE with either and / or both of a B1 and / or a B2 measurement reporting event, the UE proceeds to determine 1008 whether any NR MOs identified for the B1 and / or the B2 measurement reporting event (s) correspond to a redCapAccessAllowed field found in a SIB4 of the NR RAT, where the set of (one or multiple) redCapAccessAllowed fields as found in the SIB4 operates as a RedCap frequency listing that may be used for this purpose. Note that the SIB4 may be a SIB4 that was cached by the RedCap UE prior to the instance of the method 1002 presently under discussion.

[0117] If no NR MOs identified for the B1 and / or the B2 measurement reporting event (s) correspond to a frequency for a redCapAccessAllowed field found in NR SIB4, then the RedCap UE proceeds 1010 to prune such NR MOs from upcoming measurements. Further, the RedCap UE determines to stay camped in LTE and will not send any measurement report for a B1 and / or the B2 measurement reporting event until a  NR SIB4 contains a redCapAccessAllowed field for at least one frequency corresponding to at least one applicable NR MO.

[0118] If at least one NR MOs identified for the B1 and / or the B2 measurement reporting event (s) correspond to a frequency for a redCapAccessAllowed field found in NR SIB4, the RedCap UE proceeds 1012 to measure the NR cells in the corresponding frequency (s) .

[0119] Based on the measurements, the RedCap UE determines that there is at least one MO for which the B1 and / or the B2 measurement reporting event has occurred. Accordingly, the RedCap UE determines that a measurement report is to be sent to the LTE base station.

[0120] In preparing the measurement report, the RedCap UE performs a RedCap check mechanism. As part of the RedCap check mechanism, the RedCap UE checks whether it is already aware of a RedCap cell at the location of the RedCap UE that corresponds to the MO for which the B1 and / or the B2 measurement reporting event has been triggered. This may be accomplished by the RedCap UE referring to a database (e.g., an RCPCD as is described herein) that contains historical information of RedCap cells at the location. If the RedCap UE identifies a record of a RedCap cell for the MO in question at the location of the RedCap UE, then the RedCap UE prepares a measurement report including only measurement results corresponding to one or more known RedCap cells at that location (including at least a result for the RedCap cell corresponding to the MO for which the B1 and / or B2 measurement reporting event has been triggered) .

[0121] If the RedCap UE does not identify any record of a RedCap cell for the MO that triggers the B1 and / or the B2 reporting event at the location of the RedCap UE, the RedCap UE instead prepares a measurement report having measurement results for a (e.g., larger) set of candidate cells that have been measured by the RedCap UE (where this measurement report is not restricted to only measurement results for known RedCap cells) .

[0122] The RedCap UE transmits the prepared measurement report to the LTE base station. In response, the network may provide, in a return transmission to the RedCap UE (e.g., through the LTE base station) , an RRC reconfiguration message instructing the RedCap UE (e.g., via a handover command) to perform a handover to a target cell in the NR RAN. The target NR cell may be, for example, a RedCap cell that was reported-on in  the measurement report transmitted by the RedCap UE in response to the prior B1 and / or the prior B2 measurement report event, as is described herein.

[0123] In cases where the RedCap UE determines 1014 that such an RRC reconfiguration message has been received, the UE may proceed 1016 to perform a RedCap validation mechanism with respect to the target NR cell to attempt to determine whether the target NR cell is a RedCap cell. This is because of the fact that, in at least some cases, the UE may not be aware whether or not the target NR cell indicated in the handover command is a RedCap cell.

[0124] As a first check within the RedCap validation mechanism, the RedCap UE first determines whether a RACH configuration for the target NR cell received in the RRC reconfiguration message from the LTE base station is a RedCap RACH configuration. If so, the RedCap UE concludes that the target NR cell is a RedCap cell and proceeds to camp on and use the target NR cell going forward.

[0125] If not, the RedCap UE will perform a RACH procedure with the target NR cell using the RACH configuration without knowledge of whether or not the target NR cell is a RedCap cell that is ultimately useable by the RedCap UE.

[0126] If the RACH procedure is successful, the RedCap UE concludes that the target NR cell is a RedCap cell and proceeds to camp on and use the target NR cell going forward.

[0127] Alternatively, if the RACH procedure is a four-step RACH procedure, and the UE determines that the four-step RACH procedure fails at a Msg3 of the four-step RACH procedure, the UE determines that the target NR cell is a non-RedCap cell. Or, if the RACH procedure is a two-step RACH procedure, and the UE determines that the two-step RACH procedure fails at a MsgA of the two-step RACH procedure, the UE determines that the target NR cell is a non-RedCap cell.

[0128] Upon RACH failure, the UE will blacklist the target NR cell for purposes of RedCap access / use. The UE then proceeds to declare a radio link failure (RLF) and perform a system scan on frequencies in the NR RAT in order to attempt to identify a RedCap cell of the NR RAT to which to connect. The frequencies scanned may be frequencies that a RedCap frequency listing (e.g., frequencies for which a redCapAccessAllowed field in the (e.g., cached) SIB4 of the NR RAT) indicates that the RedCap UE is allowed to access, as is described herein.

[0129] If the UE identifies any NR cell (s) using frequency (s) found in the RedCap frequency listing according to this system scan, the UE then performs system selection to the highest energy such NR cell that also includes a redCap-ConfigCommon IE in its SIB1 (and is therefore suitable) .

[0130] It is noted that existing algorithms are designed to perform cell search in a source RAT after a UE declares an RLF. Accordingly, one difference between embodiments discussed herein and such existing algorithms is that the RedCap UE performs a search for suitable cell (s) in the target RAT (in this example embodiment, in NR RAT) after the RedCap UE declares a RLF.

[0131] If no suitable cell is found according to the system scan, then the UE will fallback to LTE RAT. In some cases, the UE may also start a blacklist timer corresponding to the NR RAT. This blacklist timer may be configured to prevent the UE from immediately re-attempting the handover to NR, thereby saving UE power, processing, and / or communication resources.

[0132] In some circumstances, it may be beneficial for a RedCap UE to perform handover to a known RedCap cell without waiting for a handover command. This may be done at the RedCap UE in cases where, as illustrated in FIG. 10A, the LTE base station has not configured any B1 and / or B2 measurement reporting event (s) to the RedCap UE, and / or where no handover command has otherwise been received at the RedCap UE.

[0133] For example, FIG. 10A illustrates that the RedCap UE may be configured to determine 1024 whether (e.g., based on an RCPCD, as is described herein) it is aware of a suitable NR cell at the present location of the RedCap UE. If so, the UE may simply proceed 1026 to perform a local release in LTE and perform the L2NR reselection to the RedCap capable cell (e.g., after verifying that the SIB1 for the cell includes a redCap-ConfigCommon IE) .

[0134] Embodiments for RedCap Network Energy Saving (NES) considerations

[0135] It is contemplated that in various contexts of successful handovers to a RedCap cell (including, but not limited to, those provided in embodiments described herein) , it may be beneficial to have the RedCap UE check whether its new RedCap cell has enabled NES. When NES is enabled, a cell operates in a reduced power mode that may ultimately have impacts on data transfer characteristics to / from the RedCap UE through that cell that may be undesirable in at least some circumstances.

[0136] Accordingly, once a RedCap UE has handed over to a RedCap cell, the RedCap UE may determine 1018 whether the RedCap cell has enabled NES by evaluating whether the NR base station for the cell configures the RedCap UE with a discontinuous transmission (DTX)  / discontinuous reception (DRX) configuration having both active periods and non-active periods. Note that this DTX / DRX configuration may be delivered to the RedCap UE from the NR base station via UE-specific RRC signaling, via a SIB having the cell DTX / DRX configuration, and / or via dynamic L1 / L2 signaling.

[0137] If the RedCap UE determines that the RedCap cell has not enabled NES, then the RedCap UE continues 1020 operation on the RedCap cell.

[0138] If the RedCap UE instead determines that the RedCap cell has enabled NES, then the RedCap UE proceeds 1022 to determine whether the RedCap UE is in need of high performance data. If the RedCap UE does need high performance data (and is not itself in a power saving mode) , then the RedCap UE skips the NES cell and switches to a non-NES cell. For example, the RedCap UE may perform a local release and reselect to another RedCap cell at the location of the RedCap UE.

[0139] If the RedCap UE is not in need of high performance data (and / or if the RedCap UE is itself in a power saving mode) , then the RedCap UE may stay in the current RedCap cell that has enabled NES. In such a case, the RedCap UE adapts to / operates according to the DTX / DRX settings of the current RedCap cell as received.

[0140] In some embodiments, when the network configures measurement for handover, the RedCap UE detects some candidates. If the candidates are in an RCPCD used by the UE, the UE may report measurements of these candidates (or, in some cases high priority ones of these as may be indicated in an RCPCD) in the measurement report, and may prune other non-RCPCD cells from the measurement report. If none of the candidates are in the RCPCD, the UE may generate a measurement report for all of the candidates.

[0141] When an RRC reconfiguration for handover is received at the RedCap UE (e.g., in response to the measurement report) , if the target cell configuration indicates any barring information related to a RedCap configuration used by the RedCap UE, any handover attempt to the target cell may be avoided, and the RedCap UE may try to reestablish a connection to the network.

[0142] For example, if, after searching the remaining cells in the RCPCD (that are not the network configured frequency) any RedCap cell is detected, the UE may trigger a  reestablishment procedure on the detected cell and / or update the RCPCD with detected cell information corresponding to the cell.

[0143] As another example, if, after searching for any non-RCPCD cell, any such cell is detected, if the detected cell uses a RedCap Msg1 / MsgA RACH configuration and no barring for the cell applies to the RedCap configuration used by the RedCap UE, the RedCap UE may trigger a reestablishment procedure on the detected cell and / or the UE may update the RCPCD with information corresponding to the detected cell.

[0144] If, on the other hand, the detected cell uses non-RedCap Msg1 / MsgA configurations (such that the RedCap UE cannot be sure whether the cell is a RedCap Cell based on a SIB) , the UE may trigger a reestablishment procedure on the detected cell. In such cases, if the RACH procedure fails at Msg3 / MsgA (e.g., no responsive Msg4 / MsgB received is received within a time threshold X) , the UE may determine that the cell is a non-RedCap cell. If the RACH procedure is instead successful and a RedCap configuration is received at the UE, the UE may consider the cell as RedCap cell and / or may update the RCPCD with information corresponding to the cell.

[0145] If no available cell is detected, the RedCap UE may perform reestablishment back to the original LTE cell or fallback to another / any other LTE cell if the original cell is unavailable.

[0146] Note that in cases where an RRC reconfiguration for a handover of the RedCap UE indicates an available RedCap configuration at the target cell, the UE may simply proceed to perform handover to the target cell.

[0147] Embodiments for Handover between Dynamic Standalone (SA) and SA RedCap Based on Conditions

[0148] A RedCap UE can be identified by the network during a random access procedure based on a Msg3 / MsgA that uses a RedCap-specific logical channel ID (s) (LCID (s) ) , and optionally based on a Msg1 / MsgA that uses a RedCap-specific PRACH occasion and / or a RedCap-specific PRACH preamble. For RedCap UE identification via Msg1 / MsgA, a RedCap-specific random access configuration may be configured by the network. For Msg3 / MsgA, a RedCap UE may identified based on the dedicated LCID (s) indicated for CCCH identification (common control channel (CCCH) or CCCH1) , regardless of whether any RedCap specific random access configuration is / has been configured by the network.

[0149] Some UEs are capable of operating as both a non-RedCap UE (e.g., in non-RedCap NR SA) and as a RedCap UE. For such UE, it may be beneficial to identify conditions where such a UE can be appropriately served on a RedCap basis and to put the UE into a RedCap mode in such conditions. This may, for example, reduce a power use of the UE.

[0150] FIG. 11 illustrates a table 1102 describing various conditions 1104 through 1118 under which it may be the case that a UE capable of optionally operating as a RedCap UE may be beneficially operated in a RedCap mode, according to embodiments herein. A first condition 1104 relates to a marginal coverage scenario of the UE. When in marginal coverage, it may be that the UE in any case will not receive a sufficiently marginal throughput benefit for operating in a non-RedCap SA mode as compared to in a RedCap mode. Accordingly, it may be that the RedCap mode is used at the UE for power saving purposes.

[0151] A second condition 1106 relates to a scenario where no user data has been sent and / or received for a defined period (e.g., for “x" minutes as shown in FIG. 11) . Under such circumstances, it may be considered unlikely that the UE needs a relatively higher throughput corresponding to operation in a non-RedCap SA mode as compared to operation in a RedCap mode (because the user of the UE has a recent history of not using the UE at such data levels) . Accordingly, it may be that the RedCap mode is used at the UE in this scenario for power saving purposes.

[0152] A third condition 1108 corresponds to a scenario where a display screen of the UE has been off for a defined period (e.g., for “y" minutes as shown in FIG. 11) . Under such circumstances, it may be considered unlikely that the UE needs a relatively higher throughput corresponding to operation in a non-RedCap SA mode as compared to operation in a RedCap mode (because the user is not actively operating the UE via the display screen to perform network-communication-related tasks) . Accordingly, it may be that the RedCap mode is used at the UE in this scenario for power saving purposes.

[0153] A fourth condition 1110 corresponds to a scenario where it is a certain time of day (e.g., it is nighttime, as shown in FIG. 11) . Under such circumstances, it may be considered unlikely that the UE needs a relatively higher throughput corresponding to operation in a non-RedCap SA mode as compared to operation in a RedCap mode (e.g., it may be assumed that user of the UE unlikely to use the UE at that time and therefore  that the UE is unlikely to use many network resources) . Accordingly, it may be that the RedCap mode is used at the UE in this scenario for power saving purposes.

[0154] A fifth condition 1112 corresponds to a scenario where a battery of the UE is below a certain level (e.g., it is below a certain percentage, as shown in FIG. 11) . Under such circumstances, the power savings achieved by operation in a RedCap mode as opposed to in a non-RedCap SA mode may be considered relatively more important than benefits from operating in the non-RedCap SA mode. Accordingly, it may be that the RedCap mode is used at the UE in this scenario for power saving purposes.

[0155] A sixth condition 1114 corresponds to a scenario where the UE is along a known route (e.g., traveling from a user's home to a user's office, as shown in FIG. 11) . Under such circumstances, it may be considered unlikely that the UE needs a relatively higher throughput corresponding to operation in a non-RedCap SA mode as compared to operation in a RedCap mode (e.g., it may be assumed that user of the UE is busy and therefore that the UE is unlikely to use many network resources) . Accordingly, it may be that the RedCap mode is used at the UE in this scenario for power saving purposes.

[0156] A seventh condition 1116 corresponds to a scenario where the UE is in a fixed location (e.g., in a gym or an office, as shown in FIG. 11) . Under such circumstances, it may be considered unlikely that the UE needs a relatively higher throughput corresponding to operation in a non-RedCap SA mode as compared to operation in a RedCap mode (e.g., because of an assumption of availability of a local area network (LAN) at that location through which appropriate throughput can be achieved) . Accordingly, it may be that the RedCap mode is used at the UE in this scenario for power saving purposes.

[0157] An eighth condition 1118 corresponds to a scenario where the UE is along a fixed route (e.g., along a jogging route of the user, as shown in FIG. 11) . Under such circumstances, it may be considered unlikely that the UE needs a relatively higher throughput corresponding to operation in a non-RedCap SA mode as compared to operation in a RedCap mode (e.g., it may be assumed that user of the UE is busy and therefore that the UE is unlikely to use many network resources) . Accordingly, it may be that the RedCap mode is used at the UE in this scenario for power saving purposes. Note that the eighth condition 1118 may correspond to a fixed route that is, for example, of a lower speed class and / or a smaller distance class than known routes described above for cases corresponding to the sixth condition 1114.

[0158] FIG. 12A and FIG. 12B together illustrate a method 1202 for handover between non-RedCap NR SA to SA RedCap (e.g., to an SA RedCap cell) based on conditions, according to embodiments herein. The method 1202 may be performed by a UE that is capable of operating in both non-RedCap NR SA and as a RedCap UE.

[0159] As illustrated, the method 1202 at first in large part follows the method 802 as described in relation to FIG. 8 for the use of system information to determine whether the UE may connect to an NR cell according to a RedCap configuration. Note that with respect to this embodiment, the method 1202 presupposes 1204 both that the UE is RedCap capable and that it is currently camped to a non-RedCap NR SA cell. Further note that details for portions of the method 1202 corresponding to reference numbers 806, 808, 810, 812, 814, 816, 818, and 820 should be understood as was correspondingly described in relation to FIG. 8.

[0160] Turning to FIG. 12B: after determining that the UE can connect to the cell according to a RedCap configuration (that the cell is a RedCap cell) , the UE evaluates 1206 whether there is an ongoing voice call at the UE. If so, the UE determines 1208 to continue operating in the non-RedCap NR SA cell in order to ensure that no interruption occurs to the voice call as a result of a handover to the RedCap cell.

[0161] If there is not an ongoing voice call at the UE, the UE then evaluates 1210 whether a condition for switching to the RedCap cell have been met. The condition may be, for example, one of the first condition 1104, the second condition 1106, the third condition 1108, the fourth condition 1110, the fifth condition 1112, the sixth condition 1114, the seventh condition 1116, and / or the eighth condition 1118 as were discussed in relation to FIG. 11. Note that these conditions are given by way of example and not by way of limitation.

[0162] If no condition for switching to the RedCap cell has been met, the UE determines 1208 to continue operating in the non-RedCap NR SA cell in order to ensure that no interruption of data transfer occurs at the UE as a result of the handover to the RedCap cell.

[0163] The UE then determines 1212 whether the RedCap cell has enabled NES by evaluating whether the NR base station for the cell configured a discontinuous transmission (DTX) and / or a discontinuous reception (DRX) configuration having both active periods and non-active periods. Note that DTX and / or DRX configuration may be delivered to the RedCap UE from the NR base station via UE-specific RRC signaling,  via a SIB having the cell DTX and / or DRX configuration, and / or via dynamic L1 / L2 signaling. If the RedCap cell has enabled NES, the UE determines 1208 to continue operating in the non-RedCap NR SA cell in order to avoid operation according to the NES mode in the RedCap cell.

[0164] If the RedCap cell has not enabled NES, then the UE declares 1214 RLF preparatory to switching from the non-RedCap NR SA cell to the RedCap cell. This puts the UE in condition to perform a fresh registration procedure with the RedCap cell.

[0165] The UE then performs 1216 a RACH procedure with the RedCap cell. As part of this RACH procedure, the UE may optionally send a Msg1 / MsgA with a RedCap specific random access preamble. As a further part of the RACH procedure, the UE sends a Msg3 / MsgB with a logical channel identifier (LCID) that is dedicated for RedCap.

[0166] Embodiments for Smart Requested Network Slice Selection Assistance Information (NSSAI) for RedCap

[0167] In some wireless systems, a RedCap UE may support up to 8 DRBs. Further, 2 of these DRBs may be utilized in SA mode for an enhanced mobile broadband (eMBB) slice (e.g., used respectively as a DRB for internet data and a DRB for internet protocol (IP) multimedia subsystem (IMS) data) .

[0168] In such a scenario, up to 6 more DRBs are available to be utilized at the RedCap UE. As each potential slice beyond the eMBB slice would use at minimum one of these 6 DRBs, it can thus be seen that in such circumstances the RedCap UE can only actually use up to 7 total network slices (the eMBB slice and up to 6 additional slices for the up to 6 additional DRBs) . Accordingly, it may be considered inefficient for the RedCap UE to request 8 total slices in a requested NSSAI. Thus, mechanisms discussed herein for use at a RedCap UE may be optimized to reduce a requested NSSAI and / or an allowed NSSAI size at the RedCap UE from existing cases (which may be configured assuming a potential use of more than 7 slices) .

[0169] For example, in some embodiments, the UE may populate 7 instances of single network slice selection assistance information (S-NSSAI (s) ) at maximum in a requested NSSAI. Further, in some embodiments, based on UE route selection policy (URSP) rules, the UE may filter a request NSSAI.

[0170] FIG. 13 illustrates a method 1302 of a RedCap UE, according to embodiments herein. The method 1302 presupposes 1304 that the UE in question is RedCap capable (that the UE is a RedCap UE) .

[0171] The RedCap UE then determines 1306 whether it is trying to register to a cell corresponding to network slicing use (e.g., an NR SA cell, as illustrated) , which may be the case in, for example, cases of L2NR handover (among other cases) .

[0172] If so, the RedCap UE then determines whether it supports IMS. If the RedCap UE does not support IMS, the RedCap UE proceeds 1308 to populate up to 8 S-NSSAIs. This is because without IMS, the eMBB slice uses only 1 DRB for internet data. Accordingly, 7 DRBs remain available for distribution between up to 7 additional slices.

[0173] If the RedCap UE does support IMS, the RedCap UE proceeds 1310 to populate up to 7 S-NSSAIs. This is because with IMS, the eMBB slice uses 2 DRBs, one for internet data and one for IMS data. Accordingly, only 6 DRBs remain available for distribution between up to 6 additional slices. In such cases, as illustrated, there is no advantage to populating a requested NSSAI information with 8 S-NSSAIs, so the UE may instead use a maximum of 7 total S-NSSAIs in requested NSSAI information.

[0174] Embodiments of Smart PDU Release Optimization in RedCap Maximum DRB Scenarios

[0175] In some cases, 8 DRBs may be setup for a RedCap UE (which may not support more than 8 DRBs, as is described elsewhere herein) . It is contemplated that a RedCap UE operating in these circumstances may invoke a new application (or in other words a supplementary service) which needs a new data network name (DNN) . This procedure corresponds to the use of a PDU session and a new DRB. Accordingly, the UE may be configured to release a current DRB and to setup a new DRB for an extensible markup language (XML) configuration access protocol (XCAP) DNN.

[0176] Accordingly, in some embodiments, when 8 DRBs are setup and running, and the RedCap UE initiates a mandatory service which calls for a new PDU Session (DNN) and thus a new DRB (e.g., a supplementary service via XCAP DNN) , the UE may identify a low-priority DRB to teardown / suspend prior to the setup of a new DRB for XCAP DNN. Then, after the XCAP service is completed, the corresponding PDU may be released (e.g., after 4 minutes, in some UE implementations) , and the UE may proceed to attempt to re-establish the DRB which was earlier torn down / suspended.

[0177] In some cases, the low-priority DRBs in a RedCap context may be identified based on the following: first, any PDU session which could be re-routed via the default internet PDU session; then, any PDU session with low user plane data usage for a past period of time (for example, for the past 4 minutes) ; and finally, any PDU session which has been dormant the longest.

[0178] General RAT Type Considerations

[0179] Various embodiments herein are discussed in the context of particular RAT types (e.g., LTE, NR) . Discussion with respect to these particular RAT type (s) is presented for purposes of illustration, and is not intended to be understood by way of limitation. It will be understood that the principles discussed in relation to various embodiments could be applied in other RAT type context (s) where analogous considerations to those described with respect to the example RAN type (s) expressly under discussion apply.

[0180] FIG. 14 illustrates a method 1400 of a UE, according to embodiments discussed herein. The method 1400 includes receiving 1402, from a first base station of a first RAN that uses a first RAT, a configuration for an inter-RAT measurement reporting event that identifies, for the inter-RAT measurement reporting event, an MO of a second RAN that uses a second RAT. The method 1400 further includes identifying 1404 that the MO of the second RAN corresponds to a RedCap frequency identified in a RedCap frequency listing for the second RAN. The method 1400 further includes measuring 1406 the MO of the second RAN based on the identifying that the MO corresponds to the RedCap frequency identified in the RedCap frequency listing for the second RAN.

[0181] In some embodiments, the method 1400 further includes receiving, from a second base station of the second RAN, in a SIB, the RedCap frequency listing for the second RAN; and storing the RedCap frequency listing for the second RAN.

[0182] In some embodiments, the method 1400 further includes determining, based on the measuring of the MO, that the inter-RAT measurement reporting event has occurred; determining, based on a database stored at the UE, that the MO corresponds to a first RedCap cell of the second RAN that provides coverage at a location of the UE; and sending, to the first base station of the first RAN, a measurement report that includes only one or more measurement results for one or more RedCap cells, the one or more  measurement results including a first measurement result for the first RedCap cell corresponding to the MO.

[0183] In some embodiments, the method 1400 further includes determining, based on the measuring of the MO, that the inter-RAT measurement reporting event has occurred; determining, based on a database stored at the UE, that the UE does not know whether there is a RedCap cell corresponding to the MO that provides coverage at a location of the UE; and sending, to the first base station of the first RAN, a measurement report that includes one or more measurement results for one or more candidate cells measured by the UE, the one or more candidate cells including a first candidate cell corresponding to the MO.

[0184] In some embodiments of the method 1400, the first RAT comprises LTE, and wherein the second RAT comprises NR.

[0185] In some embodiments of the method 1400, the inter-RAT measurement reporting event comprises a determination of whether a result of measuring the MO of the second RAN is greater than a threshold.

[0186] In some embodiments of the method 1400, the inter-RAT measurement reporting event comprises a first determination of whether a first result of measuring a current serving cell of the first RAN is worse than a first threshold and a second determination of whether a second result of measuring the MO of the second RAN is greater than a second threshold.

[0187] FIG. 15 illustrates a method 1500 of a UE, according to embodiments discussed herein. The method 1500 includes receiving 1502, from a first base station of a first RAN that uses a first RAT, a configuration for an inter-RAT measurement reporting event that identifies, for the inter-RAT measurement reporting event, an MO of a second RAN that uses a second RAT. The method 1500 further includes identifying 1504 that the MO of the second RAN does not correspond to any RedCap frequency identified in a RedCap frequency listing for the second RAN. The method 1500 further includes dropping 1506 a measurement of the MO of the second RAN based on the identifying that the MO does not correspond to any RedCap frequency identified in the RedCap frequency listing for the second RAN.

[0188] In some embodiments, the method 1500 further includes receiving, from a second base station of the second RAN, in a SIB, the RedCap frequency listing for the second RAN; and storing the RedCap frequency listing for the second RAN.

[0189] In some embodiments of the method 1500, the first RAT comprises LTE, and wherein the second RAT comprises NR.

[0190] In some embodiments of the method 1500, the inter-RAT measurement reporting event comprises a determination of whether a result of measuring the MO of the second RAN is greater than a threshold.

[0191] In some embodiments of the method 1500, the inter-RAT measurement reporting event comprises a first determination of whether a first result of measuring a current serving cell of the first RAN is worse than a first threshold and a second determination of whether a second result of measuring the MO of the second RAN is greater than a second threshold.

[0192] FIG. 16 illustrates a method 1600 of a UE, according to embodiments discussed herein. The method 1600 includes receiving 1602, from a first base station of a first RAN that uses a first RAT, an RRC reconfiguration message instructing the UE to perform a handover to a target cell of a second RAN that uses a second RAT. The method 1600 further includes determining 1604 that the target cell is a non-RedCap cell. The method 1600 further includes declaring 1606 an RLF in response to the determining that the target cell is the non-RedCap cell. The method 1600 further includes performing 1608, in response to the RLF, a system scan of the second RAN that uses the second RAT to attempt to identify a suitable RedCap cell of the second RAN.

[0193] In some embodiments of the method 1600, the determining that the target cell is the non-RedCap cell comprises identifying that a RACH configuration for the target cell found in the RRC reconfiguration message is not a RedCap RACH configuration.

[0194] In some embodiments of the method 1600, the determining that the target cell is the non-RedCap cell comprises: initiating a four-step random access channel (RACH) procedure corresponding to a RACH configuration for the target cell found in the RRC reconfiguration message; and identifying that a failure of the four-step RACH procedure corresponds to a transmission of a Message 3 of the four-step RACH procedure.

[0195] In some embodiments of the method 1600, the determining that the target cell is the non-RedCap cell comprises: initiating a two-step random access channel (RACH) procedure corresponding to a RACH configuration for the target cell found in the RRC reconfiguration message; and identifying that a failure of the two-step RACH procedure corresponds to a transmission of a Message A of the two-step RACH procedure.

[0196] In some embodiments of the method 1600, the performing the system scan of the second RAN comprises performing measurements on one or more RedCap frequencies identified in a RedCap frequency listing for the second RAN. In some of these embodiments, the method 1600 further includes receiving, from a second base station of the second RAN, the RedCap frequency listing for the second RAN; and storing the RedCap frequency listing for the second RAN.

[0197] In some embodiments, the method 1600 further includes identifying, based on the system scan, the suitable RedCap cell of the second RAN; and performing a system selection to the suitable RedCap cell of the second RAN.

[0198] In some embodiments, the method 1600 further includes failing to identify, based on the system scan, the suitable RedCap cell of the second RAN; and starting a blacklist timer corresponding to the second RAT.

[0199] In some embodiments of the method 1600, the first RAT comprises LTE, and wherein the second RAT comprises NR.

[0200] FIG. 17 illustrates a method 1700 of a UE, according to embodiments discussed herein. The method 1700 includes performing 1702 a handover to a RedCap cell. The method 1700 further includes determining 1704 that the RedCap cell has enabled NES. The method 1700 further includes determining 1706 that the UE is in need of high performance data. The method 1700 further includes performing 1708 reselection to another RedCap cell in response to determining that the RedCap cell has enabled NES and that the UE is in need of high performance data.

[0201] In some embodiments of the method 1700, the determining that the RedCap cell has enabled NES comprises determining that the RedCap cell uses a DTX / DRX configuration having both active periods and non-active periods. In some such embodiments, the DTX / DRX configuration is received at the UE in UE-specific RRC signaling. In some such embodiments, the DTX / DRX configuration is received at the UE in a SIB. In some such embodiments, the DTX / DRX configuration is received at the UE in dynamic L1 / L2 signaling.

[0202] FIG. 18 illustrates a method 1800 of a UE, according to embodiments discussed herein. The method 1800 includes determining 1802, based on a database stored at the UE, that a RedCap cell of a second RAN that uses a second RAT provides coverage at a location of the UE. The method 1800 further includes determining 1804 that the RedCap cell corresponds to a RedCap frequency identified in a RedCap frequency listing for the  second RAN. The method 1800 further includes performing 1806 handover to the RedCap cell of the second RAN in response to the determining that the RedCap cell provides coverage at the location of the UE and the determining that the RedCap cell corresponds to the RedCap frequency identified in the RedCap frequency listing for the second RAN.

[0203] In some embodiments of the method 1800, the first RAT comprises LTE, and wherein the second RAT comprises NR.

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

[0205] As shown by FIG. 19, the wireless communication system 1900 includes UE 1902 and UE 1904 (although any number of UEs may be used) . In this example, the UE 1902 and the UE 1904 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.

[0206] The UE 1902 and UE 1904 may be configured to communicatively couple with a RAN 1906. In embodiments, the RAN 1906 may be NG-RAN, E-UTRAN, etc. The UE 1902 and UE 1904 utilize connections (or channels) (shown as connection 1908 and connection 1910, respectively) with the RAN 1906, each of which comprises a physical communications interface. The RAN 1906 can include one or more base stations (such as base station 1912 and base station 1914) that enable the connection 1908 and connection 1910.

[0207] In this example, the connection 1908 and connection 1910 are air interfaces to enable such communicative coupling, and may be consistent with RAT (s) used by the RAN 1906, such as, for example, an LTE and / or NR.

[0208] In some embodiments, the UE 1902 and UE 1904 may also directly exchange communication data via a sidelink interface 1916. The UE 1904 is shown to be configured to access an access point (shown as AP 1918) via connection 1920. By way of example, the connection 1920 can comprise a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, wherein the AP 1918 may  comprise a router. In this example, the AP 1918 may be connected to another network (for example, the Internet) without going through a CN 1924.

[0209] In embodiments, the UE 1902 and UE 1904 can be configured to communicate using orthogonal frequency division multiplexing (OFDM) communication signals with each other or with the base station 1912 and / or the base station 1914 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.

[0210] In some embodiments, all or parts of the base station 1912 or base station 1914 may be implemented as one or more software entities running on server computers as part of a virtual network. In addition, or in other embodiments, the base station 1912 or base station 1914 may be configured to communicate with one another via interface 1922. In embodiments where the wireless communication system 1900 is an LTE system (e.g., when the CN 1924 is an EPC) , the interface 1922 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. In embodiments where the wireless communication system 1900 is an NR system (e.g., when CN 1924 is a 5GC) , the interface 1922 may be an Xn interface. The Xn interface is defined between two or more base stations (e.g., two or more gNBs and the like) that connect to 5GC, between a base station 1912 (e.g., a gNB) connecting to 5GC and an eNB, and / or between two eNBs connecting to 5GC (e.g., CN 1924) .

[0211] The RAN 1906 is shown to be communicatively coupled to the CN 1924. The CN 1924 may comprise one or more network elements 1926, which are configured to offer various data and telecommunications services to customers / subscribers (e.g., users of UE 1902 and UE 1904) who are connected to the CN 1924 via the RAN 1906. The components of the CN 1924 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) .

[0212] In embodiments, the CN 1924 may be an EPC, and the RAN 1906 may be connected with the CN 1924 via an S1 interface 1928. In embodiments, the S1 interface 1928 may be split into two parts, an S1 user plane (S1-U) interface, which carries traffic data between the base station 1912 or base station 1914 and a serving gateway (S-GW) , and the S1-MME interface, which is a signaling interface between the base station 1912 or base station 1914 and mobility management entities (MMEs) .

[0213] In embodiments, the CN 1924 may be a 5GC, and the RAN 1906 may be connected with the CN 1924 via an NG interface 1928. In embodiments, the NG interface 1928 may be split into two parts, an NG user plane (NG-U) interface, which carries traffic data between the base station 1912 or base station 1914 and a user plane function (UPF) , and the S1 control plane (NG-C) interface, which is a signaling interface between the base station 1912 or base station 1914 and access and mobility management functions (AMFs) .

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

[0215] FIG. 20 illustrates a system 2000 for performing signaling 2032 between a wireless device 2002 and a network device 2018, according to embodiments disclosed herein. The system 2000 may be a portion of a wireless communications system as herein described. The wireless device 2002 may be, for example, a UE of a wireless communication system. The network device 2018 may be, for example, a base station (e.g., an eNB or a gNB) of a wireless communication system.

[0216] The wireless device 2002 may include one or more processor (s) 2004. The processor (s) 2004 may execute instructions such that various operations of the wireless device 2002 are performed, as described herein. The processor (s) 2004 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.

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

[0218] The wireless device 2002 may include one or more transceiver (s) 2010 that may include radio frequency (RF) transmitter circuitry and / or receiver circuitry that use the antenna (s) 2012 of the wireless device 2002 to facilitate signaling (e.g., the signaling 2032) to and / or from the wireless device 2002 with other devices (e.g., the network device 2018) according to corresponding RATs.

[0219] The wireless device 2002 may include one or more antenna (s) 2012 (e.g., one, two, four, or more) . For embodiments with multiple antenna (s) 2012, the wireless device 2002 may leverage the spatial diversity of such multiple antenna (s) 2012 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 2002 may be accomplished according to precoding (or digital beamforming) that is applied at the wireless device 2002 that multiplexes the data streams across the antenna (s) 2012 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) .

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

[0221] The wireless device 2002 may include one or more interface (s) 2014. The interface (s) 2014 may be used to provide input to or output from the wireless device  2002. For example, a wireless device 2002 that is a UE may include interface (s) 2014 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 transmitters, receivers, and other circuitry (e.g., other than the transceiver (s) 2010 / antenna (s) 2012 already described) that allow for communication between the UE and other devices and may operate according to known protocols (e.g.,  and the like) .

[0222] The wireless device 2002 may include a RedCap module 2016. The RedCap module 2016 may be implemented via hardware, software, or combinations thereof. For example, the RedCap module 2016 may be implemented as a processor, circuit, and / or instructions 2008 stored in the memory 2006 and executed by the processor (s) 2004. In some examples, the RedCap module 2016 may be integrated within the processor (s) 2004 and / or the transceiver (s) 2010. For example, the RedCap module 2016 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) 2004 or the transceiver (s) 2010.

[0223] The RedCap module 2016 may be used for various aspects of the present disclosure, for example, aspects of FIG. 1 through FIG. 18. In some embodiments, the RedCap module 2016 may configure the wireless device 2002 to for example, perform handover (including, but not limited to, inter-RAT handover operations) with respect to RedCap, NES, etc. ; to perform condition-based switching to a RedCap cell, as described herein; to request NSSAI (s) in the manners described herein; and / or to perform DRB release in the manners described herein.

[0224] The network device 2018 may include one or more processor (s) 2020. The processor (s) 2020 may execute instructions such that various operations of the network device 2018 are performed, as described herein. The processor (s) 2020 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.

[0225] The network device 2018 may include a memory 2022. The memory 2022 may be a non-transitory computer-readable storage medium that stores instructions 2024 (which may include, for example, the instructions being executed by the processor (s) 2020) . The instructions 2024 may also be referred to as program code or a computer  program. The memory 2022 may also store data used by, and results computed by, the processor (s) 2020.

[0226] The network device 2018 may include one or more transceiver (s) 2026 that may include RF transmitter circuitry and / or receiver circuitry that use the antenna (s) 2028 of the network device 2018 to facilitate signaling (e.g., the signaling 2032) to and / or from the network device 2018 with other devices (e.g., the wireless device 2002) according to corresponding RATs.

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

[0228] The network device 2018 may include one or more interface (s) 2030. The interface (s) 2030 may be used to provide input to or output from the network device 2018. For example, a network device 2018 that is a base station may include interface (s) 2030 made up of transmitters, receivers, and other circuitry (e.g., other than the transceiver (s) 2026 / antenna (s) 2028 already described) that enables the base station to communicate with other equipment in a core network, 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.

[0229] Embodiments contemplated herein include an apparatus comprising means to perform one or more elements of any one or more of the method 1400, the method 1500, the method 1600, the method 1700, and / or the method 1800. This apparatus may be, for example, an apparatus of a UE (such as a wireless device 2002 that is a UE, as described herein) .

[0230] 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 1400, the method 1500, the method 1600, the method 1700, and / or the method 1800. This non-transitory computer-readable media may be, for example, a memory of a UE (such as a memory 2006 of a wireless device 2002 that is a UE, as described herein) .

[0231] 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 1400, the method 1500, the method 1600, the method 1700, and / or the method 1800. This apparatus may be, for example, an apparatus of a UE (such as a wireless device 2002 that is a UE, as described herein) .

[0232] 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 1400, the method 1500, the method 1600, the method 1700, and / or the method 1800. This apparatus may be, for example, an apparatus of a UE (such as a wireless device 2002 that is a UE, as described herein) .

[0233] Embodiments contemplated herein include a signal as described in or related to one or more elements of any one or more of the method 1400, the method 1500, the method 1600, the method 1700, and / or the method 1800.

[0234] 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 1400, the method 1500, the method 1600, the method 1700, and / or the method 1800. The processor may be a processor of a UE (such as a processor (s) 2004 of a wireless device 2002 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 2006 of a wireless device 2002 that is a UE, as described herein) .

[0235] 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.

[0236] 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.

[0237] 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.

[0238] 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.

[0239] 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.

[0240] 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 user equipment (UE) that is operable in a reduced capability (RedCap) mode, comprising:receiving, from a first base station of a first radio access network (RAN) that uses a first radio access technology (RAT) , a configuration for an inter-RAT measurement reporting event that identifies, for the inter-RAT measurement reporting event, a measurement object (MO) of a second RAN that uses a second RAT;identifying that the MO of the second RAN corresponds to a RedCap frequency identified in a RedCap frequency listing for the second RAN; andmeasuring the MO of the second RAN based on the identifying that the MO corresponds to the RedCap frequency identified in the RedCap frequency listing for the second RAN.2.The method of claim 1, further comprising:receiving, from a second base station of the second RAN, in a system information block (SIB) , the RedCap frequency listing for the second RAN; andstoring the RedCap frequency listing for the second RAN.3.The method of claim 1, further comprising:determining, based on the measuring of the MO, that the inter-RAT measurement reporting event has occurred;determining, based on a database stored at the UE, that the MO corresponds to a first RedCap cell of the second RAN that provides coverage at a location of the UE; andsending, to the first base station of the first RAN, a measurement report that includes only one or more measurement results for one or more RedCap cells, the one or more measurement results including a first measurement result for the first RedCap cell corresponding to the MO.4.The method of claim 1, further comprising:determining, based on the measuring of the MO, that the inter-RAT measurement reporting event has occurred;determining, based on a database stored at the UE, that the UE does not know whether there is a RedCap cell corresponding to the MO that provides coverage at a location of the UE; andsending, to the first base station of the first RAN, a measurement report that includes one or more measurement results for one or more candidate cells measured by the UE, the one or more candidate cells including a first candidate cell corresponding to the MO.5.The method of claim 1, wherein the first RAT comprises LTE, and wherein the second RAT comprises NR.6.The method of claim 1, wherein the inter-RAT measurement reporting event comprises a determination of whether a result of measuring the MO of the second RAN is greater than a threshold.7.The method of claim 1, wherein the inter-RAT measurement reporting event comprises a first determination of whether a first result of measuring a current serving cell of the first RAN is worse than a first threshold and a second determination of whether a second result of measuring the MO of the second RAN is greater than a second threshold.8.A method of a user equipment (UE) that is operable in a reduced capability (RedCap) mode, comprising:receiving, from a first base station of a first radio access network (RAN) that uses a first radio access technology (RAT) , a configuration for an inter-RAT measurement reporting event that identifies, for the inter-RAT measurement reporting event, a measurement object (MO) of a second RAN that uses a second RAT;identifying that the MO of the second RAN does not correspond to any RedCap frequency identified in a RedCap frequency listing for the second RAN; anddropping a measurement of the MO of the second RAN based on the identifying that the MO does not correspond to any RedCap frequency identified in the RedCap frequency listing for the second RAN.9.The method of claim 8, further comprising:receiving, from a second base station of the second RAN, in a system information block (SIB) , the RedCap frequency listing for the second RAN; andstoring the RedCap frequency listing for the second RAN.10.The method of claim 8, wherein the first RAT comprises LTE, and wherein the second RAT comprises NR.11.The method of claim 8, wherein the inter-RAT measurement reporting event comprises a determination of whether a result of measuring the MO of the second RAN is greater than a threshold.12.The method of claim 8, wherein the inter-RAT measurement reporting event comprises a first determination of whether a first result of measuring a current serving cell of the first RAN is worse than a first threshold and a second determination of whether a second result of measuring the MO of the second RAN is greater than a second threshold.13.A method of a user equipment (UE) that is operable in a reduced capability (RedCap) mode, comprising:receiving, from a first base station of a first radio access network (RAN) that uses a first radio access technology (RAT) , a radio resource control (RRC) reconfiguration message instructing the UE to perform a handover to a target cell of a second RAN that uses a second RAT;determining that the target cell is a non-RedCap cell;declaring a radio link failure (RLF) in response to the determining that the target cell is the non-RedCap cell; andperforming, in response to the RLF, a system scan of the second RAN that uses the second RAT to attempt to identify a suitable RedCap cell of the second RAN.14.The method of claim 13, wherein the determining that the target cell is the non-RedCap cell comprises identifying that a random access channel (RACH) configuration for the target cell found in the RRC reconfiguration message is not a RedCap RACH configuration.15.The method of claim 13, wherein the determining that the target cell is the non-RedCap cell comprises:initiating a four-step random access channel (RACH) procedure corresponding to a RACH configuration for the target cell found in the RRC reconfiguration message; andidentifying that a failure of the four-step RACH procedure corresponds to a transmission of a Message 3 of the four-step RACH procedure.16.The method of claim 13, wherein the determining that the target cell is the non-RedCap cell comprises:initiating a two-step random access channel (RACH) procedure corresponding to a RACH configuration for the target cell found in the RRC reconfiguration message; andidentifying that a failure of the two-step RACH procedure corresponds to a transmission of a Message A of the two-step RACH procedure.17.The method of claim 13, wherein performing the system scan of the second RAN comprises performing measurements on one or more RedCap frequencies identified in a RedCap frequency listing for the second RAN.18.The method of claim 17, further comprising:receiving, from a second base station of the second RAN, the RedCap frequency listing for the second RAN; andstoring the RedCap frequency listing for the second RAN.19.The method of claim 13, further comprising:identifying, based on the system scan, the suitable RedCap cell of the second RAN; andperforming a system selection to the suitable RedCap cell of the second RAN.20.The method of claim 13, further comprising:failing to identify, based on the system scan, the suitable RedCap cell of the second RAN; andstarting a blacklist timer corresponding to the second RAT.21.The method of claim 13, wherein the first RAT comprises LTE, and wherein the second RAT comprises NR.22.A method of a user equipment (UE) that is operable in a reduced capability (RedCap) mode, comprising:performing a handover to a RedCap cell;determining that the RedCap cell has enabled network energy savings (NES) ;determining that the UE is in need of high performance data; andperforming reselection to another RedCap cell in response to determining that the RedCap cell has enabled NES and that the UE is in need of high performance data.23.The method of claim 22, wherein the determining that the RedCap cell has enabled NES comprises determining that the RedCap cell uses a discontinuous transmission (DTX)  / discontinuous reception (DRX) configuration having both active periods and non-active periods.24.The method of claim 23, wherein the DTX / DRX configuration is received at the UE in UE-specific radio resource control (RRC) signaling.25.The method of claim 23, wherein the DTX / DRX configuration is received at the UE in a system information block (SIB) .26.The method of claim 23, wherein the DTX / DRX configuration is received at the UE in dynamic layer 1 (L1)  / layer 2 (L2) signaling.27.A method of a user equipment (UE) that is operable in a reduced capability (RedCap) mode and that is connected to a first radio access network (RAN) that uses a first radio access technology (RAT) , comprising:determining, based on a database stored at the UE, that a RedCap cell of a second RAN that uses a second RAT provides coverage at a location of the UE;determining that the RedCap cell corresponds to a RedCap frequency identified in a RedCap frequency listing for the second RAN; andperforming handover to the RedCap cell of the second RAN in response to the determining that the RedCap cell provides coverage at the location of the UE and the determining that the RedCap cell corresponds to the RedCap frequency identified in the RedCap frequency listing for the second RAN.28.The method of claim 27, wherein the first RAT comprises LTE, and wherein the second RAT comprises NR.29.An apparatus comprising means to perform the method of any of claim 1 to claim 28.30.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 28.31.An apparatus comprising logic, modules, or circuitry to perform the method of any of claim 1 to claim 28.

Images