Random access for reduced-function (REDCAP) devices

Abstract

This is a computer-readable storage medium that stores instructions for the execution of one or more processors of the eRedCap UE. The instructions configure the eRedCap UE for the RACH procedure in 5G NR and later networks, causing the eRedCap UE to perform operations including encoding UL data for the PUSCH transmission in Msg3. The DCI format schedules a Physical Downlink Shared Channel (PDSCH) transmission for UE conflict resolution in the fourth message (Msg4). The eRedCap UE detects that the PDSCH transmission scheduled by the DCI format contains allocated PRBs that exceed the maximum number of PRBs associated with the eRedCap UE. Based on the detection that the allocated PRBs exceed the maximum number of PRBs, the eRedCap UE determines that UE conflict resolution is unsuccessful.

Description

[Background technology]

[0001] [Claiming priority] This application claims priority to and incorporates the entirety of U.S. Provisional Patent Application No. 63 / 492,418, entitled “SYSTEMS AND METHODS FOR RANDOM ACCESS FOR REDUCED CAPABILITY USER EQUIPMENTS,” filed on 27 March 2023.

[0002] [Background technology] Mobile communications have evolved remarkably 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) in modern society continues to drive demand for diverse network-connected devices in many different environments. Fifth-generation (5G) wireless systems are emerging and are expected to enable even higher speeds, connectivity, and usability. Next-generation 5G networks (or NR networks) and beyond (e.g., 6G networks) are expected to increase throughput, coverage, and robustness, while reducing latency and operational and capital expenditures. 5G-NR (and beyond) networks will continue to evolve based on 3GPP® LTE-Advanced, which has further potential new radio access technologies (RATs) to enrich people's lives with seamless wireless connectivity solutions that deliver high-speed, rich content and services. Since current cellular network frequencies are saturated, higher frequencies such as millimeter wave (mmWave) frequencies can be beneficial due to their higher bandwidth.

[0003] Further extended operations of LTE and NR systems in licensed and unlicensed spectra are expected in future releases and systems beyond 5G. Such extended operations can include techniques for configuring random access for reduced-capability user equipment (UE).

Brief Description of Drawings

[0004] In the drawings, which are not necessarily to scale, like numerals may describe like components in different figures. Like numerals with different subscripts may represent different instances of like components. The drawings generally illustrate, by way of example, and not by way of limitation, various aspects discussed in this document. [Figure 1A] Shows the network architecture according to some aspects. [Figure 1B] Shows a non-roaming 5G system architecture according to some aspects. [Figure 1C] Shows a non-roaming 5G system architecture according to some aspects. [Figure 2] Shows various systems, devices, and components that can implement aspects of the disclosed embodiments. [Figure 3] Shows various systems, devices, and components that can implement aspects of the disclosed embodiments. [Figure 4] Shows various systems, devices, and components that can implement aspects of the disclosed embodiments. [Figure 5] Shows a 4-step random access channel (RACH) procedure according to some aspects. [Figure 6] Shows a RACH procedure with early failure identification after receiving a random access response (RAR) according to some aspects. [Figure 7]This document describes a RACH procedure involving early failure identification after decoding downlink control information (DCI) that schedules the initial transmission of Msg4, in several embodiments. [Figure 8] The diagrams show block diagrams of communication devices such as evolved Node-B (eNB), new generation Node-B (gNB) (or other RAN nodes), NCRs, access points (AP), wireless stations (STA), mobile stations (MS), or user equipment (UE) in several configurations. [Modes for carrying out the invention]

[0005] The following description and drawings are intended to illustrate embodiments to enable those skilled in the art to carry them out. Other embodiments may incorporate structural, logical, electrical, process, and other modifications. Some parts and features of certain embodiments may be included in or substituted for those of other embodiments. The embodiments outlined in the claims encompass all available equivalents of those claims.

[0006] Figures 1A to 8 illustrate various systems, devices, and components that may implement embodiments of the disclosure in different communication systems, such as 5G-NR (and later) networks. The UEs, base stations (gNBs, etc.), and / or other nodes (e.g., satellites or other computing nodes) discussed herein can be configured to perform the technologies of the disclosure.

[0007] Figure 1A shows a network architecture in several embodiments. The communication network 140A is shown to include user equipment (UE) 101 and UE102. UE101 and UE102 are shown as smartphones (e.g., handheld touchscreen mobile computing devices capable of connecting to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as a personal data assistant (PDA), pager, laptop computer, desktop computer, wireless handset, drone, or any other computing device including wired and / or wireless communication interfaces. UE101 and UE102 may collectively be referred to as UE101, which can be used to perform one or more of the technologies disclosed herein.

[0008] Any of the wireless links described herein (for example, used in communication network 140A or any other illustrated network) may operate in accordance with any of the exemplary wireless communication technologies and / or standards.

[0009] LTE and LTE-Advanced are standards for high-speed data wireless communications for UEs such as mobile phones. In LTE-Advanced and various wireless systems, carrier aggregation is a technique in which multiple carrier signals operating on different frequencies can be used to carry communications for a single UE, thus increasing the bandwidth available to a single device. In some embodiments, carrier aggregation may be used when one or more component carriers operate on unlicensed frequencies.

[0010] The embodiments described herein can be used in the context of any spectrum management scheme, including, for example, dedicated license spectrum, unlicensed spectrum, and (licensed) shared spectrum (such as Licensed Shared Access (LSA) in the 2.3-2.4 GHz, 3.4-3.6 GHz, 3.6-3.8 GHz and higher frequencies, and Spectrum Access System (SAS) in the 3.55-3.7 GHz and higher frequencies).

[0011] The embodiments described herein can also be applied to different single-carrier or OFDM flavors (CP-OFDM, SC-FDMA, SC-OFDM, filter bank-based multicarrier (FBMC), OFDM, etc.), and in particular can be applied to 3GPP® NR by assigning OFDM carrier data bit vectors to corresponding symbol resources.

[0012] In some embodiments, either UE101 or UE102 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-term UE connectivity. In some embodiments, either UE101 or UE102 may include a narrowband (NB) IoT UE (e.g., an enhanced NB-IoT (eNB-IoT) UE and a further enhanced (FeNB-IoT) UE). The IoT UE may utilize technologies such as a public land mobile network (PLMN), proximity-based service (ProSe), device-to-device (D2D) communication, a sensor network, or machine-to-machine (M2M) or machine-type communications (MTC) to exchange data with an MTC server or device via the IoT network. The exchange of data between machine-to-machine (M2M) or machine-to-machine (MTC) systems may also be machine-initiated exchanges of data. An IoT network involves interconnecting IoT UEs (Internet Entity-Effectives), which may include uniquely identifiable embedded computing devices (within the Internet infrastructure), via short-term connections. IoT UEs may run background applications (e.g., key-alive messages, status updates, etc.) to facilitate connectivity within the IoT network.

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

[0014] UE101 and UE102 may be configured to connect to a radio access network (RAN) 110, for example, to be communicatively coupled. The RAN 110 may be, for example, a Universal Mobile Telecommunications System (UMTS), an Evolved UMTS Terrestrial Radio Access Network (E-UTRAN), a NextGen RAN (NG RAN), or any other type of RAN. UE101 and UE102 utilize connections 103 and 104, respectively, each of which includes a physical communication interface or layer (discussed in more detail below). In this example, connections 103 and 104 are shown as air interfaces to enable 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, push-to-talk (PTT) protocol, POC (PTT over Cellular) protocol, UMTS (Universal Mobile Telecommunications System) protocol, 3GPP LTE (Long Term Evolution) protocol, fifth-generation (5G) protocol, and new radio (NR) protocol.

[0015] 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 that includes, but is not limited to, one or more logical channels, including a Physical Sidelink Control Channel (PSCCH), a Physical Sidelink Shared Channel (PSSCH), a Physical Sidelink Discovery Channel (PSDCH), and a Physical Sidelink Broadcast Channel (PSBCH).

[0016] UE102 is shown to be 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 Wireless Fidelity (WiFi®) router. In this example, AP106 is shown to connect to the internet without connecting to the core network of the wireless system (discussed in more detail below).

[0017] RAN110 may include one or more access nodes that enable connections 103 and 104. These access nodes (ANs) may be called base stations (BSs), NodeBs, evolved NodeBs (eNBs), next-generation NodeBs (gNBs), RAN network nodes, etc., and may include ground stations (e.g., terrestrial 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 transmission / reception points (TRPs). If communication nodes 111 and 112 are NodeBs (e.g., eNBs or gNBs), one or more TRPs may function within the communication cell of the NodeB. RAN110 may include one or more RAN nodes for providing macrocells, e.g., macroRAN nodes, and one or more RAN nodes for providing femtocells or picocells (e.g., cells with smaller coverage area, smaller user capacity, or higher bandwidth compared to macrocells), e.g., low-power (LP) RAN nodes or unlicensed spectrum-based secondary RAN nodes.

[0018] Either communication node 111 or 112 can terminate the air interface protocol and serve as the initial contact point for UE101 and UE102. In some embodiments, either communication node 111 or 112 can implement 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 and data packet scheduling, and mobility management. For example, either communication node 111 and / or 112 can be a new generation Node-B (gNB), an evolved Node-B (eNB), or another type of RAN node.

[0019] RAN110 is shown to be communicably coupled to core network (CN)120 via S1 interface 113. In this embodiment, CN120 may be an evolved packet core (EPC) network, a NextGen Packet Core (NPC) network, or any other type of CN (for example, as shown in Figures 1B-1C). In this embodiment, S1 interface 113 is divided into two parts: S1-U interface 114, which carries user traffic data between communication nodes 111 and 112 and a serving gateway (S-GW) 122, and S1-MME interface 115, which is a signaling interface between communication nodes 111 and 112 and a mobility management entity (MME) 121.

[0020] In this embodiment, CN120 includes MME121, S-GW122, Packet Data Network (PDN) Gateway (P-GW)123, and home subscriber server (HSS)124. MME121 may be functionally similar to the control plane of a Legacy Serving General Packet Radio Service (GPRS) Support Node (SGSN). 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 network entities in communication sessions. CN120 may include one or more HSS124s, depending on the number of mobile subscribers, equipment capacity, network configuration, etc. For example, HSS124 can provide support for routing / roaming, authentication, authorization, naming / address resolution, location dependency, etc.

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

[0022] P-GW123 may terminate the SGi interface toward the PDN. P-GW123 may route data packets between the EPC network 120 (e.g., CN120) and an external network such as an application server 184 (alternatively referred to as an application function (AF)) via an Internet Protocol (IP) interface 125. P-GW123 can also communicate data to other external networks 131A, which may include the Internet, an IP multimedia subsystem (IPS) network, and other networks. Generally, the application server 184 may also be an element that provides applications that use IP bearer resources together with the core network (e.g., a UMTS packet services (PS) domain, an LTE PS data service, etc.). In this embodiment, P-GW123 is shown to be 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 UE102 via CN120 (e.g., Voice-over-Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.).

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

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

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

[0026] In some embodiments, the NG system architecture can use reference points between various nodes, as provided by 3GPP Technical Specification (TS) 23.501 (e.g., V15.4.0, 2018-12). In some embodiments, the gNB and NG-eNB can be implemented as base stations, mobile edge servers, small cells, home eNBs, RAN network nodes, 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 the licensed band, and the secondary node may operate in the unlicensed band.

[0027] Figure 1B shows several embodiments of a non-roaming 5G system architecture. Referring to Figure 1B, the 5G system architecture 140B is shown in reference point representation. More specifically, UE 102 can communicate with RAN 110 and one or more other 5G core (5GC, 5G core) network entities. The 5G system architecture 140B includes multiple network functions (NF), such as an access and mobility management function (AMF) 132, a location management function (LMF) 133, a session management function (SMF) 136, a policy control function (PCF) 148, an application function (AF) 150, a user plane function (UPF) 134, a network slice selection function (NSSF) 142, an authentication server function (AUSF) 144, and a unified 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. The AMF 132 can be used to manage access control and mobility and may also include a network slice selection function. 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).

[0028] The LMF133 may be used in connection with 5G positioning functionality. In some embodiments, the LMF133 receives measurements and support information from the RAN110 and a mobile device (e.g., UE101) via the AMF132 on the NL interface to calculate the position of the UE101. In some embodiments, the NR positioning protocol A (NRPPa) may be used to carry positioning information between the NG-RAN and the LMF133 on the next generation control plane interface (NG-C). In some embodiments, the LMF133 configures the UE using the LTE positioning protocol (LPP) via the AMF132. The RAN110 configures the UE101 using the radio resource control (RRC) protocol on the LTE-Uu and NR-Uu interfaces.

[0029] In some embodiments, the 5G system architecture 140B configures 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). The downlink positioning reference signal (PRS) is a reference signal configured to support a downlink-based positioning method.

