BWP-based operation for REDCAP user devices

Abstract

This device provides a bandwidth portion (BWP) based operation for REDCAP user equipment. [Solution] A method for configuring the UE for RedCap (Reduced Capability) operation involves decrypting the Master Information Block (MIB) to determine the Control Resource Set (CORESET) and Common Search Space (CSS), decrypting the System Information Block (SIB) in the scheduled Physical Downlink Shared Channel (PDSCH) using Downlink Control Information (DCI), using the SIB to determine an additional CORESET in a separate Initial DL BWP, and in the separate Initial DL BWP, performing reception of the PDCCH or PDSCH associated with the Random Access procedure in the Physical Downlink Control Channel (PDCCH) Type 1 Common Search Space (CSS) set.

Description

Technical Field

[0001] This application claims the benefit of priority to the following U.S. provisional patent applications.

[0002] U.S. Provisional Patent Application No. 63 / 167,580, filed May 29, 2021, entitled "BANDWIDTH PART (BWP)-BASED OPERATIONS FOR REDCAP USER EQUIPMENTS IN RADIO RESOURCE CONTROL (RRC) IDLE OR RRC INACTIVE MODES".

[0003] U.S. Provisional Patent Application No. 63 / 171,982, filed April 7, 2021, entitled "BANDWIDTH PART (BWP)-BASED OPERATIONS FOR REDCAP USER EQUIPMENTS IN RADIO RESOURCE CONTROL (RRC) IDLE OR RRC INACTIVE MODES".

[0004] U.S. Provisional Patent Application No. 63 / 186,736, filed May 10, 2021, entitled "BANDWIDTH PART (BWP)-BASED OPERATIONS FOR REDCAP USER EQUIPMENTS IN RADIO RESOURCE CONTROL (RRC) IDLE OR RRC INACTIVE MODES".

[0005] U.S. Provisional Patent Application No. 63 / 251,298, filed October 1, 2021, entitled "BANDWIDTH PART (BWP)-BASED OPERATIONS FOR REDCAP USER EQUIPMENTS IN RADIO RESOURCE CONTROL (RRC) IDLE OR RRC INACTIVE MODES".

[0006] U.S. Provisional Patent Application No. 63 / 254,847, filed on October 12, 2021, is titled "BANDWIDTH PART (BWP)-BASED OPERATIONS FOR REDCAP USER EQUIPMENTS IN RADIO RESOURCE CONTROL (RRC) IDLE OR RRC INACTIVE MODES".

[0007] Each of the patent applications listed above is incorporated herein by reference in its entirety.

[0008] The embodiments relate to wireless communications. Some embodiments relate to 5G networks and above, including 3GPP® (Third Generation Partnership Project) networks, 3GPP LTE (Long Term Evolution) networks, 3GPP LTE-A (LTE Advanced) networks, (MulteFire, LTE-U), and 5G (fifth-generation) NR (new radio) (or 5G-NR) networks, 5G-LTE networks such as 5G NR unlicensed spectrum (NR-U) networks, and wireless networks including other unlicensed networks such as Wi-Fi and CBRS (OnGo). Other embodiments relate to techniques for configuring bandwidth portion (BWP) based operation for RedCap (Reduced Capacity) user equipment (UEs) (e.g., UEs in RRC idle mode and RRC inactive mode) in 5G-NR (and above) networks. [Background technology]

[0009] Mobile communications have evolved significantly from early voice systems to today's highly sophisticated integrated communication platforms. The increasing number of different types of devices communicating with various network devices has led to increased use of 3GPP LTE systems. The penetration of mobile devices (user equipment, or UE) into modern society has continued to drive the demand for diverse network-connected devices in many diverse environments. 5G (fifth-generation) wireless systems are on the horizon, expected to enable faster speeds, greater connectivity, and improved usability. Next-generation 5G networks (or NR networks) are expected to improve throughput, coverage, and robustness, while reducing latency and operational and capital expenditures. 5G-NR networks will continue to evolve based on 3GPP LTE-Advanced, along with additional possible new radio access technologies (RATs), to enrich people's lives with seamless wireless connectivity solutions that deliver high-speed, rich content and services. As current cellular network frequencies become saturated, higher frequencies, such as millimeter-wave (mmWave) frequencies, may be beneficial due to their higher bandwidth.

[0010] Possible LTE operations in the unlicensed spectrum include (but are not limited to) LTE operations in the unlicensed spectrum via DC (dual connectivity) or DC-based LAA, and standalone LTE systems in the unlicensed spectrum. According to this, LTE-based technologies operate only in the unlicensed spectrum without requiring an "anchor" in the unlicensed spectrum, known as MulteFire. Further enhanced operation of LTE and NR systems in the licensed spectrum, as well as the unlicensed spectrum, is expected in future releases and 5G (and above) systems. Such enhanced operation may include techniques for configuring BWP-based operation for RedCap UEs (e.g., UEs in RRC idle mode and RRC inactive mode) in 5G-NR (and above) networks. [Brief explanation of the drawing]

[0011] In the diagrams, the figures are not necessarily drawn to scale, and similar numbers may represent similar elements from different perspectives. Similar numbers with different suffixes may represent different examples of similar components. The diagrams are illustrative, not limiting, and generally illustrate the various aspects discussed in this document.

[0012] [Figure 1A] Several network architectures are illustrated below.

[0013] [Figure 1B] Several non-roaming 5G system architectures are illustrated below. [Figure 1C] Several non-roaming 5G system architectures are illustrated below.

[0014] [Figure 2] Various systems, devices, and components that can implement aspects of the disclosed embodiments are illustrated below. [Figure 3] Various systems, devices, and components that can implement aspects of the disclosed embodiments are illustrated below. [Figure 4] Various systems, devices, and components that can implement aspects of the disclosed embodiments are illustrated below.

[0015] [Figure 5] The following diagrams illustrate exemplary separate initial downlink (DL)BWP configuration options in several different configurations.

[0016] [Figure 6] This document illustrates different physical random access channel (PRACH) resources for RedCap and non-RedCap UEs in different initial uplink (UL) BWPs, across several configurations.

[0017] [Figure 7] Block diagrams illustrating various forms of communication devices, such as advanced Node-B, next-generation Node-B (gNB) (or another RAN node or base station), transmit / receive points (TRP), access points (AP), radio stations (STA), mobile stations (MS), and user equipment (UE), are provided as examples. [Modes for carrying out the invention]

[0018] The following description and drawings are sufficient illustrations of the embodiments so that those skilled in the art can implement them. Other embodiments may incorporate structural, logical, electrical, process, and other modifications. Some parts and features of some embodiments may be included in or replaced by those of other embodiments. The embodiments outlined in the claims encompass all available equivalents of those claims.

[0019] Figure 1A illustrates several network architectures. Network 140A is shown to include user devices (UEs) 101 and UE102. UE101 and UE102 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 devices, such as personal data assistants (PDAs), pagers, laptop computers, desktop computers, wireless handsets, drones, or any other computing devices including wired and / or wireless communication interfaces. UE101 and UE102 may be collectively referred to as UE101 in this specification, and UE101 can be used to perform one or more of the technologies disclosed herein.

[0020] Any of the wireless links described herein (such as those used in Network 140A or any other illustrated network) may operate according to any exemplary wireless communication technology and / or standard.

[0021] LTE and LTE-Advanced are standards for wireless communication of high-speed data for UEs such as mobile phones. In LTE-Advanced and various wireless systems, carrier aggregation may carry communications for a single UE using multiple carrier signals operating at different frequencies, thereby increasing the bandwidth available to a single device. In some aspects, carrier aggregation may be used when one or more component carriers operate in unlicensed frequencies.

[0022] The aspects described herein may be used in any spectrum management scheme, including, for example, licensed spectrum, unlicensed spectrum, (licensed) shared spectrum (such as LSA (Licensed Shared Access) in 2.3 - 2.4 GHz, 3.4 - 3.6 GHz, 3.6 - 3.8 GHz and above, SAS (Spectrum Access System) in 3.55 - 3.7 GHz and above).

[0023] The aspects described herein can also be applied to different single carriers or OFDM flavors (CP-OFDM, SC-FDMA, SC-OFDM, filter bank-based multi-carrier (FBMC), OFDMA, etc.), particularly 3GPP NR (New Radio), by allocating OFDM carrier data bit vectors to corresponding symbol resources.

[0024] In some embodiments, either UE101 or 102 may include an Internet of Things (IoT) UE or a Cellular IoT (CIoT) UE, which may include a network access layer designed for low-power IoT applications that utilize short-lived UE connections. In some embodiments, either UE101 or 102 may include a narrowband (NB) IoT UE (e.g., eNB-IoT (enhanced NB-IoT) UE and FeNB-IoT (Further Enhanced NB-IoT) UE). The IoT UE may utilize technologies such as M2M (machine-to-machine) or MTC (machine-type communication) to exchange data with an MTC server or device via PLMN (public land mobile network), ProSe (Proximity-Based Service), or D2D (device-to-device) communication, a sensor network, or an IoT network. The M2M or MTC data exchange may be machine-activated data exchange. An IoT network includes interconnecting IoT UEs, which may include embedded computing devices that are uniquely identifiable (within the internet infrastructure) with short-lived connections. IoT UEs may run background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connectivity within the IoT network.

[0025] In some embodiments, either UE101 or UE102 may include eMTC (enhanced MTC)UE or FeMTC (further enhanced MTC)UE.

[0026] UE101 and UE102 may be configured to connect to, for example, a radio access network (RAN) 110, for example, to be communicatively coupled. RAN110 may be, for example, a Universal Mobile Telecommunications System (UMTS), an Evolved Universal Terrestrial Radio Access Network (E-UTRAN), a NextGen RAN (NG RAN), or some other type of RAN. UE101 and 102 utilize connections 103 and 104, respectively (which will be discussed further below), each including a physical communication interface or layer. In this example, connections 103 and 104 are exemplified as air interfaces enabling communication coupling and can be compatible with cellular communication protocols such as GSM (Global System for Mobile Communications) protocol, Code Division Multiple Access (CDMA) network protocol, PTT (Push-to-Talk) protocol, POC (PTT over Cellular) protocol, UMTS (Universal Mobile Telecommunications System) protocol, 3GP LTE (Long Term Evolution) protocol, 5th generation (5G) protocol, and NR (New Radio) protocol.

[0027] In one embodiment, UE101 and UE102 may further directly exchange communication data via the ProSe interface 105. The ProSe interface 105 may also be referred to as a sidelink interface including one or more logical channels, including, but not limited to, PSCCH (Physical Sidelink Control Channel), PSSCH (Physical Sidelink Shared Channel), PSDCH (Physical Sidelink Discovery Channel), and PSBCH (Physical Sidelink Broadcast Channel).

[0028] UE102 is shown configured to access access point (AP) 106 via connection 107. Connection 107 can include a local wireless connection, such as a connection compatible with any IEEE 802.11 protocol, and accordingly, AP106 can include a WiFi® (wireless fidelity) router. In this example, AP106 is shown to connect to the internet without connecting to the core network of the wireless system (described further below).

[0029] RAN110 may include one or more access nodes that enable connections 103 and 104. These access nodes (ANs) may be called base stations (BS), NodeBs, eNBs (evolved NodeBs), gNBs (Next Generation NodeBs), RAN network nodes, etc., and may include ground stations (e.g., land access points) or satellite stations that provide coverage within a geographical area (e.g., a cell). In some embodiments, communication nodes 111 and 112 may be transmit / receive points (TRPs). In instances where communication nodes 111 and 112 are NodeBs (e.g., eNBs or gNBs), one or more TRPs may function within the communication cell of a NodeB. RAN110 may include one or more RAN nodes for providing macrocells, e.g., a macroRAN node 111, and one or more RAN nodes for providing femtocells or picocells (e.g., cells with smaller coverage area, smaller user capacity, or larger bandwidth compared to macrocells), e.g., a low-power (LP) RAN node 112 or a license-free spectrum-based secondary RAN node 112.

[0030] Both RAN node 111 and RAN node 112 can terminate the air interface protocol and can serve as the first contacts for UE101 and UE102. In some embodiments, either RAN node 111 or RAN node 112 can perform various logical functions for RAN110, including, but not limited to, radio network controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management, data packet scheduling, and mobility management. For example, either node 111 and / or node 112 can be a gNB (new generation Node-B), an eNB (evolved node-B), or another type of RAN node.

[0031] It is shown that RAN110 is communicably coupled to the core network (CN) 120 via the S1 interface 113. In this embodiment, CN120 may be an EPC (evolved packet core) network, an NPC (NextGen Packet Core) network, or any other type of CN (for example, as illustrated with reference to Figures 1B-1C). In this embodiment, the S1 interface 113 is split into two parts: the S1-U interface 114, which carries user traffic data between RAN nodes 111 and 112 and the service gateway (S-GW) 122, and the S1-Mobility Management Entity (MME) interface 115, which is a signaling interface between RAN nodes 111 and 112 and the MME 121.

[0032] In this embodiment, CN120 includes MME121, S-GW122, P-GW (PDN (Packet Data Network) Gateway)123, and HSS (home subscriber server)124. MME121 may be functionally similar to the control plane of a legacy SGSN (GPRS (Serving General Packet Radio Service) Support Node). MME121 may manage mobility aspects in access, such as gateway selection and tracking area list management. HSS124 may include a database for network users, including subscriber-related information to support the processing of communication sessions of network entities. CN120 may include one or more HSS124 depending on the number of mobile subscribers, equipment capacity, network organization, etc. For example, HSS124 can provide support for routing / roaming, authentication, authorization, naming / address resolution, location dependency, etc.

[0033] S-GW122 may terminate the S1 interface 113 toward RAN110 and route data packets between RAN110 and CN120. Additionally, S-GW122 may be a local mobility anchor point for handovers between RAN nodes and may also provide an anchor for inter-3GPP mobility. Other responsibilities of S-GW122 may include lawful interception, billing, and any policy enforcement.

[0034] P-GW123 may terminate the SGi interface to the PDN. P-GW123 may route data packets between the EPC network 120 and an external network (alternatively referred to as an Application Function (AF)), such as a network containing an application server 184, via an Internet Protocol (IP) interface 125. P-GW123 can also communicate data with other external networks 131A, which may include the Internet, an IPS (IP multimedia subsystem) network, and other networks. Generally, the application server 184 may be an element that provides applications that use IP bearer resources together with the core network (e.g., a UMTS PS (Packet Services) domain, an LTE PS data service, etc.). In this embodiment, it is shown that P-GW123 is communicably coupled to the application server 184 via the IP interface 125. The application server 184 can also be configured to support one or more communication services for UE101 and 102 via CN120 (e.g., VoIP (Voice-over-Internet Protocol) sessions, PTT sessions, group communication sessions, social networking services, etc.).

[0035] P-GW123 may also be a node for policy enforcement and billing data collection. PCRF (Policy and Charging Rules Function)126 is the policy and billing control element of CN120. In non-roaming scenarios, in some embodiments, there may be a single PCRF in the HPLMN (Home Public Land Mobile Network) associated with the UE's IP-CAN (Internet Protocol Connectivity Access Network) session. In roaming scenarios using local breakout of traffic, there may be two PCRFs associated with the UE's IP-CAN session, namely, an H-PCRF (Home PCRF) in the HPLMN and a V-PCRF (Visited PCRF) in the VPLMN (Visited Public Land Mobile Network). PCRF126 may be communicably coupled to the application server 184 via P-GW123.

[0036] In some embodiments, the communication network 140A may be a 5G network including an IoT network or a 5G new radio network using licensed (5G NR) spectrum and unlicensed (5G NR-U) spectrum communications. One of the current enablers of IoT is NB-IoT (narrowband-IoT).

[0037] The NG system architecture may include a RAN 110 and a 5G network core (5GC) 120. The NG-RAN 110 may include multiple nodes such as gNBs and NG-eNBs. The core network 120 (e.g., a 5G core network or 5GC) may include access and mobility functions (AMF) and / or user plane functions (UPF). The AMF and UPF can be communicatively coupled to the gNB and NG-eNB via NG interfaces. More specifically, in some embodiments, the gNB and NG-eNB may be connected to the AMF via an NG-C interface and to the UPF via an NG-U interface. The gNB and NG-eNB may be coupled to each other via an Xn interface.

[0038] In some embodiments, the NG system architecture can use reference points between various nodes, as provided by 3GPP TS (Technical Specification) 23.501 (e.g., V15.4.0, 2018-12). In some embodiments, each of the gNB and NG-eNB can be implemented as a base station, mobile edge server, small cell, home eNB, RAN network node, etc. In some embodiments, in a 5G architecture, the gNB can be the master node (MN) and the NG-eNB can be the secondary node (SN). In some embodiments, the master / primary node may operate in licensed bandwidth, and the secondary node may operate in unlicensed bandwidth.

