Optimization for reduced capability user equipment

Abstract

Optimizations for reduced capability (RedCap) user equipments (UEs) are disclosed herein. Various embodiments relate to the case of inter-RAT handover of Radio Access Technology (RAT) using RedCap, wherein a RedCap UE uses system information to determine whether a particular measurement object (MO) corresponds (or does not correspond) to / may correspond to a RedCap cell in a target RAT. Various embodiments relate to a manner of radio link failure (RLF) recovery following a failed handover attempt by a RedCap UE to a non-RedCap cell. Various embodiments relate to UE identification and response to a handover to a RedCap cell that has enabled network energy savings (NES). Various embodiments relate to UE triggered handover to a RedCap cell. Various embodiments relate to a condition-based UE handover to a RedCap cell. Various embodiments relate to slicing requests in the RedCap UE context. Various embodiments relate to PDU release optimization within the RedCap UE context.

Description

Technical Field

[0001] This application relates in its entirety to wireless communication systems, including wireless communication systems for user equipment (UE) that operate in a reduced capability (RedCap) mode. Background Technology

[0002] Wireless mobile communication technologies use various standards and protocols to transmit data between base stations and wireless communication devices. For example, wireless communication system standards and protocols may include, for instance, 3GPP Long Term Evolution (LTE) (e.g., 4G), 3GPP New Radio (NR) (e.g., 5G), and the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard for Wireless Local Area Networks (WLANs) (often referred to as Wi-Fi within the industry organization). ® ).

[0003] As envisioned by 3GPP, different wireless communication system standards and protocols can use various radio access networks (RANs) for communication between RAN base stations (sometimes referred to as RAN nodes, network nodes, or simply nodes) and wireless communication equipment called user equipment (UEs). 3GPP RANs can include, for example, Global System for Mobile Communications (GSM), Enhanced Data Rate 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 can use one or more Radio Access Technologies (RATs) to perform communication between the base station and the UE. For example, GERAN implements the GSM and / or EDGE RAT, UTRAN implements the Universal Mobile Telecommunications System (UMTS) RAT or other 3GPP RATs, E-UTRAN implements the LTE RAT (sometimes simply referred to as LTE), and NG-RAN implements the NR RAT (this NR RAT is sometimes referred to herein as the 5G RAT, 5G NR RAT, or simply NR). In some deployments, E-UTRAN may also implement the NR RAT. In some deployments, NG-RAN may also implement the LTE RAT.

[0005] The base stations used by a RAN can correspond to that RAN. An example of an E-UTRAN base station is an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly referred to as Evolved Node B, Enhanced Node B, eNodeB, or eNB). An example of an NG-RAN base station is a Next Generation Node B (sometimes also called gNode B or gNB).

[0006] The RAN provides communication services to external entities through its connection with the core network (CN). For example, E-UTRAN can utilize the evolved packet core (EPC), while NG-RAN can utilize the 5G core network (5GC).

[0007] 5G NR frequency bands can be divided into two or more distinct frequency ranges. For example, Frequency Range 1 (FR1) may include bands operating at frequencies below 6 GHz, some of which are available for previous standards and can potentially be extended to cover new spectrum offerings from 410 MHz to 7125 MHz. Frequency Range 2 (FR2) may include bands from 24.25 GHz to 52.6 GHz. It should be noted that in some systems, FR2 may also include bands from 52.6 GHz to 71 GHz (or higher). Bands in the millimeter-wave (mmWave) range of FR2 may have smaller coverage areas but potentially higher available bandwidth than bands in FR1. Those skilled in the art will recognize that these frequency ranges, presented by way of example, may change over time or in different regions. Attached Figure Description

[0008] To facilitate the identification of any particular element or action in the discussion, one or more of the most significant digits in the figure reference numerals refer to the figure number in which the element was first introduced.

[0009] Figure 1 An example is illustrated of a portion of a first SIB that may be used in a wireless communication system operating according to an embodiment disclosed herein.

[0010] Figure 2 An example is illustrated of a portion of a second SIB that may be used in a wireless communication system operating according to the embodiments disclosed herein.

[0011] Figure 3 Examples are given of UEs that can be provided in wireless communication systems operating according to the embodiments disclosed herein. featureCombination Part of Internet Explorer.

[0012] Figure 4 Examples are given of UEs that can be provided in wireless communication systems operating according to the embodiments disclosed herein. posSI-RequestConfigRedCap Field.

[0013] Figure 5 Signaling diagrams for a four-step RACH process according to some implementation schemes are illustrated.

[0014] Figure 6 A signaling diagram illustrating a two-step RACH process according to some implementation schemes is shown.

[0015] Figure 7Examples are given of data that can be transmitted from the network to the RedCap UE in some wireless communication systems. BWP- UplinkCommon IE.

[0016] Figure 8 An example is illustrated of a method, according to an embodiment of this document, for determining whether a RedCap UE can connect to an NR cell based on its RedCap configuration, using system information received from the network at the RedCap UE.

[0017] Figure 9 The RedCap PCPCD, which can be used by the RedCap UE as in the implementation discussed herein, is illustrated.

[0018] Figure 10A and Figure 10B A method for performing RAT handover of RedCap UE according to the implementation scheme described herein is illustrated.

[0019] Figure 11 A table illustrating various conditions described in the embodiments described herein, under which a UE that may be optionally able to operate as a RedCap UE may be advantageously able to operate in RedCap mode.

[0020] Figure 12A and Figure 12B Together, we illustrate a method for conditional handover between a non-RedCap NRSA and an SA RedCap based on an implementation scheme according to this document.

[0021] Figure 13 The method of RedCap UE according to the implementation scheme of this article is illustrated.

[0022] Figure 14 A method for a UE based on the implementation scheme discussed herein is illustrated.

[0023] Figure 15 A method for a UE based on the implementation scheme discussed herein is illustrated.

[0024] Figure 16 A method for a UE based on the implementation scheme discussed herein is illustrated.

[0025] Figure 17 A method for a UE based on the implementation scheme discussed herein is illustrated.

[0026] Figure 18 A method for a UE based on the implementation scheme discussed herein is illustrated.

[0027] Figure 19An example architecture of a wireless communication system according to the implementation scheme disclosed herein is illustrated.

[0028] Figure 20 A system for performing signaling between a wireless device and a network device according to an embodiment disclosed herein is illustrated. Detailed Implementation

[0029] Various implementations are described for the UE. However, references to the UE are provided for illustrative purposes only. The example implementations can be used with any electronic component capable of establishing a connection to a network and configured with hardware, software, and / or firmware for exchanging information and data with the network. Therefore, the UE as described herein is used to represent any suitable electronic component.

[0030] Reduced Capability (RedCap) UE In the context of various wireless communication systems, a RedCap UE is a UE that operates with reduced capabilities (e.g., compared to other non-RedCap UEs that can operate in the wireless communication system).

[0031] We will now discuss an example capability set of a RedCap UE within an NR wireless communication system. It is possible that the maximum bandwidth usable by a RedCap UE is 20MHz in FR1 and 100MHz in FR2. In such cases, the RedCap UE does not support UE characteristics and corresponding capabilities associated with and / or using UE bandwidths wider than 20MHz in FR1 and / or 100MHz in FR2.

[0032] It is possible that the maximum number of supported data radio bearers (DRBs) at the RedCap UE is 8. It is possible that the supported Packet Data Convergence Protocol (PDCP) sequence number (SN) length at the RedCap UE is 12 bits (in some cases, an 18-bit length may be optional). It is possible that the supported Radio Link Control (RLC) Acknowledgment Mode (AM) SN length at the RedCap UE is 12 bits (in some cases, an 18-bit length may be optional).

[0033] In FR1, a RedCap UE can support one downlink (DL) multiple-input multiple-output (MIMO) layer with one receive (Rx) branch, and two DL MIMO layers with two Rx branches. In FR2, one or two DL MIMO layers can be supported (with two Rx branches simultaneously). Regarding either FR1 or FR2, a RedCap UE may not support UE features and corresponding capabilities associated with more than two UE Rx branches or more than two DL MIMO layers, or UE features and capabilities associated with more than one UE Tx branch or more than one uplink (UL) MIMO layer.

[0034] RedCap UEs do not support 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 RedCap UEs are not expected to act as IAB nodes).

[0035] Table 1.1 lists one possible example of UE capabilities for DRB support according to some implementation schemes.

[0036] Table 1.1: UE Capability Constraints

[0037] In the context of Table 1.1, it can be noted that the maximum number of DRBs configured using PDCP replication and the RLC entity associated with the MAC entity is 8 for a single Media Access Control (MAC) entity. Additionally, it can be noted that this requirement applies to NR Standalone (SA), NR Dual Connectivity (NR-DC), and NR-E-UTRA Dual Connectivity (NE-DC). Finally, it should be noted that the value of the parameter “#DRB” defines the total number of multicast radio bearers (MRBs) and DRBs (and where, for these purposes, each split MRB is counted as two radio bearers (RBs)).

[0038] Regarding the core network aspects of RedCap UE "NR RedCap" can be a 3GPP RAT type identifier used in the core network to identify NG-RAN in the core network when used by a UE that indicates NR RedCap. The NR RedCap RAT type can be understood as a subtype of the NR RAT type.

[0039] Regarding high-latency communication: When an NR RedCap UE requests to use certain power-saving features (see 3GPP Technical Specification (TS) 23.501, version 18.1.10 (March 2023) (hereinafter referred to as "TS 23.501"), section 5.31.7), the Access and Mobility Management Function (AMF) may reroute the registration request to another AMF that supports high-latency communication based on local policies (see TS 23.501, section 6.5.3).

[0040] Regarding NR RedCap UE differentiation: This functionality can be used by the network to identify traffic going to / from UEs accessing via NRRedCap (e.g., for billing differentiation purposes). NR RedCap UEs using NR should provide NR RedCap indication to the NG-RAN during the Radio Resource Control (RRC) connection establishment process (see 3GPP TS 38.300, version 17.5.0 (June 2023) (hereinafter referred to as "TS 38.300")).

[0041] When the UE has provided an NR RedCap indication to the NG-RAN during RRC connection establishment, the NG-RAN provides an NR RedCap indication to the AMF in the 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)).