[0030] In some embodiments, the 5G system architecture 140B includes an IP multimedia subsystem (IMS) 168B and several IP multimedia core network subsystem entities such as a call session control function (CSCF). More specifically, the IMS 168B includes CSCFs that can operate as a proxy CSCF (P-CSCF) 162BE, a serving CSCF (S-CSCF) 164B, an emergency CSCF (E-CSCF) (not shown in Figure 1B), or an interrogating CSCF (I-CSCF) 166B. The P-CSCF 162B can be configured to be the first contact point for UE 102 within the IMS 168B. The S-CSCF 164B can be configured to handle session state within the network, and the E-CSCF can be configured to handle specific 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 contact point within the operator's network for all IMS connections destined for 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 170, for example, an IMS operated by a different network operator.

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

[0032] Reference point representation indicates that interactions can exist between corresponding NF services. For example, Figure 1B shows the following reference points, namely, 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 UDM / HSS146 and AMF132, not shown), N9 (between two UPFs, not shown), N10 (between UDM / HSS146 and SMF136, N11 (between AMF132 and SMF136, not shown), N12 (between AUSF144 and AMF132, not shown), N13 (between AUSF144 and UDM / HSS146, not shown), N14 (between two AMFs, not shown), N15 (between PCF148 and AMF132 in a non-roaming scenario, or between PCF148 and the destination 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.

[0033] Figure 1C shows a 5G system architecture 140C and a service-based representation. In addition to the network entities shown in Figure 1B, the 5G 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 the interactions between network functions can be represented by corresponding point-to-point reference points Ni or as service-based interfaces.

[0034] In some embodiments, as shown in Figure 1C, service-based representations can be used to represent network functions in the control plane that allow other permitted network functions to access these services. In this regard, the 5G system architecture 140C may include the following service-based interfaces: Namf158H (service-based interface represented by AMF132), Nsmf158I (service-based interface represented by SMF136), Nnef158B (service-based interface represented by NEF154), Npcf158D (service-based interface represented by PCF148), Nudm158E (service-based interface represented by UDM / HSS146), Naf158F (service-based interface represented by AF150), Nnrf158C (service-based interface represented by NRF156), Nnssf158A (service-based interface represented by NSSF142), and Nausf158G (service-based interface represented by AUSF144). Other service-based interfaces not shown in Figure 1C (e.g., Nudr, N5g-eir, and Nudsf) can also be used.

[0035] Figure 2 shows network 200 in various embodiments. Network 200 may operate in a manner consistent with the 3GPP technical specifications for LTE or 5G / NR systems. However, 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.

[0036] Network 200 may include UE202, which may include any mobile or non-mobile computing device designed to communicate with RAN204 via a wireless connection. UE202 may include, but is not limited to, smartphones, tablet computers, wearable computing devices, desktop computers, laptop computers, automotive infotainment systems, automotive entertainment devices, instrument clusters, head-up display devices, automotive diagnostic devices, dashboard mobile devices, mobile data terminals, electronic engine management systems, electronic / engine control units, electronic / engine control modules, embedded systems, sensors, microcontrollers, control modules, engine management systems, network appliances, machine-type communication devices, M2M or D2D devices, IoT devices, etc.

[0037] 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, PSFCH, etc.

[0038] In some embodiments, UE202 may further communicate with AP206 via a wireless connection. AP206 may manage the WLAN connection, which may function to offload some / all network traffic from RAN204. The connection between UE202 and AP206 may be consistent with any IEEE 802.11 protocol, and AP206 may be a Wireless Fidelity (Wi-Fi®) router. In some embodiments, UE202, RAN204, and AP206 may utilize cellular WLAN aggregation (e.g., LWA / LWIP). Cellular WLAN aggregation may involve UE202 configured by RAN204 to utilize both cellular wireless resources and WLAN resources.

[0039] 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, Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), MAC, and L1 protocols. In this way, AN208 may enable data / voice connectivity between core network (CN)220 and UE202. In some embodiments, AN208 may be implemented as one or more software entities running on a discrete device or as part of a virtual network, which may be called CRAN or virtual baseband unit pool, for example, on a server computer. AN208 may be referred to as BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, TRP, etc. AN208 may also be a macrocell base station or low-power base station for providing femtocells, picocells, or other similar cells that have a smaller coverage area, smaller user capacity, or higher bandwidth compared to macrocells.

[0040] In embodiments where RAN204 includes multiple ANs, the multiple ANs 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). In some embodiments, the X2 / Xn interface, which may be separated into a control / user plane interface, may enable the ANs to communicate information related to handover, data / context transfer, mobility, load management, interference control, etc.

[0041] 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 simultaneously connect 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 corresponding to Pcells or Scells, respectively. 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 AN may be any combination of eNBs, gNBs, ng-eNBs, etc.

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

[0043] In a V2X scenario, UE202 or AN208 may be a roadside unit (RSU) or function as an RSU, which may represent any traffic infrastructure entity used for V2X communication. The RSU may be implemented in or by a suitable AN or static (or relatively static) 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 to a roadside radio frequency circuit that provides connectivity support to passing vehicle UEs. The RSU may also include an internal data storage circuit that stores intersection map geometry, traffic statistics, and media, and an application / software that detects and controls 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. Furthermore, or alternatively, the RSU may provide other cellular / WLAN communication services. The RSU components may be packaged in a weather-resistant enclosure suitable for outdoor installation and may include a network interface controller for providing wired connectivity (e.g., Ethernet®) to a traffic signal controller or backhaul network.

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

[0045] 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 be connected to a 5G-enabled UE using a 5G NR interface. The gNB216 may be connected to the 5G core via an NG interface, which may include an N2 interface or an N3 interface. The ng-eNB218 may also be connected to the 5G core via an NG interface, or it may be connected to the UE via an LTE air interface. The gNB216 and ng-eNB218 may be connected via an Xn interface.

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

[0047] NG-RAN214 may provide the 5G NR air interface with the following features: variable SCS, CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL, polar codes, repeating codes, simplex codes and Reed-Muller codes for data control and LDPC. The 5G NR air interface may depend on CSI-RS and PDSCH / PDCCH DMRS, similar to the LTE air interface. The 5G NR air interface may not use CRS, but 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 physical broadcast channel (SSB, SS / PBCH block) area, which is part of the downlink resource grid including PSS / SSS / PBCH.

[0048] In some embodiments, a 5G NR air interface may utilize a bandwidth part (BWP) for various purposes. For example, a BWP can be used for dynamic adaptation of the SCS. For instance, UE202 can be composed of multiple BWPs, each having a different SCS. When a change in the BWP is indicated to UE202, the SCS of the transmission is also changed accordingly. Another use case for BWPs relates to power saving. In particular, multiple BWPs with different amounts of frequency resources (e.g., PRBs) can be configured for UE202 to support data transmission under different traffic load scenarios. BWPs with fewer PRBs can be used for data transmission with low traffic, enabling power saving in UE202 and, in some cases, in gNB216. BWPs with more PRBs can be used for scenarios with higher traffic loads.