[0039] Figure 1B illustrates several non-roaming 5G system architectures. Referring to Figure 1B, a 5G system architecture 140B in reference point representation is illustrated. More specifically, UE 102 can communicate with RAN 110 as well as one or more other 5G core (5GC) network entities. The 5G system architecture 140B includes several network functions (NFs), such as Access and Mobility Management Function (AMF) 132, Location Management Function (LMF) 133, Session Management Function (SMF) 136, Policy Control Function (PCF) 148, Application Function (AF) 150, User Plane Function (UPF) 134, Network Slice Selection Function (NSSF) 142, Authentication Server Function (AUSF) 144, and Integrated Data Management (UDM) / Home Subscriber Server (HSS) 146. The UPF 134 can provide connectivity to a data network (DN) 152, which may include, for example, operator services, internet access, or third-party services. AMF132 can be used to manage access control and mobility, and may also include network slice selection functionality. SMF136 can be configured to set up and manage various sessions according to network policies. UPF134 can be deployed in one or more configurations according to the desired service type. PCF148 can be configured to provide a policy framework using network slicing, mobility management, and roaming (similar to PCRF in 4G communication systems). UDM can be configured to store subscriber profiles and data (similar to HSS in 4G communication systems).

[0040] The LMF133 may be used in connection with 5G positioning functionality. In some embodiments, the LMF133 receives measurements and support information from the Next Generation Radio Access Network (NG-RAN) 110 and a mobile device (e.g., UE101) via the NLs interface through the AMF132, and calculates the position of the UE101. In some embodiments, positioning information may be carried between the NG-RAN and the LMF133 via the Next Generation Control Plane Interface (NG-C) using the NR Positioning Protocol A (NRPPa). In some embodiments, the LMF133 sets the UE using the LTE Positioning Protocol (LPP) via the AMF132. The NG-RAN 110 sets the UE101 using the Radio Resource Control (RRC) protocol via the LTE-Uu and NR-Uu interfaces.

[0041] In some embodiments, the 5G system architecture 140B sets up different reference signals to enable positioning measurements. Exemplary reference signals that may be used for positioning measurements include a downlink positioning reference signal (NR PRS) and an uplink sounding reference signal (SRS) for positioning. The downlink positioning reference signal (PRS) is a reference signal set up to support a downlink-based positioning method.

[0042] In some embodiments, the 5G system architecture 140B includes an IP multimedia subsystem 168B and several IP multimedia core network subsystem entities such as a Call Session Control Function (CSCF). More specifically, the IMS 168B includes a CSCF that can act as a P-CSCF (proxy CSCF) 162B, an S-CSCF (serving CSCF) 164B, an E-CSCF (emergency CSCF) (not illustrated in Figure 1B), or an I-CSCF (interrogating CSCF) 166B. The P-CSCF 162B can be configured to be a first contact for the UE 102 in the IM subsystem 168B. The S-CSCF 164B can be configured to handle session state in the network, and the E-CSCF can be configured to handle certain aspects of emergency sessions, such as routing emergency requests to the correct emergency center or PSAP. The I-CSCF166B can be configured to function as a point of contact within the operator's network for all IMS connections directed to the network operator's subscribers or roaming subscribers currently located within the network operator's service area. In some embodiments, the I-CSCF166B can connect to another IP multimedia network 170E, for example, an IMS operated by another network operator.

[0043] In some embodiments, the UDM / HSS146 may be coupled to an application server 160E which may include a telephone application server (TAS) or another application server (AS). The AS160B may be coupled to the IMS168B via the S-CSCF164B or I-CSCF166B.

[0044] Reference point representation indicates that interactions may exist between corresponding NF services. For example, Figure 1B shows reference points, i.e., N1 (between UE102 and AMF132), N2 (between RAN110 and AMF132), N3 (between RAN110 and UPF134), N4 (between SMF136 and UPF134), N5 (between PCF148 and AF150, not shown), N6 (between UPF134 and DN152), N7 (between SMF136 and PCF148, not shown), N8 (between UDM146 and AMF132, not shown), N9 (between two UPF134s, not shown), N10 (between UDM146 and SMF136 and Examples include N11 (between AMF132 and SMF136, not shown), N12 (between AUSF144 and AMF132, not shown), N13 (between AUSF144 and UDM146, not shown), N14 (between two AMFs, not shown), N15 (between PCF148 and AMF132 in a non-roaming scenario, and between PCF148 and the visited network and AMF132 in a roaming scenario, not shown), N16 (between two SMFs, not shown), and N22 (between AMF132 and NSSF142, not shown). Other reference point representations not shown in Figure 1B can also be used.

[0045] Figure 1C illustrates a 5G system architecture 140C and a service-based representation. In addition to the network entities illustrated in Figure 1B, the system architecture 140C may also include a network exposure function (NEF) 154 and a network repository function (NRF) 156. In some embodiments, the 5G system architecture can be service-based, and interactions between network functions can be represented by corresponding point-to-point reference points Ni or as service-based interfaces.

[0046] In some embodiments, as illustrated in Figure 1C, service-based representations can be used to represent network functions within the control plane that enable other authorized network functions to access those services. In this regard, the 5G system architecture 140C may include service-based interfaces, namely Namf 158H (a service-based interface exposed by AMF 132), Nsmf 158I (a service-based interface presented by SMF 136), Nnef 158B (a service-based interface presented by NEF 154), Npcf 158D (a service-based interface presented by PCF 148), Nudm 158E (a service-based interface presented by UDM 146), NaF 158f (a service-based interface presented by AF 150), Nnrf 158C (a service-based interface presented by NRF 156), Nnssf 158A (a service-based interface presented by NSSF 142), and Nausf 158G (a service-based interface presented by AUSF 144). Other service-based interfaces not shown in Figure 1C (e.g., Nudr, N5g-eir, and Nudsf) can also be used.

[0047] Figures 2, 3, and 4 illustrate various systems, devices, and components that may implement aspects of the disclosed embodiments in different communication systems, such as 5G-NR (and above) networks. The UEs, base stations (such as gNBS), and / or other nodes (e.g., satellites or other NTN nodes) discussed in relation to Figures 1A to 4 may be configured to perform the disclosed technologies.

[0048] Figure 2 illustrates various embodiments of the wireless network 200. The network 200 may operate in a manner consistent with the 3GPP technical specifications for LTE or 5G / NR systems. However, the exemplary embodiments are not limited in this respect, and the embodiments described may be applied to other networks that benefit from the principles described herein, such as future 3GPP systems.

[0049] Network 200 may include UE202, which may include any mobile or non-mobile computing device designed to communicate with RAN204 via an over-the-air connection. UE202 may be, but is not limited to, a smartphone, tablet computer, wearable computing device, desktop computer, laptop computer, in-vehicle infotainment, in-vehicle entertainment device, instrument cluster, head-up display device, onboard diagnostic device, dashboard mobile device, mobile data terminal, electronic engine management system, electronic / engine control unit, electronic / engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked appliance, machine-type communication device, M2M or D2D device, IoT device, etc.

[0050] In some embodiments, the network 200 may include multiple UEs directly coupled to one another via a sidelink interface. The UEs may be M2M / D2D devices that communicate using physical sidelink channels such as PSBCH, PSDCH, PSSCH, PSCCH, and PSFCH.

[0051] In some embodiments, UE202 may communicate additionally with AP206 via an over-air connection. AP206 may manage the wireless LAN connection, which helps offload some / all network traffic from RAN204. The connection between UE202 and AP206 may be compatible with any IEEE 802.11 protocol, and AP206 can be a Wi-Fi (wireless fidelity) router. In some embodiments, UE202, RAN204, and AP206 may utilize cellular WLAN aggregation (e.g., LWA / LWIP). Cellular WLAN aggregation may involve RAN204 configuring UE202 to utilize both cellular radio resources and WLAN resources.

[0052] RAN204 may include one or more access nodes, for example, access node (AN)208. AN208 may terminate the air interface protocol for UE202 by providing access layer protocols including RRC, PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC, and L1 protocols. In this way, AN208 may enable data / voice connectivity between the core network (CN)220 and UE202. In some embodiments, AN208 may be implemented as a discrete device or as one or more software entities running on a server computer as part of a virtual network sometimes called CRAN or virtual baseband unit pool. AN208 is referred to as BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, TRP, etc. AN208 may be a macrocell base station or a low-power base station for providing a femtocell, picocell, or other similar cell with a smaller coverage area, smaller user capacity, or larger bandwidth compared to a macrocell.

[0053] In embodiments where RAN204 includes multiple ANs, they may be coupled to each other via an X2 interface (if RAN204 is an LTE RAN) or an Xn interface (if RAN204 is a 5G RAN). The X2 / Xn interface may be separated into a control / user plane interface in some embodiments, which may allow ANs to communicate information related to handover, data / context transfer, mobility, load management, interference adjustment, etc.

[0054] Each AN of RAN204 may manage one or more cells, cell groups, component carriers, etc., and provide an air interface for network access to UE202. UE202 may be simultaneously connected to multiple cells provided by the same or different ANs of RAN204. For example, UE202 and RAN204 may use carrier aggregation to enable UE202 to connect to multiple component carriers, each corresponding to a P-cell or S-cell. In a dual connectivity scenario, the first AN may be a master node providing an MCG, and the second AN may be a secondary node providing an SCG. The first / second ANs may be any combination of eNBs, gNBs, ng-eNBs, etc.

[0055] RAN204 may provide an air interface via a licensed spectrum or an unlicensed spectrum. To operate in the unlicensed spectrum, a node may use LAA, eLAA, and / or feLAA mechanisms based on CA technology with PCells / Scells. Before accessing the unlicensed spectrum, a node may perform a medium / carrier detection operation, for example, based on the LBT (listen-before-talk) protocol.

[0056] In a V2X scenario, UE202 or AN208 is or may act as a Roadside Unit (RSU), which refers to any transport infrastructure entity used for V2X communication. The RSU may be implemented in a suitable AN or a stationary (or relatively stationary) UE. An RSU implemented in or by a UE may be called a “UE-type RSU,” an eNB may be called an “eNB-type RSU,” a gNB may be called a “gNB-type RSU,” and so on. In one example, the RSU is a computing device coupled with roadside radio frequency circuitry that provides to a vehicle UE passing through connectivity support. The RSU may also include an internal data storage circuitry mechanism that stores intersection map shapes, traffic statistics, media, and applications / software for sensing and controlling oncoming vehicle and pedestrian traffic. The RSU may provide very low-latency communication required for high-speed events such as collision avoidance and traffic warnings. Additionally or alternatively, the RSU may provide other cellular / WLAN communication services. The RSU components may be packaged in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller that provides wired connectivity (e.g., Ethernet) to a traffic signaling controller or backhaul network.

[0057] In some embodiments, RAN204 may be an LTE RAN210 having an eNB, eNB212, for example. The LTE RAN210 may provide an LTE air interface having characteristics such as a 15 kHz subcarrier spacing (SCS), CP-OFDM waveforms (DL) for the downlink (DL) and SC-FDMA waveforms (UL) for the uplink (UL), turbo code for data and TBCC for control. The LTE air interface may rely on CSI-RS for CSI acquisition and beam management, PDSCH / PDCCH DMRS for PDSCH / PDCCH demodulation, cell search and initial acquisition for coherent demodulation / detection in the UE, CRS for channel quality measurement and channel estimation. The LTE air interface may operate in the sub-6 GHz band.

[0058] In some embodiments, the RAN204 may be an NG-RAN214 having a gNB, e.g., gNB216, or an ng-eNB, e.g., ng-eNB218. The gNB216 may connect to the 5G Enable UE using a 5G NR interface. The gNB216 may connect to the 5G core via an NG interface including an N2 interface or an N3 interface. The ng-eNB218 may also connect to the 5G core via an NG interface, or it may connect to the UE via an LTE Air interface. The gNB216 and ng-eNB218 may connect via an Xn interface.

[0059] In some embodiments, the NG interface may be split into two parts: an NG user plane (NG-U) interface (e.g., N3 interface) that carries traffic data between the NG-RAN214 nodes and the UPF248, and an NG control plane (NG-C) interface (e.g., N2 interface) that is a signaling interface between the NG-RAN214 nodes and the AMF244.

[0060] NG-RAN214 may provide a 5G-NR air interface having the characteristics of variable SCS, CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL, polar, iterative, simple, and Reed-Muller code for control, and LDPC for data. The 5G-NR air interface may depend on CSI-RS and PDSCH / PDCCH DMRS, similar to an LTE air interface. The 5G-NR air interface may not use CRS and may use PBCH DMRS for PBCH demodulation, PTRS for PDSCH phase tracking, and a tracking reference signal for time tracking. The 5G-NR air interface may operate in the sub-6GHz band including the 24.25GHz to 52.6GHz band or the FR1 band including the FR2 band. The 5G-NR air interface may include a synchronization signal and a physical broadcast channel (SS / PBCH) block (SSB), which is an area of ​​the downlink resource grid including PSS / SSS / PBCH.

[0061] In some embodiments, the 5G-NR air interface may utilize the Bandwidth Part (BWP) for various purposes. For example, the BWP can be used for dynamic adaptation of the SCS. For instance, multiple BWPs may be configured on the UE202, each with a different SCS. When a BWP change is indicated to the UE202, the transmit SCS is also changed accordingly. Another use case example of the BWP relates to power saving. In particular, multiple BWPs may be configured on the UE202 with different amounts of frequency resources (e.g., PRBs) to support data transmission under different traffic load scenarios. A BWP with fewer PRBs can be used for data transmission with a small traffic load on the UE202, and possibly the gNB216, while enabling power saving. A BWP with more PRBs can be used for scenarios with a higher traffic load.

[0062] RAN204 is communicatively coupled to CN220, which includes network elements, to provide customers / subscribers (e.g., users of UE202) with various functions to support data and communication services. The components of CN220 may be implemented on one physical node or separate physical nodes. In some embodiments, NFV may be used to virtualize some or all of the functions provided by the network elements of CN220 onto physical computing / storage resources such as servers and switches. A logical instantiation of CN220 may be called a network slice, and a logical instantiation of a portion of CN220 may be called a network subslice.

[0063] In some embodiments, CN220 may be connected to an LTE radio network as part of an Enhanced Packet System (EPS) 222, sometimes also called an EPC (or Enhanced Packet Core). The EPC222 may include MME224, SGW226, SGSN228, HSS230, PGW232, and PCRF234 coupled to each other via interfaces (or "reference points"), as shown in the figure. The function of each element of the EPC222 may be briefly described below.

[0064] The MME224 may implement mobility management features that track the current location of the UE202 to facilitate paging, bearer activation / deactivation, handover, gateway selection, authentication, etc.

[0065] SGW226 may terminate the S1 interface toward the RAN and route data packets between the RAN and EPC222. Additionally, S-GW226 may be a local mobility anchor point for handovers between RAN nodes and may also provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful interception, billing, and any policy enforcement.

[0066] SGSN228 may track the location of UE202 and perform security functions and access control. Additionally, SGSN228 may perform EPC node-to-node signaling for mobility between different RAT networks, PDN and S-GW selection identified by MME224, and MME selection for handover. An S3 reference point between MME224 and SGSN228 may enable information exchange between users and bearers for 3GPP inter-access network mobility in idle / active states.

[0067] The HSS230 may include a database for network users, containing subscriber-related information to support the processing of communication sessions for network entities. The HSS230 can provide support for routing / roaming, authentication, authorization, naming / address resolution, location dependency, etc. An S6a reference point between the HSS230 and the MME224 may enable the transfer of subscription and authentication data for authenticating / authorizing user access to the LTE CN220.

[0068] PGW232 may terminate its SGi interface toward a data network (DN) 236 which may include an application / content server 238. PGW232 may route data packets between the LTE CN 220 and the data network 236. PGW232 may be coupled to SGW226 by an S5 reference point to facilitate user plane tunneling and tunnel management. PGW232 may further include nodes for policy enforcement and billing data collection (e.g., PCEF). Additionally, the SGi reference point between PGW232 and the data network 236 may be, for example, an operator-external public, private PDN, or operator-internal packet data network for providing IMS services. PGW232 may be coupled to PCRF234 via a Gx reference point.

[0069] PCRF234 is a policy and billing control element of LTE CN220. PCRF234 may be communicatively coupled with the application / content server 238 to determine appropriate QoS and billing parameters for the service flow. PCRF234 may provide rules related to PCEF (via the Gx reference point) along with appropriate TFT and QCI.

[0070] In some embodiments, CN220 may be 5GC240. 5GC240 may include AUSF242, AMF244, SMF246, UPF248, NSSF250, NEF252, NRF254, PCF256, UDM258, and AF260 coupled to one another via interfaces (or "reference points"), as shown in the figure. The function of each element of 5GC240 may be briefly described below.

[0071] AUSF242 may store data for authentication of UE202 and handle authentication-related functionality. AUSF242 may facilitate a common authentication framework for various access types. In addition to communicating with other elements of 5GC240 via a reference point as shown in the figure, AUSF242 may present a Nausf service-based interface.

[0072] The AMF244 may enable other functions of the 5GC240 to communicate with the UE202 and RAN204 and subscribe to notifications regarding mobility events related to the UE202. The AMF244 may be responsible for registration management (e.g., for registering the UE202), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. The AMF244 provides transport for SM messages between the UE202 and SMF246 and acts as a transparent proxy for routing SM messages. The AMF244 may also provide transport for SMS messages between the UE202 and SMSF. The AMF244 may interact with the AUSF242 and UE202 to perform various security anchor and context management functions. Furthermore, AMF244 may include an N2 reference point between RAN204 and AMF244, or may be the endpoint of a RAN CP interface which may be an N2 reference point, and AMF244 may be the endpoint of NAS(N1) signaling and perform NAS encryption and integrity protection. AMF244 may also support NAS signaling with UE202 via an N3 IWF interface.

[0073] SMF246 may be responsible for SM (e.g., session establishment, tunnel management between UPF248 and AN208), UE IP address allocation and management (including optional authorization), selection and control of UP functions, configuring traffic steering on UPF248 to route traffic to appropriate destinations, termination of interfaces toward policy control functions, policy enforcement, billing, and some control of QoS, lawful interception (for SM events and interfaces to LI systems), termination of SM portions of NAS messages, downlink data notification, initiation of AN-specific SM information sent to AN208 via AMF244 through N2, and determining the SSC mode of the session. SM may also refer to the management of PDU sessions, and PDU sessions or “session” may refer to PDU connectivity services that provide or enable the exchange of PDUs between UE202 and data network 236.

[0074] UPF248 may act as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point interconnecting to data network 236, and a branch point to support multi-homed PDU sessions. UPF248 may also perform packet routing and forwarding, perform packet inspection, enforce the user plane portion of policy rules, lawfully intercept packets (UP collection), perform traffic usage reporting, perform QoS processing for the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), perform uplink traffic validation (e.g., SDF-to-QoS flow mapping), mark transport level packets on the uplink and downlink, and perform downlink packet buffering and downlink data notification triggers. UPF248 may include an uplink classifier to support routing traffic flows to the data network.