[0042] When the AMF receives an NR RedCap indication from the NG-RAN in the initial UE message, the AMF should store the NR RedCap indication in the UE context, consider the RAT type to be NR RedCap, and signal it accordingly to the Short Message Service Function (SMSF) during the Short Message Service (SMS) registration process on the Non-Access Stratum (NAS), and / or signal it to the Session Management Function (SMF) during Protocol Data Unit (PDU) session establishment or PDU session modification. The Policy Control Function (PCF) also receives an NR RedCap RAT type indication from the SMF during Session Management (SM) policy association establishment or SM policy association modification (where applicable).

[0043] During the handover from Evolved Universal Terrestrial Radio Access (E-UTRA) to NR, the target NG-RAN (e.g., the target gNB of the target NG-RAN) provides the AMF with an NR RedCap indication based on the UE capability information provided to the target RAN by the source RAN in the NG Application Protocol (NGAP) path handover request message during Xn handover, or in the NGAP handover request confirmation message during N2 handover (including N2 handover within 5GS and Evolved Packet System (EPS) to 5GS handover) (see TS 38.300).

[0044] Network functions (NFs) that interact with the Charging Function (CHF) include NR RedCap as a RAT type. When the AMF changes, the source AMF provides an NR RedCap indication to the target AMF.

[0045] RAN aspect of RedCap UE As discussed in this article, RedCap UEs have a reduction capability. This can be designed to allow RedCap UEs to operate with lower complexity and / or power usage compared to non-RedCap UEs. Therefore, in some wireless communication systems, it is possible that RedCap UEs support a UE channel bandwidth of 20MHz (maximum) in FR1 and / or 100MHz (maximum) in FR2.

[0046] Regarding RAN capabilities: RedCap UEs may not support various CA, MR-DC, DAPS, CPA, Conditional Primary / Secondary Cell Group (SCG) Cell Change (CPC), and / or IAB-related capabilities (e.g., as defined along with other aspects in 3GPP TS 38.306, Release 17.5.0 (June 2023)). Preventing RedCap UEs from using radio capabilities not intended for RedCap UEs may depend on the network.

[0047] Regarding identification, access, and residency restrictions: RedCap UEs can be identified by the network during the random access procedure based on Msg3 / MsgA using a RedCap-specific Logical Channel ID (LCID) and optionally based on Msg1 / MsgA using a RedCap-specific Physical Random Access Channel (PRACH) timing and / or a RedCap-specific PRACH preamble. For RedCap UE identification via Msg1 / MsgA, a RedCap-specific random access configuration can be configured by the network. For Msg3 / MsgA, RedCap UEs can be identified based on a dedicated LCID indicated by the Common Control Channel (CCCH) identifier (CCCH or CCCH1), regardless of whether any RedCap-specific random access configuration has been / is configured by the network.

[0048] RedCap UEs with one Rx branch and two Rx branches can be individually permitted / processed via system information. Furthermore, RedCap UEs in half-duplex frequency division duplex (FDD) mode can be individually permitted / processed via system information. Additionally, a RedCap-Specific Intra-Frequency Resolution Indication (IFRI) can be provided in SIB1, and RedCap UE access is not permitted when it is absent. Information regarding the frequencies on which RedCap UE access is permitted can be provided in the system information.

[0049] RedCap UEs with one Rx branch apply an associated offset to the broadcast cell-specific reference signal received power (RSRP) thresholds used for random access, small data transmission (SDT), cell edge conditions, and / or cell (re)selection criteria in a specified manner (see 3GPP TS 38.133, version 18.2.0 (June 2023)).

[0050] It can be noted that, if possible, avoiding triggering handover attempts by RedCap UEs to target NR cells that do not support RedCap depends on the E-UTRA network. Recovery from handover attempts to target NR cells that do not support RedCap depends on the RedCap UE implementation.

[0051] Regarding Radio Resource Management (RRM) measurement relaxation: RRM measurement relaxation can be enabled and / or disabled by the network. In RRC Idle mode (“RRC_IDLE”) and / or RRC Inactive mode (“RRC_INACTIVE”), RedCap UEs may be allowed to relax neighboring cell RRM measurements when the stationary criterion is met, or when both the stationary criterion and the not-at-cell-edge criterion are met. When the UE is in RRC Connected mode (“RRC_CONNECTED”), the network can configure the stationary criterion for the RedCap UE, and the UE can use UE Auxiliary Information to report its RRM measurement relaxation compliance status when the stationary criterion is met or no longer met.

[0052] Regarding Bandwidth Part (BWP) operation: RedCap UEs in RRC_IDLE or RRC_INACTIVE can monitor paging in the initial BWP (default initial BWP or RedCap-specific initial BWP) associated with the Cell Defined 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 can perform the Random Access Channel (RACH) procedure using only the RedCap-specific initial UL BWP.

[0053] RedCap UEs can utilize multiple Non-Cell Defined Synchronization Signal Blocks (NCD-SSBs) configurations, provided that each BWP utilizes at most one SSB configuration. When an active BWP does not contain a CD-SSB, an NCD-SSB can be configured for a RedCap UE in RRC_CONNECTED state to perform Radio Link Management (RLM), Beam Failure Detection (BFD), RRM Measurement, and / or Random Access (RA) resource selection.

[0054] Regarding RRC aspects of RedCap UE Figure 1 A portion of a first system information block (SIB) 102 is illustrated, which may be used in a wireless communication system operating according to the embodiments disclosed herein. In some embodiments, the first SIB 102 may be SIB1.

[0055] As illustrated, the first SIB 102 includes redCap-ConfigCommon Information element (IE) 104. As illustrated, in the first SIB 102 redCap-ConfigCommon IE 104 can refer to or be used RedCap- ConfigCommonSIB IE 106 and intraFreqReselectionRedCap Field 108.

[0056] As exemplified, RedCap-ConfigCommonSIB IE 106 can include halfDuplexRedCapAllowed Field 110 and cellBarredRedCap IE 112. halfDuplexRedCapAllowed If field 110 exists, it indicates that the cell supports half-duplex FDD RedCap UE.

[0057] cellBarredRedCap IE 112 can include cellBarredRedCap1Rx Field 114 and / or cellBarredRedCap2Rx Each of field 116. Carrying a value. barred of cellBarredRedCap1Rx Field 114 provides an indication that the cell is prohibited for use with a RedCap UE that has one Rx branch. Any cellBarredRedCap1Rx Field 114 is ignored by non-RedCap UEs. (Carrying value) barred of cellBarredRedCap2Rx Field 116 provides an indication that the cell is prohibited for use with a RedCap UE that has two Rx branches. Any cellBarredRedCap2Rx Field 116 is ignored by non-RedCap UEs.

[0058] at last, intraFreqReselectionRedCap Field 108 controls the cell selection / reselection by the RedCap UE for a given cell when the cell is blocked within the frequency range or is considered blocked by the RedCap UE. If this field is not present, the RedCap UE considers the cell blocked (the UE believes the cell does not support RedCap).

[0059] Figure 2 A portion of a second SIB 202 is illustrated, which may be used in a wireless communication system operating according to the embodiments disclosed herein. In some embodiments, the second SIB 202 may be an SIB4.

[0060] As illustrated, the second SIB 202 includes one or more interFreqCarrierFreqList IE 204, and interFreqCarrierFreqList IE 204 can include one or more interFreqCarrierFreqInfo IE 206.