[0049] RAN204 is communicatively coupled to CN220, which includes network elements that provide various functions to support data and telecommunications services to customers / subscribers (e.g., users of UE202). 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, switches, etc. Logical instantiations of CN220 may be called network slices, and some logical instantiations of CN220 may be called network subslices.

[0050] In some embodiments, CN220 may be connected to an LTE radio network as part of an Enhanced Packet System (EPS) 222, which may also be called an EPC (or Evolutionary Packet Core). The EPC222 may include MME224, SGW226, SGSN228, HSS230, PGW232, and PCRF234 coupled to each other on an interface (or "reference point"), as shown in the figure. The functions of the elements of the EPC222 can be briefly described below.

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

[0052] SGW226 may terminate the S1 interface toward the RAN and route data packets between the RAN and EPC222. SGW226 may also be a local mobility anchor point for RAN node handovers and may provide an anchor for 3GPP inter-node mobility. Several other roles may include lawful interception, billing, and any policy enforcement.

[0053] SGSN228 may track the location of UE202 and perform security functions and access control. Furthermore, SGSN228 may perform EPC node-to-node signaling for mobility between different RAT networks, PDN and S-GW selection as specified by MME224, MME selection for handover, etc. An S3 reference point between MME224 and SGSN228 may enable the exchange of user and bearer information about mobility between 3GPP access networks in idle / active states.

[0054] The HSS230 may include a database for network users, including subscription-related information, to support the processing of communication sessions by 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 to authenticate / authorize user access to an LTE CN (e.g., CN220).

[0055] PGW232 may terminate an 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 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). Furthermore, the SGi reference point between PGW232 and the data network 236 may be an external public, private PDN, or an internal packet data network, for example, to provide IMS services. PGW232 may be coupled to PCRF234 via a Gx reference point.

[0056] PCRF234 is the policy and billing control element of CN220. PCRF234 may be communicably coupled to the app / content server 238 to determine appropriate quality of service and billing parameters for the service flow. PCRF234 may provide the associated rules to the PCEF (via the Gx reference point) with appropriate TFT and QCI.

[0057] In some embodiments, CN220 may be 5GC240. 5GC240 may include AUSF242, AMF244, SMF246, UPF248, NSSF250, NEF252, NRF254, PCF256, UDM258, and AF260 coupled to each other on an interface (or "reference point"), as shown in the figure. The functions of the elements of 5GC240 can be briefly described below.

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

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

[0060] SMF246 may also be responsible for SM (e.g., session establishment between UPF248 and AN208, tunnel management), allocation and management of UE IP addresses (including permission for arbitrary selection), selection and control of UP functions, configuration of traffic steering in UPF248 for routing traffic to appropriate destinations, termination of interfaces toward policy control functions, policy enforcement, billing and some control of quality of service, lawful interception (for SM events and interface to LI systems), termination of the SM portion of NAS messages, downlink data notification, initiation of AN-specific SM information transmitted to AN208 via AMF244 on N2, and determination of the session's SSC mode. The SM may also indicate management of PDU sessions, and a PDU session or "session" may present a PDU connectivity service that provides or enables the exchange of PDUs between UE202 and data network 236.

[0061] UPF248 may function as an anchor point for mobility within and between RATs, an external PDU session point for interconnection to data network 236, and a branching 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 user plane quality of service processing (e.g., packet filtering, gating, UL / DL rate enforcement), perform uplink traffic verification (e.g., mapping flows from SDF to QoS), mark transport-level packets on uplinks and downlinks, and trigger downlink packet buffering and downlink data notification. UPF248 may include an uplink classifier to support routing traffic flows to the data network.

[0062] The NSSF250 may select a set of network slice instances to service the UE202. The NSSF250 may also determine the allowed NSSAIs and, if necessary, the mapping to the joined S-NSSAIs. The NSSF250 may also determine a set of AMFs, or a list of candidate AMFs, to be used to service the UE202, possibly by querying the NRF254, based on a preferred configuration. The selection of a set of network slice instances for the UE202 may be triggered by the AMF244 to which the UE202 is registered, by interacting with the NSSF250, which may result in a change of AMF. The NSSF250 may interact with the AMF244 via the N22 reference point and may communicate with another NSSF in the visited network via the N31 reference point (not shown). Furthermore, the NSSF250 may present an Nnssf service-based interface.

[0063] 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 throttle 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. Furthermore, NEF252 may present an Nnef service-based interface.

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

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

[0066] UDM258 may process join-related information to support the handling of communication sessions by network entities and may store join data for UE202. For example, join 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 join data and policy data for UDM258 and PCF256, and / or structured data for publication and application data for NEF252 (including application discovery for multiple UEs and a PFD for application request information). The UDR may present a Nudr service-based interface that allows UDM258, PCF256 and NEF252 to access specific sets of stored data and to read notifications of changes to relevant data in the UDR, update (e.g., add, modify), delete, and join. The UDM may include a UDM-FE responsible for certificate processing, location management, join management, etc. Several different frontends may serve the same user in different transactions. The UDM-FE accesses the subscription information stored in the UDR and performs authentication certificate processing, user identification information processing, access permission, registration / mobility management, and subscription management. In addition to communicating with other NFs on reference points as shown in the diagram, the UDM258 may present a Nudm service-based interface.

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

[0068] In some embodiments, the 5GC240 may enable edge computing by selecting an operator / third-party service that is geographically closer to where the UE202 is attached to the network. This may reduce latency and network load. To provide an implementation of edge computing, the 5GC240 may select a UPF248 that is close 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 join data, UE location, and information provided by the AF260. Thus, the AF260 may influence the UPF(re)selection and traffic routing. Based on operator deployment, if the AF260 is considered a trusted entity, the network operator may allow the AF260 to interact directly with the relevant NF. Furthermore, the AF260 may present a NAF service-based interface.

[0069] The data network 236 may represent various network operator services, internet access, or third-party services, which may be provided by one or more servers, including, for example, an application / content server 238.

[0070] In some embodiments, the network 200 is configured for NR positioning using a location management function (LMF) 245, which can be configured as an LMF node or as a function within a different type of node. In some embodiments, the LMF 245 is configured to calculate the position of the UE by receiving measurements and support information from the NG-RAN 214 and UE 202 via the AMF 244 (e.g., using an NL interface). In some embodiments, the NR positioning protocol A (NRPPa) can be used to transport positioning information between the NG-RAN 214 and the LMF 245 over a next-generation control plane interface (NG-C). In some embodiments, the LMF 245 configures the UE 202 via the AMF 244 using the LTE positioning protocol (LPP) (e.g., an LPP-based communication link). In some embodiments, NG-RAN214 configures UE202 using, for example, radio resource control (RRC) protocol signaling on the LTE-Uu and NR-Uu interfaces. In some embodiments, UE202 uses the LTE-Uu interface to communicate with ng-eNB218 and the NR-Uu interface to communicate with gNB216. In some embodiments, ng-eNB216 and gNB216 use the NG-C interface to communicate with AMF244.

[0071] In some embodiments, the following reference signals, namely the downlink NR positioning reference signal (NR PRS) and the uplink sounding reference signal (SRS), can be used to achieve positioning measurements in an NR communication network. The downlink positioning reference signal (PRS) can be used as a reference signal to support downlink-based positioning techniques. In some embodiments, the entire NR bandwidth can be covered by transmitting the PRS over multiple symbols that can be aggregated to store power.

[0072] Figure 3 schematically shows the wireless network 300 in various embodiments. The wireless network 300 may include a UE302 that communicates wirelessly with AN304. The UE302 and AN304 may be similar to, and substantially interchangeable with, other components of similar names described elsewhere here.

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

[0074] 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 to 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.

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

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

[0077] The modem platform 310 may 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 318 may include a digital-to-analog converter, a mixer, an intermediate frequency (IF) component, etc.; the receiving circuit 320 may include an analog-to-digital converter, a mixer, an IF component, etc.; the RF circuit 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 configuration of the components of the transmitting circuit 318, receiving circuit 320, RF circuit 322, RFFE 324, and one or more antenna panels 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 consist of multiple parallel transmit / receive chains and may be located on the same or different chips / modules, etc.

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

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

[0080] UE transmission may be established by and through a protocol processing circuit 314, a digital baseband circuit 316, a transmitting circuit 318, an RF circuit 322, an RFFE 324, and one or more antenna panels 326. In some embodiments, the transmitting component of UE 302 may apply a spatial filter to the data to be transmitted in order to form a transmit beam radiated by the antenna elements of one or more antenna panels 326.

[0081] Similar to UE302, AN304 may include a host platform 328 coupled to a modem platform 330. The host platform 328 may include an application processing circuit 332 coupled to a 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, for example, RNC functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling.

[0082] Figure 4 is a block diagram showing a component 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, according to several exemplary embodiments. Specifically, Figure 4 shows a schematic representation 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 executed to provide an execution environment for one or more network slices / subslice to utilize the hardware resources 400.

[0083] One or more processors 410 may include, for example, processors 412 and 414. One or more processors 410 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex 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 a preferred combination of any of these.

[0084] The memory / storage device 420 may include main memory, disk storage, or a preferred combination thereof. The memory / storage device 420 may include, but is not limited to, any type of volatile, non-volatile, 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, solid-state storage, etc.

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

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

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

[0088] The term “application” may refer to a complete, deployable package or an environment for achieving specific functionality in an operating environment. Terms such as “AI / ML application” may also 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 constitute or implement one or more of the embodiments of the disclosure.

[0089] The term “machine learning” or “ML” refers to the use of computer systems that implement algorithms and / or statistical models to perform a particular task without using explicit instructions, but instead relying on patterns and inference. An ML algorithm builds or estimates a mathematical model (called an “ML model,” etc.) based on sample data (called “training data,” “model training information,” etc.) to make predictions or decisions without being explicitly programmed to perform such tasks. Generally, an ML algorithm is a computer program that learns from experience with respect to several tasks and several performance metrics, 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 term “ML algorithm” refers to a different concept from the term “ML model,” but these terms may be used interchangeably in this disclosure as discussed herein.