[0075] NSSF250 may select a set of network slice instances to serve UE202. NSSF250 may also determine, if necessary, mappings to enabled NSSAI and subscribed S-NSSAI. NSSF250 may also determine a list of candidate AMFs, either by querying NRF254 if possible, based on the set of AMFs to be used to serve UE202 or a preferred configuration. The selection of a set of network slice instances for UE202 may be triggered by AMF244, to which UE202 is registered, by interacting with NSSF250, which may lead to a change in AMF. NSSF250 may interact with AMF244 via the N22 reference point, or communicate with another NSSF in the visited network via the N31 reference point (not shown). Additionally, NSSF250 may present an Nnssf service-based interface.

[0076] NEF252 may securely expose services and capabilities provided by 3GPP network functions to third parties, internal public / republishing, AFs (e.g., AF260), edge computing, or fog computing systems. In such embodiments, NEF252 may authenticate, authorize, or restrict AFs. NEF252 may also translate information exchanged with AF260 and information exchanged with internal network functions. For example, NEF252 may translate between AF service identifiers and internal 5GC information. NEF252 may also receive information from other NFs based on the exposed capabilities of those NFs. This information may be stored in NEF252 as structured data, or in a data storage NF using a standardized interface. The stored information can then be republished by NEF252 to other NFs and AFs, or used for other purposes such as analysis. Additionally, NEF252 may present an Nnef service-based interface.

[0077] The NRF254 may support service discovery functionality, receive NF discovery requests from NF instances, and provide the NF instances with information about discovered NF instances. The NRF254 also maintains information about available NF instances and the services they support. As used herein, terms such as “instantiation” and “instantiation” refer to the creation of an instance, and “instance” may refer to the specific occurrence of an object, for example, during the execution of program code. Additionally, the NRF254 may present an Nnrf service-based interface.

[0078] PCF256 may provide policy rules to control plane functions to implement them, and may also support a unified policy framework for governing network behavior. PCF256 may also implement a front-end for accessing subscription information related to policy decisions in the UDR of UDM258. In addition to communicating with functions via reference points as shown in the diagram, PCF256 presents an Npcf service-based interface.

[0079] UDM258 may process subscription-related information to support the processing of communication sessions of network entities and may store subscription data for UE202. For example, subscription data may be communicated via an N8 reference point between UDM258 and AMF244. UDM258 may include two parts: an application frontend and a UDR. The UDR may store subscription and policy data for UDM 258 and PCF256, and / or structured data for public and application data for NEF252 (including a PFD for application discovery and application request information for multiple UEs). A Nuder service-based interface may be presented by the UDR to allow UDM 258, PCF256, and NEF252 to access specific sets of stored data and to allow reading, updating (e.g., adding, modifying), deleting, and subscribing to notifications of relevant data changes in the UDR. The UDM may include a UDM-FE responsible for credential processing, location management, subscription management, etc. Several different frontends may serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identification processing, access authorization, registration / mobility management, and subscription management. In addition to communicating with other NFs via a reference point as shown in the diagram, the UDM 258 may present a Nudm service-based interface.

[0080] AF260 may provide application influence on traffic routing, provide access to NEF, and interact with a policy framework for policy control.

[0081] In some embodiments, the 5GC240 may enable edge computing such that the UE202 is geographically closer to the point where it is attached to the network by selecting an operator / third-party service. This may reduce latency and load on the network. To provide an edge computing implementation, the 5GC240 may select a UPF248 closer to the UE202 and perform traffic steering from the UPF248 to the data network 236 via the N6 interface. This may be based on UE subscription data, UE location, and information provided by the AF260. In this way, the AF260 may influence UPF (re)selection and traffic routing. Based on the operator's deployment, when the AF260 is considered a trusted entity, the network operator may allow the AF260 to interact directly with the relevant NF. Additionally, the AF260 may present a Naf service-based interface.

[0082] The data network 236 may represent various network operator services, internet access, or third-party services that may be provided by one or more servers, such as an application / content server 238.

[0083] Figure 3 schematically illustrates various embodiments of the wireless network 300. The wireless network 300 may include a UE302 that wirelessly communicates with AN304. The UE302 and AN304 may be substantially interchangeable, as are similarly named components described elsewhere in this specification.

[0084] UE302 may be communicatively coupled to AN304 via connection 306. Connection 306 is exemplified as an air interface for enabling communication coupling and can be compatible with cellular communication protocols such as the LTE protocol or the 5G NR protocol operating at mmWave or sub-6GHz frequencies.

[0085] UE302 may include a host platform 308 coupled with a modem platform 310. The host platform 308 may include an application processing circuit 312 which can be coupled with a protocol processing circuit 314 of the modem platform 310. The application processing circuit 312 may run various applications for UE302 that source / sink application data. The application processing circuit 312 may further implement one or more layer operations for sending / receiving application data to and from a data network. These layer operations may include transport (e.g., UDP) and internet (e.g., IP) operations.

[0086] The protocol processing circuit mechanism 314 may implement one or more layer operations to facilitate the transmission or reception of data via the connection 306. The layer operations implemented by the protocol processing circuit mechanism 314 may include, for example, MAC, RLC, PDCP, RRC, and NAS operations.

[0087] The modem platform 310 may further include a digital baseband circuit 316 that can implement one or more layer operations, which are “lower” layer operations performed by the protocol processing circuit 314 in the network protocol stack. These operations include, for example, one or more PHY operations including HARQ-ACK operations, scrambling / descrambling, coding / decoding, layer mapping / demapping, modulation symbol mapping, received symbol / bitmetric determination, multi-antenna port pre-recording / decoding, which may include one or more of the following: spatial time, spatial frequency or spatial coding, reference signal generation / detection, preamble sequence generation and / or decoding, synchronous sequence generation / detection, control channel signal blind decoding, and other related functions.

[0088] The modem platform 310 may further include a transmitting circuit 318, a receiving circuit 320, an RF circuit 322, and an RF front end (RFFE) 324, which may include or be connected to one or more antenna panels 326. Briefly, the transmitting circuit mechanism 318 may include a digital-to-analog converter, a mixer, an intermediate frequency (IF) component, etc.; the receiving circuit mechanism 320 may include an analog-to-digital converter, a mixer, an IF component, etc.; the RF circuit mechanism 322 may include a low-noise amplifier, a power amplifier, a power tracking component, etc.; and the RFFE 324 may include a filter (e.g., a surface / bulk acoustic wave filter), a switch, an antenna tuner, a beamforming component (e.g., a phase array antenna component), etc. The selection and arrangement of the components of the transmitting circuit mechanism 318, receiving circuit mechanism 320, RF circuit mechanism 322, RFFE 324, and antenna panel 326 (commonly referred to as “transmitting / receiving components”) may be specific to particular implementation details, such as whether the communication is TDM or FDM, or whether it is mmWave or sub-6GHz frequency. In some embodiments, the transmitting / receiving components may be arranged in multiple parallel transmit / receive chains, or they may be arranged on the same or different chips / modules.

[0089] In some embodiments, the protocol processing circuit mechanism 314 may include one or more instances of a control circuit mechanism (not shown) that provides control functions for the transmit / receive components.

[0090] UE reception may be established by and through the antenna panel 326, RFFE 324, RF circuitry 322, receiving circuitry 320, digital baseband circuitry 316, and protocol processing circuitry 314. In some embodiments, the antenna panel 326 may receive transmissions from AN304 by a received beamforming signal received by multiple antennas / antenna elements of one or more antenna panels 326.

[0091] UE transmission may be established by and through the protocol processing circuitry 314, the digital baseband circuitry 316, the transmitting circuitry 318, the RF circuitry 322, the RFFE 324, and the antenna panel 326. In some embodiments, components of UE 302 may apply spatial filters to the data that is used to form the transmit beam emitted by the antenna elements of the antenna panel 326.

[0092] Similar to UE302, AN304 may include a host platform 328 coupled with a modem platform 330. The host platform 328 may include an application processing circuit 332 coupled with the protocol processing circuit 334 of the modem platform 330. The modem platform may further include a digital baseband circuit 336, a transmit circuit 338, a receive circuit 340, an RF circuit 342, an RFFE circuit 344, and an antenna panel 346. The components of AN304 may be similar to, and substantially interchangeable with, components of similar names in UE302. In addition to performing data transmission / reception as described above, the components of AN304 may perform various logical functions, including RNC functions such as radio bearer management, dynamic radio resource management for uplink and downlink, and data packet scheduling.

[0093] Figure 4 is a block diagram illustrating components, in several exemplary embodiments, that are capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-temporary machine-readable storage medium) and executing one or more of the methodologies discussed herein. Specifically, Figure 4 shows a schematic diagram of hardware resources 400, including one or more processors (or processor cores) 410, one or more memory / storage devices 420, and one or more communication resources 430, each of which may be communicatively coupled via a bus 440 or other interface circuitry. In embodiments where node virtualization (e.g., NFV) is utilized, a hypervisor 402 may be run to provide an execution environment for one or more network slices / subslices to utilize the hardware resources 400.

[0094] The processor 410 may include, for example, processors 412 and 414. The processor 410 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a composite instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radio frequency integrated circuit (RFIC), another processor (including those discussed herein), or any preferred combination thereof.

[0095] The memory / storage device 420 may include main memory, disk storage, or any preferred combination thereof. The memory / storage device 420 may include, but is not limited to, any type of volatile memory, non-volatile memory, or semi-volatile memory, such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, or solid-state storage.

[0096] The communication resource 430 may include interconnectors or network interface controllers, components, or other suitable devices for communicating with other network elements via one or more peripheral devices 404, one or more databases 406, or a network 408. For example, the communication resource 430 may include wired communication components (for coupling via USB, Ethernet, etc.), cellular communication components, NFC components, Bluetooth® (or Bluetooth Low Energy) components, Wi-Fi components, and other communication components.