[0061] at last, interFreqCarrierFreqInfo IE 206 includes redCapAccessAllowed Field 208. redCapAccessAllowed Field 208 indicates whether RedCap UE access is permitted and / or via... interFreqCarrierFreqInfo IE 206 (for example, in interFreqCarrierFreqInfoThe frequency of one or more other fields in IE 206 (or in IE, if not explicitly specified) corresponding to / identified by.

[0062] It should be noted that, compared with the multiple found in the second SIB 202 redCapAccessAllowed The frequency set corresponding to field 208 can be considered as the "RedCap frequency list" as used in this article.

[0063] Figure 3 Examples are given of UEs that can be provided in wireless communication systems operating according to the embodiments disclosed herein. featureCombination Part of IE 302. featureCombination IE 302 indicates the features or combinations of features to be associated with a set of random access resources (e.g., featureCombinationPreambles (Examples).

[0064] As exemplified, featureCombination IE 302 can include redCap Field 304. If it exists, then redCap Field 304 indicates that RedCap is part of that specific combination of features.

[0065] Figure 4 Examples are given of UEs that can be provided in wireless communication systems operating according to the embodiments disclosed herein. posSI-RequestConfigRedCap Field 402. posSI-RequestConfigRedCap Field 402 may be in, for example, an information block corresponding to a positioning system used by a wireless communication system (e.g., in...). PosSystemInformation (In IE) Provided to UE.

[0066] The posSI-RequestConfigRedCap field 402 indicates the configuration used by the RedCap UE for requesting system information messages (e.g., as can be configured in...). initialUplinkBWP-RedCap The configuration of the Msg1 resource (found in IE) (see below), for example, posSI-BroadcastStatus The field is set to notBroadcasting .

[0067] As illustrated, based on the condition (“REDCAP-Msg-1”), posSI-RequestConfigRedCap Field 402 is optionally provided (Need R) to the UE when initialUplinkBWP-RedCap Configured in UplinkConfigCommonSIB In IE, and if included in posSchedulingInfoList Any system information message in IE, posSI-BroadcastStatus Set as notBroadcasting Or if for those included schedulingInfoList2 Any SI message containing type2 SIB in IE si-BroadcastStatus Set as notBroadcasting If the condition is true, then the condition is true. Otherwise, it does not exist.

[0068] Implementation plan of the four-step RACH process A four-step RACH procedure can 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). A four-step RACH procedure can also be referred to as a Type 1 RACH. For example, Figure 5 This is a signaling diagram illustrating a RACH procedure 500 performed by a UE 502 and a network node 504 (e.g., a base station) that can be used in some implementations. As shown, the UE 502 may transmit Msg1 506 to the network node 504. The Msg1 transmission 506 may include a PRACH preamble that includes timing information for uplink transmission.

[0069] In response to receiving Msg1 transmission 506, network node 504 may transmit Msg2 transmission 508 on the Physical Downlink Control Channel (PDCCH) or Physical Downlink Shared Channel (PDSCH). Msg2 transmission 508 may also be referred to as a Random Access Response (RAR) message. Msg2 transmission 508 may include timing parameters or information, uplink grant for Msg3 transmission 510, Temporary Cell Radio Network Temporary Identifier (TC-RNTI), etc.

[0070] In response to Msg3 transmission 510, network node 504 may transmit Msg4 PDSCH transmission 512, which includes a contention resolution message. After UE 502 transmits Msg3 transmission 510, a contention resolution timer starts. Network node 504 assists UE 502 in contention resolution by using the Cell Radio Network Temporary Identifier (C-RNTI) on the PDCCH or the Contention Resolution Identifier (IE) on the PDSCH. If UE 502 obtains a C-RNTI via the PDCCH, or if the UE obtains a temporary C-RNTI via the PDCCH and the MACPDU is successfully decoded, UE 502 continues to monitor the PDCCH until the timer expires, considers the contention resolution successful, and stops the timer. If the contention resolution timer expires, UE 502 considers the contention resolution to have failed.

[0071] To enhance the coverage of Msg4 PDSCH transmission 512, network node 504 can apply repetition to Msg4 PDSCH transmission 512. For example, network node 504 can transmit one or more Msg4 PDSCH repetitions 514. Msg4 PDSCH repetitions 514 allow network node 504 to retransmit contention resolution information transmitted at different times via Msg4 PDSCH transmission 512. In this way, if UE 502 fails to receive Msg4 PDSCH transmission 512 due to interference, UE 502 will have an additional opportunity to receive Msg4 information.

[0072] After UE 502 receives Msg4 PDSCH transmission 512 and any repetitions, UE 502 may transmit Msg4 HARQ-ACK 516 to network node 504 in the Physical Uplink Control Channel (PUCCH) or Physical Uplink Shared Channel (PUSCH). The HARQ-ACK timing can be adjusted for Msg4 PDSCH repetitions. Msg4 HARQ-ACK 516 allows UE 502 to provide feedback regarding Msg4 PDSCH transmission 512. To enhance Msg4 HARQ-ACK 516, the wireless communication system may support the UE transmitting one or more Msg4 HARQ-ACK repetitions 518. Msg4 HARQ-ACK repetitions 518 involve the UE repeatedly transmitting Msg4 HARQ-ACK on the PUCCH. In this way, if network node 504 fails to receive Msg4 HARQ-ACK 516 due to interference, network node 504 will have an additional opportunity to receive HARQ-ACK information.

[0073] In some implementations, Msg4 HARQ-ACK repetitions with a demodulation reference signal (DMRS) bundle can be used to enhance Msg4. For the DMRS, a time-domain window (TDW) can be specified. During the TDW, the UE is expected to maintain power coherence and phase continuity between PUCCH repetitions as a basis for HARQ-ACK for Msg4.

[0074] Implementation plan for the two-step RACH process A two-step RACH procedure can reduce the latency of a four-step RACH procedure and can include at least a first message (MsgA) and a second message (MsgB). A two-step RACH procedure can also be referred to as a Type 2 RACH. For example, Figure 6 This is a signaling diagram illustrating a two-step RACH procedure 600 performed by UE 602 and network node 604 (e.g., a base station) that may be used in some implementations. As shown, UE 602 may transmit MsgA transmission 606 to network node 604. MsgA transmission 606 may include Figure 5 The Msg1 and Msg3 transmissions are shown. In response to receiving MsgA transmission 606, network node 604 can transmit MsgB transmission 608 on the PDCCH or Physical Downlink Shared Channel (PDSCH). MsgB transmission 608 may include... Figure 5 The Msg2 and Msg4 transmissions are shown.

[0075] After UE 602 receives MsgB transmission 608 (and any repetitions of MsgB transmission 608), UE 602 may transmit PUCCH HARQ-ACK 610 to network node 604. PUCCH HARQ-ACK 610 allows UE 602 to provide feedback regarding MsgB transmission 608 (i.e., Msg2+Msg4 transmission). To enhance PUCCH HARQ-ACK 610, the wireless communication system may support the UE transmitting one or more PUCCH HARQ-ACK repetitions 612. PUCCH HARQ-ACK repetition 612 involves UE 602 repeatedly transmitting PUCCH HARQ-ACK to network node 604. In this way, if network node 604 fails to receive PUCCH HARQ-ACK 610 due to interference, network node 604 will have an additional opportunity to receive HARQ-ACK information. As used in this article, for simplicity, a reference to Msg4 HARQ-ACK repeat can refer to PUCCH HARQ-ACK repeat for type 2 RACH.

[0076] Implementation of RedCap RACH Configuration The network can provide information to the RedCap UE that enables the RedCap UE to determine whether the RACH configuration is a RedCap RACH configuration (the RACH configuration corresponding to a RedCap-compatible cell).

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

[0078] Figure 7 Examples are given of data that can be transmitted from the network to the RedCap UE in some wireless communication systems. BWP- UplinkCommon IE 702. BWP-UplinkCommon IE 702 includes additionalRACH-ConfigListIE704. additionalRACH-ConfigList IE 704 can contain a list of features for a specific RACH configuration (and it should be noted that these can be interpreted as in addition to any other features). rach-ConfigCommon IE or any msgA-ConfigCommon (In addition to any RACH configuration configured in the IE). The network associates all possible preambles of this additional RACH configuration with features or combinations of features. In various implementations, additionalRACH-ConfigList IE 704 accordingly includes RACH configurations corresponding to RedCap features and / or combinations of features including RedCap features.

[0079] Therefore, both the resources configured for RACH and the preamble for RACH configuration can be notified to the RedCap UE.

[0080] Implementation plan for RedCap UE handover Various RedCap UEs can support both LTE and NR. Therefore, LTE-to-NR (L2NR) handover mechanisms should be supported. Regarding such L2NR handover mechanisms, the handover command provided to the RedCap UE indicating the handover to a cell in NR may depend on E-UTRA. However, the RedCap UE receiving the handover command may not know whether the target NR cell supports the RedCap UE.

[0081] For some wireless communication system specifications, avoiding handover attempts from a RedCap UE to a target NR cell that does not support RedCap, where possible, depends on the E-UTRA network, and / or, where possible, recovery from handover attempts to a target NR cell that does not support RedCap, depends on the RedCap UE implementation. Such a framework does not inherently require / expect the network to provide a complete guarantee that the L2NR handover command provided to the RedCap UE will be used for a RedCap-compatible target NR cell. Therefore, UE-side mechanisms for, for example, determining whether a target NR cell is RedCap-compatible are beneficial.

[0082] Figure 8 An example of method 802 is illustrated according to an embodiment of this document for determining whether a RedCap UE can connect to an NR cell based on its RedCap configuration using system information received from the network at the RedCap UE.

[0083] Method 802 presupposes that the UE discussed in 804 has RedCap capability (the UE is a RedCap UE). Before camping on the NR cell, the RedCap UE receives SIB1 broadcast by the NR cell and determines 806 whether SIB1 contains redCap- ConfigCommonIE. If not, the RedCap UE determines that cell 808 NR is not suitable for RedCap UE camping.

[0084] If SIB1 does indeed contain redCap-ConfigCommon IE, then RedCap UE then determines 810 SIB1. redCap-ConfigCommon Does IE include cellBarredRedCap IE. If so, UE checks if there are any cellBarredRedCap1Rx The field indicates that the cell is prohibited from use for RedCap 1Rx configuration, and whether there are any cellBarredRedCap2Rx The field indicates that the cell is prohibited from being used for RedCap 2Rx configuration.

[0085] If SIB1 does not contain cellBarredRedCap IE, or if in SIB1 cellBarredRedCap If the information found in the IE does not indicate any prohibition for the RedCap configuration used by the RedCap UE, then the RedCap UE determines that cell 814 NR is the appropriate cell on which the RedCap UE can camp. The RedCap UE continues to camp on the NR cell.

[0086] After camping on the NR cell, the RedCap UE receives SIB4 from the NR cell and determines whether SIB4 contains an indication of the frequency allowed for the RedCap UE to access the NR cell. redCapAccessAllowed Field. If not, RedCapUE determines that the frequency of 818 NR cell is not available for RedCap UE access (and the NR cell cannot be further used by RedCap UE).

[0087] SIB4 does indeed contain instructions indicating the frequencies allowed for RedCap UEs to access NR cells. redCapAccessAllowed In the case of the field, the RedCap UE determines that 820 allows the frequency to be used for RedCap UE access purposes (and therefore the NR cell can be further used by the RedCap UE).

[0088] Figure 9 An example is illustrated of the RedCap Preferred Cell Database (PCPCD) 902 that can be used by the RedCap UE in the implementation scheme discussed herein. The RCPCD 902 stores RedCap-related information for one or more cells 904 (in... Figure 9In this context, the Physical Cell Identifier (PCI) can be understood as representing different cells 904. Information about the RCPCD 902 can be collected by the RedCapUE as it continues to connect to or attempts to connect to various cells 904, as appropriate (e.g., based on information about various cells 904 collected in various ways as described herein and / or otherwise).

[0089] Information about cell 904 represented by RPCD 902 can be organized within RPCD 902 based on the geographical location 906 where cells are found / covered by cell 904.

[0090] This can include priority 908 for cell 904. These priorities can include the measurement report (MR) report priority corresponding to the cell.

[0091] Information about the frequency band 910 and frequency 912 of cell 904 can be included in RCPCD 902.

[0092] RedCap configuration 914 for cell 904 can be included in RCPCD 902. RedCap configuration 914 can indicate whether the cell is known to support RedCap, whether the cell is known to not support RedCap, and / or whether to disable the cell for RedCap UEs, as already illustrated.

[0093] RCPCD 902 also includes a service prohibition state 916 for cell 904. Service prohibition state 916 may involve, for example, any prohibition information that can be received in SIB1.

[0094] RCPCD 902 also includes an in-frequency prohibition state 918 for cell 904. The in-frequency prohibition state 918 can be received, for example, for cell 904. intraFreqReselectionRedCap Information from fields is used for control (such as information received in SIB1). intraFreqReselectionRedCap Field 108, as mentioned elsewhere in this article... Figure 1 (As discussed).

[0095] RCPCD 902 also includes a 1Rx disabled state 920 for cell 904. The 1Rx disabled state 920 can be received, for example, for cell 904. cellBarredRedCap1Rx Information from fields is used for control (such as information received in SIB1). cellBarredRedCap1Rx Field 114, as mentioned elsewhere in this article... Figure 1 (As discussed).

[0096] RCPCD 902 also includes a 2Rx disabled state 922 for cell 904. The 2Rx disabled state 922 can be received, for example, for cell 904. cellBarredRedCap2RxInformation from fields is used for control (such as information received in SIB1). cellBarredRedCap2Rx Field 116, as mentioned elsewhere in this article... Figure 1 (As discussed).

[0097] RCPCD 902 also includes a half-duplex disable state 924 for cell 904. The half-duplex disable state 924 can be, for example, received for cell 904. cellBarredRedCap2Rx Information from fields is used for control (such as information received in SIB1). cellBarredRedCap2Rx Field 116, as mentioned elsewhere in this article... Figure 1 (As discussed).

[0098] In some implementations, the RCPCD 902 may be maintained in the memory of the RedCap UE. In other implementations, the RedCap UE may communicate with a network server to store, update, maintain, and / or read the RCPCD 902 from the network server's memory (this allows multiple RedCap UEs within the wireless communication system to update, maintain, and / or use the RCPCD 902 at the server).

[0099] In some implementations, it is possible that only RedCap-supported cells with prohibited information are recorded in RCPCD 902.

[0100] Based on its use of RPCD 902, RedCap UEs can avoid unnecessary handover attempts to non-RedCap cells and / or recover more quickly after failed handover attempts. For example, before executing a handover based on network indications found in the handover command, a RedCap UE can refer to RPCD 902 to determine whether the cell supports the RedCap configuration used by the RedCap UE (and therefore whether a successful handover of the RedCap UE to the cell is possible). If a reference to RPCD 902 informs the RedCap UE that the handover will not be successful (e.g., because information about the target cell in RPCD 902 indicates that the target cell does not use RedCap and / or the target cell is disabled in a manner incompatible with the RedCap configuration used by the RedCap UE), the UE can discard the handover command without attempting a handover to the target cell.

[0101] As another example, after a failed handover attempt and / or after a discarded handover command (as just described), the RedCap UE can refer to RPCD 902 to identify the fallback cell to connect to. In some implementations, the RedCap UE will first attempt to fall back to a cell in cell 904 for which RPCD 902 does not indicate any type of prohibition. If no such cell exists, the RedCap UE can then attempt to fall back to a cell in cell 904 for which RPCD 902 only indicates a prohibition type that does not affect the RedCap configuration used by the RedCap UE.

[0102] Figure 10A and Figure 10B A method 1002 for performing RAT handover of RedCap UE according to the implementation scheme of this document is illustrated.

[0103] Method 1002 presupposes that the UE discussed in 1004 has RedCap capability (the UE is a RedCap UE) and that it camps on an LTE cell in the LTE RAN.

[0104] The RedCap UE then determines whether the 1006 LTE base station (e.g., eNB) has configured either or both of the B1 measurement report event and the B2 measurement report event for the RedCap UE.

[0105] A configured B1 measurement report event can be triggered at the RedCap UE based on a determination that the result of a measurement object (MO) of the NR RAN measured by the RedCap UE is greater than a threshold. A configured B2 measurement report event can be triggered based on a first determination that a first result of a measurement of the current serving cell on the LTE RAN measured by the RedCap UE differs from a first threshold, and a second determination that a second result of a measurement of the MO of the NR RAN measured by the RedCap UE is greater than a second threshold. Therefore, since each of the B1 and B2 measurement report events is related to a measurement of NR while the UE is camped in LTE, each represents an inter-RAT measurement report event.

[0106] If the LTE base station has already configured either and / or both of the B1 and B2 measurement report events for the RedCap UE, the UE continues to determine whether any NR MO identified by 1008 for the B1 and / or B2 measurement report event matches the one found in SIB4 of the NR RAT. redCapAccessAllowed The fields correspond, including (one or more) found in SIB4. redCapAccessAllowedThe field set is operated as a list of RedCap frequencies that can be used for this purpose. It should be noted that SIB4 can be a SIB4 cached by the RedCap UE prior to the instance of method 1002 discussed here.

[0107] If there is no NR MO for the B1 and / or B2 measurement report event identifier, it is not consistent with the one found in NR SIB4. redCapAccessAllowed If the frequency corresponds to the field, the RedCap UE continues with step 1010 to prune such NR MOs from upcoming measurements. Additionally, the RedCap UE determines to remain camped in LTE and will not transmit any measurement reports for B1 and / or B2 measurement report events until NR SIB4 contains data for at least one frequency corresponding to at least one applicable NR MO. redCapAccessAllowed Field.

[0108] If at least one NR MO for the measurement report event identifier for B1 and / or B2 is related to the one found in NR SIB4 redCapAccessAllowed If the frequency of the field corresponds, the RedCap UE continues for 1012 to measure the NR cell in the corresponding frequency.

[0109] Based on the measurements, the RedCap UE determines that there is at least one MO corresponding to a B1 and / or B2 measurement report event that has occurred. Accordingly, the RedCap UE determines that a measurement report should be transmitted to the LTE base station.

[0110] When preparing a measurement report, the RedCap UE performs a RedCap check mechanism. As part of this mechanism, the RedCap UE checks whether it already knows a RedCap cell at its location that corresponds to an MO for which it has triggered B1 and / or B2 measurement report events. This can be achieved by the RedCap UE referencing a database containing historical information about RedCap cells at that location (e.g., an RCPCD as described herein). If the RedCap UE identifies a record of a RedCap cell at its location for the MO in question, the RedCap UE prepares a measurement report that includes only the measurement results corresponding to one or more known RedCap cells at that location (at least the results for the RedCap cell corresponding to the MO for which it has triggered B1 and / or B2 measurement report events).

[0111] If the RedCap UE does not identify any RedCap cell for an MO that triggered a B1 and / or B2 reporting event at the location of the RedCap UE, the RedCap UE alternatively prepares a measurement report with measurement results for (e.g., a larger) set of candidate cells that have already been measured by the RedCap UE (where the measurement report is not limited to measurement results only for known RedCap cells).

[0112] The RedCap UE sends the prepared measurement report to the LTE base station. In response, the network may provide an RRC reconfiguration message in the return transmission to the RedCap UE (e.g., via the LTE base station), which instructs 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 reported as enabled in a measurement report sent by the RedCap UE in response to a previous B1 and / or previous B2 measurement report event, as described herein.

[0113] If the RedCap UE determines that it has received such an RRC reconfiguration message at 1014, the UE can proceed to 1016 to perform a RedCap verification mechanism regarding the target NR cell to attempt to determine whether the target NR cell is a RedCap cell. This is because, in at least some cases, the UE may not know whether the target NR cell indicated in the handover command is a RedCap cell.

[0114] As the first check within the RedCap verification mechanism, the RedCap UE first determines whether the RACH configuration of 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 continues to camp on and use the target NR cell.

[0115] If not, the RedCap UE will use RACH configuration to perform the RACH procedure with the target NR cell without knowing whether the target NR cell is a RedCap cell that the RedCap UE can eventually use.

[0116] If the RACH procedure is successful, the RedCap UE concludes that the target NR cell is a RedCap cell and continues to camp on and use the target NR cell.

[0117] Alternatively, if the RACH procedure is a four-step RACH procedure, and the UE determines that the four-step RACH procedure failed at Msg3, then 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 failed at MsgA, then the UE determines that the target NR cell is a non-RedCap cell.

[0118] Upon RACH failure, the UE will blacklist the target NR cell for RedCap access / use purposes. The UE then proceeds to declare a Radio Link Failure (RLF) and performs a system scan on frequencies in the NR RAT to attempt to identify RedCap cells for which it wants to connect. The scanned frequencies may be frequencies indicated by the RedCap frequency list that allow RedCap UE access (e.g., in SIB4 of its NR RAT, e.g., cached). redCapAccessAllowed (Frequency of the field), as described in this article.

[0119] If the UE identifies any NR cell using a frequency found in the RedCap frequency list based on the system scan, the UE then performs a system selection for the highest-energy NR cell in its SIB1. redCap-ConfigCommon IE (and therefore appropriate).

[0120] It should be noted that existing algorithms are designed to perform cell search in the source RAT after the UE declares an RLF. Therefore, one difference between the implementation discussed in this paper and such existing algorithms is that, after the RedCap UE declares an RLF, the RedCap UE performs a search for suitable cells in the target RAT (in the NR RAT in this example implementation).

[0121] If no suitable cell is found based on the system scan, the UE will fall back to the LTE RAT. In some cases, the UE can also start a blacklist timer corresponding to the NR RAT. This blacklist timer can be configured to prevent the UE from immediately retrying the handover to NR, thereby saving UE power, processing, and / or communication resources.

[0122] In some cases, it may be beneficial for a RedCap UE to perform a handover to a known RedCap cell without waiting for a handover command. This can be achieved in situations such as... Figure 10A The illustrated scenario is completed at the RedCap UE, where the LTE base station has not yet configured any B1 and / or B2 measurement reporting events to the RedCap UE, and / or where a handover command has not yet been received at the RedCap UE.

[0123] For example, Figure 10A This example illustrates how a RedCap UE can be configured to determine, 1024 (e.g., based on RCPCD, as described herein), whether it knows the appropriate NR cell at the RedCap UE's current location. If so, the UE can simply proceed 1026 to perform a local release in LTE and perform an L2NR reselection to a cell with RedCap capability (e.g., during the verification of SIB1 for the cell, including...). redCap-ConfigCommon (After IE).

[0124] Implementation plan for RedCap Network Energy Saving (NES) considerations It is envisioned that in various contexts of successful handover to a RedCap cell (including, but not limited to, those provided in the implementations described herein), it may be beneficial for the RedCap UE to check whether its new RedCap cell has NES enabled. When NES is enabled, the cell operates in a reduced power mode, which can ultimately affect the characteristics of data transmission to / from the RedCap UE through that cell, which may be undesirable in at least some cases.

[0125] Therefore, once a RedCap UE has been handed over to a RedCap cell, the RedCap UE can determine whether NES has been enabled in the 1018 RedCap cell by evaluating whether the NR base station for the cell is configured with Discontinuous Transmission (DTX) / Discontinuous Reception (DRX) configuration that includes both active and inactive periods. It should be noted that this DTX / DRX configuration can be delivered to the RedCap UE from the NR base station via UE-specific RRC signaling, via an SIB with cell DTX / DRX configuration, and / or via dynamic L1 / L2 signaling.

[0126] If the RedCap UE determines that NES is not yet enabled in the RedCap cell, the RedCap UE continues the operation on the 1020 RedCap cell.

[0127] If the RedCap UE alternatively determines that the RedCap cell is already NES enabled, the RedCap UE continues to step 1022 to determine if the RedCap UE needs high-performance data. If the RedCap UE does need high-performance data (and is not in power-saving mode), the RedCap UE skips the NES cell and switches to a non-NES cell. For example, the RedCap UE can perform a local release and reselect to another RedCap cell at the RedCap UE's location.

[0128] If the RedCap UE does not require high-performance data (and / or if the RedCap UE itself is in power-saving mode), the RedCap UE can remain in the current RedCap cell where NES is enabled. In this case, the RedCap UE adapts / operates according to the DTX / DRX settings of the current RedCap cell, as received.

[0129] In some implementations, when the network is configured to perform measurements for handover, the RedCap UE detects a number of candidates. If a candidate is in an RCPCD used by the UE, the UE can report the measurements of these candidates in the measurement report (or, in some cases, the higher-priority candidates among these candidates as indicated in the RCPCD), and can prune other non-RCPCD cells from the measurement report. If none of the candidates are in an RCPCD, the UE can generate a measurement report for all candidates.

[0130] When a handover RRC reconfiguration is received at the RedCap UE (e.g., in response to a measurement report), any handover attempt to the target cell can be avoided if the target cell configuration indicates any prohibition information related to the RedCap configuration used by the RedCap UE, and the RedCap UE can attempt to re-establish a connection to the network.

[0131] For example, if any RedCap cell is detected after searching the remaining cells in the RCPCD (which are not network-configured frequencies), the UE can trigger a re-establishment process for the detected cell and / or update the RCPCD using the detected cell information corresponding to the cell.

[0132] As another example, if any such cell is detected after searching for any non-RCPCD cell, and if the detected cell uses the RedCap Msg1 / MsgA RACH configuration and there is no prohibition for that cell applied to the RedCap configuration used by the RedCap UE, then the RedCap UE may trigger a re-establishment process for the detected cell and / or the UE may use the information corresponding to the detected cell to update the RPCD.

[0133] On the other hand, if the detected cell uses a non-RedCap Msg1 / MsgA configuration (making it impossible for the RedCap UE to determine whether the cell is a RedCap cell based on SIB), the UE can trigger a re-establishment procedure for the detected cell. In such cases, if the RACH procedure fails at Msg3 / MsgA (e.g., at a time threshold), XIf no response (Msg4 / MsgB) is received within the cell, the UE can determine that the cell is a non-RedCap cell. If the RACH procedure is successfully performed alternatively and RedCap configuration is received at the UE, the UE can treat the cell as a RedCap cell and / or can use the cell-specific information to update the RCPCD.

[0134] If no available cell is detected, the RedCap UE can re-establish itself back to the original LTE cell, or fall back to another / any other LTE cell if the original cell is unavailable.

[0135] It should be noted that if the RRC reconfiguration for the handover of a RedCap UE indicates the availability of RedCap configuration at the target cell, the UE can simply proceed with the handover to the target cell.

[0136] Implementation scheme for condition-based handover between Dynamic Independent (SA) and SA RedCap A RedCap UE can be identified by the network during a random access procedure based on Msg3 / MsgA using a RedCap-specific Logical Channel ID (LCID) and optionally based on Msg1 / MsgA using a RedCap-specific PRACH timing and / or a RedCap-specific PRACH preamble. For RedCap UE identification via Msg1 / MsgA, a RedCap-specific random access configuration can be configured by the network. For Msg3 / MsgA, a RedCap UE can be identified based on a dedicated LCID indicated by the CCCH identifier (Common Control Channel (CCCH) or CCCH1), regardless of whether any RedCap-specific random access configuration has been / is configured by the network.

[0137] Some UEs are capable of operating as both a non-RedCap UE (e.g., in a non-RedCap NR SA) and a RedCap UE. For such UEs, identifying the conditions under which such UEs can be appropriately served on a RedCap basis and placing the UE in RedCap mode under such conditions may be beneficial. This can, for example, reduce the UE's power consumption.

[0138] Figure 11Table 1102 illustrates various conditions 1104 to 1118 according to embodiments described herein, under which a UE that may be optionally able to operate as a RedCap UE may benefit from operating in RedCap mode. The first condition 1104 relates to a marginal coverage scenario for the UE. When in marginal coverage, it is possible that the UE will not receive sufficient marginal throughput benefits for operation in non-RedCap SA mode in any case, compared to RedCap mode. Therefore, it is possible to use RedCap mode at the UE for power-saving purposes.

[0139] The second condition 1106 involves within a defined time period (e.g., such as...). Figure 11 The scenario shown is one where user data has not been transmitted and / or received (in the "x" minutes). In such cases, it is likely less likely that the UE would require the relatively higher throughput corresponding to operation in non-RedCap SA mode compared to operation in RedCap mode (because the UE's users have a recent history of not using the UE at this data level). Therefore, it is possible that RedCap mode would be used at the UE for power saving purposes in this scenario.

[0140] The third condition 1108 is that the UE's display screen has been off for a defined period of time (e.g., until...). Figure 11 The scenario corresponds to the "y" minutes shown. In this case, it is unlikely that the UE would require the relatively high throughput corresponding to operation in non-RedCap SA mode compared to operation in RedCap mode (because the user does not actively operate the UE via the display to perform network communication-related tasks). Therefore, it is possible that in this scenario, RedCap mode would be used at the UE for power saving purposes.

[0141] The fourth condition 1110 is where a specific time of day (e.g., nighttime, such as...) Figure 11 The scenario described is as follows. In such cases, it might be considered less likely that the UE would require the relatively higher throughput required for operation in non-RedCap SA mode compared to operation in RedCap mode (e.g., it can be assumed that the UE's users are unlikely to be using the UE at that time, and therefore the UE is unlikely to be using many network resources). Therefore, it is possible that in this scenario, RedCap mode would be used at the UE for power saving purposes.

[0142] The fifth condition 1112 involves the UE's battery being below a certain level (e.g., below a certain percentage, such as...). Figure 11The scenario shown corresponds to this. In such cases, the power savings achieved through operation in RedCap mode can be considered relatively more important than the benefits of operation in non-RedCap SA mode, as opposed to those in non-RedCap SA mode. Therefore, it is possible that in this scenario, RedCap mode is used at the UE for power saving purposes.

[0143] The sixth condition 1114 involves the UE traveling along a known route (e.g., from the user's home to the user's office, such as...). Figure 11 This corresponds to the scenario shown. In such cases, it might be considered less likely that the UE would require the relatively higher throughput corresponding to operation in non-RedCap SA mode compared to operation in RedCap mode (e.g., it can be assumed that the UE user is busy and therefore the UE is unlikely to use many network resources). Therefore, it is possible that in this scenario, RedCap mode would be used at the UE for power saving purposes.

[0144] The seventh condition 1116 is that the UE is in a fixed location (e.g., in a gym or office, such as...). Figure 11 The scenario described is as follows. In such cases, it is likely that the UE would be less likely to require the relatively high throughput corresponding to operation in non-RedCap SA mode compared to operation in RedCap mode (e.g., due to the assumption of LAN availability at a location where adequate throughput can be achieved). Therefore, it is possible that RedCap mode would be used at the UE for power saving purposes in this scenario.

[0145] The eighth condition 1118 is that the UE follows a fixed route (e.g., along the user's jogging route, such as...). Figure 11 The scenario described above corresponds to the scenario shown. In such cases, it might be considered less likely that the UE would require the relatively higher throughput corresponding to operation in non-RedCap SA mode compared to operation in RedCap mode (e.g., it can be assumed that the UE user is busy and therefore the UE is unlikely to use many network resources). Therefore, it is possible that in this scenario, RedCap mode is used at the UE for power saving purposes. Note that the eighth condition 1118 may correspond to a fixed route, for example, having a lower speed class and / or smaller distance class than the known route described above for the case corresponding to the sixth condition 1114.

[0146] Figure 12A and Figure 12BA method 1202 for conditional handover between a non-RedCap NRSA and an SA RedCap (e.g., to an SA RedCap cell) according to an embodiment of this document is illustrated. Method 1202 can be performed by a UE capable of operating under both a non-RedCap NRSA and a RedCap UE.

[0147] As illustrated, method 1202 first largely follows the principles outlined in the section on... Figure 8 The described method 802 uses system information to determine whether a UE can connect to an NR cell according to a RedCap configuration. It should be noted that, regarding this implementation, method 802 presupposes that the UE 804 has RedCap capability and is currently camped on a non-RedCap NR SA cell. Further note that the details of the parts of method 802 corresponding to reference numerals 806, 808, 810, 812, 814, 816, 818, and 820 should be understood as per the description of... Figure 8 Correspondingly described.

[0148] Go to Figure 12B After determining that the UE can connect to a cell according to the RedCap configuration (i.e., the cell is a RedCap cell), the UE assesses whether there is an ongoing voice call at the UE's location. If so, the UE determines that it will continue to operate in a non-RedCap NR SA cell to ensure that the voice call is not interrupted as a result of the handover to the RedCap cell.

[0149] If there is no ongoing voice call at the UE, the UE then evaluates whether 1210 has met the conditions for handing over to a RedCap cell. These conditions could be, for example, regarding... Figure 11 The conditions discussed are one of the following: First condition 1104, Second condition 1106, Third condition 1108, Fourth condition 1110, Fifth condition 1112, Sixth condition 1114, Seventh condition 1116, and / or Eighth condition 1118. It should be noted that these conditions are given by way of example rather than limitation.

[0150] If the conditions for handover to a RedCap cell have not yet been met, the UE determines 1208 to continue operating in a non-RedCap NRSA cell in order to ensure that no data transmission interruption occurs at the UE as a result of the handover to a RedCap cell.

[0151] The UE then determines whether NES is enabled in the RedCap cell by evaluating whether the NR base station for the RedCap cell is configured with discontinuous transmission (DTX) and / or discontinuous reception (DRX) configurations that include both active and inactive periods. Note that the DTX and / or DRX configurations can be delivered to the RedCap UE from the NR base station via UE-specific RRC signaling, via an SIB with cell DTX and / or DRX configurations, and / or via dynamic L1 / L2 signaling. If NES is enabled in the RedCap cell, the UE determines to continue operating in a non-RedCap NR SA cell to avoid operating in the RedCap cell according to NES mode.

[0152] If NES is not yet enabled in the RedCap cell, the UE declares 1214 RLF, preparing to switch from a non-RedCap NR SA cell to a RedCap cell. This puts the UE in a state of performing a new registration procedure with the RedCap cell.

[0153] The UE then performs the RACH procedure with the RedCap cell (1216). As part of this RACH procedure, the UE may optionally transmit Msg1 / MsgA with a RedCap-specific random access preamble. As another part of the RACH procedure, the UE transmits Msg3 / MsgB with a Logical Channel Identifier (LCID) dedicated to RedCap.

[0154] Implementation of RedCap's Smart Request Network Slice Selection Auxiliary Information (NSSAI) In some wireless systems, RedCap UEs can support up to eight DRBs. Additionally, two of these DRBs can be used in SA mode for enhanced mobile broadband (eMBB) slicing (e.g., as a DRB for Internet data and a DRB for Internet Protocol (IP) Multimedia Subsystem (IMS) data, respectively).

[0155] In this scenario, up to six more DRBs can be used at the RedCap UE. Since each potential slice outside the eMBB slice will use at least one of these six DRBs, it can be seen that in such cases, the RedCap UE can effectively only use a total of up to seven network slices (eMBB slices and up to six additional slices for up to six additional DRBs). Therefore, requesting a total of eight slices in the requested NSSAI for the RedCap UE may be considered inefficient. Therefore, the mechanism discussed in this paper for use at the RedCap UE can be optimized to reduce the requested NSSAI and / or allowed NSSAI size at the RedCap UE from the existing situation (which can be configured to assume potential use of more than seven slices).

[0156] For example, in some implementations, the UE can populate up to seven instances of a single Network Slice Selection Assistance Information (S-NSSAI) in the requested NSSAI. Additionally, in some implementations, the UE can filter requested NSSAI based on UE Route Selection Policy (URSP) rules.

[0157] Figure 13 Method 1302 for a RedCap UE according to an embodiment of this document is illustrated. Method 1302 presupposes that the UE discussed in 1304 has RedCap capability (the UE is a RedCap UE).

[0158] The RedCap UE then determines whether it is attempting to register to a cell corresponding to the network slice (e.g., an NR SA cell as illustrated), which could be in cases such as L2NR handover (and others).

[0159] If so, the RedCap UE determines whether it supports IMS. If the RedCap UE does not support IMS, the RedCap UE continues with step 1308 to fill up to 8 S-NSSAIs. This is because without IMS, an eMBB slice only uses 1 DRB for Internet data. Therefore, 7 DRBs can still be used for distribution across up to 7 additional slices.

[0160] If the RedCap UE supports IMS, then the RedCap UE continues with step 1310 to populate up to 7 S-NSSAIs. This is because for IMS, eMBB slices use 2 DRBs, one for Internet data and one for IMS data. Therefore, only 6 DRBs are still available for distribution across up to 6 additional slices. In such cases, as illustrated, there is no advantage to using 8 S-NSSAIs to populate the requested NSSAI information, so the UE can instead use up to 7 S-NSSAIs in total for the requested NSSAI information.

[0161] Implementation plan for optimizing smart PDU release in RedCap's largest DRB scenario In some cases, up to eight DRBs can be set up for a RedCap UE (it may not support more than eight DRBs, as described elsewhere in this document). Imagine a RedCap UE operating in these scenarios invoking a new application (or, in other words, a supplementary service) that requires a new Data Network Name (DNN). This process corresponds to the use of a PDU session and a new DRB. Therefore, the UE can be configured to release the current DRB and be configured to set up a new DRB for the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) DNN.

[0162] Therefore, in some implementations, when eight DRBs are set up and running, and the RedCap UE initiates a forced service (which calls a new PDU session (DNN) and thus a new DRB) (e.g., a supplemental service via the XCAP DNN), the UE can identify the low-priority DRBs to be torn down / suspended before setting up a new DRB for the XCAP DNN. Then, after the XCAP service is completed, the corresponding PDU can be released (e.g., after 4 minutes in some UE implementations), and the UE can continue to attempt to re-establish the previously torn down / suspended DRBs.

[0163] In some cases, low-priority DRBs in the RedCap context can be identified based on the following: first, any PDU session that can be rerouted via the default Internet PDU session; then, any PDU session that has had low user plane data usage in the past period (e.g., the past 4 minutes); and finally, any PDU session with the longest dormancy time.

[0164] General RAT type considerations The various implementations described herein are discussed in the context of specific RAT types (e.g., LTE, NR). The discussion of these specific RAT types is given for illustrative purposes and is not intended to be construed as limiting. It should be understood that the principles discussed regarding the various implementations can be applied to other RAT type contexts, where similar considerations are applied to those described with respect to the example RAN types explicitly discussed.

[0165] Figure 14 A method 1400 for a UE according to an embodiment discussed herein is illustrated. Method 1400 includes receiving 1402 a configuration for an inter-RAT measurement report event from a first base station using a first RAN, the configuration identifying the MO of a second RAN using a second RAT for the inter-RAT measurement report event. Method 1400 further includes identifying 1404 that the MO of the second RAN corresponds to a RedCap frequency identified in a RedCap frequency list for the second RAN. Method 1400 further includes measuring 1406 the MO of the second RAN based on the identification that the MO corresponds to a RedCap frequency identified in the RedCap frequency list for the second RAN.

[0166] In some implementations, method 1400 further includes: receiving a RedCap frequency list for the second RAN from a second base station of the second RAN in the SIB; and storing the RedCap frequency list for the second RAN.

[0167] In some implementations, method 1400 further includes: determining that an inter-RAT measurement report event has occurred based on measurements of the MO; determining that the MO corresponds to a first RedCap cell of the second RAN providing coverage at the location of the UE based on a database stored at the UE; and transmitting a measurement report to a first base station of the first RAN, the measurement report including 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.

[0168] In some implementations, method 1400 further includes: determining that an inter-RAT measurement report event has occurred based on measurements of the MO; determining, based on a database stored at the UE, that the UE is unaware of the existence of a RedCap cell corresponding to the MO that provides coverage at the UE's location; and transmitting a measurement report to a first base station of a first RAN, the measurement report including 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.

[0169] In some implementations of method 1400, the first RAT includes LTE, and the second RAT includes NR.

[0170] In some implementations of method 1400, the inter-RAN measurement reporting event includes a determination of whether the result of measuring the MO of the second RAN is greater than a threshold.

[0171] In some implementations of method 1400, the RAT inter-measurement reporting event includes a first determination of whether a first result of measuring the current serving cell of the first RAN differs from 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.

[0172] Figure 15 A method 1500 for a UE according to the embodiments discussed herein is illustrated. Method 1500 includes receiving 1502 a configuration for an inter-RAT measurement report event from a first base station in a first RAN using a first RAT, the configuration identifying the MO of a second RAN using a second RAT for the inter-RAT measurement report event. 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 list for the second RAN. Method 1500 further includes discarding 1506 measurements of the MO of the second RAN based on the identification that the MO does not correspond to any RedCap frequency identified in the RedCap frequency list for the second RAN.

[0173] In some implementations, method 1500 further includes: receiving a RedCap frequency list for the second RAN from a second base station of the second RAN in the SIB; and storing the RedCap frequency list for the second RAN.

[0174] In some implementations of method 1500, the first RAT includes LTE, and the second RAT includes NR.

[0175] In some implementations of method 1500, the inter-RAN measurement reporting event includes a determination of whether the result of measuring the MO of the second RAN is greater than a threshold.

[0176] In some implementations of method 1500, the RAT inter-measurement reporting event includes a first determination of whether a first result of measuring the current serving cell of the first RAN differs from 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.

[0177] Figure 16 Method 1600 of a UE according to the implementation discussed herein is illustrated. Method 1600 includes receiving, 1602, an RRC reconfiguration message from a first base station in a first RAN using a first RAT, the RRC reconfiguration message instructing the UE to perform a handover to a target cell in a second RAN using a second RAT. Method 1600 also includes determining, 1604, that the target cell is a non-RedCap cell. Method 1600 further includes declaring, 1606, an RLF in response to determining that the target cell is a non-RedCap cell. Method 1600 also includes performing, 1608, a system scan of the second RAN using the second RAT in response to the RLF, to attempt to identify suitable RedCap cells in the second RAN.

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

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

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

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

[0182] In some implementations, method 1600 further includes identifying suitable RedCap cells in the second RAN based on system scanning; and performing system selection to the suitable RedCap cells in the second RAN.

[0183] In some implementations, method 1600 also includes failing to identify a suitable RedCap cell for the second RAN based on a system scan; and initiating a blacklist timer corresponding to the second RAT.

[0184] In some implementations of method 1600, the first RAT includes LTE, and the second RAT includes NR.

[0185] Figure 17 Method 1700 of a UE according to the implementation scheme discussed herein is illustrated. Method 1700 includes performing a handover 1702 to a RedCap cell. Method 1700 also includes determining 1704 that the RedCap cell has NES enabled. Method 1700 further includes determining 1706 that the UE requires high-performance data. Method 1700 also includes performing a reselection 1708 to another RedCap cell in response to determining that the RedCap cell has NES enabled and the UE requires high-performance data.

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

[0187] Figure 18 Method 1800 of a UE according to the implementation discussed herein is illustrated. Method 1800 includes determining, 1802, that a RedCap cell of a second RAN using a second RAT provides coverage at the UE's location based on a database stored at the UE. Method 1800 also includes determining, 1804, that the RedCap cell corresponds to a RedCap frequency identified in a RedCap frequency list for the second RAN. Method 1800 further includes performing, 1806, a handover to the RedCap cell of the second RAN in response to determining that the RedCap cell provides coverage at the UE's location and determining that the RedCap cell corresponds to a RedCap frequency identified in a RedCap frequency list for the second RAN.

[0188] In some implementations of method 1800, the first RAT includes LTE, and the second RAT includes NR.

[0189] Figure 19 An example architecture of a wireless communication system 1900 according to an embodiment disclosed herein is illustrated. The following description is provided for an example wireless communication system 1900 operating in conjunction with LTE system standards and / or 5G or NR system standards provided by 3GPP technical specifications.

[0190] like Figure 19 As shown, the wireless communication system 1900 includes UE 1902 and UE 1904 (but any number of UEs can be used). In this example, UE 1902 and UE 1904 are exemplified as smartphones (e.g., handheld touchscreen mobile computing devices capable of connecting to one or more cellular networks), but may also include any mobile or non-mobile computing device configured for wireless communication.

[0191] UE 1902 and UE 1904 can be configured to be communicatively coupled to RAN 1906. In an implementation, RAN 1906 can be NG-RAN, E-UTRAN, etc. UE 1902 and UE 1904 utilize connections (or channels) with RAN 1906 (shown as connection 1908 and connection 1910, respectively), each connection including a physical communication interface. RAN 1906 may include one or more base stations (such as base station 1912 and base station 1914) implementing connection 1908 and connection 1910.

[0192] In this example, Connection 1908 and Connection 1910 are air interfaces that enable this type of communication coupling and can conform to the RAT used by RAN 1906, such as LTE and / or NR, for example.

[0193] In some implementations, UE 1902 and UE 1904 can also exchange communication data directly via sidelink interface 1916. UE 1904 is shown configured to access an access point (shown as AP 1918) via connection 1920. For example, connection 1920 may include a local wireless connection, such as a connection conforming to any IEEE 802.11 protocol, while AP 1918 may include Wi-Fi. ® Router. In this example, AP 1918 can connect to another network (e.g., the Internet) without using CN 1924.

[0194] In the implementation scheme, UE 1902 and UE 1904 may be configured to communicate with each other or with base station 1912 and / or base station 1914 on a multi-carrier communication channel using orthogonal frequency division multiplexing (OFDM) communication signals according to various communication technologies, such as but not limited to orthogonal frequency division multiple access (OFDMA) communication technology (e.g., for downlink communication) or single-carrier frequency division multiple access (SC-FDMA) communication technology (e.g., for uplink and ProSe or sidelink communication), but the scope of the implementation scheme is not limited in this respect. The OFDM signal may include multiple orthogonal subcarriers.

[0195] In some implementations, all or some of the base stations in base station 1912 or base station 1914 may be implemented as one or more software entities running on a server computer as part of a virtual network. Furthermore, or in other implementations, base station 1912 or base station 1914 may be configured to communicate with each other via interface 1922. In implementations where the wireless communication system 1900 is an LTE system (e.g., when CN 1924 is an EPC), interface 1922 may be an X2 interface. This X2 interface may be defined between two or more base stations (e.g., two or more eNBs, etc.) connected to the EPC and / or between two eNBs connected to the EPC. In implementations where the wireless communication system 1900 is an NR system (e.g., when CN 1924 is a 5GC), interface 1922 may be an Xn interface. The Xn interface is defined between two or more base stations (e.g., two or more gNBs, etc.) connected to the 5GC, between base station 1912 (e.g., a gNB) connected to the 5GC and an eNB, and / or between two eNBs connected to the 5GC (e.g., CN 1924).

[0196] RAN 1906 is shown communicatively coupled to CN 1924. CN 1924 may include one or more network elements 1926 configured to provide various data and telecommunications services to customers / subscribers (e.g., users of UE 1902 and UE 1904) connected to CN 1924 via RAN 1906. Components of CN 1924 may be implemented in a single physical device or a separate physical device including components for reading and executing instructions from machine-readable or computer-readable media (e.g., non-transitory machine-readable storage media).

[0197] In the implementation scheme, CN 1924 may be an EPC, and RAN 1906 may be connected to CN 1924 via S1 interface 1928. In the implementation scheme, S1 interface 1928 may be divided into two parts: an S1 user plane (S1-U) interface, which carries service data between base station 1912 or base station 1914 and the serving gateway (S-GW); and an S1-MME interface, which is the signaling interface between base station 1912 or base station 1914 and the mobility management entity (MME).

[0198] In the implementation scheme, CN 1924 may be a 5GC, and RAN 1906 may be connected to CN 1924 via NG interface 1928. In the implementation scheme, NG interface 1928 may be divided into two parts: an NG user plane (NG-U) interface, which carries service data between base station 1912 or base station 1914 and the User Plane Function (UPF); and an S1 control plane (NG-C) interface, which is the signaling interface between base station 1912 or base station 1914 and the Access and Mobility Management Function (AMF).

[0199] Generally, application server 1930 can be a component that provides Internet Protocol (IP) carried resources (e.g., packet-switched data services) for use with CN 1924. Application server 1930 can also be configured to support one or more communication services (e.g., VoIP sessions, group communication sessions, etc.) for UE 1902 and UE 1904 via CN1924. Application server 1930 can communicate with CN 1924 via IP communication interface 1932.

[0200] Figure 20A system 2000 for performing signaling 2032 between a wireless device 2002 and a network device 2018 according to an embodiment disclosed herein is illustrated. System 2000 may be part of a wireless communication system as described herein. Wireless device 2002 may be, for example, a UE of a wireless communication system. Network device 2018 may be, for example, a base station (e.g., an eNB or gNB) of a wireless communication system.

[0201] Wireless device 2002 may include one or more processors 2004. Processor 2004 is executable instructions that cause various operations of wireless device 2002 to be performed as described herein. Processor 2004 may include one or more baseband processors, which are implemented using, for example, a central processing unit (CPU), digital signal processor (DSP), application-specific integrated circuit (ASIC), controller, field-programmable gate array (FPGA) device, another hardware device, firmware device, or any combination thereof configured to perform the operations described herein.

[0202] Wireless device 2002 may include memory 2006. Memory 2006 may be a non-transitory computer-readable storage medium that stores instructions 2008, which may include instructions executed, for example, by processor 2004. Instructions 2008 may also be referred to as program code or computer program. Memory 2006 may also store data used by processor 2004 and results calculated by the processor.

[0203] Wireless device 2002 may include one or more transceivers 2010, which may include radio frequency (RF) transmitter circuitry and / or receiver circuitry, which use the antenna 2012 of wireless device 2002 to facilitate signaling (e.g., signaling 2032) to and / or from wireless device 2002 and other devices (e.g., network device 2018) in accordance with the corresponding RAT.

[0204] Wireless device 2002 may include one or more antennas 2012 (e.g., one, two, four or more). In embodiments with multiple antennas 2012, wireless device 2002 may utilize spatial diversity of such multiple antennas 2012 to transmit and / or receive multiple different data streams on the same time-frequency resource. This behavior may be referred to as, for example, multiple-input multiple-output (MIMO) behavior (referring to multiple antennas used at each of the transmitting and receiving devices to implement this aspect). MIMO transmission performed by wireless device 2002 can be achieved based on pre-decoding (or digital beamforming) applied at wireless device 2002, which multiplexes data streams across antennas 2012 according to known or assumed channel characteristics, such that each data stream is received with appropriate signal strength relative to the others at a desired location in the spatial domain (e.g., the location of the receiver associated with that data stream). Some implementations may use a single-user MIMO (SU-MIMO) approach (where all data streams are directed to a single receiver) and / or a multi-user MIMO (MU-MIMO) approach (where individual data streams may be directed to individual (different) receivers at different locations in the airspace).

[0205] In some implementations with multiple antennas, the wireless device 2002 can implement analog beamforming technology, whereby the phase of the signal transmitted by the antenna 2012 is relatively adjusted so that the (joint) transmission of the antenna 2012 can be directed (this is sometimes referred to as beam control).

[0206] Wireless device 2002 may include one or more interfaces 2014. Interfaces 2014 may be used to provide input to or output to wireless device 2002. For example, wireless device 2002 as a UE may include interfaces 2014, such as microphones, speakers, touchscreens, and buttons, to allow users of the UE to make inputs and / or outputs to the UE. Other interfaces of such UEs may consist of transmitters, receivers, and other circuitry that allow the UE to communicate with other devices (e.g., in addition to the transceiver 2010 / antenna 2012 described), and may be compatible with known protocols (e.g., Wi-Fi). ® and Bluetooth ® (etc.) to perform the operation.

[0207] Wireless device 2002 may include RedCap module 2016. RedCap module 2016 may be implemented via hardware, software, or a combination thereof. For example, RedCap module 2016 may be implemented as a processor, circuitry, and / or instructions 2008 stored in memory 2006 and executed by processor 2004. In some examples, RedCap module 2016 may be integrated within processor 2004 and / or transceiver 2010. For example, RedCap module 2016 may be implemented via a combination of software components (e.g., executed by a DSP or general-purpose processor) and hardware components (e.g., logic gates and circuitry) within processor 2004 or transceiver 2010.

[0208] RedCap Module 2016 can be used in various aspects of this disclosure, for example, Figures 1 to 18 In some implementations, the RedCap module 2016 can configure the radio device 2002 to, for example, perform handover with respect to RedCap, NES, etc. (including but not limited to inter-RAT handover operations); perform condition-based handover to RedCap cells as described herein; request NSSAI in the manner described herein; and / or perform DRB release in the manner described herein.

[0209] Network device 2018 may include one or more processors 2020. Processor 2020 is executable instructions that cause various operations of network device 2018 to be performed as described herein. Processor 2020 may include one or more baseband processors, which are implemented using, for example, a CPU, DSP, ASIC, controller, FPGA device, another hardware device, firmware device, or any combination thereof configured to perform the operations described herein.

[0210] Network device 2018 may include memory 2022. Memory 2022 may be a non-transitory computer-readable storage medium that stores instructions 2024, which may include instructions that are executed, for example, by processor 2020. Instructions 2024 may also be referred to as program code or computer program. Memory 2022 may also store data used by processor 2020 and results calculated by the processor.

[0211] Network device 2018 may include one or more transceivers 2026, which may include RF transmitter circuitry and / or receiver circuitry, which use the antenna 2028 of network device 2018 to facilitate signaling (e.g., signaling 2032) to and / or from network device 2018 and other devices (e.g., wireless device 2002) in accordance with the corresponding RAT.

[0212] Network device 2018 may include one or more antennas 2028 (e.g., one, two, four or more). In embodiments having multiple antennas 2028, network device 2018 may perform MIMO, digital beamforming, analog beamforming, beam control, etc., as described.

[0213] Network device 2018 may include one or more interfaces 2030. Interface 2030 may be used to provide input to or output to network device 2018. For example, network device 2018 as a base station may include interfaces 2030 consisting of transmitters, receivers, and other circuitry (e.g., in addition to the transceiver 2026 / antenna 2028 already described), which enable the base station to communicate with other equipment in the core network and / or enable the base station to communicate with external networks, computers, databases, etc., for the purpose of performing operations, management, and maintenance of the base station or other equipment operatively connected to the base station.

[0214] The embodiments contemplated herein include an apparatus comprising components for performing one or more elements of any one or more of methods 1400, 1500, 1600, 1700, and / or 1800. The apparatus may be, for example, a UE (such as a wireless device 2002 as a UE, as described herein).

[0215] The embodiments contemplated herein include one or more non-transitory computer-readable media comprising instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of any one or more of methods 1400, 1500, 1600, 1700, and / or 1800. The non-transitory computer-readable medium may be, for example, a memory of a UE (such as memory 2006 of a wireless device 2002 serving as a UE, as described herein).

[0216] The embodiments contemplated herein include an apparatus comprising logic components, modules, or circuitry for performing one or more elements of any one or more of methods 1400, 1500, 1600, 1700, and / or 1800. The apparatus may be, for example, a UE (such as a wireless device 2002 as a UE, as described herein).

[0217] The embodiments contemplated herein include an apparatus comprising: one or more processors and one or more computer-readable media including 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 method 1400, method 1500, method 1600, method 1700, and / or method 1800. The apparatus may be, for example, a UE (such as wireless device 2002 as a UE, as described herein).

[0218] The implementation scheme envisioned herein includes a signal as described in or associated with one or more elements of any one or more of methods 1400, 1500, 1600, 1700, and / or 1800.

[0219] The embodiments contemplated herein include a computer program or computer program product comprising instructions, wherein execution by a processor will cause the processor to perform one or more elements of any one or more of method 1400, method 1500, method 1600, method 1700, and / or method 1800. The processor may be a processor of the UE (such as processor 2004 as a wireless device 2002 of the UE, as described herein). These instructions may, for example, reside in the processor and / or in the memory of the UE (such as memory 2006 as a wireless device 2002 of the UE, as described herein).

[0220] For one or more embodiments, at least one of the components illustrated in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, and / or methods as described herein. For example, a baseband processor as described herein in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples illustrated herein. Similarly, circuitry associated with a UE, base station, network element, etc., as described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples illustrated herein.

[0221] Unless otherwise expressly stated, any of the embodiments described above may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more specific embodiments provides illustrative and descriptive information, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise form disclosed. In light of the teachings above, modifications and variations are possible, or modifications and variations may be derived from practice with various embodiments.

[0222] Implementations and specific embodiments of the systems and methods described herein may include various operations embodied in machine-executable instructions to be executed by a computer system. The computer system may include one or more general-purpose or special-purpose computers (or other electronic devices). The computer system may include hardware components, including specific logical parts for performing the operations; or may include a combination of hardware, software, and / or firmware.

[0223] It should be recognized that the systems described herein include descriptions of specific implementations. These implementations may be combined into a single system, partially integrated into other systems, divided into multiple systems, or otherwise partitioned or combined. Furthermore, it is conceivable to use parameters, attributes, aspects, etc., of one implementation in one implementation. For clarity, these parameters, attributes, aspects, etc., are described only in one or more implementations, and it should be recognized that, unless expressly stated herein, these parameters, attributes, aspects, etc., may be combined with or substituted for parameters, attributes, aspects, etc., of another implementation.

[0224] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.

[0225] Although the foregoing has been described in considerable detail for clarity, it will be apparent that certain changes and modifications can be made without departing from the principles of the invention. It should be noted that there are many alternative ways to implement both the processes and apparatus described herein. Therefore, embodiments of the invention should be considered illustrative rather than restrictive, and this specification is not limited to the details given herein, but can be modified within the scope and equivalents of the appended claims.

Claims

1. A method for user equipment (UE) capable of operating in a reduced capability (RedCap) mode, the method comprising: A configuration for an inter-RAT measurement report event is received from a first base station of a first radio access network (RAN) using a first radio access technology (RAT), the configuration identifying the measurement object (MO) of a second RAN using a second RAT for the inter-RAT measurement report event. Identify that the MO of the second RAN corresponds to a RedCap frequency identified in the RedCap frequency list for the second RAN; and The MO of the second RAN is measured based on identifying that the MO corresponds to the RedCap frequency identified in the RedCap frequency list for the second RAN.

2. The method according to claim 1, further comprising: The RedCap frequency list for the second RAN is received from the second base station of the second RAN in the System Information Block (SIB); as well as Store the RedCap frequency list for the second RAN.

3. The method according to claim 1, wherein the method further comprises: The RAT inter-measurement report event has been determined to have occurred based on the measurement of the MO; The MO is determined to correspond to the first RedCap cell that provides coverage at the location of the UE based on the database stored at the UE. as well as A measurement report is transmitted to the first base station of the first RAN. The measurement report includes only one or more measurement results for one or more RedCap cells, and the one or more measurement results include a first measurement result for the first RedCap cell corresponding to the MO.

4. The method according to claim 1, wherein the method further comprises: The RAT inter-measurement report event has been determined to have occurred based on the measurement of the MO; Based on the database stored at the UE, it is determined that the UE is unaware of the existence of a RedCap cell corresponding to the MO that provides coverage at the UE's location; as well as A measurement report is transmitted to the first base station of the first RAN. The measurement report 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 includes determining whether the 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 includes a first determination of whether a first result of measuring the 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 for user equipment (UE) capable of operating in a reduced capability (RedCap) mode, the method comprising: A configuration for an inter-RAT measurement report event is received from a first base station of a first radio access network (RAN) using a first radio access technology (RAT), the configuration identifying the measurement object (MO) of a second RAN using a second RAT for the inter-RAT measurement report event. The MO of the second RAN is identified as not corresponding to any RedCap frequency identified in the RedCap frequency list for the second RAN; and Measurements of the MO for the second RAN are discarded based on the identification that the MO does not correspond to any RedCap frequency identified in the RedCap frequency list for the second RAN.

9. The method according to claim 8, further comprising: The RedCap frequency list for the second RAN is received from the second base station of the second RAN in the System Information Block (SIB); as well as Store the RedCap frequency list 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 includes determining whether the 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 includes a first determination of whether a first result of measuring the 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 for user equipment (UE) capable of operating in a reduced capability (RedCap) mode, the method comprising: The UE receives a radio resource control (RRC) reconfiguration message from a first base station of a first radio access network (RAN) using a first radio access technology (RAT), instructing the UE to perform a handover to a target cell of a second RAN using a second RAT; The target cell is determined to be a non-RedCap cell; In response to determining that the target cell is the non-RedCap cell, a radio link failure (RLF) is declared; and In response to the RLF, a system scan of the second RAN using the second RAT is performed to attempt to identify suitable RedCap cells in the second RAN.

14. The method of claim 13, wherein determining that the target cell is the non-RedCap cell includes identifying that the 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 determining that the target cell is the non-RedCap cell comprises: Initiate a four-step RACH procedure corresponding to the Random Access Channel (RACH) configuration for the target cell found in the RRC reconfiguration message; as well as The failure of the four-step RACH process is identified as corresponding to the transmission of message 3 in the four-step RACH process.

16. The method of claim 13, wherein determining that the target cell is the non-RedCap cell comprises: Initiate a two-step RACH procedure corresponding to the Random Access Channel (RACH) configuration for the target cell found in the RRC reconfiguration message; as well as The failure of the two-step RACH process is identified as corresponding to the transmission of message A in the two-step RACH process.

17. The method of claim 13, wherein performing the system scan of the second RAN includes performing measurements on one or more RedCap frequencies identified in a RedCap frequency list for the second RAN.

18. The method of claim 17, further comprising: Receive the RedCap frequency list for the second RAN from the second base station of the second RAN; as well as Store the RedCap frequency list for the second RAN.

19. The method of claim 13, further comprising: The appropriate RedCap cell of the second RAN is identified based on the system scan. as well as The system selection of the appropriate RedCap cell is performed to the second RAN.

20. The method of claim 13, further comprising: The system scan failed to identify the appropriate RedCap cell for the second RAN; as well as Start the 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 for user equipment (UE) capable of operating in a reduced capability (RedCap) mode, the method comprising: Execute the handover to the RedCap cell; It has been determined that Network Energy Saving (NES) has been enabled in the RedCap cell. It was determined that the UE required high-performance data; as well as In response to determining that the RedCap cell has NES enabled and that the UE requires high-performance data to perform a reselection to another RedCap cell.

23. The method of claim 22, wherein determining that the RedCap cell has NES enabled includes determining that the RedCap cell uses a discontinuous transmission (DTX) / discontinuous reception (DRX) configuration having both active and inactive 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 for a user equipment (UE) capable of operating in a reduced-capacity (RedCap) mode and connected to a first radio access network (RAN) using a first radio access technology (RAT), the method comprising: Based on the database stored at the UE, the RedCap cell of the second RAN using the second RAT is determined to provide coverage at the location of the UE; Determine that the RedCap cell corresponds to a RedCap frequency identified in the RedCap frequency list for the second RAN; and In response to determining that the RedCap cell provides coverage at the location of the UE and determining that the RedCap cell corresponds to the RedCap frequency identified in the RedCap frequency list for the second RAN, a handover of the RedCap cell to the second RAN is performed.

28. The method of claim 27, wherein the first RAT comprises LTE, and wherein the second RAT comprises NR.

29. An apparatus comprising components for performing the method according to any one of claims 1 to 28.

30. A computer-readable medium comprising instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform the method according to any one of claims 1 to 28.

31. An apparatus comprising a logic component, module, or circuit for performing the method according to any one of claims 1 to 28.

Images