[0090] Terms such as “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 ML algorithms in operation to address a specific use case. ML models include supervised learning (e.g., linear regression, k-nearest neighbor (KNN), decision tree algorithm, 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-armed bandit learning, deep RL, etc.), neural networks, etc. Depending on the implementation, a particular ML model may have many submodels as components, and an ML model may train all submodels together. Separately trained ML models may also be joined together in an ML pipeline during inference. An “ML pipeline” is a set of functionality, features, or feature entities specific to an ML-assisted solution, and an ML pipeline may include one or more data sources among data pipelines, model training pipelines, model evaluation pipelines, and 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 (including both model execution and, where applicable, online learning). The ML host informs the actor about 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 an ML model to determine inferences. While the data used to train the ML model and the data used to determine inferences may overlap, "training data" and "inference data" represent distinct concepts.

[0091] The 5G NR specification requires support for a diverse set of vertical and use cases, including enhanced mobile broadband (eMBB) and newly introduced ultra-reliable low latency communication (URLLC) services. Support for low-power wide-area (LPWA) networks targeting extreme coverage and extremely long battery life, and use cases for extremely low-complexity / cost devices, are expected to be served by MTC (Category M UE) and NB-IoT (Category NB UE) technologies.

[0092] The disclosed technology can be used to establish a framework for enabling reduced-function NR devices suitable for a range of use cases, including industrial sensors, video surveillance, and wearable use cases, which have requirements for low UE complexity and, in some cases, low UE power consumption. The disclosed technology includes extensions to improve support for the mentioned use cases, as well as extensions to extend RedCap to a new range of use cases such as smart grids.

[0093] To further expand the market for RedCap use cases with relatively low cost, low energy consumption, and low data rate requirements, such as industrial wireless sensor network use cases, one enhancement is to reduce the baseband bandwidth of the Rel-18 enhanced RedCap UE (eRedCap UE, enhanced RedCap UE). Specifically, the radio frequency (RF) bandwidth remains 20 MHz, which is the same as the existing RedCap UE. The eRedCap UE can still process control channels / signals transmitted in all PRBs within a 20 MHz BWP, which is the same as the existing RedCap UE. For broadcast PDSCHs scheduled by DCI with CRCs masked by SI-RNTI, P-RNTI, and RA-RNTI, the PDSCH may be scheduled in all PRBs within a 20 MHz BWP. Relaxed timing is employed to process the broadcasted PDSCH. With respect to unicast PDSCHs or PUSCHs, the allocated PRBs can still spread within a 20 MHz BWP. However, the number of PRBs assigned to eRedCap UE is a maximum of N. max It may not exceed the value N. max This can be determined, for example, by assuming 5MHz, and for 15kHz SCS, N max =25, and for 30kHz SCS, N max = 12

[0094] NR Rel-15 defines a four-step procedure. Figure 5 shows the four-step random access channel (RACH) procedure in several embodiments. In the first step, the UE transmits a physical random access channel (PRACH) on the uplink (e.g., Msg1) by randomly selecting one preamble signature, which allows the gNB to estimate the delay between the gNB and the UE for subsequent uplink (UL) timing adjustment. Then, in the second step, the gNB feeds back a random access response (RAR) (e.g., in Msg2), which carries timing advanced (TA) command information and uplink grant for uplink transmission in the third step. The UE is expected to receive the RAR within a time window, the start and end of which are configured by the gNB via a system information block (SIB). Next, according to the UL grant in the RAR, the UE can transmit a UL message (e.g., Msg3) containing the UE identity. Finally, after the successful receipt of msg3, the gNB can transmit a DL message (e.g., Msg4) that serves as a conflict resolution for the UE.

[0095] However, the reduced BB bandwidth for the eRedCap UE may affect RACH operation. The disclosed techniques include various designs for handling the RACH procedure for the eRedCap UE. For example, the eRedCap UE may identify failed race resolution as early as possible to reduce the latency of RACH operation.

[0096] For Rel-18 eRedCap UEs, due to the reduced bandwidth (BW), the number of allocated physical resource blocks (PRBs) for unicast PDSCH or PUSCH cannot exceed the maximum number N max For example, for 15 kHz SCS, N max = 25, and for 30 kHz SCS, N max = 12. In other words, if the eRedCap UE detects a UL grant that schedules more PRBs than N max for PUSCH, or detects a DL allocation that schedules more PRBs than N max for PDSCH, the UE can conclude that the PUSCH or PDSCH cannot be processed. In the RACH procedure, Msg3 and Msg4 can be considered as unicast PUSCH and PDSCH respectively. If the number of PRBs allocated for Msg3 or Msg4 as indicated by the UL grant or DL allocation exceeds N max , the UE can conclude that its RACH attempt has failed.

[0097] Early RACH failure identification by Msg3 In the following scenarios, the eRedCap UE may detect that the number of scheduled PRBs for Msg3 exceeds N max . In the first scenario, assume that early identification of the eRedCap UE from existing RedCap UEs and / or non-RedCap UEs is not configured.

[0098] (a) After receiving a PRACH preamble from the eRedCap UE, the gNB may mistakenly assume a non-eRedCap UE, e.g., an existing RedCap UE or non-RedCap UE. As a result, the gNB may schedule more PRBs than N max for Msg3.

[0099] (b) eRedCap UEs and non-eRedCap UEs may coincidentally use the same PRACH preamble. gNB may detect only the preamble of non-eRedCap UEs. In this case, gNB assumes an existing RedCap UE or non-RedCap UE and N for msg3 max The correct behavior is to be able to schedule more PRBs than a certain number of them.

[0100] In the second scenario, when early identification of eRedCap UEs from existing RedCap UEs and / or non-RedCap UEs is configured, gNB incorrectly identifies N max It is possible that more PRBs than necessary are used to schedule Msg3 for the eRedCap UE. This is an error. In both scenarios, the UE may conclude that the current RACH attempt has failed.

[0101] In some embodiments, the disclosure method also applies to a fallback RAR for a two-step RACH. In this case, the RAR includes a UL grant, i.e., Msg3, that schedules the PUSCH.

[0102] In some embodiments, for eRedCap UE, the number of PRBs for Msg3 is N max If the value exceeds this, the UE may assume that the current RACH attempt has failed. As a result, the UE can restart the RACH procedure without waiting for the processing of Msg3 and / or Msg4 of the current RACH attempt.

[0103] In some embodiments, the number of PRBs allocated for Msg3 in the UL grant in RAR is N maxIf the threshold is exceeded, the UE can restart the RACH procedure. Figure 6 shows the RACH procedure with early failure identification after RAR reception in several embodiments. More specifically, Figure 6 shows that the random access preamble identity (RAPID) used by the UE is in the RAR PDSCH and the associated Msg3 is N max When scheduling is performed using more than one PRB, the eRedCap UE can recognize the failure of the current RACH procedure after decrypting the RAR PDSCH.

[0104] For example, 3GPP Technical Specification (TS) 38.213 (e.g., Section 8.2) can be updated to include new conditions for restarting the RACH procedure. In response to the PRACH transmission, the UE attempts to detect DCI format 1_0 with the corresponding RA-RNTI-scrambled CRC during a window controlled by the upper layer (e.g., TS38.321). If the UE does not detect a DCI format 1_0 with a corresponding RA-RNTI-scrambled CRC within the window, or if the UE detects a DCI format 1_0 with a corresponding RA-RNTI-scrambled CRC within the window, and the LSB of the SFN field in the DCI format 1_0 (if included and applicable) is not the same as the corresponding LSB of the SFN from which the UE transmitted the PRACH, or if the UE does not correctly receive the transport block in the corresponding PDSCH within the window, or if the upper layer does not identify the RAPID associated with the PRACH transmission from the UE, or if the number of PRBs scheduled for msg3 transmission is N when the UE is an eRedCap UE max If it is greater than this, the upper layer can indicate to the physical layer to transmit PRACH (for example, to restart the RACH procedure).

[0105] In some embodiments, the number of allocated PRBs in the UL grant that schedule the HARQ retransmission of Msg3 is N max If it exceeds this limit, the UE can restart the RACH procedure.

[0106] For example, Section 8.2 in TS38.213 can be updated to include new conditions for restarting the RACH procedure. In response to a PRACH transmission, the UE attempts to detect a DCI format 1_0 with the corresponding RA-RNTI-scrambled CRC during a window controlled by the upper layer (e.g., TS38.321). If the UE does not detect a DCI format 1_0 with the corresponding RA-RNTI-scrambled CRC within the window, or if the UE detects a DCI format 1_0 with the corresponding RA-RNTI-scrambled CRC within the window and the LSB of the SFN field in the DCI format 1_0 (if included and applicable) is not the same as the corresponding LSB of the SFN from which the UE transmitted the PRACH, or if the UE does not correctly receive the transport block in the corresponding PDSCH within the window, or if the upper layer does not identify the RAPID associated with the PRACH transmission from the UE, or if the UE is an eRedCap UE and after the initial transmission of Msg3, the UE max If a DCI format is detected that schedules a retransmission of Msg3 with more than 1 PRB, the upper layer can indicate to the physical layer to transmit the PRACH.

[0107] In some embodiments, the number of allocated PRBs in the UL grant that schedule the initial transmission of Msg3 and / or the retransmission of Msg3 RAR is N max If it exceeds this limit, the UE can restart the RACH procedure.

[0108] In the above embodiment, a timeline can be defined between the DCI format for scheduling the transmission / retransmission of Msg3 and the time for restarting the RACH procedure. For example, Section 8.2 in TS38.213 can be updated to include a new timeline for restarting the RACH procedure. The timeline for restarting the RACH procedure can be defined by referencing the last symbol of DCI format 1_0 for scheduling the initial transmission of Msg3 or DCI format 0_0 for scheduling the retransmission of Msg3.