[0097] Instruction 450 may include software, programs, applications, applets, apps, or other executable code to cause at least one of the processors 410 to perform one or more of the methodologies discussed herein. Instruction 450 may reside entirely or partially in at least one of the processors 410 (e.g., in the processor's cache memory), memory / storage devices 420, or any preferred combination thereof. Furthermore, any portion of instruction 450 may be transferred to the hardware resource 400 from any combination of peripheral devices 404 or database 406. Thus, the memory of the processor 410, memory / storage devices 420, peripheral devices 404, and database 406 are examples of computer-readable and machine-readable media.

[0098] For one or more embodiments, at least one of the components outlined in one or more of the aforementioned figures may be configured to perform one or more operations, techniques, processes, and / or methods as outlined in the following exemplary sections. For example, a baseband circuit mechanism associated with one or more of the aforementioned figures may be configured to operate according to one or more of the examples described below. As another example, a circuit associated with a UE, base station, satellite, network element, etc., as described above in relation to one or more of the aforementioned figures may be configured to operate according to one or more of the examples described below in the exemplary sections.

[0099] The term "application" may refer to a complete and deployable package or environment for achieving certain functions in an operating environment. The term "AI / ML application," for example, may refer to an application that includes several artificial intelligence (AI) / machine learning (ML) models and application-level descriptions. In some embodiments, an AI / ML application may be used to set up or implement one or more of the disclosed embodiments.

[0100] The terms “machine learning” or “ML” refer to the use of computer systems that implement algorithms and / or statistical models to perform specific tasks by relying on patterns and inference without using explicit instructions. An ML algorithm builds or estimates a mathematical model (such as an “ML model”) based on sample data (such as “training data” or “model training information”) and makes predictions or decisions without being explicitly programmed to perform such tasks. Generally, an ML algorithm is a computer program that learns from experience with some task and some performance measurement, and an ML model may be any object or data structure created after an ML algorithm has been trained on one or more training datasets. After training, an ML model may be used to make predictions on a new dataset. The terms “ML algorithm” refer to a different concept from the terms “ML model,” but the terms discussed herein may be used interchangeably for the purposes of this disclosure.

[0101] The terms “machine learning model” and “ML model” may also refer to ML methods and concepts used by ML-assisted solutions. An “ML-assisted solution” is a solution that uses an ML algorithm in operation to address a specific use case. ML models include supervised learning (e.g., linear regression, k-nearest neighbors (KNN), decision tree algorithms, support machine vectors, Bayesian algorithms, ensemble algorithms, etc.), unsupervised learning (e.g., K-means clustering, principal component analysis (PCA), etc.), reinforcement learning (e.g., Q-learning, multi-arm bandwidth learning, deep RL, etc.), and neural networks. Depending on the implementation, a particular ML model may have many submodels as components, and the ML model may train all submodels together. Separately trained ML models may be chained together in an ML pipeline during inference. An “ML pipeline” is a set of functionalities, features, or feature entities specific to an ML-assisted solution, and an ML pipeline may include a data pipeline, a model training pipeline, a model evaluation pipeline, and one or more data sources in actors. An "actor" is an entity that hosts an ML-assisted solution using the output of an ML model inference. The term "ML training host" refers to an entity such as a network function that hosts the training of a model. The term "ML inference host" refers to an entity such as a network function that hosts a model during inference mode (this includes both model execution and online learning, where applicable). The ML host informs the actor of the output of the ML algorithm, and the actor decides on an action ("action" is performed by the actor as a result of the output of the ML-assisted solution). The term "model inference information" refers to information used as input to the ML model to decide on the inference, and while the data used to train the ML model and the data used to decide on the inference may overlap, "training data" and "inference data" refer to different concepts.

[0102] The 5G NR 3GPP Technical Specification (TS) supports a variety of vertical markets and use cases, including enhanced mobile broadband (eMBB) and newly introduced URLLC services. Support for LPWA (Low Power Wide Area) and use cases for ultra-low complexity / cost devices targeting ultra-high coverage and ultra-long battery life are expected to be served by MTC (Category M UE) and NB-IoT (Category NB UEs).

[0103] In some aspects, the disclosed technology supports a class of NR UEs having lower complexity and power consumption levels than Rel-15 NR UEs, and may be used to address use cases such as industrial wireless sensor networks (IWSNs), certain classes of wearables, and video surveillance, to bridge the gap between current LPWA solutions and eMBB solutions in NR, and to further facilitate a smooth transition from 3.5G and 4G technologies to 5G (NR) technologies for currently deployed bandwidths that serve relevant use cases requiring relatively low to moderate reference (e.g., median) and peak user throughput, low device complexity, small device form factor, and relatively long battery life.

[0104] To that end, it is expected that a class of RedCap (Reduced Capability) NR UEs (User Equipment) can be defined using the currently defined 5G NR framework, with the necessary adaptations and enhancements to limit device complexity and power consumption while minimizing adverse effects on network resource utilization, system spectral efficiency, and operational efficiency. In some embodiments, a RedCap UE may support a maximum UE BW of 20 MHz in the frequency range 1 (FR1) band and a maximum UE BW of 100 MHz in the FR2 band.

[0105] The disclosed technology includes methods for Bandwidth Partial (BWP) operation for a RedCap UE in RRC_IDLE or RRC_INACTIVE mode, taking into account coexistence with non-RedCap UEs and BW limitations for RedCap UEs. In particular, the disclosed technology includes methods for BWP configuration and operation for a RedCap UE when (a) an additional DL BWP may be provided to the RedCap UE for at least some common control receptions in idle / inactive mode, (b) a separate initial UL BWP may be provided to the RedCap UE that is different from that of a non-RedCap UE, and (c) a PEI (Paging Early Indication) or TRS / CSI-R configuration is set on the RedCap UE in RRC_IDLE / INACTIVE mode.

[0106] System information block 1 (SIB1) and SIBx (x>1) received. Reception of SIB1 and SIBx (x>1) may be common to both RedCap and non-RedCap UEs and may be limited to CORESET#0 as defined by the Master Information Block (MIB).

[0107] Separate CORESET and DL BWP for paging or random access for RedCap UE Figure 5 illustrates exemplary separate initial downlink DLBWP configuration options in several embodiments. More specifically, Figure 5 illustrates examples of separate initial DL BWP configuration options (e.g., separate iDL BWP A, B, C). The illustrated “Active DL BWP X / Y in connection mode” are examples of RRC-configured DL BWPs in connection mode that do not fully include CD-SSB. In such cases, UEs that do not show support for SSB-less operation in the RRC-configured DL BWP expect NCD-SSB in the respective “Active DL BWP X / Y”.

[0108] Figure 6 illustrates different PRACH resources for RedCap and non-RedCap UEs in different initial UL BWPs in several embodiments. As illustrated in Figure 6, a separate initial DL BWP may be provided to the RedCap UE to match the center frequency between the initial DL and UL BWP for the RedCap UE. In Figure 6, the "initial DL BWP for non-RedCap UE" corresponds to the MIB display "CORESET#0".

[0109] In some embodiments, the PDCCH Type 2 Common Search Space (CSS) for paging and the associated PDSCH may be restricted to the primary cell's CORESET#0.

[0110] In some embodiments, an additional CORESET called CORESET#0A, defined in an additional DL BWP (sometimes called a "separate initial DL BWP"), may be set for the RedCap UE via a System Information Block (SIB) message, primarily to offload common controls and avoid congestion in CORESET#0. In one example, it may be set via SIB1.

[0111] In some embodiments, an additional CORESET (CORESET#0A) may be defined within an additional DL BWP (which may also be called a “separate initial DL BWP”) called DL BWP#0A for receiving PDCCHs and PDSCHs for paging monitoring. As another example, DL BWP#0A may be used for receiving one or more PDCCH type 1 CSSs for some or all PDCCHs and PDSCHs associated with a random access procedure, namely, scheduling the PDSCH carrying Msg2, scheduling the retransmission of the PUSCH carrying Msg3, and scheduling the PDSCH carrying Msg4.

[0112] In time-division duplex (TDD) deployment, the center frequencies of simultaneously configured DL and UL BWPs with the same BWP index may be the same. In one embodiment, for an unpaired spectrum (TDD deployment), the UE may be configured with DL BWP#0A, which may have a different center frequency than UL BWP#0. In such a case, the UE must perform RF frequency retuning during any transition between receiving in DL and transmitting in UL. Therefore, in one embodiment, in addition to the Rx-to-Tx and Tx-to-Rx switching times currently specified (e.g., in 3GPP TS 38.211), frequency retuning gaps may be specified between the last DL symbol from which the UE can receive a DL physical channel or signal and the first UL symbol used for transmission from the UE, and vice versa. The frequency retuning gap may be defined in terms of the number of OS (OFDM Symbols) or in units of time.

[0113] In some embodiments, the size of DCI format 1_0 monitored by CSS is determined based on the size of CORESET#0 when CORESET#0 is set in a cell, and based on the size of the initial DL BWP if CORESET#0 is not set in a cell. For RedCap UEs where CORESET#0A is provided for at least one of paging or random access, it is also necessary to monitor DCI format 1_0 with a Cyclic Redundancy Check (CRC) scrambled with SI-RNTI for receiving SI (System Information) messages. Generally, if the sizes of CORESET#0 and CORESET#0A are different, it may result in two sizes for DCI format 1_0 monitoring in CSS.

[0114] In some embodiments, when CORESET#0A is provided for one or more paging and random access-related DL receptions, the size of CORESET#0A in the frequency domain may be constrained to be the same as the size for CORESET#0. As a result, the size of DCI format 1_0 may be determined according to the size of either CORESET#0 or CORESET#0A in the frequency domain. Furthermore, it should be noted that it may be assumed that the same subcarrier spacing (SCS) is set for both DL BWP#0 and DL BWP#0A. Alternatively, the sizes of CORESET#0 and CORESET#0A may be different, and the size of DCI format 1_0 monitored in CSS may be determined according to CORESET#0. In this case, for example, the Frequency Domain Resource Allocation (FDRA) may be determined by the UE by applying truncation of some of the most significant bits (MSB) or zero padding to the received bit field of DCI format 1_0 received in Type 2 CSS (for paging) or Type 1 CSS (for receiving random access-related PDSCHs), depending on whether the BW of CORESET#0 is greater than or less than the BW of CORESET#0A, for scheduling paging PDSCH, Msg2 PDSCH, or Msg4 PDSCH.

[0115] In some embodiments, when CORESET#0A, DL BWP#0A is configured for paging reception, and when in RRC_CONNECTED mode, all PR Bs in CORESET#0A are contained within the UE's active DL BWP, and the UE may be expected to monitor PDCCH type 2 CSS (indicated by pagingSearchSpace) in CORESET#0A, provided that the active DL BWP and separate initial DL BWP have the same subcarrier interval (SCS).

[0116] In some embodiments, when in RRC_CONNECTED mode, if a PDCCH type 1 CSS (indicated by ra-SearchSpace) is indicated to map to CORESET#0A instead of CORESET#0, the UE may be expected to monitor the PDCCH type 1 CSS (indicated by ra-SearchSpace) in CORESET#0A, provided that all PRBs in CORESET#0A are contained within the UE's active DL BWP and the active DL BWP and the separate initial DL BWP have the same subcarrier interval (SCS).

[0117] In some embodiments, when CORESET#0A is provided, for a CORESET having index 0A, the UE may assume that the DM-RS antenna port for PDCCH reception in the CORESET is QCL-ed (quasi co-located) with one or more DL RSs set by a TCI state, which is indicated by a MAC CE activation command to the CORESET, if any. Alternatively, if no MAC CE activation command indicating a TCI state to the CORESET is received after the most recent random access procedure, the UE identifies an SS / PBCH block during the most recent random access procedure that is not initiated by a PDCCH instruction triggering a no-conflict random access procedure.

[0118] In some embodiments, for a CORESET having index 0A, the UE may expect that a CSI-RS with qclType set to "typeD" in the TCI state indicated by the MAC CE activation command for the CORESET is provided by the SS / PBCH block. When the UE receives a MAC CE activation command for one of the TCI states, the UE applies the activation command in the first slot following slot k+3N slot subframe μ, where k is the slot from which the UE will send a PUCCH with HARQ-ACK information for the PDSCH providing the activation command, and μ is the SCS setting for the PUCCH. The active BWP is defined as the active BWP in the slot when the activation command is applied.

[0119] In some embodiments, the frequency domain span for CORESET#0A is the same as that for a separate initial DL BWP (DL BWP#0A). Alternatively, the frequency domain span for CORESET#0A may be smaller than (i.e., a suitable subset of) the frequency domain span for DL ​​BWP#0A.

[0120] In some embodiments, the RedCap UE may expect the SSB (Synchronization Signal Block) to be configured in a separate initial DL BWP (DL BWP#0A) where a Type 1 PDCCH CSS for random access-related DL reception for the RedCap UE is configured via SIB signaling, if a Type 2 PDCCH CSS for paging reception is also configured in DL BWP#0A, and the SSB periodicity and indexing are identical to the cell-defined SSB (CD-SSB) for the camping or serving cell, but are located in the frequency domain at a non-zero offset from the NR frequency raster.

[0121] Alternatively, in some embodiments, the SSB periodicity may differ from that of CD-SSB. In further examples, for the same or longer periodicity values ​​compared to CD-SSB, the SSB opportunities in a separate initial DL BWP may be the same as, or an appropriate subset of, the SSB opportunities for CD-SSB.

[0122] In another embodiment, a RedCap UE that cannot support operation in an active DL BWP without an SSB may expect that, when in the RRC_CONNECTED state, one of the following is set in the active DL BWP: (1) a CD-SSB, (2) an SSB set in a separate initial DL BWP (DL BWP#0A), or (3) a separate setting of a non-cell defined SSB.

[0123] In some embodiments, if a Type 2 PDCCH CSS for paging reception is also configured for DL ​​BWP#0A, the RedCap UE may expect a separate initial DL BWP (DL BWP#0A) where a Type 1 PDCCH CSS for random access-related DL reception for the RedCap UE is configured via SIB signaling, to have settings for Type 0 and Type 0A for RMSI (Remaining Minimum System Information) and OSI (Other System Information), and a setting for SSB (Synchronization Signal Block), respectively. The SSB periodicity and indexing are identical to the cell-defined SSB (CD-SSB) for a camping or serving cell, but are located at a non-zero offset from the NR synchronous raster in the frequency domain. Therefore, the SSB in DL BWP#0A may also be associated with RMSI, but such an SSB does not need to be interpreted as a cell-defined SSB (CD-SSB) because it is not located on the synchronous raster.

[0124] In some embodiments, the RedCap UE may be provided with a configuration of type 0 or 0A PDCCH CSS having the same monitoring opportunities (MOs) as defined for CORESET#0. Alternatively, the MOs for the type 0 / 0A PDCCH CSS set in CORESET#0A in a separate initial DL BWP may be provided to the RedCap UE independently of the monitoring opportunities for the type 0 / 0A PDCCH CSS set in CORESET#0. In a further example, the signaling for the configuration for type 0 PDCCH CSS is provided to the UE using 4 bits used via the MIB (Master Information Block) signaling for CORESET#0, defined by the MIB. In another example, the RedCap UE may assume the same SI (System Information) monitoring window configuration as CORESET#0, which includes a time offset, duration, and periodicity. Alternatively, the SI monitoring window configuration may be provided separately to the UE via SIB1, which may differ from that for CORESET#0.

[0125] In some embodiments, the multiplexing between the SSB and CORESET#0A in a separate initial DL BWP (DL BWP#0A) may follow the same multiplexing pattern used between the CD-SSB and CORESET#0. Alternatively, the RedCap UE may be provided with a multiplexing pattern between the SSB and CORESET#0A in a separate initial DL BWP via SIB1 signaling, and the pattern used may be independent of the SSB-CORESET#0 multiplexing pattern.

[0126] In some embodiments, when the RedCap UE is configured with enhanced paging reception and PEI (Paging Early Indication) for paging monitoring, and a Type 2 PDCCH CSS for paging reception is also configured in DL BWP#0A, it can be expected that the PEI and SSB (Synchronization Signal Block) settings are provided in a separate initial DL BWP (DL BWP#0A) where a Type 1 PDCCH CSS for random access-related DL reception for the RedCap UE is configured via SIB signaling, and the SSB periodicity and indexing are identical to the cell-defined SSB (CD-SSB) for the camping or serving cell, but are located at a non-zero offset from the NR-synchronous raster in the frequency domain.

[0127] In some embodiments, the frequency position of the SSB may be provided to a RedCap UE, which is provided with an SSB configuration in a separate initial DL BWP (DL BWP#0A), via SIB1 signaling. In one example embodiment, the UE may be provided with a starting (minimum) PRB index for the SSB, which may be based on one of the following: (1) a Common Resource Block (CRB) grid, or (2) a set of PRBs indexed within DL BWP#0A (i.e., a representation of the frequency offset in the number of PRBs from the lowest PRB of DL BWP#0A), or (3) a representation of the frequency offset in the number of PRBs from the lowest PRB of CORESET#0A.

[0128] In some embodiments, the UE may optionally provide via SIB1 a subcarrier-level offset in a 15 kHz subcarrier spacing (SCS) ranging from 0 to 23 relative to FR1 (kSSB DLBWP0A), or a subcarrier-level offset in the SCS relative to an initial DL BWP defined by CORESET#0 (DL BWP#0) ranging from 0 to 11 relative to FR2, where the offset is defined with respect to the PRB grid. Alternatively, if not provided, the UE may assume a subcarrier level offset value of 0 for non-CD-SSB transmitted in a separate initial DL BWP (DL BWP#0A).

[0129] In some embodiments, a RedCap UE that provides an SSB configuration in a separate initial DL BWP (DL BWP#0A) may assume that SSBs with the same SSB index are QCL-ed (Quasi-Co-Located). In other words, the UE may assume that antenna ports used to transmit SS / PBCH blocks with the same index that repeat with the SS / PBCH burst set periodicity are in pseudo-collocation with respect to spatial, mean gain, delay, and Doppler parameters. By default, the UE does not have to assume that antenna ports used to transmit SSBs with different indices are in pseudo-collocation with respect to spatial, mean gain, delay, and Doppler parameters.

[0130] In some embodiments, a RedCap UE provided with a separate initial DL BWP (DL BWP#0A) may assume that the DMRS for the PDCCH in CORESET#0A and the DMRS for the PDSCH for receiving one or more type 0 / 0A / 1 / 2 PDCCH CSS sets or associated PDSCHs are in the corresponding CD-SSB and QCL-ed (Quasi-Co-Located), and the mapping to the CD-SSB index is the same as the mapping to CORESET#0 or is explicitly defined via SIB1 signaling.

[0131] In some embodiments, a RedCap UE provided with a separate initial DL BWP (DL BWP#0A) may assume that the DMRS for the PDCCH and the DMRS for the PDSCH for receiving one or more type 0 / 0A / 1 / 2 PDCCH CSS sets or associated PDSCHs in CORESET#0A are QCL-ed (Quasi-Co-Located) with the corresponding non-CD-SSB, and the mapping to the CD-SSB index is the same as the mapping to CORESET#0, or is explicitly defined via SIB1 signaling.

[0132] PEI and TRS / CSI-RS in RRC_IDLE / RRC_INACTIVE mode for RedCap UE provided with CORESET#0A / DL BWP#0A In some embodiments, a UE configured with CORESET 0A / DL BWP 0A may also be configured with a Paging Early Indication (PEI) function, which indicates to the UE whether to monitor one or more subsequent POs for paging message reception. In one embodiment, the UE may monitor only the PEI in the default DL BWP, which may be either BWP 0 or 0A. Alternatively, the UE may monitor the PEI in the DL BWP that is active at the time of monitoring. In another embodiment, the UE may be configured to monitor the PEI in the same CORESET or DL ​​BWP configured to monitor type 2 PDCCH CSS for paging reception.

[0133] In some embodiments, the UE may monitor the PEI in a first DL BWP, and if the PEI indicates to the UE to monitor the PO, the UE may receive paging messages (paging DCI and / or paging PDSCH) in a second DL BWP which may be different from the first DL BWP. In one embodiment, the UE may be configured by higher-layer signaling, such as SIBx(x=1,2,…), to identify the first and second DL BWPs. In another embodiment, the PEI may indicate a DL BWP index in which the UE expects to receive paging messages, which may be the same as or different from the DL BWP in which the PEI was received. In the above example, the PEI may be a sequence-based transmission or a PDCCH-based transmission. In one embodiment, if the PEI and PO are monitored in different BWPs, the UE may expect to observe the smallest time gap between the last valid PEI monitoring opportunity and the start of the PO. In one example, the smallest time gap may be expressed in slots or milliseconds (e.g., based on the numerology of the active DL BWP or reference DL BWP).

[0134] In some embodiments, the UE may be configured by SIBx signaling having a TRS / CSI-RS opportunity in idle / inactive mode, which may be used for time / frequency tracking, AGC, and / or cell measurement. In one embodiment, the TRS / CSI-RS opportunity may be configured in DL BWP configured for the UE to monitor paging reception. In another embodiment, the TRS / CSI-RS opportunity may be configured in DL BWP#0 defined by CORESET#0.

[0135] In some embodiments, TRS / CSI-RS opportunities may be monitored in any active DL BWP, which may be either BWP 0 or BWP 0A, and it is not expected that TRS / CSI-RS will be received outside of the active DL BWP. This suggests that the BW for TRS / CSI-RS at configured opportunities does not have to be limited by the initial DL BWP or active DL BWP, which may be either BWP 0 or 0A. Alternatively, the UE may monitor TRS / CSI-RS only in the default BWP, which may be either BWP 0 or BWP 0A. In some embodiments, the UE may be provided with a parameter as part of the BWP 0 or BWP 0A configuration regarding whether to monitor TRS / CSI-RS opportunities when the corresponding BWP is active.

[0136] In some embodiments, the UE may be provided with an availability indicator for TRS / CSI-RS opportunities, which informs the UE whether TRS / CSI-RS is transmitted on a configured opportunity. In one embodiment, the availability indicator may be specific to a DL BWP that is, for example, BWP 0 or BWP 0A. Alternatively, the availability indicator may generally be applied to any configured DL BWP, and the UE monitors TRS / CSI-RS opportunities when it is indicated that a TRS / CSI-RS opportunity is available on any active DL BWP.

[0137] In some embodiments, the numerology of a TRS / CSI-RS transmission may be assumed to be the same as that of the active DL BWP, which may be BWP 0 or BWP0A, or based on a reference numerology. For example, the reference numerology may be shown as part of the TRS / CSI-RS configuration. The reference numerology may be the same as or different from the numerology of BWP 0 or 0A. Alternatively, the numerology of the TRS / CSI-RS may be assumed to be the same as that of the initial BWP 0, or the same as that of the SSB, regardless of the numerology of the active DL BWP. In one example, if the UE identifies that the numerology of the TRS / CSI-RS is different from that of the active DL BWP, the UE may choose not to monitor TRS / CSI-RS opportunities that overlap with the active DL BWP. Alternatively, the UE may switch to the TRS / CSI-RS numerology and monitor them before switching back to the active DL BWP numerology, i.e., the UE may observe the gap.

[0138] In some embodiments, separate TRS / CSI-RS settings may be provided for each DL BWP 0 and 0A. For example, the BWP ID may be included in the TRS / CSI-RS setting, or the TRS / CSI-RS setting may be included as part of the BWP setting.

[0139] Initial UL BWP for RedCap UE In some embodiments, the initial UL BWP (referred to as UL BWP#0) is provided to the UE via the SIB1 message. Separate settings of UL BWP#0 for RedCap UEs and non-RedCap UEs may be beneficial, for example, if UL BWP#0 for non-RedCap UEs may be greater than the maximum RedCap UE BW in UL, i.e., 20 MHz in FR1 and 100 MHz in FR2.

[0140] In some embodiments, for a TDD deployment, the initial DL BWP (DL BWP#0 / #0A) and UL BWP#0 for the RedCap UE do not need to share a common center frequency. In such cases, the frequency retuning gap may be defined in addition to the Rx-to-Tx and Tx-to-Rx switching times between the DL-to-UL transition and the UL-to-DL transition, respectively.

[0141] In some embodiments, UL BWP#0 may be provided separately for RedCap UEs from that for non-RedCap UEs. Such a setting may be explicit, for example, via an SIB1 message, or implicitly determined based on one or more of the FDRAs indicated for Msg3 PUSCH, such as the setting of UL BWP#0 and setting RACH opportunity (RO) for non-RedCap UEs (according to the Rel-15 specification), or the UL grant in the Random Access Response (RAR).

[0142] In some embodiments, the option of using RO to determine the initial UL BWP for RedCap UE may be implemented using a combination of the options described below.

[0143] (a) A reference setting for the initial UL BWP is provided to the UE, which provides all parameters that can be provided via the initial UL BWP setting (using initialUplinkBWP), except for the actual frequency domain resources for the BWP. In one example, the reference setting for the initial UL BWP for a RedCap UE may be the same as the one provided in SIB1 for a non-RedCap UE. Furthermore, in one example, the BW of the initial UL BWP may be provided separately for the RedCap UE, for example, by the number of PRBs assuming the same SCS as indicated in the reference setting for the initial UL BWP. In another example, the BW of the initial UL BWP for a RedCap UE may be determined as (i) the BW of the initial UL BWP set in SIB1 for a non-RedCap UE (via initialUplinkBWP), and (ii) the minimum of the maximum UE BW for the RedCap UE in the corresponding frequency range (FR).

[0144] (b) Instead of explicitly setting startPRB and numPRB, a reference frequency position may be provided to the UE.

[0145] (b.1) In one example, the reference frequency position is the start PRB of UL BWP#0, which is set to SIB1 for non-RedCap UEs.

[0146] (b.2) In another example, the reference frequency position is the RO start PRB provided as part of the initial UL BWP configuration in SIB1 for non-RedCap UEs via RACH-ConfigCommon in BWP-UplinkCommon. In a further example, if multiple ROs are provided at different frequency positions, the RO used to define the initial UL BWP start PRB is determined based on the RO selected for Msg1 transmission from the RedCap UE.

[0147] (b.3) In some embodiments, the RACH setting is provided separately to RedCap and non-RedCap UEs. Specifically, a separate UL BWP#0 setting may be provided to the RedCap UE via SIB1 to provide a “reference UL BWP#0” location. The separate UL BWP#0 setting may include the RACH setting, and the UE may determine the actual UL BWP#0 based on the RO location as described above.

[0148] (b.4) In yet another example, the reference frequency position is the starting PRB of the Msg3 PUSCH scheduled by the UL grant in the RAR. In this example, the RedCap UE may transmit Msg1 using an RO which can be configured via RACH-ConfigCommon in the BWP-UplinkCommon. Alternatively, one or more ROs may be configured separately for the RedCap UE, which has frequency resources for the ROs indicated with respect to the CRB (Common Resource Block) grid provided to the UL carrier. Furthermore, in one example, the FDRA for the Msg3 PUSCH may be defined with respect to the CRB grid, or with respect to PRB#0 of the initial UL BWP configured for a non-RedCap UE (via initialUplinkBWP).

[0149] In some embodiments, once the initial UL BWP is determined by the RedCap UE, subsequent UL transmissions may include one or more of the following: Msg1 transmission, Msg3 transmission, Msg3 retransmission, and PUCCH transmission with HARQ-ACK feedback in response to Msg4 PDSCH (depending on the stage during the initial access where the initial UL BWP is determined by the RedCap UE), MsgA PRACH and PUSCH, and PUCCH transmission with HARQ-ACK feedback in response to MsgB PDSCH for 2-step RACH, transmitted in the initial UL BWP for the RedCap UE.

[0150] In some embodiments, in idle / inactive mode, the RedCap UE may expect that the initial DL BWP is configured on the UE for at least random access-related monitoring, i.e., including at least a Type 1 PDCCH CSS configuration, and that the initial UL BWP (which may be configured separately for the RedCap UE) with PRACH resources configured for the RedCap UE shares the same center frequency. Here, the initial DL BWP may be either MIB display CORESET#0 or a separate initial DL BWP provided to the UE via SIB1. In other words, in RRC idle or inactive mode, the RedCap UE may expect that the UL BWP#0 configured for the RedCap UE shares the same center frequency as the initial DL BWP, in which the RedCap UE is expected to monitor a Type 2 PDCCH CSS candidate for monitoring as part of the random access procedure.

[0151] In some embodiments, the RedCap UE can expect that the UL BWP#0 configured for the RedCap UE in RRC idle mode or inactive mode shares the same center frequency as the initial DL BWP, during which the RedCap UE is expected to monitor type 1 PDCCH CSS candidates for monitoring as part of a random access procedure.

[0152] In some embodiments, if the RedCap UE is configured with a Small Data Transmission (SDT) feature on a 4-step or 2-step RACH (RA-SDT) that enables UL transmission when the RRC is inactive, the initial UL BWP for which a RACH opportunity (RO) is set for the RedCap UE may be used to trigger the SDT based on either the 4-step or 2-step RACH.

[0153] In some embodiments, a RedCap UE with RA-SDT features configured may expect that, in RRC inactive mode, the initial UL BWP in which the RO for sending message 1 or message A is configured on the RedCap UE shares the same center frequency as the initial DL BWP, during which the RedCap UE is expected to monitor type 1 PDCCH CSS candidates for monitoring as part of the random access procedure.

[0154] In another embodiment, if the RedCap UE is configured with an SDT (Small Data Transmission) feature on a CG-SDT (Configured Grant PUSCH) that enables UL transmission when the RRC is inactive, a CG PUSCH opportunity for the RedCap UE to trigger the CG-SDT may be set in the initial UL BWP where the RO (RACH Occasion) is set for the RedCap UE. Alternatively, when the RedCap UE is configured with an SDT (Small Data Transmission) feature on a CG-SDT (Configured Grant PUSCH) that enables UL transmission when the RRC is inactive, a CG PUSCH opportunity for the RedCap UE to trigger the CG-SDT may be set in a UL BWP different from the initial UL BWP where the RO (RACH Occasion) is set for the RedCap UE.

[0155] In some embodiments, a RedCap UE configured with a CG-SDT feature may expect that, in RRC inactive mode, the initial UL BWP in which the CG PUSCH is set to trigger the CG-SDT on the RedCap UE shares the same center frequency as the DL BWP, in which the RedCap UE is expected to monitor PDCCH search space (SS) set candidates to monitor PDCCH from gNBs responding to CG-SDT transmissions. In one example of this embodiment, the DL BWP in which the RedCap UE is expected to monitor PDCCH search space (SS) set candidates to monitor PDCCH from gNBs responding to CG-SDT transmissions is the same as the initial DL BWP in which the RedCap UE is expected to monitor type 1 PDCCH CSS candidates for the Random Access (RA) procedure.

[0156] In some embodiments, the above embodiments and examples relating to SDT can be extended to the case of SDT from RRC idle mode, provided that the latter features are supported.

[0157] SIB settings DL BWP In some embodiments, the UE may be provided with a setting for the initial DL BWP via SIB1, which replaces the initial DL BWP defined by CORESET#0 when the UE enters RRC_CONNECTED mode. That is, for RRC_IDLE mode and RRC_INACTIVE mode, DL BWP#0 defined by CORESET#0 is used for DL ​​reception.

[0158] In some embodiments, with the introduction of a RedCap UE, the initial DL BWP settings provided via SIB1 may be applied separately to non-RedCap UEs and RedCap UEs. In one embodiment, the initial DL BWP settings indicated via SIB1 (in initialDownlinkBWP) may not be used by the RedCap UE. In some embodiments, the index applies only to non-RedCap UEs. In one example embodiment, a RedCap UE, once in RRC_CONNECTED mode, may assume, to define the initial DL BWP, one or more of the following: (i) the initial DL BWP defined by CORESET#0, (ii) the initial DL BWP defined by CORESET#0A, if supported and provided to the UE for at least one or more of the paging and random access-related PDL receptions, and (iii) one or more initial DL BWP settings for the RedCap UE that may be optionally provided to the UE via SIB signaling separate from the initial DL BWP indication for non-RedCap UEs via initialDownlinkBWP.

[0159] In one embodiment, a RedCap UE, once in RRC_CONNECTED mode, may assume the following to define the initial DL BWP: (i) the initial DL BWP defined by CORESET#0, (ii) the initial DL BWP defined by CORESET#0A, if supported and provided to the UE, for at least one of the paging and random access-related PDL receptions, (iii) an initial DL BWP setting for the RedCap UE that may be optionally provided to the UE via SIB signaling separate from the initial DL BWP indication for non-RedCap UEs via initialDownlinkBWP, and (iv) one or more initial DL BWP settings shown for non-RedCap UEs. In a further example, if the corresponding BW does not exceed the maximum RedCap UE BW, the initial DL BWP setting shown for non-RedCap UEs is used by the RedCap UE. Thus, an example of the overall mechanism for determining the initial DL BWP in RRC_CONNECTED mode can be summarized as follows:

[0160] In some embodiments, the initial DL BWP for a RedCap UE in connected mode is given by (a) the initial DL BWP set for the RedCap UE (separate from the one indicated via initialDownlinkBWP), if provided; otherwise, (b) the initial DL BWP set for a non-RedCap UE (indicated via initialDownlinkBWP), if the BW does not exceed the maximum RedCap UE BW; otherwise, (c) the initial DL BWP defined by CORESET#0A, if provided and indicated; otherwise, (d) the initial DL BWP defined by CORESET#0.

[0161] In some embodiments, instead of providing a separate initialDownlinkBWP setting, the BWP-DownlinkCommon structure provided via the DownlinkConfigCommonSIB used for initialDownlinkBWP may be extended with a new optional parameter locationAndBandwidth-r17 that can be configured to be used by RedCap UE to replace the locationAndBandwidth parameter associated with the initialDownlinkBWP setting, while other parameters are used as provided via initialDownlinkBWP.

[0162] In some embodiments, if a separate DL BWP#0 is provided to the RedCap UE via a DL BWP configured to a separate setting of initialDownlinkBWP or a separate setting of the locationAndBandwidth parameter, or a UE setting with an index greater than 0, the UE expects the separately indicated DL BWP#0 or DL ​​BWP with an index greater than 0 to also include the SSB and CORESET#0 for the serving cell, provided that the span at the frequencies covering at least DL BWP#0 and SSB and / or CORESET#0 can exceed the maximum RedCap UE BW. In another example, the constraint on a separate DL BWP#0 to include the service cell's SSB and CORESET#0 is limited to the FR1 band only.

[0163] In some embodiments, when RRC connection is made, if SSB and / or CORESET#0 are not included in the RedCap UE's active DL BWP, and the span in the frequencies covering the active DL BWP and SSB and / or CORESET#0 may exceed the maximum RedCap UE BW, the UE may be expected to retune to the frequency domain defined by CORESET#0 for DL ​​reception, for a set of symbols for the slots indicated to the UE by ssbPositionsInBurst in SIB1 or ssb-PositionsInBurst in ServingCellConfigCommon, for receiving SS / PBCH blocks, and for a set of symbols for which the UE is expected to receive PDCCH in CORESET#0, for example, for a PDCCH with CRC scrambled with SI-RNTI, P-RNTI, RA-RNTI and any associated PDSCH. In other words, CORESET#0 may define the active DL BWP in the set of symbols, while other parameters provided via the DL BWP setting (e.g., at least pdcch-ConfigCommon, pdsch-ConfigCommon) may be reused from those for the active DL BWP if they are not provided separately. Alternatively, if the UE is configured with a DL BWP setting, e.g., DL BWP#0, or a DL BWP that may not include one or more of SSB and CORESET#0, another UE-specific DL BWP that always includes CORESET#0 and SSB may be provided. For unpaired spectra, a UL BWP may also be defined corresponding to this DL BWP having SSB and CORESET#0 to share the same center frequency. If there may be multiple DL BWP settings, and at least one DL BWP setting that does not include CORESET#0, the DL BWP setting that includes SSB and CORESET#0 and has the smallest BWP index is selected.

[0164] In some embodiments where the DL BWP configuration is partially reused from the active DL BWP configuration, all parameters except PDCCH monitoring or PDSCH receiving, which can be mapped to resources outside the frequency domain and SSB defined by CORESET#0, may be reused from the active DL BWP configuration. Thus, when configured and mapped to CORESET#0, the UE may be expected to receive a PDCCH with a CRC scrambled in one of C-RNTI, CS-RNTI, or MCS-C-RNTI, or one of a Type 3 PDCCH CSS search space set. Furthermore, the UE may not be expected to be dynamically scheduled on DL channels or signals outside the frequency domain defined by CORESET#0.

[0165] In some embodiments, the frequency retuning gap may be defined before or after a set of symbols in a slot, and the UE is expected to receive either SSB or DL ​​in CORESET#0 when SSB or CORESET#0 (each) does not necessarily have to be included in the active DL BWP. In one example, the frequency retuning gap explains only frequency retuning and is shorter than the BWP switching time specified by the Rel-15 NR specification.

[0166] In some embodiments, for receiving PDCCH and any associated PDSCH in CORESET#0, the symbol set may include symbols corresponding to PDCCH monitoring opportunities (MOs), and the maximum number of slots and symbols corresponding to the sum of the maximum K0 slot offset between the PDCCH and PDSCH for the DCI format monitored in CORESET#0 as defined by the applicable PDSCH Time-Domain Resource Allocation (TDRA) table and the maximum duration of the scheduled PDSCH (e.g., 14 (or 12) symbols for a normal (or extended) cyclic prefix). In another example, the symbol set may be defined by the number of slots starting from a first slot having the corresponding SSB opportunity or PDCCH MO for monitoring in CORESET#0.

[0167] In some embodiments, for unpaired spectra, the UE may continue operating in the active UL BWP, while there may be a BWP switch between the active DL BWP and CORESET#0, so that a frequency retuning gap may be defined between DL reception and UL transmission, and vice versa. Alternatively, for unpaired spectra, the UE may switch its active UL BWP to the frequency domain defined by CORESET#0 in DL, which may or may not match the UL BWP#0 setting provided for the UE via SIB1.

[0168] Exemplary embodiments of the disclosed technology may include one or more of the following functionalities: A system and method of radio communication for a fifth-generation (5G) or new radio (NR) system, including support for a RedCap (reduced capability) NR UE. For the RedCap UE, one or more of the following may be configured: (a) an additional CORESET (e.g., CORESET#0A) defining a DL BWP (DL BWP#0A) in addition to DL BWP#0 for receiving PDCCH and / or PDSCH related to at least one of the paging and random access procedures; and (b) an initial UL BWP configuration separate from the initial UL BWP configuration for a non-RedCap UE.

[0169] In some embodiments, for an unpaired spectrum (TDD expansion), DL BWP#0A is set in the UE, which may have a center frequency different from the center frequency of UL BWP#0.

[0170] In some embodiments, in addition to the Rx-to-Tx and Tx-to-Rx switching times currently specified in [3GPP TS 38.211], frequency retuning gaps are defined between the last DL symbol from which the UE can receive a DL physical channel or signal and the first UL symbol used for transmission from the UE, and vice versa, and the frequency retuning gap is defined in terms of the number of OS (OFDM Symbols) or time units.

[0171] In some embodiments, when CORESET#0A is provided for one or more paging and random access-related DL receptions, the size of CORESET#0A in the frequency domain is the same as the size of CORESET#0.

[0172] In some embodiments, when CORESET#0A is provided for one or more paging and random access-related DL receptions, the sizes of CORESET#0 and CORESET#0A may be different, and the size of DCI format 1_0 monitored in CSS is determined according to CORESET#0.

[0173] In some embodiments, when CORESET#0A is provided for one or more paging and random access-related DL receptions, for a CORESET having index 0A, the UE may assume that the DM-RS antenna port for PDCCH reception in the CORESET is in pseudo-collocation with one or more DL RSs set by a TCI state, the TCI state being indicated by a MAC CE activation command for the CORESET (if any), or, if no MAC CE activation command indicating a TCI state for the CORESET is received after the latest random access procedure, an SS / PBCH block identified by the UE during the latest random access procedure not initiated by a PDCCH instruction that triggers a conflict-free random access procedure.

[0174] In some embodiments, when a Paging Early Indication (PEI) feature is configured to indicate to the UE whether the PEI is monitoring one or more subsequent POs for receiving paging messages, the UE may monitor only the PEI in the default DL BWP, which may be either BWP 0 or 0A.

[0175] In some embodiments, when a Paging Early Indication (PEI) feature is configured to indicate to the UE whether the PEI is monitoring one or more subsequent POs for paging message reception, the UE may monitor only the PEI in the CORESET or DL ​​BWP where the UE monitors paging reception (i.e., a Type 2 PDCCH CSS is configured).

[0176] In some embodiments, when a Paging Early Indication (PEI) feature is configured to indicate to the UE whether the PEI is monitoring one or more subsequent POs for receiving paging messages, the UE monitors the PEI in a first DL BWP, and if the PEI indicates to the UE to monitor a PO, the UE receives paging messages (paging DCI and / or paging PDSCH) in a second DL BWP different from the first DL BWP.

[0177] In some embodiments, when a TRS or CSI-RS opportunity is configured for use in RRC_INACTIVE or RRC_IDLE mode, the TRS / CSI-RS opportunity is configured with a DL BWP, in which the UE is configured to monitor paging reception (i.e., a Type 2 PDCCH CSS is configured).

[0178] In some embodiments, when a TRS or CSI-RS opportunity is configured for use in RRC_INACTIVE or RRC_IDLE mode, the TRS / CSI-RS opportunity is configured in DL BWP#0 as defined by CORESET#0.

[0179] In some embodiments, when a TRS or CSI-RS opportunity is configured for use in RRC_INACTIVE or RRC_IDLE mode, the TRS / CSI-RS opportunity is also configured separately for DL ​​BWP#0 and DL BWP#0A as defined by CORESET#0.

[0180] In some embodiments, when the initial UL BWP (UL BWP#0) is set via SIB1 for an unpaired spectrum (TDD expansion), the initial DL BWP (DL BWP#0 or DL#0A, if provided) and UL BWP#0 for the RedCap UE do not have to share a common center frequency.

[0181] In some embodiments, the initial DL BWP settings, indicated via SIB1 (in initialDownlinkBWP), may not be used by RedCap UE.

[0182] In some embodiments, when a RedCap UE is in RRC_CONNECTED mode, one or more of the following may be used to define the initial DL BWP for the RedCap UE: (i) the initial DL BWP defined by CORESET#0, (ii) the initial DL BWP defined by CORESET#0A, if supported and provided to the UE, for at least one or more of the paging and random access-related PDL receptions, and (iii) one or more of the initial DL BWP settings for the RedCap UE, which may be optionally provided to the UE via SIB signaling separate from the initial DL BWP display for non-RedCap UEs via initialDownlinkBWP.

[0183] In some embodiments, it is assumed that for a RedCap UE, when in RRC_CONNECTED mode, the following initial DL BWP settings are defined for the RedCap UE: (i) an initial DL BWP defined by CORESET#0, (ii) an initial DL BWP defined by CORESET#0A, if provided for at least one of the paging and random access-related PDL receptions, and (iii) one or more initial DL BWP settings for the RedCap UE that may be optionally provided to the UE via SIB signaling separate from the initial DL BWP indication for non-RedCap UEs via initialDownlinkBWP.

[0184] In some embodiments, for a RedCap UE, when in RRC_CONNECTED mode, it is assumed that the following are defined for defining the initial DL BWP: (i) the initial DL BWP defined by CORESET#0, (ii) the initial DL BWP defined by CORESET#0A, if provided, for at least one or more of the paging and random access-related PDL receptions, (iii) an initial DL BWP setting for the RedCap UE that may be optionally provided to the UE via SIB signaling separate from the initial DL BWP display to non-RedCap UEs via initialDownlinkBWP, and (iv) one or more initial DL BWP settings shown to non-RedCap UEs.

[0185] In some embodiments, the initial DL BWP for a RedCap UE in connected mode is given by the initial DL BWP set for the RedCap UE (separate from the one indicated via initialDownlinkBWP), if provided, or by the initial DL BWP set for a non-RedCap UE (indicated via initialDownlinkBWP), if the BW does not exceed the maximum RedCap UE BW, or by the initial DL BWP defined by CORESET#0A, if provided and indicated, or by the initial DL BWP defined by ORESET#0.

[0186] In some embodiments, the BWP-DownlinkCommon structure provided via the DownlinkConfigCommonSIB used for initialDownlinkBWP is extended with an optional parameter locationAndBandwidth-r17 which can be configured to be used by RedCap UE to replace the locationAndBandwidth parameter associated with the initialDownlinkBWP setting, while other parameters are used as provided via initialDownlinkBWP.

[0187] In some embodiments, if a separate DL BWP#0 is provided to the RedCap UE via a DL BWP configured to a separate setting of initialDownlinkBWP or a separate setting of the locationAndBandwidth parameter, or to a UE setting with an index greater than 0, the UE expects the separately indicated DL BWP#0 or DL ​​BWP with an index greater than 0 to also include SSB and CORESET#0 for the serving cell if the span at the frequency covering at least DL BWP#0 and SSB and / or CORESET#0 can exceed the maximum RedCap UE BW.

[0188] In some embodiments, when RRC connection is made, if SSB and / or CORESET#0 are not included in the RedCap UE's active DL BWP, and the span in the frequencies covering the active DL BWP and SSB and / or CORESET#0 may exceed the maximum RedCap UE BW, the UE may be expected to retune to the frequency domain defined by CORESET#0 for DL ​​reception, for example, for a PDCCH with a CRC scrambled with SI-RNTI, P-RNTI, RA-RNTI and any associated PDSCH.

[0189] In some embodiments, if the UE is configured with a DL BWP that may not include one or more of the SSB and CORESET#0, the UE is always provided with a DL BWP configuration that includes CORESET#0 and SSB.

[0190] In some embodiments, the DL BWP setting is DL BWP#0, or a DL BWP set specifically for another UE.

[0191] In some embodiments, in the case of multiple DL BWP settings and at least one DL BWP setting that does not include SSB or CORESET#0, a DL BWP setting that includes SSB and CORESET#0 and has the smallest BWP index is selected.

[0192] In some embodiments, the frequency domain span for CORESET#0A is the same as that for a separate initial DL BWP (DL BWP#0A).

[0193] In some embodiments, the frequency domain span for CORESET#0A may be smaller than (i.e., a suitable subset thereof) the frequency domain span for DL ​​BWP#0A.

[0194] In some embodiments, the UE may expect the SSB (Synchronization Signal Block) to be configured in a separate initial DL BWP (DL BWP#0A) where a Type 1 PDCCH CSS for random access-related DL reception for the RedCap UE is configured via SIB signaling, if a Type 2 PDCCH CSS is also configured for paging reception in DL BWP#0A, and the SSB periodicity and indexing are identical to the cell-defined SSB (CD-SSB) for the camping or serving cell, but are located in the frequency domain at a non-zero offset from the NR frequency raster.

[0195] In some embodiments, if a Type 2 PDCCH CSS is also configured for paging reception in DL BWP#0A, the UE may expect a separate initial DL BWP (DL BWP#0A) configured via SIB signaling for random access-related DL reception for the RedCap UE to have settings for Type 0 and 0A for RMSI (Remaining Minimum System Information) and OSI (Other System Information) and a Synchronization Signal Block (SSB), where the periodicity and indexing of the SSB are identical to that of a CD-SSB (Cell Defining SSB) for a camping cell or service cell, but located at a non-zero offset from the NR synchronous raster in the frequency domain.

[0196] In some embodiments, the UE may be provided with a type 0 or 0A PDCCH CSS configuration having the same monitoring opportunities (MOs) as defined for CORESET#0.

[0197] In some embodiments, the UE is provided with a PDCCH MO (Monitoring Occasion) setting for the type 0 / 0A PDCCH CSS set in CORESET#0A in a separate initial DL BWP, which is provided separately from the monitoring opportunity for the type 0 / 0A PDCCH CSS set in CORESET#0.

[0198] In some embodiments, the signaling of the configuration for type 0 PDCCH CSS is provided to the UE using 4 bits used via MIB (Master Information Block) signaling for CORESET#0 as defined by the MIB.

[0199] In some embodiments, the UE may assume the same SI (System Information) monitoring window settings as CORESET#0, which include a time offset, duration, and periodicity.

[0200] In some embodiments, the multiplexing between the SSB and CORESET#0A in a separate initial DL BWP (DL BWP#0A) may follow the same multiplexing pattern used between CD-SSB (Cell Defining-SSB) and CORESET#0.

[0201] In some embodiments, the UE is provided with a multiplexing pattern between the SSB and CORESET#0A in a separate initial DL BWP via SIB1 signaling.

[0202] In some embodiments, when enhanced paging reception and PEI (Paging Early Indication) for paging monitoring are set up for the UE, and a Type 2 PDCCH CSS for paging reception is also set up for DL ​​BWP#0A, it may be expected that the PEI setting and SSB (Synchronization Signal Block) setting are provided in a separate initial DL BWP (DL BWP#0A) where a Type 1 PDCCH CSS for random access-related DL reception for the RedCap UE is set up via SIB signaling, and the SSB periodicity and indexing are identical to the cell-defined SSB (CD-SSB) for the camping or serving cell, but are located at a non-zero offset from the NR-synchronous raster in the frequency domain.

[0203] In some embodiments, the frequency position of the SSB may be provided to the RedCap UE, which is provided with SSB settings in a separate initial DL BWP (DL BWP#0A), via SIB1 signaling.

[0204] In some embodiments, the UE is provided with a starting (minimum) PRB index for SSB, and the PRB index is based on one of the following: (1) a CRB (Common Resource Block) grid, or (2) a set of PRBs indexed within DL BWP#0A (i.e., a representation of the frequency offset in the number of PRBs from the lowest PRB in DL BWP#0A), or (3) a representation of the frequency offset in the number of PRBs from the lowest PRB in CORESET#0A.

[0205] In some embodiments, the UE may optionally provide via SIB1 a subcarrier-level offset in a 15 kHz subcarrier spacing (SCS) ranging from 0 to 23 relative to FR1 (kSSB DLBWP0A), or a subcarrier-level offset in the SCS relative to an initial DL BWP defined by CORESET#0 (DL BWP#0) ranging from 0 to 11 relative to FR2, respectively. The offset is defined with respect to the PRB grid, and if not provided, the UE may assume a subcarrier level offset value of 0 for non-CD-SSB transmitted in a separate initial DL BWP (DL BWP#0A).

[0206] In some embodiments, a UE provided with an SSB configuration in a separate initial DL BWP (DL BWP#0A) may assume that SSBs with the same SSB index are QCL-ed (Quasi-Co-Located), i.e., the UE may assume that antenna ports used to transmit SS / PBCH blocks with the same index that repeat in SS / PBCH burst set periodicity are in pseudo-collocation with respect to spatial, mean gain, delay, and Doppler parameters. By default, the UE does not have to assume that antenna ports used to transmit SSBs with different indices are in pseudo-collocation with respect to spatial, mean gain, delay, and Doppler parameters.

[0207] In some embodiments, a RedCap UE that cannot support operation in an active DL BWP without an SSB may expect that, when in the RRC_CONNECTED state, one of the following is set in the active DL BWP: (1) a CD-SSB, (2) an SSB set in a separate initial DL BWP (DL BWP#0A), or (3) a separate setting of a non-cell defined SSB.

[0208] In some embodiments, a UE provided with a separate initial DL BWP (DL BWP#0A) may assume that the DMRS for the PDCCH in CORESET#0A and the DMRS for the PDSCH or associated PDSCH for receiving one or more of the type 0 / 0A / 1 / 2 PDCCH CSS sets are in the corresponding CD-SSB and QCL-ed (Quasi-Co-Located), and that the mapping to the CD-SSB index is the same as for CORESET#0 or explicitly defined via SIB1 signaling.

[0209] In some embodiments, if a separate initial DL BWP (DL BWP#0A) is provided for a UE, and a non-CD-SSB is set to the separate initial DL BWP (DL BWP#0A), then the DMRS of the PDCCH in CORESET#0A and the DMRS of the PDSCH or associated PDSCH for receiving one or more of the type 0 / 0A / 1 / 2 PDCCH CSS sets are QCL-ed (Quasi-Co-Located) with the corresponding non-CD-SSB, and the mapping to the CD-SSB index is the same as for CORESET#0 or explicitly defined via SIB1 signaling.

[0210] In some embodiments, during idle or inactive mode, the UE can expect that the UL BWP#0 configured for the RedCap UE shares the same center frequency as the initial DL BWP, during which the RedCap UE is expected to monitor type 2 PDCCH CSS candidates for monitoring as part of a random access procedure.

[0211] In some embodiments, during idle or inactive mode, the UE can expect that the UL BWP#0 configured for the RedCap UE shares the same center frequency as the initial DL BWP, during which the RedCap UE is expected to monitor type 1 PDCCH CSS candidates for monitoring as part of a random access procedure.

[0212] In some embodiments, when an SDT (Small Data Transmission) feature is set on a 4-step or 2-step RACH (RA-SDT), the initial UL BWP that sets a RACH opportunity (RO) for the RedCap UE may be used to trigger the SDT based on either the 4-step or 2-step RACH.

[0213] In some embodiments, a RedCap UE with RA-SDT features configured may expect that, in RRC inactive mode, the initial UL BWP in which the RO for sending message 1 or message A is configured on the RedCap UE shares the same center frequency as the initial DL BWP, during which the RedCap UE is expected to monitor type 1 PDCCH CSS candidates for monitoring as part of the random access procedure.

[0214] In some embodiments, if the RedCap UE is configured with an SDT (Small Data Transmission) feature on CG-SDT (Configured Grant PUSCH) that enables UL transmission when RRC is inactive, a CG PUSCH opportunity for the RedCap UE to trigger CG-SDT may be set in the initial UL BWP where RO (RACH Occasion) is set for the RedCap UE.

[0215] In some embodiments, when the CG-SDT feature is configured, in RRC inactive mode, it may be expected that the initial UL BWP, in which the CG PUSCH is set to trigger the CG-SDT on the RedCap UE, shares the same center frequency as the DL BWP, in which the RedCap UE is expected to monitor the PDCCH search space (SS) set candidates to monitor the PDCCH from the gNB in ​​response to the CG-SDT transmission.

[0216] In some embodiments, when a CG-SDT feature is set, the DL BWP that the UE is expected to monitor for PDCCH search space (SS) set candidates to monitor PDCCH from gNBs responding to a CG-SDT transmission is the same as the initial DL BWP that the UE is expected to use to monitor type 1 PDCCH CSS candidates for a Random Access (RA) procedure.

[0217] Figure 7 illustrates block diagrams of communication devices such as advanced Node-B, next-generation Node-B (gNB) (or another RAN node), transmit / receive point (TRP), access point (AP), radio station (STA), mobile station (MS), and user equipment (UE) in several embodiments. In alternative embodiments, the communication device 700 may operate as a standalone device or be connected to other communication devices (e.g., network connection).

[0218] A circuit mechanism (e.g., a processing circuit mechanism) is a collection of circuits implemented on a tangible entity of device 700, including hardware (e.g., simple circuits, gates, logic, etc.). The membership of the circuit mechanism may be flexible over time. The circuits include components that may perform specific operations individually or in combination when in operation. In one example, the hardware of the circuit may be designed immutably (e.g., hardwired) to perform specific operations. In one embodiment, the hardware of the circuit mechanism may include variably connected physical components (e.g., execution units, transistors, simple circuits, etc.) including a machine-readable medium that is physically modified (e.g., magnetically, electrically, or a movable arrangement of invariant mass particles, etc.) to encode instructions for specific operations.

[0219] When connecting physical components, the underlying electrical properties of the hardware components are changed, for example, from an insulator to a conductor, or vice versa. Instructions enable embedded hardware (e.g., an execution unit or loading mechanism) to create components of a circuit mechanism in hardware via variable connections, thereby performing a specific part of an operation during operation. Thus, in one example, a machine-readable medium element is part of a circuit mechanism or is communicatively coupled to other components of a circuit mechanism when the device is operating. In one example, any of the physical components may be used in multiple components of multiple circuits. For example, during operation, an execution unit may be used in a first circuit of a first circuit mechanism at one point in time, and reused at different times by a second circuit in the first circuit mechanism, or by a third circuit in the second circuit mechanism. Additional examples of these components relating to device 700 are as follows:

[0220] In some embodiments, device 700 may operate as a standalone device or may be connected to other devices (e.g., network connection). In a networked deployment, communication device 700 may operate as a server communication device, a client communication device, or both in a server-client network environment. For example, communication device 700 may act as a peer communication device in a peer-to-peer (P2P) (or other distributed) network environment. Communication device 700 may be a UE, eNB, PC, tablet PC, STB, PDA, mobile phone, smartphone, web appliance, network router, switch or bridge, or any communication device capable of executing (sequentially or otherwise) instructions that specify the actions that the communication device should take. Furthermore, although only a single communication device is exemplified, the term “communication device” shall be interpreted to include any collection of communication devices that individually or collectively execute a set (or set) of instructions for performing any one or more of the methods discussed herein, such as cloud computing, SaaS (software as a service), and other computer cluster configurations.

[0221] As described herein, examples may include, or operate on, logical or numerous components, modules, or mechanisms. A module is a tangible entity (e.g., hardware) capable of performing a specific operation and may be configured or arranged in a particular manner. In one example, a circuit may be arranged as a module in a particular way (e.g., internally or to an external entity such as another circuit). In one example, one or more computer systems (e.g., standalone, client, or server computer systems) or one or more hardware processors, in whole or in part, may be configured by firmware or software (e.g., instructions, application parts, or applications) as modules that operate to perform a specific operation. In one example, the software may reside on a communication device-readable medium. In one example, the software causes the hardware to perform a specific operation when executed by the underlying hardware of the module.

[0222] Therefore, the term “module” is understood to encompass tangible entities, i.e., entities that are physically constructed, specifically configured (e.g., hardwired), or temporarily configured (e.g., transiently) (e.g., programmed) to operate in a particular way or to perform some or all of any operations described herein. Considering an example where a module is temporarily configured, each module does not need to be instantiated at all times. For example, if a module includes a general-purpose hardware processor configured with software, the general-purpose hardware processor may be configured as different modules at different times. Thus, the software may configure the hardware processor to, for example, configure a particular module in one time instance and different modules in different time instances.

[0223] The communication device (e.g., UE) 700 may include a hardware processor 702 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), main memory 704, static memory 706, and storage devices 707 (e.g., a hard drive, a tape drive, a flash storage device, or other block or storage devices), some or all of which may communicate with each other via an interlink (e.g., a bus) 708.

[0224] The computer system 700 may further include a display device 710, an alphanumeric input device 712 (e.g., a keyboard), and a user interface (UI) navigation device 714 (e.g., a mouse). In one example, the display device 710, the input device 712, and the UI navigation device 714 may be touchscreen displays. The communication device 700 may additionally include a signal generating device 718 (e.g., a speaker), a network interface device 720, and one or more sensors 721 such as a Global Positioning System (GPS) sensor, a compass, an accelerometer, or another sensor. The communication device 700 may also include an output controller 728, such as a serial (e.g., Universal Serial Bar (USB)), parallel, or other wired or wireless (e.g., infrared (IR), near-field communication (NFC)) connection, for communicating with or controlling one or more peripheral devices (e.g., a printer, a card reader, etc.).

[0225] The storage device 707 may include a communication device-readable medium 722 on which one or more sets of data structures or instructions (e.g., software) embodied or utilized by any one or more of the technologies or functions described herein are stored. In some embodiments, the registers of the processor 702, the main memory 704, the static memory 706, and / or the storage device 707 may be a device-readable medium 722 on which one or more sets of data structures or instructions 724 embodied or utilized by any one or more of the technologies or functions described herein are stored, or may include (all or at least partially) it. In one example, one or any combination of the hardware processor 702, the main memory 704, the static memory 706, or the mass storage 716 may constitute the device-readable medium 722.

[0226] As used herein, the term “device-readable medium” is interchangeable with “computer-readable medium” or “machine-readable medium.” Although the communication device-readable medium 722 is exemplified as a single medium, the term “communication device-readable medium” may also include a single or multiple mediums configured to store one or more instructions 724 (e.g., a centralized or distributed database, and / or associated caches and servers). The term “communication device-readable medium” includes the terms “machine-readable medium” or “computer-readable medium” and may include any medium capable of storing, encoding, or carrying instructions (e.g., instructions 724) for execution by the communication device 700, and capable of causing the communication device 700 to execute one or more of the technologies of this disclosure, or storing, encoding, or carrying data structures used by or associated with such instructions. Examples of non-limiting communication device-readable mediums may include solid-state memory, optical media, and magnetic media. Specific examples of communication device-readable media may include non-volatile memory such as semiconductor memory devices (e.g., EPROM (Electrically Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory)) and flash memory devices, magnetic disks such as internal hard disks and removable disks, magneto-optical disks, RAM (Random Access Memory), and CD-ROM and DVD-ROM disks. In some examples, the communication device-readable media may include non-temporary communication device-readable media. In some examples, the communication device-readable media may include communication device-readable media that are not temporary propagating signals.

[0227] Instruction 724 may further be transmitted or received over the communication network 726 using a transmission medium via the network interface device 720, utilizing one of a number of transport protocols. In one example, the network interface device 720 may include one or more physical jacks (e.g., Ethernet, coaxial, or telephone jacks) or one or more antennas for connecting to the communication network 726. In one example, the network interface device 720 may include multiple antennas for wireless communication using at least one of the SIMO (single-input-multiple-output), MIMO, or MISO (multiple-input-single-output) techniques. In some examples, the network interface device 720 may wirelessly communicate using multiple-user MIMO technique.

[0228] The term “transmitting medium” includes any intangible medium capable of storing, encoding, or carrying instructions for machine execution, and is construed to include any other intangible medium for facilitating the communication of digital or analog communication signals or such software. In this context, “transmitting medium” in the context of this disclosure is a device-readable medium.

[0229] The terms “machine-readable medium,” “computer-readable medium,” and “device-readable medium” mean the same thing and may be used interchangeably in this disclosure. These terms are defined to include both machine storage media and transmission media. Therefore, these terms include both storage devices / mediums and carrier / modulated data signals.

[0230] The implementation described in the subject may include one or more features individually or in combination, as illustrated in the following examples.

[0231] Example 1 is a device for a user device (UE) configured to operate in a 5G NR (Fifth Generation New Radio) network, comprising: a processing circuit mechanism that decodes a master information block (MIB) to determine a control resource set (CORESET) and a common search space (CSS) in order to configure the UE for RedCap (Reduced Capability) operation in a 5G NR network, wherein the CORESET defines a downlink (DL) bandwidth portion (BWP); decodes a system information block (SIB) configured via downlink control information (DCI), wherein the DCI is received based on the CORESET and CSS; determines an additional CORESET using the SIB, wherein the additional CORESET defines an additional DL BWP; and performs paging monitoring associated with RedCap operation using a physical downlink shared channel (PDSCH) or physical downlink control channel (PDCCH) configured within the additional DL BWP; and a memory coupled to the processing circuit mechanism and configured to store the MIB and SIB.

[0232] In Example 2, the subject of Example 1 includes a subject in which the processing circuit mechanism is configured to perform a random access procedure during RedCap operation using a PDSCH or PDCCH set up in an additional BWP.

[0233] In Example 3, the themes from Examples 1 and 2 include themes in which the processing circuit mechanism is configured to determine the size of the DCI based on the CORESET.

[0234] In Example 4, the themes from Examples 1-3 include themes configured to perform paging monitoring based on the processing circuit mechanism monitoring the additional CORESET type 2 CSS in the additional CORESET when the UE is in RRC_CONNECTED mode and the additional CORESET physical resource block (PRB) is included in the DL BWP.

[0235] In Example 5, the themes from Examples 1-4 include themes configured to perform paging monitoring based on monitoring the PDCCH type 1 CSS in the additional CORESET when the processing circuit mechanism is shown to map the PDCCH type 1 CSS to an additional CORESET, the UE is in RRC_CONNECTED mode, and the physical resource block (PRB) of the additional CORESET is included in the active DL BWP.

[0236] In Example 6, the themes from Examples 1-5 include themes where the frequency domain span of the additional CORESET is smaller than the frequency domain span for the additional DL BWP.

[0237] In Example 7, the themes from Examples 1-6 include the themes of whether DL BWP sets up a cell-defined synchronization signal block (CD-SSB) or a separate setting for non-CD-SSB when the UE is in the RRC_CONNECTED state.

[0238] In Example 8, the themes of Examples 1-7 include themes in which the processing circuit mechanism is configured to determine that the demodulation reference signal (DMRS) of the PDCCH and the DMRS of the PDSCH for receiving the PDSCH or one or more PDCCH CSS sets are in the cell-defined synchronization signal block (CD-SSB) and QCL-ed (Quasi-Co-Located).

[0239] In Example 9, the themes from Examples 1-8 are configured such that the processing circuit mechanism determines the uplink (UL) BWP defined by the CORESET and additional UL BWPs defined by additional CORESETs, the additional UL BWPs include themes associated with RedCap operation.

[0240] In Example 10, the subject of Example 9 includes subjects in which additional DL BWP and additional UL BWP share the same center frequency.

[0241] In Example 11, the subject matter of Examples 1-10 includes a transceiver circuit coupled to a processing circuit mechanism, and one or more antennas coupled to the transceiver circuit.

[0242] Example 12 is a computer-readable storage medium for storing instructions for execution by one or more processors of a source base station, wherein the instructions configure the base station for RedCap (Reduced Capability) operation in a 5G NR (Fifth Generation New Radio) network and cause the base station to perform the operation, the operation encoding a Master Information Block (MIB) for transmission to a RedCap user equipment (UE), the MIB configuring a Control Resource Set (CORESET) and a Common Search Space (CSS), the CORESET defining a Downlink (DL) Bandwidth Portion (BWP), and encoding a System Information Block (SIB) for transmission to a RedCap UE, the SIB being transmitted based on Downlink Control Information (DCI), the DCI being transmitted based on the CORESET and CSS, the SIB further configuring an additional CORESET for the RedCap UE, the additional CORESET defining an additional DL BWP, and using a Physical Downlink Shared Channel (PDSCH) or Physical Downlink Control Channel (PDCCH) configured within the additional DL BWP, RedCap This includes encoding paging information associated with RedCap operation for transmission to the UE.

[0243] In Example 13, the subject from Example 12 includes a subject whose frequency domain span for the additional CORESET is smaller than the frequency domain span for the additional DL BWP.

[0244] Example 14 is a computer-readable storage medium for storing instructions for execution by one or more processors of a user device (UE), the instructions for configuring the UE for RedCap (Reduced Capability) operation in a 5G NR (Fifth Generation New Radio) network and causing the UE to perform an operation, the operation comprising decoding a Master Information Block (MIB) to determine a Control Resource Set (CORESET) and a Common Search Space (CSS), the CORESET defining a Downlink (DL) Bandwidth Portion (BWP), decoding a System Information Block (SIB) configured via Downlink Control Information (DCI), the DCI being received based on the CORESET and CSS, determining an additional CORESET using the SIB, the additional CORESET defining an additional DL BWP, and performing paging monitoring associated with the RedCap operation using a Physical Downlink Shared Channel (PDSCH) or Physical Downlink Control Channel (PDCCH) configured within the additional DL BWP.

[0245] In Example 15, the subject of Example 14 further includes the operation of performing a random access procedure during RedCap operation using a PDSCH or PDCCH configured within an additional BWP.

[0246] In Example 16, the subject matter of Examples 14-15 is further expanded to include the operation of determining the size of the DCI based on the CORESET.

[0247] In Example 17, the subject matter of Examples 14-16 is further expanded to include performing paging monitoring based on monitoring PDCCH type 2 CSS in the additional CORESET when the UE is in RRC_CONNECTED mode and the additional CORESET's physical resource block (PRB) is contained within the DL BWP.

[0248] In Example 18, the subject matter of Examples 14–17 is shown to be mapped to an additional CORESET, and further includes performing paging monitoring based on monitoring the PDCCH type 1 CSS in the additional CORESET when the UE is in RRC_CONNECTED mode and the physical resource block (PRB) of the additional CORESET is contained within the DL BWP.

[0249] In Example 19, the themes from Examples 14–18 include themes where the frequency domain span of the additional CORESET is smaller than the frequency domain span for the additional DL BWP.

[0250] In Example 20, the themes from Examples 14-19 include the theme of whether DL BWP sets up a cell-defined synchronization signal block (CD-SSB) or a separate setting for non-CD-SSB when the UE is in the RRC_CONNECTED state.

[0251] Example 21 is at least one machine-readable medium containing instructions, the instructions being at least one machine-readable medium that, when executed by a processing circuit mechanism, causes the processing circuit mechanism to perform an action to implement any of Examples 1 to 20.

[0252] Example 22 is a device that includes means for implementing any of Examples 1 to 20.

[0253] Example 23 is a system that implements one of Examples 1 through 20.

[0254] Example 24 is a way to implement any of Examples 1 through 20.

[0255] Example 25 is a device for a user device (UE) configured to operate in a 5G NR (Fifth Generation New Radio) network, comprising: a processing circuit mechanism that decodes a master information block (MIB) to determine a control resource set (CORESET) and a common search space (CSS) in order to configure the UE for RedCap (Reduced Capability) operation in a 5G NR network; decodes a system information block (SIB) in a physical downlink shared channel (PDSCH) scheduled by downlink control information (DCI) format, the DCI format being received based on the CORESET and CSS; uses the SIB to determine an additional CORESET in a separate initial DL BWP; and in the separate initial DL BWP, performs the reception of a physical downlink control channel (PDCCH) in a PDCCH type 1 CSS (Common Search Space) set, or a PDSCH associated with a Random Access (RA) procedure; and a memory coupled to the processing circuit mechanism and configured to store the MIB and SIB.

[0256] In Example 26, the subject of Example 25 includes a subject in which the processing circuit mechanism is configured to perform receiving of PDCCH in a PDCCH type 2 CSS set, or PDSCH for paging monitoring in a separate initial DL BWP for RedCap operation.

[0257] In Example 27, the themes of Examples 25-26 include themes configured to determine the initial DL BWP when a UE transitions to the RRC_CONNECTED state, either as a separate initial DL BWP set for the RedCap UE (separate from the one indicated via initialDownlinkBWP), if provided, or as one of the initial DL BWPs set for the non-RedCap UE (indicated via initialDownlinkBWP), provided that the bandwidth (BW) of the initial DL BWP for the non-RedCap UE does not exceed the maximum RedCap UE BW.

[0258] In Example 28, the themes of Examples 25-27 include themes configured to determine the initial DL BWP when a UE transitions to the RRC_CONNECTED state, either as a separate initial DL BWP set for the RedCap UE (separate from the one indicated via initialDownlinkBWP), if provided, or as one of the initial DL BWPs set for the non-RedCap UE (indicated via initialDownlinkBWP), provided that the bandwidth (BW) of the initial DL BWP for the non-RedCap UE does not exceed the maximum RedCap UE BW, or as one of the initial DL BWPs defined by the CORESET indicated by the MIB.

[0259] In Example 29, the themes from Examples 26-28 include themes configured to perform paging monitoring based on the processing circuit mechanism monitoring a PDCCH type 2 CSS in the additional CORESET when the UE is in RRC_CONNECTED mode, the additional CORESET's physical resource block (PRB) is contained within the active DL BWP, and the active DL BWP and the separate initial DL BWP have the same subcarrier interval (SCS).

[0260] In Example 30, the themes from Examples 25-29 include themes configured to perform random access-related DL reception based on monitoring the PDCCH type 1 CSS in the additional CORESET, where the processing circuit mechanism is shown to map a PDCCH type 1 CSS to an additional CORESET, the UE is in RRC_CONNECTED mode, the physical resource block (PRB) of the additional CORESET is contained within the active DL BWP, and the active DL BWP and a separate initial DL BWP have the same SCS.

[0261] In Example 31, the subject matter of Examples 25-30 includes CSS settings.

[0262] In Example 32, the themes of Examples 25-31 include themes in which the processing circuit mechanism is configured to determine that the demodulation reference signal (DMRS) of the PDCCH and the DMRS of the PDSCH in a separate initial DL BWP are in the cell-defined synchronization signal block (CD-SSB) and QCL-ed (Quasi-Co-Located).

[0263] In Example 33, the themes of Examples 25-32 include themes in which a processing circuit mechanism is configured to determine a separate initial UL BWP associated with an initial uplink (UL) BWP or RedCap operation for a UL transmission as part of a Random Access (RA) procedure that includes one or more PUCCHs in response to Msg1 (Message 1), Msg3 (Message 3), MsgA (Message A), Msg4 (Message 4), or MsgB (Message B), based on the reception of a SIB1 (System Information Block Type 1) signal.

[0264] In Example 34, the subject of Example 33 includes the fact that separate initial DL BWP and initial UL BWP, or separate initial UL BWP set for UL transmissions associated with the RA procedure, share the same center frequency for operation in the unpaired spectrum.

[0265] In Example 35, the subject matter of Examples 25-34 includes a transceiver circuit coupled to a processing circuit mechanism, and one or more antennas coupled to the transceiver circuit.

[0266] Example 36 is a computer-readable storage medium for storing instructions for execution by one or more processors of a source base station, wherein the instructions configure the base station for RedCap (Reduced Capability) operation in a 5G NR (Fifth Generation New Radio) network and cause the base station to perform the operation, the operation encoding a Master Information Block (MIB) for transmission to a RedCap user equipment (UE), the MIB configuring a Control Resource Set (CORESET) and a Common Search Space (CSS), and encoding a System Information Block (SIB) for transmission to a RedCap UE, the SIB being transmitted in a Physical Downlink Shared Channel (PDSCH) scheduled by Downlink Control Information (DCI) format, the DCI format being transmitted based on the CORESET and CSS, the SIB further configuring an additional CORESET in a separate initial DL BWP for the RedCap UE, and RedCap in DL using a Physical Downlink Control Channel (PDCCH) or Physical Downlink Shared Channel (PDSCH) in a PDCCH Type 1 CSS set configured in a separate initial DL BWP. A computer-readable storage medium that includes encoding information associated with the RA procedure for transmission to the UE.

[0267] In Example 37, the subject of Example 36 includes a subject in which the frequency domain span of the additional CORESET is less than or equal to the frequency domain span for a separate initial DL BWP.

[0268] Example 38 is a computer-readable storage medium for storing instructions for execution by one or more processors of a user device (UE), wherein the instructions configure the UE for RedCap (Reduced Capability) operation in a 5G NR (Fifth Generation New Radio) network and cause the UE to perform an operation, the operation comprising: decoding a Master Information Block (MIB) to determine a Control Resource Set (CORESET) and a Common Search Space (CSS); decoding a System Information Block (SIB) in a Physical Downlink Shared Channel (PDSCH) scheduled by Downlink Control Information (DCI) format, the DCI format being received based on the CORESET and CSS; using the SIB to determine an additional CORESET in a separate initial DL BWP; and in a separate initial DL BWP, performing the reception of a Physical Downlink Control Channel (PDCCH) in a PDCCH Type 1 CSS (Common Search Space) set, or a PDSCH associated with a Random Access (RA) procedure.

[0269] In Example 39, the subject of Example 38 further includes operations that involve receiving a PDCCH within a PDCCH type 26 CSS set, or a PDSCH for paging monitoring within a separate initial DL BWP for RedCap operation.

[0270] In Example 40, the subject matter of Examples 38-40 further includes the operation of determining the initial DL BWP when the UE transitions to the RRC_CONNECTED state, either as a separate initial DL BWP set for the RedCap UE (separate from the one indicated via initialDownlinkBWP), if provided, or as one of the initial DL BWPs set for the non-RedCap UE (indicated via initialDownlinkBWP), provided that the bandwidth (BW) of the initial DL BWP for the non-RedCap UE does not exceed the maximum RedCap UE BW.

[0271] In Example 41, the subject matter of Examples 38-40 further includes the operation of determining the initial DL BWP when the UE transitions to the RRC_CONNECTED state, either as a separate initial DL BWP set for the RedCap UE (separate from the one indicated via initialDownlinkBWP), if provided, or as one of the initial DL BWPs defined by the CORESET indicated by the MIV, if the bandwidth (BW) of the initial DL BWP for the non-RedCap UE does not exceed the maximum RedCap UE BW, or as one of the initial DL BWPs set for the non-RedCap UE (indicated via initialDownlinkBWP).

[0272] Example 42 further includes the operation of performing paging monitoring based on the subject matter of Examples 39-41, where the UE is in RRC_CONNECTED mode, the additional CORESET's physical resource block (PRB) is contained within the active DL BWP, and the active DL BWP and the separate initial DL BWP have the same subcarrier interval (SCS), and monitoring the PDCCH type 2 CSS in the additional CORESET.

[0273] In Example 43, the subject matter of Examples 38-42 is shown to be mapped to an additional CORESET, and the operation further includes performing random access-related DL reception based on monitoring the PDCCH type 1 CSS in the additional CORESET when the UE is in RRC_CONNECTED mode, the physical resource block (PRB) of the additional CORESET is contained within the active DL BWP, and the active DL BWP and a separate initial DL BWP have the same SCS.

[0274] In Example 44, the subject matter of Examples 38-43 includes CSS settings.

[0275] Example 45 is at least one machine-readable medium containing instructions, which, when executed by a processing circuit, cause the processing circuit to perform an action to implement any of Examples 25 to 44.

[0276] Example 46 is a device that includes means for implementing any of Examples 25 to 44.

[0277] Example 47 is a system for implementing any of Examples 25-44.

[0278] Example 48 is a method for implementing any of Examples 25-44.

[0279] While certain embodiments are described with reference to specific exemplary embodiments, it will be apparent that various modifications and changes may be made to these embodiments without departing from the broader scope of this disclosure. Therefore, the specification and drawings should be considered illustrative rather than restrictive. Accordingly, this detailed description should not be interpreted restrictively, and the scope of the various embodiments, along with the entire scope of equivalents of those titled "Appendix Claims," ​​is defined solely by the Appendix Claims.

Claims

1. A device for RedCap (reduced capacities) user equipment (UE) configured to operate in a 5G NR (Fifth Generation New Radio) network, A processing circuit mechanism for setting up the RedCap UE for a random access procedure in the 5G NR network, Decoding a first configuration signaling to explicitly obtain an initial downlink bandwidth portion (DL BWP), wherein the initial DL BWP includes downlink resources in the Common Search Space (CSS), and the first configuration signaling explicitly specifies to the RedCap UE an initial DL BWP for use by the RedCap UE that is different from the initial DL BWP signaled by the first configuration signaling for use by a non-RedCap UE. Decoding the second configuration signaling to explicitly obtain the initial uplink bandwidth portion (UL BWP) of the RedCap UE, wherein the initial UL BWP of the RedCap UE includes uplink resources, and the second configuration signaling explicitly specifies to the RedCap UE an initial UL BWP for use by the RedCap UE that is different from the initial UL BWP signaled by the second configuration signaling for use by the non-RedCap UE. A processing circuit mechanism that performs the random access procedure based on decoding a first random access communication received using the downlink resource of the CSS and encoding a second random access communication for transmission using the uplink resource, An apparatus comprising: a memory coupled to the processing circuit mechanism and configured to store the first setting signaling and the second setting signaling.

2. The apparatus according to claim 1, wherein the center frequency of the initial DL BWP of the RedCap UE is the same as the center frequency of the initial UL BWP of the RedCap UE.

3. The aforementioned processing circuit mechanism is The apparatus according to claim 1, wherein during the RRC_CONNECTED state, a third setting signaling is decoded, the third setting signaling sets an active DL BWP for the RedCap UE, and the active DL BWP includes a synchronization signal block (SSB).

4. The apparatus according to claim 3, wherein the SSB is a non-cell-defined SSB.

5. The aforementioned processing circuit mechanism is Decoding a System Information Block (SIB) in a Physical Downlink Shared Channel (PDSCH) scheduled by Downlink Control Information (DCI) format, wherein the DCI format is received based on the CSS, Using the aforementioned SIB, an additional set of control resources (CORESET) is determined within a separate initial DL BWP, The apparatus according to claim 1, wherein the separate initial DL BWP is configured to perform reception of a physical downlink control channel (PDCCH) in a PDCCH type 1CSS set, or a PDSCH associated with a second random access procedure.

6. The aforementioned processing circuit mechanism is The apparatus according to claim 5, configured to perform receiving of a PDCCH in a PDCCH type 2 CSS set, or a PDSCH for paging monitoring in the separate initial DL BWP for RedCap operation.

7. The aforementioned processing circuit mechanism is The apparatus according to claim 6, wherein the UE is in RRC_CONNECTED mode, an additional CORESET physical resource block (PRB) is included in the active DL BWP, and the apparatus is configured to perform the paging monitoring based on monitoring the PDCCH type 2 CSS in the additional CORESET when the active DL BWP and a separate initial DL BWP have the same subcarrier spacing (SCS).

8. The aforementioned processing circuit mechanism is The apparatus according to claim 5, which is configured to perform random access-related DL reception based on monitoring a PDCCH type 1 CSS in the additional CORESET, wherein when the PDCCH type 1 CSS is indicated to be mapped to the additional CORESET, the UE is in RRC_CONNECTED mode, the physical resource blocks (PRBs) of the additional CORESET are contained within an active DL BWP, and the active DL BWP and the separate initial DL BWP have the same SCS.

9. If, when the UE is in the RRC_CONNECTED state, the UE does not demonstrate the ability to operate in a DL BWP without a synchronization signal block (SSB), the UE expects that the active RRC-configured DL BWP includes a cell-defined synchronization signal block (CD-SSB) or that a separate configuration is provided for a non-CD-SSB in the active DL BWP, wherein the non-CD-SSB is an SSB that is not used to determine the PCID (Primary Cell Identity) or to obtain SIB1 scheduling information (PDCCH type 0 CSS configuration), the apparatus according to claim 5.

10. A transceiver circuit mechanism coupled to the processing circuit mechanism, The apparatus according to claim 1, further comprising one or more antennas coupled to the transceiver circuit mechanism.

11. A non-temporary computer-readable storage medium storing instructions for execution by one or more processors of a source base station, wherein the instructions configure the base station for RedCap (Reduced Capability) operation in a 5G NR (Fifth Generation New Radio) network and cause the base station to perform the operation, the operation being: Encoding a first configuration signaling that explicitly indicates an initial downlink bandwidth portion (DL BWP) to a RedCap user device (UE), wherein the initial DL BWP includes downlink resources in the Common Search Space (CSS), and the first configuration signaling explicitly specifies to the RedCap UE an initial DL BWP for use by the RedCap UE that is different from the initial DL BWP signaled in the first configuration signaling for use by a non-RedCap UE. Encoding a second configuration signaling that explicitly indicates an initial uplink bandwidth portion (UL BWP) to the RedCap UE, wherein the initial UL BWP of the RedCap UE includes uplink resources, and the second configuration signaling explicitly specifies to the RedCap UE an initial UL BWP for use by the RedCap UE that is different from the initial UL BWP signaled by the second configuration signaling for use by the non-RedCap UE. A computer-readable storage medium comprising encoding random access communications for transmission to the RedCap UE using the downlink resources of the CSS.

12. The computer-readable storage medium according to claim 11, wherein the center frequency of the initial DL BWP of the RedCap UE is the same as the center frequency of the initial UL BWP of the RedCap UE.

13. The aforementioned operation is, The computer-readable storage medium according to claim 11, comprising encoding a third setting signaling for transmission to the RedCap UE, wherein the RedCap UE is in the RRC_CONNECTED state, the third setting signaling sets up an active DL BWP for the RedCap UE, and the active DL BWP includes a synchronization signal block (SSB).

14. A non-temporary computer-readable storage medium for storing instructions for execution by one or more processors of a RedCap (Reducet Capability) user device (UE), wherein the instructions configure the RedCap UE for RedCap operation in a 5G NR (Fifth Generation New Radio) network and cause the RedCap UE to perform an operation, the operation being: Decoding a first configuration signaling to explicitly obtain an initial downlink bandwidth portion (DL BWP), wherein the initial DL BWP includes downlink resources in the Common Search Space (CSS), and the first configuration signaling explicitly specifies to the RedCap UE an initial DL BWP for use by the RedCap UE that is different from the initial DL BWP signaled by the first configuration signaling for use by a non-RedCap UE. Decoding the second configuration signaling to explicitly obtain the initial uplink bandwidth portion (UL BWP) of the RedCap UE, wherein the initial UL BWP of the RedCap UE includes uplink resources, and the second configuration signaling explicitly specifies to the RedCap UE an initial UL BWP for use by the RedCap UE that is different from the initial UL BWP signaled by the second configuration signaling for use by the non-RedCap UE. A computer-readable storage medium comprising performing a random access procedure based on decoding a first random access communication received using the downlink resource of the CSS and encoding a second random access communication for transmission using the uplink resource.

15. The computer-readable storage medium according to claim 14, wherein the center frequency of the initial DL BWP of the RedCap UE is the same as the center frequency of the initial UL BWP of the RedCap UE.

16. The aforementioned operation is, The computer-readable storage medium according to claim 14, comprising decoding a third setting signaling during the RRC_CONNECTED state, wherein the third setting signaling sets an active DL BWP for the RedCap UE, and the active DL BWP includes a synchronization signal block (SSB).

17. The computer-readable storage medium according to claim 16, wherein the SSB is a non-cell-defined SSB.

18. The aforementioned operation is, Decoding a System Information Block (SIB) in a Physical Downlink Shared Channel (PDSCH) scheduled by Downlink Control Information (DCI) format, wherein the DCI format is received based on the CSS, Using the aforementioned SIB, an additional set of control resources (CORESET) is determined within a separate initial DL BWP, The computer-readable storage medium according to claim 14, further comprising performing reception of a physical downlink control channel (PDCCH) in a PDCCH type 1CSS set, or a PDSCH associated with a second random access procedure, in the separate initial DL BWP.

19. The aforementioned operation is, The computer-readable storage medium according to claim 18, further comprising performing reception of a PDCCH in a PDCCH type 2 CSS set, or a PDSCH for paging monitoring in the separate initial DL BWP for RedCap operation.

20. The aforementioned operation is, The computer-readable storage medium according to claim 19, further comprising performing the paging monitoring based on monitoring the PDCCH type 2 CSS in the additional CORESET when the UE is in RRC_CONNECTED mode, the additional CORESET physical resource block (PRB) is contained within the active DL BWP, and the active DL BWP and a separate initial DL BWP have the same subcarrier spacing (SCS).

Images