[0109] In some embodiments, if requested by a higher layer, the UE has the N after the last symbol of DCI format 1_0 having the CRC scrambled by the corresponding RA-RNTI. T,1 We can prepare to transmit PRACH within +X milliseconds, where N T,1 This is the duration of N1 symbols corresponding to the PDSCH processing time for UE processing capacity 1. The subcarrier spacing (SCS) numerology μ can correspond to the smallest SCS configuration among the SCS configurations for the PDCCH and corresponding PRACH carrying DCI format 1_0. Alternatively, the SCS numerology μ can correspond to the SCS configuration for the PDCCH carrying DCI format 1_0. Alternatively, the SCS numerology μ can correspond to the SCS configuration for the PDSCH. The SCS numerology μ can correspond to the smallest SCS configuration among the SCS configurations for the PDCCH carrying DCI format 1_0, the corresponding PDSCH when a further PDSCH DM-RS is configured, and the corresponding PRACH. The SCS numerology μ can correspond to the minimum SCS configuration among the SCS configurations for a PDCCH carrying DCI format 1_0, a corresponding PDSCH when no further PDSCH DM-RS is configured, and a corresponding PRACH. For μ=0, UE is N 1,0We can assume that = 14 [6, TS38.214]. X is a further time that can be predefined or depend on UE capabilities (e.g., X = 0.75; X may be 0 or less than 0).

[0110] In some embodiments, if requested by a higher layer, the UE schedules a retransmission of Msg3 after the last symbol of DCI format 0_0. T,2 We can prepare to transmit PRACH within +X milliseconds, where N T,2 is the duration of N2 symbols corresponding to the PUSCH preparation time for UE processing capability 1 (e.g., TS38.214). SCS Numerology μ can correspond to the minimum SCS configuration among the SCS configurations for PDCCH and the corresponding PRACH carrying DCI format 0_0. Alternatively, SCS Numerology μ can correspond to the SCS configuration for PDCCH carrying DCI format 0_0. Alternatively, SCS Numerology μ can correspond to the SCS configuration for PUSCH. X is a further time that can be predefined or depend on the UE capability, for example, X = 0.75, and X may also be 0 or less than 0.

[0111] Msg4 Early Conflict Resolution In the following embodiment, the eRedCap UE has N scheduled PRBs for msg4. max It may detect if it exceeds N. In the first scenario, eRedCap UEs and non-eRedCap UEs may use the same PRACH preamble. gNB may detect the preamble of non-eRedCap UEs. Msg3 may also detect up to N max It may be scheduled using individual PRBs. Finally, after the gNB receives Msg3 from a non-eRedCap UE, the gNB will... max It is possible to schedule Msg4 for non-eRedCap UEs using more than one PRB.

[0112] In some embodiments relating to the eRedCap UE, after transmitting its Msg3, the eRedCap UE may begin detecting a PDCCH that schedules Msg4. As a result, the eRedCap UE may detect a PDCCH that schedules Msg4 for a non-eRedCap UE using the same PRACH preamble. In another embodiment, the gNB mistakenly detects N max It is possible that more PRBs than necessary are used to schedule Msg4 for the eRedCap UE. This is an error. In both cases, the UE may assume that the current RACH attempt has failed.

[0113] In some embodiments, for eRedCap UE, the number of PRBs for Msg4 in DL allocation is N max If it exceeds this value, the UE may assume that the current RACH attempt has failed. As a result, the UE can restart the RACH procedure without waiting for the Msg4 transmission / retransmission processing of the current RACH attempt, i.e., it can stop the ContentionResolutionTimer and discard TEMPORARY_C-RNTI.

[0114] In some embodiments, the number of allocated PRBs in the DL allocation that schedules the initial transmission of Msg4 is N max If it exceeds N, the UE can restart the RACH procedure. Figure 7 shows the RACH procedure with early failure identification after decoding the DCI that schedules the initial transmission of msg4 in several embodiments. More specifically, Figure 7 shows the RACH procedure with early failure identification after decoding the DCI that schedules the initial transmission of msg4 in several embodiments. max This describes a procedure that allows the eRedCap UE to recognize a failure in the current RACH procedure after decoding the DCI that schedules the initial transmission of Msg4 when scheduling with more than one PRB.

[0115] In some embodiments, the number of PRBs allocated in the DL allocation that schedules Msg4 retransmissions is N. max If it exceeds this limit, the UE can restart the RACH procedure.

[0116] In some embodiments, the number of allocated PRBs in the DL allocation that schedules the initial transmission and / or retransmission of Msg4 is N max If it exceeds this limit, the UE can restart the RACH procedure.

[0117] In some embodiments, the above options may be incorporated into TS38.213. For example, if UE is an eRedCap UE, then UE is N max If a DCI format is detected that schedules the HARQ retransmission (i.e., initial transmission or HARQ retransmission) of Msg3 or Msg4 using more than 1 PRB, the upper layer can indicate to the physical layer to transmit PRACH. In another embodiment, the UE is an eRedCap UE, and the UE is N max If a DCI format is detected that uses more than one PRB to schedule Msg3 (i.e., initial transmission or HARQ retransmission) or Msg4 (i.e., initial transmission or HARQ retransmission), the upper layer can indicate to the physical layer to transmit PRACH (e.g., restart the RACH procedure).

[0118] The above options may be incorporated into TS38.321. For example, the behavior regarding conflict resolution in TS38.321 can be updated as listed in Table 1 below. [Table 1]

[0119] In some embodiments, the conflict resolution behavior specified in TS38.321 can be updated as listed in Table 2 below. [Table 2]

[0120] In other examples, the conflict resolution behavior specified in TS38.321 can be updated as listed in Table 3 below. [Table 3]

[0121] The above options allow you to define a timeline between the DCI format that schedules Msg4 and the time to restart the RACH procedure. The timeline for restarting the RACH procedure can be defined by referencing the last symbol of DCI format 1_0 that schedules Msg4.

[0122] For example, if requested by a higher layer, the UE will schedule Msg4 after the last symbol of DCI format 1_0. T,1 We can prepare to transmit PRACH within +X milliseconds, where N T,1 This is the duration of N1 symbols corresponding to the PDSCH processing time for UE processing capacity 1. SCS numerology μ can correspond to the minimum SCS configuration among SCS configurations for a PDCCH carrying DCI format 1_0 and the corresponding PRACH. Alternatively, SCS numerology μ can correspond to an SCS configuration for a PDCCH carrying DCI format 1_0. Alternatively, SCS numerology μ can correspond to an SCS configuration for a PDSCH. SCS numerology μ can correspond to the minimum SCS configuration among SCS configurations for a PDCCH carrying DCI format 1_0, the corresponding PDSCH when further PDSCH DM-RS are configured, and the corresponding PRACH. SCS numerology μ can correspond to the minimum SCS configuration among SCS configurations for a PDCCH carrying DCI format 1_0, the corresponding PDSCH when further PDSCH DM-RS are not configured, and the corresponding PRACH. For μ=0, UE is N 1,0It may be assumed that = 14 (e.g., TS38.214). For PRACH transmission using 1.25 kHz or 5 kHz SCS, the UE may determine N1 by assuming an SRS configuration μ=0. X is a further time that can be predefined or configured based on the UE's capabilities, for example, X=0.75. Alternatively, X may be 0 or less than 0.

[0123] In some embodiments, if requested by a higher layer, the UE may prepare to transmit PRACH N+X symbols after the last symbol of DCI format 1_0 scheduling Msg4. For example, N can be the same as the processing time for HARQ-ACK transmission of SPS PDSCH release, e.g., N=10 for μ=0, N=12 for μ=1, N=22 for μ=2, N=25 for μ=3, N=100 for μ=5, and N=200 for μ=6. Here, μ may correspond to the minimum SCS configuration between the SCS configuration of the PDCCH and the corresponding PRACH. Alternatively, μ may correspond to the SCS configuration of the PDCCH. X is a further time that can be predefined or depend on the UE's capabilities, e.g., X=0.

[0124] Early Conflict Resolution for MsgBs In the following scenario related to the 2-step RACH procedure, the eRedCap UE determines that the number of scheduled PRBs in the MsgB is N. max It may be detected that it exceeds N. In the first scenario, the eRedCap UE and the non-eRedCap UE may coincidentally use the same PRACH preamble and / or msgA PUSCH. The gNB may detect only the preamble of the non-eRedCap UE. After the gNB receives the MsgA from the non-eRedCap UE, the gNB may detect N max It is possible to schedule MsgBs for non-eRedCap UEs using more than one PRB.

[0125] In some aspects related to the eRedCap UE, after transmitting its MsgA, the eRedCap UE begins detecting the PDCCH that schedules MsgB. As a result, eRedCap may detect the PDCCH that schedules MsgB for a non-eRedCap UE using the same PRACH preamble. In a second scenario, the gNB mistakenly detects the N max It is possible that more PRBs than one are used to schedule MsgBs for the eRedCap UE. This is an error. In both cases, the UE may assume that the current RACH attempt has failed (the PRACH procedure can be resumed).

[0126] In some embodiments, for eRedCap UE, the number of PRBs for MsgBs in DL allocation is N max If the value exceeds this limit, the UE may assume that the current RACH attempt has failed. As a result, the UE can restart the RACH procedure without waiting for the MsgB of the current RACH attempt to be processed.

[0127] The disclosed techniques may be incorporated into TS38.213. For example, if a UE does not detect a DCI format 1_0 with a scrambled CRC by the corresponding MsgB-RNTI within a window, or if a UE detects a DCI format 1_0 with a scrambled CRC by the corresponding MsgB-RNTI within a window, and the LSB of the SFN field in DCI format 1_0 (if applicable) is not the same as the corresponding LSB of the SFN from which the UE transmitted the PRACH, or if a UE does not correctly receive the transport block in the corresponding PDSCH within a window, or if the upper layer does not identify the RAPID associated with the PRACH transmission from the UE, or if the number of PRBs scheduled for the MsgB is N when the UE is an eRedCap UE maxIf the value is greater than this, the upper layer can instruct the physical layer to transmit only PRACH according to a Type 1 random access procedure, or to transmit both PRACH and PUSCH according to a Type 2 random access procedure (e.g., TS38.321).

[0128] The above techniques may be incorporated into TS38.321. For example, the behavior regarding conflict resolution in TS38.321 can be updated as listed in Table 4 below. [Table 4]

[0129] In other examples, the conflict resolution behavior specified in TS38.321 can be updated as listed in Table 5 below. [Table 5]

[0130] In the above embodiment, a timeline can be defined between the DCI format for scheduling MsgB and the time for restarting the RACH procedure. The timeline for restarting the RACH procedure can be defined by referencing the last symbol of DCI format 1_0 for scheduling MsgB.

[0131] In some embodiments, if requested by a higher layer, the UE schedules the MsgB after the last symbol of DCI format 1_0. T,1 Prepare to transmit PRACH within +X milliseconds, where N T,1 This is the duration of N1 symbols corresponding to the PDSCH processing time for UE processing capacity 1 when a further PDSCH DM-RS is configured. Alternatively, N T,1This is the duration of N1 symbols corresponding to the PDSCH processing time for UE processing capacity 1 when no further PDSCH DM-RS are configured. SCS numerology μ can correspond to the smallest SCS configuration among SCS configurations for PDCCH and corresponding PRACH carrying DCI format 1_0. Alternatively, SCS numerology μ can correspond to an SCS configuration for PDCCH carrying DCI format 1_0. Alternatively, SCS numerology μ can correspond to an SCS configuration for PDSCH. SCS numerology μ can correspond to the smallest SCS configuration among SCS configurations for PDCCH, corresponding PDSCH, and corresponding PRACH carrying DCI format 1_0. For μ=0, UE is N 1,0 We may assume that = 14 (e.g., TS38.214). X is a further time that can be predefined or constructed based on UE capabilities, for example, X = 0.75. X may also be 0 or less than 0.

[0132] In some embodiments, if requested by a higher layer, the UE shall prepare to transmit PRACH after N+X symbols from the last symbol of DCI format 1_0 scheduling MsgB. For example, N may be the same as the processing time for HARQ-ACK transmission of SPS PDSCH release, e.g., N=10 for μ=0, N=12 for μ=1, N=22 for μ=2, N=25 for μ=3, N=100 for μ=5, and N=200 for μ=6. Here, μ may correspond to the minimum SCS configuration between the SCS configuration of the PDCCH and the corresponding PRACH. Alternatively, μ may correspond to the SCS configuration of the PDCCH. X is a further time that may be predefined or depend on the capabilities of the UE, e.g., X=0.

[0133] Early RACH failure identification using Msg2 Regarding Rel-18 eRedCap UE, due to reduced BW, RAR PDSCH is N maxWhen scheduling is done using more than one PRB, the decoding timeline of the RAR PDSCH is relaxed. For example, the minimum time between the last symbol of a PDSCH reception carrying a RAR message with a RAR UL grant and the first symbol of the corresponding PUSCH transmission scheduled by the RAR UL grant is N. T,1 +N T,2 This is equal to +0.5+X milliseconds, where N T,1 This is the duration of N1 symbols corresponding to the PDSCH processing time for UE processing capacity 1 when a further PDSCH DM-RS is configured, and N T,2 n is the duration of N2 symbols corresponding to the PUSCH preparation time for UE processing capacity 1 (e.g., TS38.214). In relation to determining the minimum time, the UE assumes that N1 and N2 correspond to the smaller of the SCS configurations for PDSCH and PUSCH. For μ=0, the UE is N 1,0 Assume that = 14 (e.g., TS38.214). However, if the number of scheduled PRBs in RAR PDSCH is N max When this value is exceeded, the eRedCap UE may detect that the scheduling delay between RAR PDSCH and Msg3 scheduled by the UL grant in RAR is shorter than the relaxed timeline. In such cases, the UE may conclude that the current RACH attempt has failed.

[0134] In some embodiments, the disclosure method also applies to a fallback RAR for a two-step RACH. In this case, the RAR includes a UL grant, i.e., Msg3, that schedules the PUSCH.

[0135] In some embodiments, for the eRedCap UE, the number of scheduled PRBs of the RAR PDSCH is N max If the time exceeds this limit, and the scheduling delay between RAR PDSCH and Msg3 scheduled by the UL grant in RAR is shorter than the mitigated timeline, the UE can resume the RACH procedure.

[0136] In some embodiments, Section 8.2 in TS38.213 may be updated to include new conditions for restarting the RACH procedure. In response to a PRACH transmission, the UE attempts to find a DCI format 1_0 with the corresponding RA-RNTI-scrambled CRC during a window controlled by the upper layer (e.g., TS38.321). If the UE does not find a DCI format 1_0 with the corresponding RA-RNTI-scrambled CRC within the window, or if the UE finds a DCI format 1_0 with the corresponding RA-RNTI-scrambled CRC within the window and the LSB of the SFN field in DCI format 1_0 (if included and applicable) is not the same as the corresponding LSB of the SFN from which the UE transmitted the PRACH, or if the UE does not correctly receive the transport block in the corresponding PDSCH within the window, or if the upper layer does not identify the RAPID associated with the PRACH transmission from the UE, or if the UE is an eRedCap UE, the number of scheduled PRBs in the RAR PDSCH is N max If the scheduling delay for Msg3 transmission exceeds the minimum time between the last symbol of the PDSCH receiving carrying the RAR message with the RAR UL grant and the first symbol of the Msg3 scheduled by the RAR UL grant, the upper layer may indicate to the physical layer to transmit PRACH.

[0137] The disclosed technology includes a system and method for random access for UEs with reduced bandwidth. In some embodiments, for an eRedCap UE, the number of PRBs for Msg3 is N max If it exceeds N, the UE restarts the RACH procedure, and here, max This is the maximum number of PRBs for Msg3.

[0138] In some embodiments, the number of PRBs allocated for Msg3 in the UL grant in RAR is N max It exceeds.

[0139] In some embodiments, the number of allocated PRBs in the UL grant that schedule the HARQ retransmission of Msg3 is N max It exceeds.

[0140] In some embodiments, for eRedCap UE, the number of PRBs for Msg4 is N max If it exceeds N, the UE restarts the RACH procedure, and here, max This is the maximum number of PRBs for Msg4.

[0141] In some embodiments, the number of PRBs allocated in the DL allocation for scheduling the initial transmission of Msg4 is N max It exceeds.

[0142] In some embodiments, the number of PRBs allocated in the DL allocation for scheduling Msg4 retransmissions is N max It exceeds.

[0143] In some embodiments, for eRedCap UE, the number of PRBs for MsgB is N max If it exceeds N, the UE restarts the RACH procedure, and here, max This is the maximum number of PRBs for MsgB.

[0144] In some embodiments, N max This is equal to 25 for a 15kHz SCS and equal to 12 for a 30kHz SCS.

[0145] In some embodiments, for eRedCap UE, the number of scheduled PRBs for RAR PDSCH is N maxIf the time exceeds this limit, and the scheduling delay between RAR PDSCH and Msg3 scheduled by the UL grant in RAR is shorter than the mitigated timeline, the UE restarts the RACH procedure.

[0146] Figure 8 shows block diagrams of communication devices such as evolved Node-B (eNB), new generation Node-B (gNB) (or another RAN node such as a base station), network-controlled repeater (NCR), access point (AP), wireless station (STA), mobile station (MS), or user equipment (UE) for performing one or more of the technologies disclosed herein in several embodiments. In alternative embodiments, the communication device 800 may operate as a standalone device or may be connected to other communication devices (e.g., network connection).

[0147] A circuit (e.g., a processing circuit) is a collection of circuits implemented on a tangible entity of device 800, including hardware (e.g., simple circuits, gates, logic, etc.). The membership of a circuit may be flexible over time. A circuit includes components that can perform specified operations individually or in combination when in operation. For example, the hardware of a circuit may be designed immutably to perform a particular operation (e.g., hardwired). For example, the hardware of a circuit 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 immutable aggregate particles, etc.) to encode instructions for a particular operation.

[0148] 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 allow embedded hardware (e.g., an execution unit or loading mechanism) to create members of a circuit within the hardware via variable connections to perform a specific part of an operation during operation. Thus, in one example, a machine-readable media element is part of a circuit or is communicatively coupled to other components of a circuit when the device is operating. For example, any one of the physical components may be used in more than one member of more than one circuit. For example, during operation, an execution unit may be used in a first circuit of a first circuit at one point and reused at a different point by a second circuit of the first circuit or a third circuit of the second circuit. Further examples of these components relating to device 800 follow below.

[0149] In some embodiments, device 800 may operate as a standalone device or may be connected to other devices (e.g., network connection). In a networked deployment, communication device 800 may operate as a server communication device, a client communication device, or both in a server-client network environment. For example, communication device 800 may operate as a peer communication device in a peer-to-peer (P2P) (or other distributed) network environment. Communication device 800 may be a UE, eNB, PC, tablet PC, STB, PDA, mobile phone, smartphone, web device, network router, switch or bridge, or any communication device capable of executing instructions (sequential or other instructions) that specify the actions to be performed by the communication device. Furthermore, although only a single communication device is shown, the term “communication device” shall also be interpreted to include any set of communication devices that individually or collectively execute a set (or set) of instructions to perform one or more of the methodologies discussed herein, such as cloud computing, software as a service (SaaS), or other computer cluster configurations.

[0150] The examples described herein may include, or operate on, logic or several components, modules, or mechanisms. A module is a tangible entity (e.g., hardware) capable of performing a specified operation and may be configured or arranged in a particular manner. In one example, a circuit may be arranged as a module in a specified manner (e.g., internally or relative 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 specified operation. In one example, the software may reside on a communication device-readable medium. In one example, the software, when executed by the underlying hardware of the module, causes the hardware to perform a specified operation.

[0151] Therefore, the term “module” is understood to encompass tangible entities that are physically constructed, specifically configured (e.g., wired), or temporarily (e.g., transiently) configured (e.g., programmed) to operate in a specified manner or to perform some or all of the operations described herein. Considering an example where a module is temporarily configured, each module does not need to be instantiated at any single point in time. For example, if a module includes a general-purpose hardware processor configured using 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 at one point in time and different modules at different points in time.

[0152] The communication device (e.g., UE) 800 may include a hardware processor 802 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), main memory 804, static memory 806, and storage devices 816 (e.g., a hard drive, tape drive, flash storage, or other block or storage devices), some or all of which may communicate with each other via an interlink 808 (e.g., a bus).

[0153] The communication device 800 may further include a display device 810, an input device 812 (e.g., a keyboard), and a user interface (UI) navigation device 814 (e.g., a mouse). In one example, the display device 810, the input device 812, and the UI navigation device 814 may be touchscreen displays. The communication device 800 may further include a signal generating device 818 (e.g., a speaker), a network interface device 820, and one or more sensors 821 such as a global positioning system (GPS) sensor, a compass, an accelerometer, or other sensors. The communication device 800 may also include an output controller 828, such as a serial (e.g., universal serial bus (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.).

[0154] The storage device 816 may include a device-readable medium 822 that stores one or more sets of data structures or instructions 824 (e.g., software) that embody or are utilized by any one or more of the technologies or functions described herein. In some embodiments, the registers of the hardware processor 802, the main memory 804, the static memory 806 and / or the storage device 816 may be, or may include (all or at least partially) a device-readable medium 822 that stores one or more sets of data structures or instructions 824 that embody or are utilized by any one or more of the technologies or functions described herein. In one example, one or a combination of the hardware processor 802, the main memory 804, the static memory 806, and the storage device 816 may constitute the device-readable medium 822.

[0155] The term “device-readable medium” as used herein is interchangeable with “computer-readable medium” or “machine-readable medium.” Although device-readable medium 822 is shown as a single medium, the term “communication device-readable medium” may include a single or multiple mediums configured to store instructions 824 (e.g., a centralized or distributed database and / or associated caches and servers). The term “communication device-readable medium” may include any medium capable of storing, encoding, or carrying instructions (e.g., instructions 824) for execution by communication device 800, causing communication device 800 to execute one or more of the technologies of this disclosure, or any medium capable of 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 and magnetic media. Specific examples of communication device-readable media may include non-volatile memory such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices, magnetic disks such as internal hard disks and removable disks, magneto-optical disks, random access memory (RAM), 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 propagation signals.

[0156] Furthermore, instruction 824 may be transmitted or received over the communication network 826 using a transmission medium via the network interface device 820, utilizing one of several transport protocols. In one example, the network interface device 820 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 826. In one example, the network interface device 820 may include multiple antennas for wireless communication using at least one of the following technologies: single-input multiple-output (SIMO), MIMO, or multiple-input single-output (MISO).

[0157] The term “transmission medium” is to be interpreted as including any intangible medium capable of storing, encoding, or carrying instructions for execution by the communication device 800, including digital or analog communication signals or other intangible mediums for facilitating the communication of such software. In this context, the transmission medium in the context of this disclosure is a device-readable medium.

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

[0159] The implementation forms of the described subject may include one or more features individually or in combination, as shown below as an example.

[0160] In some embodiments, the eRedCap UE determines whether the number of PRBs for RAR PDSCH exceeds the maximum number of PRBs associated with the eRedCap UE, and whether the UL grant in RAR exhibits a scheduling delay insufficient for Msg3 transmission, where the minimum scheduling delay for Msg3 transmission is N T,1 +N T,2 Given by +0.5+X milliseconds, N T,1 and N T,2 This is defined in section 8.3 of 3GPP TS38.213, where X = 1.0 milliseconds for a 15 kHz SCS and X = 0.5 milliseconds for a 30 kHz SCS. Depending on such a determination, the RACH procedure may be considered to have failed.

[0161] Example 1 is a device for an eRedCap user device (UE) configured for operation in a fifth-generation new radio (5G NR) network, the device comprising a processing circuit and a memory coupled to the processing circuit and configured to store a random access response (RAR) received in a second message (Msg2), and for the Random Access Channel (RACH) procedure in a 5G NR network, eRedCap To configure the UE, the processing circuit encodes a random access preamble for transmission to the base station in the first message (Msg1) of the RACH procedure, decodes the RAR received from the base station in Msg2 of the RACH procedure, which includes an uplink grant for the third message (Msg3) of the RACH procedure, encodes uplink data for physical uplink shared channel (PUSCH) transmission to the base station using the uplink grant in Msg3, decodes the downlink control information (DCI) format received on the physical downlink control channel (PDCCH) in response to the PUSCH transmission for scheduling a physical downlink shared channel (PDSCH) transmission for UE conflict resolution in the fourth message (Msg4), detects that the PDSCH transmission scheduled by the DCI format contains allocated PRBs that exceed the maximum number of physical resource blocks (PRBs) associated with the eRedCap UE, and determines that UE conflict resolution is unsuccessful based on the detection that the allocated PRBs exceed the maximum number of PRBs.

[0162] In Example 2, the subject of Example 1 includes the subject of restarting the RACH procedure based on the processing circuit detecting that the allocated PRB exceeds the maximum number of PRBs.

[0163] In Example 3, the themes of Examples 1 and 2 include the themes in which the processing circuit performs a first detection that the PDSCH bandwidth of the RAR contains a number of PRBs exceeding the maximum number of PRBs associated with the eRedCap UE, and a second detection that the uplink grant for Msg3 in the RAR is shorter than the relaxed timeline for the transmission of Msg3.

[0164] In Example 4, the subject of Example 3 includes the subject in which the processing circuit restarts the RACH procedure based on the first and second detections.

[0165] In Example 5, the themes of Examples 1-4 include the theme that the processing circuit detects an uplink grant in the received PDCCH that schedules a Hybrid Automatic Retransmission Request (HARQ) retransmission of the Msg3 PUSCH transmission, and detects a failure of the RACH procedure based on the number of allocated PRBs in the uplink grant that schedules the HARQ retransmission exceeding the maximum number of PRBs associated with the eRedCap UE.

[0166] In Example 6, the subject of Example 5 includes the subject of the processing circuit determining the timing for restarting the RACH procedure based on the last symbol of the downlink control information (DCI) format 0_0 that schedules the retransmission of Msg3.

[0167] In Example 7, the themes of Examples 1-6 include the theme that the processing circuit decodes a second DCI that schedules a Hybrid Automatic Retransmission Request (HARQ) retransmission of Msg4 and detects a failure of the RACH procedure based on the number of PRBs allocated for the HARQ retransmission of Msg4 exceeding the maximum number of PRBs associated with the eRedCap UE.

[0168] In Example 8, the subject of Example 7 includes the subject of the processing circuit determining the timing for restarting the RACH procedure based on the last symbol of the Downlink Control Information (DCI) format 1_0 that schedules the initial transmission of Msg4 or the DCI format 1_0 that schedules the retransmission of Msg4.

[0169] In Example 9, the themes of Examples 1-8 include themes in which the maximum number of PRBs associated with the eRedCap UE is 25 for a 15kHz subcarrier spacing (SCS), or 12 for a 30kHz SCS.

[0170] In Example 10, the subject of Examples 1-9 includes a transceiver circuit coupled to a processing circuit and two or more antennas coupled to the transceiver circuit.

[0171] Example 11 is a computer-readable storage medium storing instructions for execution by one or more processors of a base station, the instructions configuring the base station for a Random Access Channel (RACH) procedure in a 5G NR or later network, causing the base station to perform operations including decoding a random access preamble received from an eRedCap user device (UE) in the first message (Msg1) of the RACH procedure, encoding a random access response for transmission to an eRedCap UE in the second message (Msg2) of the RACH procedure, which includes an uplink grant for the third message (Msg3) of the RACH procedure, and decoding a second random access preamble received from an eRedCap UE in the second Msg1 of the RACH procedure, which is restarted based on the number of physical resource blocks (PRBs) allocated for Msg3 indicated in the uplink grant exceeding the maximum number of PRBs associated with the eRedCap UE.

[0172] In Example 12, the themes of Example 11 include themes where the maximum number of PRBs associated with the eRedCap UE is 25 for a 15 kHz subcarrier spacing (SCS), or 12 for a 30 kHz SCS.

[0173] Example 13 is a computer-readable storage medium storing instructions for execution by one or more processors of an extended-shrunk (eRedCap) user device (UE), wherein the instructions constitute an eRedCap UE for random access channel (RACH) procedures in a 5G NR or later network, and eRedCap The UE is instructed to perform the following actions: encode a random access preamble for transmission to the base station in the first message (Msg1) of the RACH procedure; decode a random access response (RAR) received from the base station in the second message (Msg2) of the RACH procedure, which includes an uplink grant for the third message (Msg3) of the RACH procedure; encode uplink data for physical uplink shared channel (PUSCH) transmission to the base station using the uplink grant in Msg3; decode a downlink control information (DCI) format received on the physical downlink control channel (PDCCH) in response to the PUSCH transmission, which schedules a physical downlink shared channel (PDSCH) transmission for UE conflict resolution in the fourth message (Msg4); detect that the PDSCH transmission scheduled by the DCI format contains allocated PRBs that exceed the maximum number of physical resource blocks (PRBs) associated with the eRedCap UE; and determine that UE conflict resolution is unsuccessful based on the detection that the allocated PRBs exceed the maximum number of PRBs.

[0174] In Example 14, the subject of Example 13 involves restarting the RACH procedure based on the detection that the number of allocated PRBs exceeds the maximum number of PRBs.

[0175] In Example 15, the subject matter of Examples 13-14 includes performing a first detection that the PDSCH bandwidth of the RAR contains a number of PRBs exceeding the maximum number of PRBs associated with the eRedCap UE, and a second detection that the uplink grant for Msg3 in the RAR is shorter than the relaxed timeline for the transmission of Msg3.

[0176] In Example 16, the subject of Example 15 includes restarting the RACH procedure based on the first and second detections.

[0177] In Example 17, the subject matter of Examples 13–16 includes detecting an uplink grant in a received PDCCH that schedules a Hybrid Automatic Retransmission Request (HARQ) retransmission of Msg3's PUSCH transmission, and detecting a failure of the RACH procedure based on the number of allocated PRBs in the uplink grant scheduling the HARQ retransmission exceeding the maximum number of PRBs associated with the eRedCap UE.

[0178] In Example 18, the subject of Example 17 involves determining the timing to restart the RACH procedure based on the last symbol of the Downlink Control Information (DCI) format 0_0 that schedules the retransmission of Msg3.

[0179] In Example 19, the subject matter of Examples 13–18 includes decoding a second DCI that schedules a Hybrid Automatic Retransmission Request (HARQ) retransmission of Msg4 and detecting a failure of the RACH procedure based on the number of PRBs allocated for the HARQ retransmission of Msg4 exceeding the maximum number of PRBs associated with the eRedCap UE.

[0180] In Example 20, the subject of Example 19 involves determining the timing to restart the RACH procedure based on the last symbol of the Downlink Control Information (DCI) format 1_0 that schedules the initial transmission of Msg4 or the DCI format 1_0 that schedules the retransmission of Msg4.

[0181] Example 21 is at least one machine-readable medium that, when executed by the processing circuit, contains instructions causing the processing circuit to perform an action to carry out any of Examples 1 to 20.

[0182] Example 22 is an apparatus that includes means for carrying out any of Examples 1 to 20.

[0183] Example 23 is a system for implementing any of Examples 1 through 20.

[0184] Example 24 is a method for implementing any of Examples 1 through 20.

[0185] While embodiments have been described with respect to specific exemplary aspects, it is clear that various modifications and changes may be made to these embodiments without departing from the broader scope of this disclosure. Therefore, this specification and the 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 to which the appended claims are granted, is defined solely by the appended claims.

Claims

1. An apparatus for an eRedCap user equipment (UE) configured for operation in a 5th generation new wireless (5G NR) network, Processing circuit and A memory coupled to the processing circuit and configured to store the random access response (RAR) received in the second message (Msg2), Includes, To configure the eRedCap UE for the Random Access Channel (RACH) procedure in the 5G NR network, the processing circuit is: In the first message (Msg1) of the RACH procedure, a random access preamble is encoded for transmission to the base station. In Msg2 of the RACH procedure, which includes an uplink grant for the third message (Msg3) of the RACH procedure, the RAR received from the base station is decoded. In Msg3, uplink data is encoded for physical uplink shared channel (PUSCH) transmission to the base station using the uplink grant. In response to the aforementioned PUSCH transmission, the downlink control information (DCI) format is decoded in the fourth message (Msg4) received on the physical downlink control channel (PDCCH) to schedule a physical downlink shared channel (PDSCH) transmission for UE conflict resolution. The system detects that the PDSCH transmission scheduled in the DCI format includes allocated PRBs that exceed the maximum number of physical resource blocks (PRBs) associated with the eRedCap UE. A device that determines that the UE conflict resolution is unsuccessful based on the detection that the number of allocated PRBs exceeds the maximum number of PRBs.

2. The aforementioned processing circuit is The apparatus according to claim 1, which restarts the RACH procedure based on the detection that the number of allocated PRBs exceeds the maximum number of PRBs.

3. The aforementioned processing circuit is A first detection is performed in which the PDSCH bandwidth of the RAR contains a number of PRBs that exceeds the maximum number of PRBs associated with the eRedCap UE. The apparatus according to claim 1, which performs a second detection that the uplink grant for the Msg3 in the RAR is shorter than the relaxed timeline for the transmission of the Msg3.

4. The aforementioned processing circuit is The apparatus according to claim 3, wherein the RACH procedure is restarted based on the first detection and the second detection.

5. The aforementioned processing circuit is An uplink grant is detected in the received PDCCH that schedules a Hybrid Automatic Retransmission Request (HARQ) retransmission of the PUSCH transmission of Msg3, The apparatus according to claim 1, which detects a failure of the RACH procedure based on the number of PRBs allocated in the uplink grant that schedules the HARQ retransmission exceeding the maximum number of PRBs associated with the eRedCap UE.

6. The aforementioned processing circuit is The apparatus according to claim 5, which determines the timing for restarting the RACH procedure based on the last symbol of the downlink control information (DCI) format 0_0 that schedules the retransmission of the Msg3.

7. The aforementioned processing circuit is The second DCI that schedules the Hybrid Automatic Retransmission Request (HARQ) retransmission of the aforementioned Msg4 is decoded, The apparatus according to claim 1, which detects a failure of the RACH procedure based on the number of PRBs allocated for HARQ retransmission of Msg4 exceeding the maximum number of PRBs associated with the eRedCap UE.

8. The aforementioned processing circuit is The apparatus according to claim 7, which determines the timing for restarting the RACH procedure based on the last symbol of the downlink control information (DCI) format 1_0 that schedules the initial transmission of the Msg4 or the DCI format 1_0 that schedules the retransmission of the Msg4.

9. The apparatus according to any one of claims 1 to 8, wherein the maximum number of PRBs associated with the eRedCap UE is 25 for a subcarrier spacing (SCS) of 15 kHz, or 12 for a 30 kHz SCS.

10. A transceiver circuit coupled to the processing circuit, Two or more antennas coupled to the transceiver circuit and The apparatus according to any one of claims 1 to 8, further comprising:

11. A computer program comprising instructions for execution by one or more processors of a base station, The aforementioned instruction configures the base station for the Random Access Channel (RACH) procedure in a 5th generation new radio (5G NR) or later network, and instructs the base station to In the first message (Msg1) of the RACH procedure, the random access preamble received from the eRedCap user device (UE) is decoded. In the second message (Msg2) of the RACH procedure, which includes an uplink grant for the third message (Msg3) of the RACH procedure, a random access response is encoded for transmission to the eRedCap UE. In the second Msg1 of the RACH procedure, which is restarted based on the fact that the number of physical resource blocks (PRBs) allocated for Msg3 as indicated in the uplink grant exceeds the maximum number of PRBs associated with the eRedCap UE, the second random access preamble received from the eRedCap UE is decoded. A computer program that causes an action to be performed, including the actions mentioned above.

12. The computer program according to claim 11, wherein the maximum number of PRBs associated with the eRedCap UE is 25 for a subcarrier spacing (SCS) of 15 kHz, or 12 for a 30 kHz SCS.

13. A computer program comprising instructions for execution by one or more processors of an extended-reduction (eRedCap) user device (UE), The aforementioned instruction constitutes the eRedCap UE for Random Access Channel (RACH) procedures in 5G NR and later networks. In the aforementioned eRedCap UE, In the first message (Msg1) of the RACH procedure, a random access preamble is encoded for transmission to the base station. In the second message (Msg2) of the RACH procedure, which includes an uplink grant for the third message (Msg3) of the RACH procedure, the random access response (RAR) received from the base station is decoded. In Msg3, uplink data is encoded for physical uplink shared channel (PUSCH) transmission to the base station using the uplink grant. In response to the aforementioned PUSCH transmission, the downlink control information (DCI) format is decoded in the fourth message (Msg4) received on the physical downlink control channel (PDCCH) to schedule a physical downlink shared channel (PDSCH) transmission for UE conflict resolution. The system detects that the PDSCH transmission scheduled in the DCI format includes allocated PRBs that exceed the maximum number of physical resource blocks (PRBs) associated with the eRedCap UE. Based on the detection that the number of allocated PRBs exceeds the maximum number of PRBs, it is determined that the UE conflict resolution is unsuccessful. A computer program that causes an action to be performed, including the actions mentioned above.

14. The aforementioned operation is, The computer program according to claim 13, which includes restarting the RACH procedure based on the detection that the number of allocated PRBs exceeds the maximum number of PRBs.

15. The aforementioned operation is, A first detection is performed in which the PDSCH bandwidth of the RAR contains a number of PRBs that exceeds the maximum number of PRBs associated with the eRedCap UE. The second detection in the RAR is that the uplink grant for Msg3 is shorter than the relaxed timeline for the transmission of Msg3. The computer program according to claim 13, including the computer program described in claim 13.

16. The aforementioned operation is, The computer program according to claim 15, comprising restarting the RACH procedure based on the first detection and the second detection.

17. The aforementioned operation is, An uplink grant is detected in the received PDCCH that schedules a Hybrid Automatic Retransmission Request (HARQ) retransmission of the PUSCH transmission of Msg3, The failure of the RACH procedure is detected based on the number of PRBs allocated in the uplink grant that schedules the HARQ retransmission exceeding the maximum number of PRBs associated with the eRedCap UE. The computer program according to claim 13, including the computer program described in claim 13.

18. The aforementioned operation is, The computer program according to claim 17, comprising determining the timing to restart the RACH procedure based on the last symbol of the downlink control information (DCI) format 0_0 that schedules the retransmission of the Msg3.

19. The aforementioned operation is, The second DCI that schedules the Hybrid Automatic Retransmission Request (HARQ) retransmission of the aforementioned Msg4 is decoded, The failure of the RACH procedure is detected based on the fact that the number of PRBs allocated for HARQ retransmission in Msg4 exceeds the maximum number of PRBs associated with the eRedCap UE. The computer program according to claim 13, including the computer program described in claim 13.

20. The aforementioned operation is, The computer program according to claim 19, comprising determining the timing to restart the RACH procedure based on the last symbol of the downlink control information (DCI) format 1_0 that schedules the initial transmission of the Msg4 or the DCI format 1_0 that schedules the retransmission of the Msg4.

21. A computer-readable storage medium storing the computer program described in claim 11 or 12.

22. A computer-readable storage medium storing a computer program according to any one of claims 13 to 20.

Images