Physical random access channel (PRACH) format configuration

Abstract

The present disclosure relates to physical random access channel (PRACH) format configuration. A user equipment (UE) can include processing circuitry configured to decode system information block (SIB) information including a PRACH configuration index. The PRACH configuration index indicates at least a first preamble format and a second preamble format. A PRACH preamble is encoded for transmission to a base station within a PRACH resource indicated by the PRACH configuration index. The PRACH preamble is associated with the first preamble format or the second preamble format. A random access channel response (RAR) message from the base station is decoded. The RAR message includes an uplink grant for scheduling a physical uplink shared channel (PUSCH) transmission. Data is encoded for transmission on the PUSCH based on the uplink grant. The PRACH resource includes a plurality of PRACH occasions, wherein the PRACH preamble is transmitted within a PRACH occasion of the plurality of PRACH occasions having a starting symbol indicated by the PRACH configuration index.

Description

[0001] This application is a divisional application of Chinese invention patent application filed on September 10, 2018, with national application number 201880070011.3 and invention title "Physical Random Access Channel (PRACH) Format Configuration".

[0002] Priority requirements

[0003] This patent application claims the priority of the following patent applications:

[0004] U.S. Provisional Patent Application Serial No. 62 / 556,930, filed on September 11, 2017, entitled “Mechanism on configuring random access channel format”; and

[0005] U.S. Provisional Patent Application Serial No. 62 / 567,027, filed on October 2, 2017, entitled “Mechanism on Confirming Random Access Channel Formation”.

[0006] Each of the patent applications described above is incorporated herein by reference in its entirety. Technical Field

[0007] The scope involves wireless communications. Some aspects relate to wireless networks, including 3GPP (3rd Generation Partnership Project) networks, 3GPP LTE (Long Term Evolution) networks, 3GPP LTE-A (LTE Advanced) networks, and fifth-generation (5G) networks, which include 5G New Radio (NR) (or 5G-NR) networks and 5G-LTE networks. Other aspects relate to systems and methods for configuring Physical Random Access Channel (PRACH) formats. Additional aspects relate to Radio Network Temporary Identifier (RNTI) configuration. Background Technology

[0008] Mobile communications have evolved significantly from early voice systems to today's highly complex integrated communication platforms. The use of 3GPP LTE systems has increased with the growing number of different types of devices communicating with various network devices. The continued penetration of mobile devices (User Equipment) in modern society continues to drive the demand for a variety of connected devices in many different environments. The upcoming fifth-generation (5G) wireless system is expected to deliver higher speeds, connectivity, and availability. The next generation of 5G networks (or NR networks) is expected to improve throughput, coverage, and robustness, while reducing latency and operating and capital expenditures. 5G-NR networks will continue to develop based on 3GPP LTE-Advanced and with the potential addition of new radio access technologies (RATs) to enrich people's lives with seamless wireless connectivity solutions, providing fast, rich content and services. Since current cellular network frequencies are saturated, higher frequencies such as millimeter wave (mmWave) frequencies can benefit from their high bandwidth.

[0009] Potential LTE operations in unlicensed spectrum include (but are not limited to) LTE operations in unlicensed spectrum via dual connectivity (DC) or DC-based LAA and standalone LTE systems, whereby LTE-based technologies operate only in unlicensed spectrum without an "anchor" in licensed spectrum; this approach is known as MulteFire. MulteFire combines the performance advantages of LTE technology with the simplicity of Wi-Fi-like deployment.

[0010] In future releases and 5G systems, LTE systems are expected to have further operational enhancements in both licensed and unlicensed spectrum. Such enhancements may include techniques for resolving the configuration of PRACH and RNTI (e.g., Random Access RNTI or RA-RNTI). Attached Figure Description

[0011] In accompanying drawings that are not necessarily drawn to scale, similar numbers may describe similar parts in different views. Similar numbers with different letter suffixes may represent different instances of similar parts. The accompanying drawings are illustrated in general terms of the various aspects described in this document, rather than as limiting.

[0012] Figure 1A The architecture of the network is shown based on some aspects.

[0013] Figure 1B It is a simplified diagram of the overall next-generation (NG) system architecture based on some aspects.

[0014] Figure 1C An exemplary MulteFire Neutral Host Network (NUN) 5G architecture is shown based on some aspects.

[0015] Figure 1D This illustrates the functional division between the Next Generation Radio Access Network (NG-RAN) and the 5G Core Network (5GC) based on some aspects.

[0016] Figure 1E and Figure 1F The non-roaming 5G system architecture is shown based on some aspects.

[0017] Figure 1G An exemplary cellular Internet of Things (CIoT) network architecture is shown based on some aspects.

[0018] Figure 1H An exemplary Service Capability Open Function (SCEF) is shown based on some aspects.

[0019] Figure 1I An exemplary roaming architecture for SCEF is shown, based on several aspects.

[0020] Figure 1J An exemplary Evolution Universal Terrestrial Radio Access (E-UTRA) New Radio Dual Connectivity (EN-DC) architecture is shown, based on several aspects.

[0021] Figure 2 Exemplary components of device 200 according to some aspects are shown.

[0022] Figure 3 An exemplary interface of a baseband circuit according to some aspects is shown.

[0023] Figure 4 It is a diagram of the control plane protocol stack based on some aspects.

[0024] Figure 5 It is a diagram of the user plane protocol stack based on some aspects.

[0025] Figure 6 This is a block diagram illustrating components according to some exemplary aspects, which are capable of reading instructions from a machine-readable medium or a computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more methods discussed herein.

[0026] Figure 7 It is a diagram of the initial access procedure based on several aspects, including the retransmission of the PRACH preamble.

[0027] Figure 8 A first exemplary PRACH configuration is shown based on some aspects.

[0028] Figure 9 A second exemplary PRACH configuration is shown based on some aspects.

[0029] Figure 10A A third exemplary PRACH configuration is shown based on some aspects.

[0030] Figure 10B A third exemplary PRACH configuration is shown based on some aspects.

[0031] Figure 11 An exemplary communication exchange between the UE and the next-generation node B (gNB) for configuring the PRACH format is shown, according to some aspects.

[0032] Figure 12 The flowcharts are shown in general, illustrating exemplary functions based on some aspects that can be implemented in conjunction with a PRACH configuration in a wireless architecture.

[0033] Figure 13 A block diagram of a communication device is shown, which may include, for example, an evolved Node B (eNB), a next-generation Node B (gNB), an access point (AP), a radio station (STA), a mobile station (MS), or a user equipment (UE). Detailed Implementation

[0034] The following description and accompanying drawings fully illustrate the aspects, enabling those skilled in the art to practice them. Other aspects may be combined with structural variations, logical variations, electrical variations, process variations, and other variations. Parts and features of some aspects may be included in, or replace, parts and features of other aspects. The aspects set forth in the claims cover all available equivalents of these claims.

[0035] Figure 1A The architecture of the network is illustrated according to several aspects. Network 140A is shown as including user equipment (UE) 101 and UE 102. UE 101 and UE 102 are shown as smartphones (e.g., handheld touchscreen mobile computing devices that can connect 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, cordless phone, drone, or any other computing device including wired and / or wireless communication interfaces.

[0036] Any radio link described herein (e.g., used in Network 140A or any other exemplified network) may operate according to any one or more of the following exemplary radio communication technologies and / or standards, including but not limited to: Global System for Mobile Communications (GSM) radio communication technology, General Packet Radio Service (GPRS) radio communication technology, Enhanced Data Rate GSM Evolution (EDGE) radio communication technology, and / or 3rd Generation Partnership Project (3GPP) radio communication technologies, such as Universal Mobile Telecommunications System (UMTS), Free Mobile Multimedia Access (FOMA), 3GPP Long Term Evolution (LTE), and 3GPP Long Term Evolution Upgrade (LTE-WLE). Advanced, Code Division Multiple Access 2000 (CDMA2000), Cellular Digital Packet Data (CDPD), Mobitex, 3G, Circuit Switched Data (CSD), High-Speed ​​Circuit Switched Data (HSCSD), Universal Mobile Telecommunications System (3G) (UMTS(3G)), Wideband Code Division Multiple Access (W-CDMA(UMTS)), High-Speed ​​Packet Access (HSPA), High-Speed ​​Downlink Packet Access (HSDPA), High-Speed ​​Uplink Packet Access (HSUPA), Enhanced High-Speed ​​Packet Access (HSPA+), Universal Mobile Telecommunications System - Time Division Duplex (UMTS-TDD), Time Division - Code Division Multiple Access (TD-CDMA), Time Division - Synchronous Code Division Multiple Access (TD-CDMA), 3GPP Rel. 8 (Pre-4G), 3GPP Rel. 9 (3GPP Rel. 9), 3GPP Rel. 10 (3GPP Rel. 10), 3GPP 3GPP Rel.11 (3rd Generation Partnership Project Version 11), 3GPP Rel.12 (3rd Generation Partnership Project Version 12), 3GPP Rel.13 (3rd Generation Partnership Project Version 13), 3GPP Rel.14 (3rd Generation Partnership Project Version 14), 3GPP Rel.15 (3rd Generation Partnership Project Version 15), 3GPP Rel.16 (3rd Generation Partnership Project Version 16), 3GPP Rel.17 (3rd Generation Partnership Project Version 17), 3GPP Rel.18 (3rd Generation Partnership Project Version 18), 3GPP 5G or 5G-NR, 3GPP LTE Extra, LTE-Advanced Pro, LTE Licensed Assisted Access (LAA), MulteFire, UMTS Terrestrial Radio Access (UTRA), Evolved UMTS Terrestrial Radio Access (E-UTRA), LTE Advanced (4G) (LTE Advanced (4G)), cdmaOne (2G), CDMA2000 (3G) (CDMA2000 (3G)), Evolved Data Optimized or Evolved Data Dedicated (EV-DO), Advanced Mobile Telephone Systems (1G) (AMPS (1G)), Total Access Communications System / Extended Total Access Communications System (TACS / ETACS), Digital AMPS (2G) (D-AMPS (2G)), Push-to-Talk (PTT), Mobile Telephone Systems (MTS), Improved Mobile Telephone Systems (IMTS), Advanced Mobile Telephone Systems (AMTS), OLT (Offentlig Landmobile) Telefoni (Norwegian for public land mobile phone), MTD (Swedish abbreviation for Mobile Telephone System D, or Mobile Telephone System D), Autotel / PALM (Public Automatic Land Mobile), ARP (Finnish for Autoradiopuhelin, "Car Radio Telephone"), NMT (Nordic Mobile Telephone), High Capacity Version NTT (Japan Telecom Telephone) (Hicap), Cellular Digital Packet Data (CDPD), Mobitex, DataTAC, Integrated Digital Enhanced Network (iDEN), Personal Digital Cellular Telephone (PDC), Circuit Switched Data (CSD), Personal Handheld Telephone System (PHS), Broadband Integrated Digital Enhanced Network (WiDEN), iBurst, Unlicensed Mobile Access (UMA) (also known as 3GPP Universal Access Network or GAN standard), Zigbee, Bluetooth(r), Wireless Gigabit Alliance (WiGig) standard, Millimeter Wave General Standard (Wireless systems operating in the 10-300 GHz and above frequency bands, such as WiGig, IEEE 802.11ad, IEEE Technologies operating in the 300GHz and THz frequency bands (based on 3GPP / LTE, or IEEE 802.11p and others), vehicle-to-vehicle (V2V) communication technologies, vehicle-to-the-world (V2X) communication technologies, vehicle-to-infrastructure (V2I) communication technologies, infrastructure-to-vehicle (12V) communication technologies, 3GPP cellular V2X, and DSRC (Dedicated Short Range Communication) communication systems (such as intelligent transportation systems and others).

[0037] LTE and LTE-Advanced are wireless communication standards for high-speed data transmission for user equipment (UEs) such as mobile phones. In LTE-Advanced and various wireless systems, carrier aggregation is a technique that allows multiple carrier signals operating at different frequencies to be used to carry communication for a single UE, thereby increasing the bandwidth available to a single device. In some aspects, carrier aggregation can be used when one or more component carriers are operating at unlicensed frequencies.

[0038] Interest began to grow in operating LTE systems in unlicensed spectrum. Therefore, a significant enhancement to LTE in 3GPP Release 13 was enabling operation in unlicensed spectrum via Licensed Assisted Access (LAA), which extends system bandwidth by leveraging the Flexible Carrier Aggregation (CA) framework introduced in LTE-Advanced systems. The Rel-13 LAA system focused on designing downlink operation in unlicensed spectrum via CA, while the Rel-14 Enhanced LAA (eLAA) system focused on designing uplink operation in unlicensed spectrum via CA.

[0039] The aspects described herein can be used in the context of any spectrum management scheme, including, for example, dedicated licensed spectrum, unlicensed spectrum, (licensed) shared spectrum (such as licensed shared access (LSA) at 2.3–2.4 GHz, 3.4–3.6 GHz, 3.6–3.8 GHz and other frequencies, and spectrum access systems (SAS) at 3.55–3.7 GHz and other frequencies). Exemplary applicable spectrum bands include IMT (International Mobile Telecommunications) spectrum (including 450-470MHz, 790-960MHz, 1710-2025MHz, 2110-2200MHz, 2300-2400MHz, 2500-2690MHz, 698-790MHz, 610-790MHz, 3400-3600MHz, etc.), IMT-advanced spectrum, IMT-2020 spectrum (expected to include, for example, the 3600-3800MHz, 3.5GHz band, 700MHz band, and bands in the 24.25-86GHz range), and spectrum covered by the Federal Communications Commission's "Spectrum Frontier" 5G plan (including 27.5-28.35GHz, 29.1-29.25GHz, 31-31.3GHz, 37-38.6GHz, and 38.6-40GHz). The ITS (Intelligent Transportation Systems) bands include the following: 42-42.5GHz, 57-64GHz, 71-76GHz, 81-86GHz, and 92-94GHz, etc.; 5.9GHz (typically 5.85-5.925GHz) and 63-64GHz bands; and bands currently allocated to WiGig (such as WiGig band 1 (57.24-59.40GHz), WiGig band 2 (59.40-61.56GHz), WiGig band 3 (61.56-63.72GHz), and WiGig band 4 (63.72-65.88GHz)); the 70.2GHz-71GHz band; any band between 65.88GHz and 71GHz; bands currently allocated to automotive radar applications, such as 76-81GHz; and future bands including 94-300GHz and above. Furthermore, this solution can be used on a secondary basis in frequency bands such as the TV white space band (typically below 790MHz), specifically the 400MHz and 700MHz bands. Beyond cellular applications, it can meet specific applications for vertical markets such as PMSE (Programming and Special Events), medical, healthcare, surgical, automotive, low latency, and drones.

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

[0041] In some aspects, either UE 101 or UE 102 may include an Internet of Things (IoT) UE or a Cellular IoT (CIoT) UE, which may include a network access layer designed for low-power IoT applications utilizing short-lived UE connectivity. In some aspects, either UE 101 or UE 102 may include a narrowband (NB) IoT UE (e.g., enhanced NB-IoT (eNB-IoT) UE and further enhanced (FeNB-IoT) UE). IoT UEs may utilize technologies such as machine-to-machine (M2M) or machine-type communication (MTC) to exchange data with MTC servers or devices via a Public Land Mobile Network (PLMN), Proximity-Based Service (ProSe) or Device-to-Device (D2D) communication, sensor networks, or IoT networks. M2M or MTC data exchange may be machine-initiated data exchange. The IoT network includes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) utilizing short-lived connectivity. IoT UEs may execute background applications (e.g., keeping track of activity messages, status updates, etc.) to facilitate connectivity within the IoT network.

[0042] In some respects, NB-IoT devices can be configured to operate within a single Physical Resource Block (PRB) and can be rescheduled to two different PRBs within the system bandwidth. In other respects, an eNB-IoT UE can be configured to acquire system information in one PRB and then reschedule to a different PRB to receive or transmit data.

[0043] In some respects, either UE 101 or UE 102 may include an enhanced MTC (eMTC) UE or a further enhanced MTC (FeMTC) UE.

[0044] UE 101 and UE 102 can be configured to connect (e.g., communicatively coupled) to a radio access network (RAN) 110. RAN 110 can be, for example, an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), a Next Generation RAN (NGRAN), or some other type of RAN. UE 101 and UE 102 utilize connections 103 and 104, respectively, where each connection includes a physical communication interface or layer (discussed in further detail below); in this example, connections 103 and 104 are shown as air interfaces for communication coupling and can be consistent with cellular communication protocols such as the Global System for Mobile Communications (GSM) protocol, Code Division Multiple Access (CDMA) network protocol, Push-to-Talk (PTT) protocol, Cellular PTT protocol (POC), Universal Mobile Telecommunications System (UMTS) protocol, 3GPP Long Term Evolution (LTE) protocol, 5G protocol, New Radio (NR) protocol, etc.

[0045] In some respects, Network 140A may include Core Network (CN) 120. This document references, for example... Figure 1B , Figure 1C , Figure 1D , Figure 1E , Figure 1F and Figure 1G Various aspects of NG RAN and NG core are discussed.

[0046] In one aspect, UE 101 and UE 102 may also exchange communication data directly via ProSe interface 105. ProSe interface 105 may alternatively be referred to as a sidelink interface including one or more logical channels, including but not limited to the Physical Sidelink Control Channel (PSCCH), Physical Sidelink Shared Channel (PSSCH), Physical Sidelink Discovery Channel (PSDCH), and Physical Sidelink Broadcast Channel (PSBCH).

[0047] The illustrated UE 102 is configured to access access point (AP) 106 via connection 107. Connection 107 may include a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, according to which AP 106 may include Wi-Fi. Router. In this example, AP 106 is shown connected to the Internet but not to the core network of the wireless system (described in further detail below).

[0048] RAN 110 may include one or more access nodes that enable connections 103 and 104. These access nodes (ANs) may be referred to as base stations (BS), node Bs, evolved Node Bs (eNBs), next-generation Node Bs (gNBs), RAN nodes, etc., and may include ground sites (e.g., terrestrial access points) or satellite sites covering a geographic area (e.g., a cell). In some aspects, communication nodes 111 and 112 may be transmit / receive points (TRPs). When communication nodes 111 and 112 are node Bs (e.g., eNBs or gNBs), one or more TRPs may operate within the communication cell of the node B. RAN 110 may include one or more RAN nodes (e.g., macro RAN node 111) for providing macro cells, and one or more RAN nodes (e.g., low-power (LP) RAN node 112) for providing femtocells or picocells (e.g., cells with smaller coverage areas, smaller user capacity, or higher bandwidth compared to macro cells).

[0049] Either RAN node 111 or RAN node 112 can terminate the air interface protocol and can be the first point of contact for UE 101 and UE 102. In some respects, either RAN node 111 or RAN node 112 can perform various logical functions of RAN 110, 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. In one example, either node 111 and / or node 112 can be a next-generation node B (gNB), an evolved Node B (eNB), or another type of RAN node.

[0050] Depending on some aspects, UE 101 and UE 102 may be configured to communicate with each other using Orthogonal Frequency Division Multiplexing (OFDM) communication signals, or to communicate with either RAN Node 111 or RAN Node 112 via a multi-carrier communication channel based on various communication technologies, such as, but not limited to, Orthogonal Frequency Division Multiple Access (OFDMA) communication technology (e.g., for downlink communication) or Single Carrier Frequency Division Multiple Access (SC-FDMA) communication technology (e.g., for uplink and ProSe for sidelink communication), but such aspects are not required. OFDM signals may include multiple orthogonal subcarriers.

[0051] In some respects, downlink resource grids can be used for downlink transmissions from either RAN Node 111 or RAN Node 112 to UE 101 and UE 102, while uplink transmissions can utilize similar techniques. The grid can be a time-frequency grid, referred to as a resource grid or time-frequency resource grid, which represents the physical resources in the downlink within each time slot. This time-frequency plane representation can be used in OFDM systems, making OFDM systems suitable for radio resource allocation. Each column and each row of the resource grid can correspond to an OFDM symbol and an OFDM subcarrier, respectively. The duration of the resource grid in the time domain can correspond to a time slot in a radio frame. The smallest time-frequency unit in the resource grid can be represented as a resource element. Each resource grid can include multiple resource blocks that describe the mapping from a specific physical channel to resource elements. Each resource block can include a set of resource elements; in the frequency domain, this can, in some respects, represent the minimum amount of resources currently available for allocation. Multiple different physical downlink channels can exist that are transmitted using such resource blocks.

[0052] The Physical Downlink Shared Channel (PDSCH) delivers user data and higher-layer signaling to UE 101 and UE 102. The Physical Downlink Control Channel (PDCCH) carries information such as transmission format and resource allocation related to the PDSCH channel. It also notifies UE 101 and UE 102 of transmission format, resource allocation, and H-ARQ (Hybrid Automatic Repeat Request) information related to the uplink shared channel. Typically, downlink scheduling (allocating control and shared channel resource blocks to UE 102 within the cell) can be performed at either RAN Node 111 or RAN Node 112 based on channel quality information fed back from either UE 101 or UE 102. Downlink resource allocation information can be transmitted on the PDCCH used (e.g., allocated to) each of UE 101 and UE 102.

[0053] PDCCH can use Control Channel Elements (CCEs) to transmit control information. Before being mapped to resource elements, the complex-valued symbols of the PDCCH can first be organized into quadruplets, which can then be arranged using a sub-block interleaver for rate matching. One or more of these CCEs can be used to transmit each PDCCH, where each CCE can correspond to a set of four physical resource elements (REGs) of nine. Four Quadrature Phase Shift Keying (QPSK) symbols can be mapped to each REG. Depending on the size of the Downlink Control Information (DCI) and channel conditions, one or more CCEs can be used to transmit the PDCCH. In LTE, four or more different PDCCH formats can be defined with different numbers of CCEs (e.g., aggregation levels, L = 1, 2, 4, or 8).

[0054] In some aspects, the concept of resource allocation can be applied to control channel information, where the concept of resource allocation is an extension of the aforementioned concept. For example, some aspects can utilize an Enhanced Physical Downlink Control Channel (EPDCCH), which uses PDSCH resources for control information transmission. One or more Enhanced Control Channel Elements (ECCEs) can be used to transmit the EPDCCH. Similarly, each ECCE can correspond to a set of nine physical resource elements, called an Enhanced Resource Element Group (EREG). Depending on some arrangements, an ECCE may have a different number of EREGs.

[0055] RAN 110 is shown communicatively coupled to core network (CN) 120 via S1 interface 113. In some respects, CN 120 may be an evolved packet core (EPC) network, a next-generation packet core (NPC) network, or some other type of CN (e.g., as referenced). Figures 1B-1I (As shown). In this respect, the S1 interface 113 is divided into two parts: the S1-U interface 114, which carries communication data between RAN nodes 111 and RAN nodes 112 and the serving gateway (S-GW) 122; and the S1 mobility management entity (MME) interface 115, which is the signaling interface between RAN nodes 111 and RAN nodes 112 and the MME 121.

[0056] In this respect, CN 120 includes MME 121, S-GW 122, Packet Data Network (PDN) Gateway (P-GW) 123, and Home Subscriber Server (HSS) 124. MME 121 can functionally resemble the control plane of a legacy General Packet Radio Service (GPRS) Support Node (SGSN). MME 121 can manage mobility aspects of access, such as gateway selection and tracking area list management. HSS 124 may include a database for network users, containing subscription-related information to support network entities in handling communication sessions. Depending on the number of mobile subscribers, equipment capacity, network organization, etc., CN120 may include one or more HSS 124s. For example, HSS 124 can provide support for routing / roaming authentication, authorization, naming / addressing resolution, location dependencies, etc.

[0057] The S-GW 122 can terminate the S1 interface 113 toward RAN 110 and route data packets between RAN 110 and CN 120. Additionally, the S-GW 122 can serve as a local mobility anchor for inter-RAN node handover and can also provide an anchor for inter-3GPP mobility. Other responsibilities of the S-GW 122 may include lawful interception, billing, and some policy enforcement.

[0058] P-GW 123 can terminate the SGi interface to the PDN. P-GW 123 can route data packets between EPC network 120 and external networks such as a network including application server 184 (alternatively referred to as Application Function (AF)) via Internet Protocol (IP) interface 125. P-GW 123 can also transmit data to other external networks 131A, which may include the Internet, IP Multimedia Subsystem (IPS) networks, and other networks. Generally, application server 184 can be an element providing IP-bearing resources for use with the core network (e.g., UMTS Packet Service (PS) domain, LTE PS data service, etc.). In this respect, P-GW 123 is shown communicatively coupled to application server 184 via IP interface 125. Application server 184 can also be configured to support one or more communication services (e.g., Voice over Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for UE 101 and UE 102 via CN 120.

[0059] P-GW 123 can also be a node for policy enforcement and charging data collection. The Policy and Charging Rule Function (PCRF) 126 is the policy and charging control element of CN 120. In non-roaming scenarios, in some aspects, a single PCRF may exist in 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 breaches, there may be two PCRFs associated with the UE's IP-CAN session: a domestic PCRF (H-PCRF) in the HPLMN and a visited PCRF (V-PCRF) in the Visited Public Land Mobile Network (VPLMN). PCRF 126 can be communicatively coupled to application server 184 via P-GW 123. Application server 184 can signal PCRF 126 to indicate new service flows and select appropriate Quality of Service (QoS) and charging parameters. PCRF 126 can configure the rule as a policy and charging enforcement function (PCEF) (not shown) with an appropriate communication flow template (TFT) and QoS category identifier (QCI), which begins with QoS and charging specified by application server 184.

[0060] In one example, either node 111 or node 112 may be configured to transmit antenna panel selection and receive (Rx) beam selection to UE 101 and UE 102 (e.g., dynamically), which can be used by the UE for data reception on the physical downlink shared channel (PDSCH) and for channel state information reference signal (CSI-RS) measurement and channel state information (CSI) calculation.

[0061] In one example, either node 111 or node 112 may be configured to transmit antenna panel selection and transmit (Tx) beam selection to UE 101 and UE 102 (e.g., dynamically), which can be used by the UE for data transmission on the Physical Uplink Shared Channel (PUSCH) and for the transmission of Sounding Reference Signals (SRS).

[0062] In some respects, the communication network 140A can be an IoT network. One of the current enablers of IoT is Narrowband IoT (NB-IoT). NB-IoT has objectives such as extended coverage, reduced UE complexity, longer battery life, and backward compatibility with LTE networks. Furthermore, NB-IoT aims to provide deployment flexibility, allowing operators to introduce NB-IoT using a small fraction of their existing available spectrum and to operate in one of three modes: (a) standalone deployment (the network operates in reconstructed GSM spectrum); (b) in-band deployment (the network operates within LTE channels); and (c) guard band deployment (the network operates within the guard band of legacy LTE channels). In some respects, support for NB-IoT in small cells (e.g., in microcell, picocell, or femtocell deployments) can be provided, such as with the use of further enhanced NB-IoT (FeNB-IoT). One of the challenges facing NB-IoT systems in supporting small cells is UL / DL link imbalance, where base stations have lower available power for small cells than for macrocells, thus potentially affecting and / or reducing DL coverage. Furthermore, if reused for UL transmission, some NB-IoT UEs can be configured to transmit at maximum power. This can lead to significant inter-cell interference in dense small-cell deployments.

[0063] In some aspects, UE 101 may receive system information including a System Information Block (SIB) 190A. SIB 190A may include system and configuration information, such as a Physical Random Access Channel (PRACH) configuration index. The PRACH configuration index can be used to configure the PRACH format for transmitting a short sequence length PRACH preamble 192A. Various PRACH formats are shown in Table 2 below. In response to the PRACH preamble 192A, gNB 111 may transmit a Random Access Response (RAR) message 194A with a Random Access Radio Network Temporary Identifier (RA-RNTI). In some aspects, the RA-RNTI may be generated based on the slot index, frequency index, OFDM symbol index, PRACH instance index, and / or PRACH sequence index associated with the transmission of the PRACH preamble 192A.

[0064] Figure 1B This is a simplified diagram based on some aspects of the next-generation (NG) system architecture 140B. (Reference) Figure 1BThe NG system architecture 140B includes a RAN 110 and a 5G network core (5GC) 120. The NG-RAN 110 may include multiple nodes, such as gNB 128 and NG-eNB 130. gNB 128 and NG-eNB 130 may be communicatively coupled to UE 102 via, for example, an N1 interface.

[0065] The core network 120 (e.g., a 5G core network or 5GC) may include Access and Mobility Management Functions (AMF) 132 and / or User Plane Functions (UPF) 134. AMF 132 and UPF 134 may be communicatively coupled to gNB 128 and NG-eNB 130 via NG interfaces. More specifically, in some aspects, gNB 128 and NG-eNB 130 may be connected to AMF 132 via NG-C interfaces and to UPF 134 via NG-U interfaces. gNB 128 and NG-eNB 130 may be coupled to each other via Xn interfaces.

[0066] In some aspects, gNB 128 may include a node that provides New Radio (NR) user plane and control plane protocol termination to the UE and is connected to 5GC 120 via an NG interface. In some aspects, NG-eNB 130 may include a node that provides Evolved Universal Terrestrial Radio Access (E-UTRA) user plane and control plane protocol termination to the UE and is connected to 5GC 120 via an NG interface.

[0067] In some respects, each of the gNB 128 and NG-eNB 130 can be implemented as a base station, a mobile edge server, a small cell, a home eNB, etc.

[0068] Figure 1C An exemplary MulteFire Neutral Host Network (NHN) 5G architecture 140C is shown, based on some aspects. Reference Figure 1C The MulteFire 5G architecture 140C may include UE 102, NG-RAN 110, and core network 120. NG-RAN 110 may be MulteFire NG-RAN (MF NG-RAN), and core network 120 may be MulteFire 5G Neutral Host Network (NHN).

[0069] In some aspects, MF NHN 120 may include a neutral host AMF (NH AMF) 132, an NH SMF 136, an NH UPF 134, and a local AAA agent 151C. The AAA agent 151C provides connectivity to the 3GPP AAA server 155C and the participating service provider AAA (PSP AAA) server 153C. The NH-UPF 134 provides connectivity to the data network 157C.

[0070] The MF NG-RAN 120 provides functionality similar to NG-RAN operating under 3GPP specifications. The NH-AMF 132 can be configured to provide functionality similar to AMF in the 3GPP 5G core network (e.g., as referenced). Figure 1D The NH-SMF 136 can be configured to provide functionality similar to that of the SMF in the 3GPP 5G core network (e.g., as described in the reference). Figure 1D The NH-UPF134 can be configured to provide functionality similar to that of a UPF in a 3GPP 5G core network (e.g., as described in the reference). Figure 1D The above).

[0071] Figure 1D This illustrates the functional division between NG-RAN and 5G core (5GC) based on several aspects. (Reference) Figure 1D It shows a more detailed illustration of the functions that can be performed by the gNB 128 and NG-eNB 130 within NG-RAN 110, and the AMF 132, UPF 134, and SMF 136 within 5GC 120. In some respects, 5GC 120 can provide access to the Internet 138 to one or more devices via NG-RAN 110.

[0072] In some respects, the gNB 128 and NG-eNB 130 can be configured to host the following functions: functions for radio resource management (e.g., inter-cell radio resource management 129A, radio bearer control 129B, connection mobility control 129C, radio admission control 129D, dynamic resource allocation (scheduling) for the UE in the uplink and downlink 129F); IP header compression, encryption, and integrity protection of data; selection of the AMF at the UE annex when a route to the AMF cannot be determined based on information provided by the UE; routing user plane data to one or more UPFs; and routing control plane information to... AMF; connection setup and release; scheduling and transmission of paging messages (derived from AMF); scheduling and transmission of system broadcast information (derived from AMF or Operation and Maintenance); measurement and measurement report configuration for mobility and scheduling 129E; transport layer packet marking in the uplink; session management; network slicing support; QoS flow management and mapping to data radio bearers; support for UEs in RRC_INACTIVE state; distribution of non-access stratum (NAS) messages; radio access network sharing; dual connectivity; and tight interoperability between NR and E-UTRA, etc.

[0073] In some aspects, AMF 132 can be configured to host functions such as: NAS signaling termination; NAS signaling security 133A; Access Layer (AS) security control; Core Network (CN) inter-node signaling for mobility between 3GPP access networks; Idle State / Mode Mobility Processing 133B, including mobile devices, such as UE reachability (e.g., control and execution of paging retransmission); Registration Area Management; Intra-system and Inter-system Mobility Support; Access Authentication; Access Authorization, including checking roaming permissions; Mobility Management Control (subscriptions and policies); Network Slicing Support; and / or SMF Selection, etc.

[0074] UPF 134 can be configured to host functions such as: mobility anchoring 135A (e.g., anchoring points for mobility within / between RATs); packet data unit (PDU) processing 135B (e.g., external PDU session points interconnected with a data network); packet routing and forwarding; packet inspection and user plane portions of policy rule enforcement; traffic usage reporting; an uplink classifier to support routing communication flows to the data network; a branch point to support multi-homed PDU sessions; QoS processing for the user plane, such as packet filtering, gating, UL / DL rate enforcement; uplink communication authentication (SDF to QoS flow mapping); and / or downlink packet buffering and downlink data notification triggering.

[0075] The Session Management Function (SMF) 136 can be configured to host functions such as: session management; UE IP address allocation and management 137A; selection and control of User Plane Functions (UPFs); PDU session control 137B, including configuring traffic guidance at UPF 134 to route traffic to the correct destination; policy enforcement and QoS control; and / or downlink data notification, etc.

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

[0077] In some aspects, the 5G system architecture 140E includes an IP Multimedia Subsystem (IMS) 168E and multiple IP Multimedia Core Network Subsystem entities, such as the Call Session Control Function (CSCF). More specifically, the IMS 168E includes a CSCF that can act as a proxy CSCF (P-CSCF) 162E, a serving CSCF (S-CSCF) 164E, an emergency CSCF (E-CSCF) (not shown in Figure IE), and / or an interrogation CSCF (I-CSCF) 166E. The P-CSCF 162E can be configured as the first point of contact for UE 102 within the IMS 168E. The S-CSCF 164E can be configured to handle session states in the network, and the E-CSCF can be configured to handle certain aspects of emergency sessions, such as routing emergency requests to the correct emergency center or PSAP. The I-CSCF 166E can be configured to act as a point of contact within the operator's network for all IMS connections directed to subscribers of that network operator or roaming subscribers currently within the service area of ​​that network operator. In some respects, the I-CSCF 166E can connect to another IP multimedia network 170E, such as IMS operated by a different network operator.

[0078] In some respects, the UDM / HSS146 can be coupled to an application server 160E, which may include a Telephone Application Server (TAS) or another application server (AS). The AS160E can be coupled to the IMS168E via the S-CSCF 164E and / or the I-CSCF 166E.

[0079] In some respects, the 5G system architecture 140E may use one or more of the techniques described herein to employ a unified access restriction mechanism applicable to all RRC states of UE 102, such as RRC_IDLE, RRC_CONNECTED, and RRC_INACTIVE states.

[0080] In some respects, the 5G System Architecture 140E can be configured to use the 5G access control mechanisms described herein based on access categories, which can be categorized according to a minimal default set of access categories common across all networks. This functionality allows Public Land Mobile Networks (PLMNs), such as Accessible PLMNs (VPLMNs), to protect the network from different types of registration attempts, enable acceptable services for roaming subscribers, and enable VPLMNs to control access attempts intended to receive certain essential services. It also provides operators with more options and flexibility by offering a set of access categories that can be configured and used in an operator-specific manner.

[0081] refer to Figure 1F This illustrates the 5G system architecture 140F and its service-based representation. System architecture 140F is broadly similar to (or identical to) system architecture 140E. Except... Figure 1E The network entities shown in the system architecture 140F may also include Network Open Function (NEF) 154 and Network Repository Function (NRF) 156.

[0082] In some aspects, 5G system architecture can be service-based, and the interaction between network functions can be facilitated by corresponding point-to-point reference points Ni (e.g., ...). Figure 1E The interface is represented as a service-based interface (as shown in Figure 1F).

[0083] Reference points indicate that interactions are possible between the corresponding NF services. For example, Figure 1EThe following reference points are shown: N1 (between UE 102 and AMF 132), N2 (between RAN 110 and AMF 132), N3 (between RAN 110 and UPF 134), N4 (between SMF 136 and UPF 134), N5 (between PCF 148 and AF 150), N6 (between UPF 134 and DN 152), N7 (between SMF 136 and PCF 148), N8 (between UDM 146 and AMF 132), N9 (between the two UPF 134), N10 (between UDM 146 and SMF 136), N11 (between AMF 132 and SMF 136), N12 (between AUSF 144 and AMF 132), N13 (between AUSF 144 and UDM 132). N14 (between PCF 146 and AMF 132), N15 (between PCF 148 and AMF 132 if it is a non-roaming scenario; between PCF 148 and the access network and AMF 132 if it is a roaming scenario), and N16 (between two SMFs). Figure 1E (Not shown in the image) and N22 (between AMF 132 and NSSF 142). Also available are... Figure 1E Other reference points not shown in the text are indicated.

[0084] In some aspects, such as Figure 1F As shown, service-based representations can be used to represent network functions within a control plane that enables other authorized network functions to access their services. In this regard, the 5G system architecture 140F may include the following service-based interfaces: Namf 158H (service-based interface shown by AMF 132), Nsmf 1581 (service-based interface shown by SMF 136), Nnef 158B (service-based interface shown by NEF 154), Npcf 158D (service-based interface shown by PCF 148), Nudm 158E (service-based interface shown by UDM 146), Naf 158F (service-based interface shown by AF 150), Nnrf 158C (service-based interface shown by NRF 156), Nnssf 158A (service-based interface shown by NSSF 142), and Nausf 158G (service-based interface shown by AUSF 144). Also available Figure 1F Other service-based interfaces not shown (e.g., Nudr, N5g-eir, and Nudsf).

[0085] Figure 1G An exemplary CIoT network architecture is shown based on some aspects. (Reference) Figure 1GThe CIoT architecture 140G may include UE 102 and RAN 110, which are coupled to multiple core network entities. In some aspects, UE 102 may be a machine-type communication (MTC) UE. The CIoT network architecture 140G may also include a Mobile Serving Switching Center (MSC) 160, an MME 121, a Serving GPRS Support Node (SGSN) 162, an S-GW 122, an IP Short Message Gateway (IP-SM-GW) 164, an IWMSC (Imported Wireless Message Service Center) / Gateway Mobile Serving Center (GMSC) Interoperability MSC 166, an MTC Interoperability Function (MTC-IWF) 170, a Service Capability Opening Function (SCEF) 172, a Gateway GPRS Support Node (GGSN) / Packet GW (P-GW) 174, a Billing Data Function (CDF) / Billing Gateway Function (CGF) 176, a Home Subscriber Server (HSS) / Home Location Register (HLR) 177, a Short Message Entity (SME) 168, an MTC Authentication, Authorization and Accounting (MTC AAA) Server 178, a Service Capability Server (SCS) 180, and Application Servers (AS) 182 and 184.

[0086] In some respects, SCEF 172 can be configured to securely expose services and capabilities provided by various 3GPP network interfaces. SCEF 172 also provides ways to discover exposed services and capabilities, as well as access network capabilities through various network application programming interfaces (e.g., API interfaces for SCS180).

[0087] Figure 1GVarious reference points between different servers, functions, or communication nodes in the CIoT network architecture 140G are also shown. Some exemplary reference points related to MTC-IWF 170 and SCEF 172 include the following: Tsms (a reference point used by entities outside the 3GPP network to communicate with the UE via SMS for MTC), Tsp (a reference point used by the SCS to communicate with control plane signaling related to MTC-IWF), T4 (a reference point used between MTC-IWF 170 and SMS-SC 166 in HPLMN), T6a (a reference point used between SCEF 172 and Serving MME 121), T6b (a reference point used between SCEF 172 and Serving SGSN 162), T8 (a reference point used between SCEF 172 and SCS / AS180 / 182), and S6m (used by MTC-IWF 170 to query HSS / HLR). The reference point is S6n (the reference point used by MTC-AAA server 178 to query HSS / HLR 177) and S6t (the reference point used between SCEF 172 and HSS / HLR 177).

[0088] In some respects, the CIoT UE 102 can be configured to communicate with one or more entities within the CIoT architecture 140G via RAN 110 according to a Non-Access Stratum (NAS) protocol and using one or more reference points (such as a narrowband air interface), for example based on one or more communication technologies (such as Orthogonal Frequency Division Multiplexing (OFDM) technology). As used herein, the term "CIoT UE" refers to a UE capable of CIoT optimization as part of a CIoT communication architecture.

[0089] In some respects, the NAS protocol can support a set of NAS messages for communication between the CIoT UE 102 and the Evolved Packet System (EPS) Mobility Management Entity (MME) 121 and SGSN 162.

[0090] In some aspects, the CIoT network architecture 140F may include a packet data network, a carrier network, or a cloud service network, with, for example, a service capability server (SCS) 180, an application server (AS) 182, or one or more other external servers or network components.

[0091] RAN 110 can be coupled to HSS / HLR server 177 and AAA server 178 using one or more reference points (including, for example, an air interface based on the S6a reference point), and can be configured to authenticate / authorize CIoT UE 102 to access the CIoT network. RAN 110 can be coupled to CIoT network architecture 140G using one or more other reference points (including, for example, an air interface corresponding to the SGi / Gi interface used for 3GPP access). RAN 110 can be coupled to SCEF 172 using, for example, an air interface based on the T6a / T6b reference point for service capability exposure. In some respects, SCEF 172 can act as an API GW for third-party application servers such as AS182. SCEF 172 can be coupled to HSS / HLR 177 and MTC AAA 178 servers using the S6t reference point, and can further expose application programming interfaces to network capabilities.

[0092] In some examples, one or more of the CIoT devices disclosed herein, such as CIoT UE 102, CIoTRAN 110, etc., may include one or more other non-CIoT devices, or include non-CIoT devices that act as CIoT devices or have CIoT device functionality. For example, CIoT UE 102 may include a smartphone, a tablet, or one or more other electronic devices that act as CIoT devices for a specific function while having other additional functions.

[0093] In some aspects, RAN 110 may include a CIoT enhanced node B (CIoT eNB) 111 communicatively coupled to a CIoT access network gateway (CIoT GW) 195. In some examples, RAN 110 may include multiple base stations (e.g., CIoT eNBs) connected to CIoT GW 195, which may include MSG 160, MME 121, SGSN 162, and / or S-GW 122. In some examples, the internal architecture of RAN 110 and CIoT GW 195 may be left to implementation and does not require standardization.

[0094] As used herein, the term "circuit" can refer to, belong to, or include application-specific integrated circuits (ASICs) or other special-purpose circuits, electronic circuits, processors (shared, dedicated, or grouped), memory (shared, dedicated, or grouped) executing one or more software or firmware programs, combinational logic circuits, or other suitable hardware components that provide the said functionality. In some aspects, a circuit may be implemented in one or more software or firmware modules, or the functionality associated with the circuit may be implemented by one or more software or firmware modules. In some aspects, a circuit may include logic components that operate at least partially in hardware. In some aspects, the circuits and modules disclosed herein may be implemented using a combination of hardware, software, and / or firmware. In some aspects, the functionality associated with the circuit may be distributed across multiple hardware or software / firmware modules. In some aspects, a module (as disclosed herein) may include logic components that operate at least partially in hardware. The aspects described herein may be implemented into a system using any suitably configured hardware or software.

[0095] Figure 1H An exemplary Service Capability Open Function (SCEF) is shown based on some aspects. (Reference) Figure 1H The SCEF172 can be configured to expose services and capabilities provided by 3GPP network interfaces to external third-party service provider servers hosting various applications. In some aspects, 3GPP networks such as the CIoT architecture 140G can expose the following services and capabilities: Home Subscriber Server (HSS) 116H, Policy and Charging Rules Function (PCRF) 118H, Packet Flow Description Function (PFDF) 120H, MME / SGSN 122H, Broadcast Multicast Service Center (BM-SC) 124H, Service Telephone Server Control Function (S-CSCF) 126H, RAN Congestion Awareness Function (RCAF) 128H, and one or more other network entities 130H. These services and capabilities of the 3GPP network can communicate with the SCEF 172 via one or more interfaces, such as... Figure 1H As shown.

[0096] SCEF 172 can be configured to expose 3GPP network services and capabilities to one or more applications running on one or more Service Capability Servers (SCS) / Application Servers (AS) (such as SCS / AS 102H, 104H, ..., 106H). Each of the SCS / AS 102H to 106H can communicate with SCEF 172 via Application Programming Interfaces (APIs) 108H, 110H, 112H, ..., 114H, such as... Figure 1H As shown.

[0097] Figure 1I An exemplary roaming architecture for SCEF is shown, based on several aspects. References Figure 1ISCEF 172 can reside in HPLMN 110I and can be configured to open 3GPP network services and capabilities such as 102I, ..., 104I. In some aspects, 3GPP network services and capabilities, such as 106I, ..., 108I, can reside within VPLMN 112I. In this case, the 3GPP network services and capabilities within VPLMN 112I can be opened to SCEF 172 via the interoperable SCEF (IWK-SCEF) 197 within VPLMN 112I.

[0098] Figure 1J An exemplary evolution of the Universal Terrestrial Radio Access (E-UTRA) New Radio Dual Connectivity (EN-DC) architecture is illustrated based on several aspects. Reference Figure 1G The EN-DC architecture 140J includes a radio access network (or E-TRA network, or E-TRAN) 110 and an EPC 120. The EPC 120 may include an MME 121 and an S-GW 122. The E-UTRAN 110 may include a node 111 (e.g., an eNB) and an Evolved Universal Terrestrial Radio Access New Radio (EN) Next Generation Evolution Node B (en-gNB) 128.

[0099] In some respects, the en-gNB 128 can be configured to provide NR user plane protocol termination and control plane protocol termination to the UE 102, and act as an auxiliary node (or SgNB) in the EN-DC communication architecture 140J. The eNB 111 can be configured as a master node (or MeNB) in the EN-DC communication architecture 140J. For example... Figure 1J As shown, eNB 111 is connected to EPC 120 via the S1 interface and to EN-gNB 128 via the X2 interface. EN-gNB 128 can be connected to EPC 120 via the S1-U interface and to other EN-gNBs via the X2-U interface.

[0100] Figure 2Exemplary components of device 200 according to some aspects are shown. In some aspects, device 200 may include application circuitry 202, baseband circuitry 204, radio frequency (RF) circuitry 206, front-end module (FEM) circuitry 208, one or more antennas 210, and power management circuitry (PMC) 212 (at least coupled together as shown). Components of the illustrated device 200 may be included in a UE or RAN node. In some aspects, device 200 may include fewer components (e.g., the RAN node may not utilize application circuitry 202, but instead include a processor / controller to process IP data received from the EPC). In some aspects, device 200 may include additional components such as, for example, memory / storage devices, displays, cameras, sensors, and / or input / output (I / O) interface elements. In other aspects, the components described below may be included in multiple devices (e.g., the circuitry may be individually included in multiple devices for a Cloud-RAN (C-RAN) implementation).

[0101] Application circuitry 202 may include one or more application processors. For example, application circuitry 202 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The one or more processors may include any combination of general-purpose processors, special-purpose processors, and special-purpose processors (e.g., graphics processors, application processors, etc.). The processor may be coupled to and / or may include a memory / storage device, and may be configured to execute instructions stored in the memory / storage device to enable various applications or operating systems to run on device 200. In some aspects, the processor of application circuitry 202 may process IP data packets received from the EPC.

[0102] Baseband circuitry 204 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. Baseband circuitry 204 may include one or more baseband processors or control logic components to process baseband signals received from the receive signal path of RF circuitry 206 and generate baseband signals for the transmit signal path of RF circuitry 206. Baseband processing circuitry 204 may interact with application circuitry 202 to generate and process baseband signals and control the operation of RF circuitry 206. For example, in some aspects, baseband circuitry 204 may include a third-generation (3G) baseband processor 204A, a fourth-generation (4G) baseband processor 204B, a fifth-generation (5G) baseband processor 204C, or one or more other baseband processors 204D for other existing generations of communication, communications under development, or communications to be developed in the future (e.g., second-generation (2G), sixth-generation (6G), etc.). Baseband circuitry 204 (e.g., one or more of baseband processors 204A-D) can handle various radio control functions capable of communicating with one or more radio networks via RF circuitry 206. In other aspects, some or all of the functions of baseband processors 204A-D may be included in modules stored in memory 204G and may be executed via central processing unit (CPU) 204E. Radio control functions may include, but are not limited to, signal modulation / demodulation, encoding / decoding RF shifting, etc. In some aspects, the modulation / demodulation circuitry of baseband circuitry 204 may include Fast Fourier Transform (FFT), precoding, or constellation mapping / demapping functions. In some aspects, the encoding / decoding circuitry of baseband circuitry 204 may include convolution, tail-biting convolution, turbo, Viterbi, or low-density parity-check (LDPC) encoder / decoder functions. The aspects of modulation / demodulation and encoder / decoder functions are not limited to these examples, and other suitable functions may be included in other aspects.

[0103] In some aspects, the baseband circuitry 204 may include one or more audio digital signal processors (DSPs) 204F. The one or more audio DSPs 204F may include elements for compression / decompression and echo cancellation, and in other aspects may include other suitable processing elements. In some aspects, components of the baseband circuitry 204 may be suitably combined in a single chip, a single chipset, or disposed on the same circuit board. In some aspects, some or all components of the baseband circuitry 204 and the application circuitry 202 may be implemented together, such as (e.g.) on a system-on-a-chip (SoC).

[0104] In some aspects, baseband circuit 204 can provide communications compatible with one or more radio technologies. For example, in some aspects, baseband circuit 204 can support communications with the Evolved Universal Terrestrial Radio Access Network (EUTRAN), other Wireless Metropolitan Area Networks (WMAN), Wireless Local Area Networks (WLAN), and / or Wireless Personal Area Networks (WPAN). In some aspects, baseband circuit 204 configured to support radio communications of multiple radio protocols may be referred to as a multi-mode baseband circuit.

[0105] RF circuit 206 can communicate with a wireless network using modulated electromagnetic radiation over a non-solid medium. In various aspects, RF circuit 206 may include switches, filters, amplifiers, etc., to facilitate communication with the wireless network. RF circuit 206 may include a receive signal path, which may include circuitry for down-converting the RF signal received from FEM circuit 208 and providing a baseband signal to baseband circuit 204. RF circuit 206 may also include a transmit signal path, which may include circuitry for up-converting the baseband signal provided by baseband circuit 204 and providing an RF output signal for transmission to FEM circuit 208.

[0106] In some aspects, the receive signal path of RF circuit 206 may include mixer 206A, amplifier 206B, and filter 206C. In some aspects, the transmit signal path of RF circuit 206 may include filter 206C and mixer 206A. RF circuit 206 may also include synthesizer 206D, which synthesizes frequencies used by mixer 206A for both the receive and transmit signal paths. In some aspects, mixer 206A for the receive signal path may be configured to down-convert the RF signal received from FEM circuit 208 based on the synthesized frequency provided by synthesizer 206D. Amplifier 206B may be configured to amplify the down-converted signal, and filter 206C may be a low-pass filter (LPF) or a band-pass filter (BPF) and is configured to remove unwanted signals from the down-converted signal to generate an output baseband signal. The output baseband signal may be provided to baseband circuit 204 for further processing. In some aspects, the output baseband signal may optionally be a zero-frequency baseband signal. In some respects, the mixer 206A for receiving the signal path may include a passive mixer.

[0107] In some respects, the mixer 206A of the transmit signal path can be configured to up-convert the input baseband signal based on the synthesized frequency provided by the synthesizer 206D to generate an RF output signal for the FEM circuit 208. The baseband signal can be provided by the baseband circuit 204 and can be filtered by the filter 206C.

[0108] In some aspects, the mixer 206A in the receive signal path and the mixer 206A in the transmit signal path may include two or more mixers, and may be arranged for quadrature downconversion and upconversion, respectively. In some aspects, the mixer 206A in the receive signal path and the mixer 206A in the transmit signal path may include two or more mixers, and may be arranged for image suppression (e.g., Hartley image suppression). In some aspects, the mixer 206A in the receive signal path and the mixer 206A in the transmit signal path may be arranged for direct downconversion and direct upconversion, respectively. In some aspects, the mixer 206A in the receive signal path and the mixer 206A in the transmit signal path may be configured for superheterodyne operation.

[0109] In some aspects, the output baseband signal and the input baseband signal may optionally be analog baseband signals. According to some alternative aspects, the output baseband signal and the input baseband signal may be digital baseband signals. In these alternative aspects, RF circuitry 206 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry, and baseband circuitry 204 may include a digital baseband interface for communication with RF circuitry 206.

[0110] In some dual-mode applications, separate radio IC circuitry may optionally be provided for processing signals in each spectrum.

[0111] In some respects, synthesizer 206D may be optionally a fractional N synthesizer or a fractional N / N+1 synthesizer, but other types of frequency synthesizers may also be suitable. For example, synthesizer 206D may be a trigonometric integrator, a frequency multiplier, or a synthesizer including a phase-locked loop with a frequency divider.

[0112] Synthesizer 206D can be configured to synthesize an output frequency based on the frequency input and the divider control input for use by mixer 206A of RF circuit 206. In some respects, synthesizer 206D can be a fractional N / N+1 synthesizer.

[0113] In some respects, the frequency input can be provided by a voltage-controlled oscillator (VCO), but this is not mandatory. Depending on the desired output frequency, the divider control input can be provided, for example, by baseband circuit 204 or application circuit 202. In some respects, the divider control input (e.g., N) can be determined from a lookup table based on the channel indicated by application circuit 202.

[0114] The synthesizer circuit 206D of the RF circuit 206 may include a frequency divider, a delay latch-up loop (DLL), a multiplexer, and a phase accumulator. In some aspects, the frequency divider may be a dual-mode divider (DMD), and the phase accumulator may be a digital phase accumulator (DPA). In some aspects, the DMD may be configured to divide the input signal by N or N+1 (e.g., based on execution) to provide a fractional division ratio. In some exemplary aspects, the DLL may include a set of cascaded tunable delay elements, a phase detector, a charge pump, and a D-type flip-flop. In these aspects, the delay elements may be configured to decompose the VCO cycle into Nd equal groups of phases, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help maintain the total delay across the delay line as one VCO cycle.

[0115] In some aspects, the synthesizer circuit 206D can be configured to generate a carrier frequency as the output frequency, while in others, the output frequency can be a multiple of the carrier frequency (e.g., twice or four times the carrier frequency) and can be used in conjunction with quadrature generator and frequency divider circuitry to generate multiple signals having multiple different phases relative to each other at the carrier frequency. In some aspects, the output frequency can be the LO frequency (fLO). In some aspects, the RF circuit 206 may include an IQ / polarity converter.

[0116] FEM circuit 208 may include a receive signal path, which may include circuitry configured to operate on RF signals received from one or more antennas 210, and / or amplify the received signals and provide an amplified version of the received signals to RF circuit 206 for further processing. FEM circuit 208 may also include a transmit signal path, which may include circuitry configured to amplify transmit signals provided by RF circuit 206 for transmission through one or more of the one or more antennas 210. In various aspects, amplification via the transmit or receive signal path may be performed partially or entirely in RF circuit 206, partially or entirely in FEM circuit 208, or both.

[0117] In some aspects, FEM circuit 208 may include a TX / RX switch to switch between transmit and receive mode operation. FEM circuit 208 may include a receive signal path and a transmit signal path. The receive signal path of FEM circuit 208 may include an LNA to amplify the received RF signal and provide the amplified received RF signal as an output (e.g., to RF circuit 206). The transmit signal path of FEM circuit 208 may include a power amplifier (PA) for amplifying the input RF signal (e.g., provided by RF circuit 206) and one or more filters for generating the RF signal for subsequent transmission (e.g., through one or more of one or more antennas 210).

[0118] In some respects, the PMC 212 can manage the power supplied to the baseband circuitry 204. The PMC 212 can control power selection, voltage scaling, battery charging, and / or DC-DC conversion. In some respects, the PMC 212 may be included when the device 200 is capable of being battery powered, for example, when the device is included in a UE. The PMC 212 can improve power conversion efficiency while providing advantageous implementation size and thermal characteristics.

[0119] Figure 2 PMC 212 is shown coupled to baseband circuit 204. In other respects, PMC 212 may additionally or alternatively be coupled to other components (such as, but not limited to, application circuit 202, RF circuit 206, or FEM circuit 208) or perform similar power management operations for other components.

[0120] In some respects, PMC 212 can control or otherwise participate in various power-saving mechanisms of device 200. For example, if device 200 is in the RRC_Connected state, and in this state it is still connected to the RAN node because it expects to receive communication soon, then it may enter a state called Discontinuous Receive Mode (DRX) after a period of inactivity. During this state, device 200 can power down for short intervals, thereby saving power.

[0121] Depending on several factors, if no data communication activity occurs during the extended time period, device 200 may transition to the RRC Idle state, in which the device disconnects from the network and does not perform operations such as channel quality feedback or handover. Device 200 enters an extremely low-power state and performs paging; during this state, the device periodically wakes up to listen to the network and then powers off again. Device 200 may transition back to the RRC_Connected state to receive data.

[0122] An additional power-saving mode allows the device to be unavailable from the network for periods exceeding the paging interval (ranging from seconds to hours). During this time, the device 200 may be unable to access the network in some ways and may power off. Any data sent during this period will incur a delay (potentially significant), and this delay is assumed to be acceptable.

[0123] The processors of application circuit 202 and baseband circuit 204 are elements that can be used to execute one or more instances of the protocol stack. For example, the processor of baseband circuit 204 can be used alone or in combination to execute layer 3, layer 2, or layer 1 functions, while the processor of application circuit 202 can utilize data received from these layers (e.g., packet data) and further execute layer 4 functions (e.g., Transport Communication Protocol (TCP) and User Datagram Protocol (UDP) layers). As mentioned herein, layer 3 may include the Radio Resource Control (RRC) layer, which will be described in further detail below. As mentioned herein, layer 2 may include the Media Access Control (MAC) layer, the Radio Link Control (RLC) layer, and the Packet Data Convergence Protocol (PDCP) layer, which will be described in further detail below. As mentioned herein, layer 1 may include the physical (PHY) layer of the UE / RAN node, which will be described in further detail below.

[0124] Figure 3 An exemplary interface of the baseband circuit 204 according to some aspects is shown. As discussed above, Figure 2 The baseband circuit 204 may include processors 204A to 204E and a memory 204G utilized by the processors. Each of the processors 204A to 204E may respectively include a memory interface 304A to 304E for sending / receiving data to / from the memory 204G.

[0125] Baseband circuit 204 may further include: one or more interfaces for communication coupling to other circuits / devices, such as memory interface 312 (e.g., an interface for sending / receiving data to / from a memory external to baseband circuit 204); application circuit interface 314 (e.g., for sending / receiving data to / from a memory external to baseband circuit 204); and application circuit interface 314 (e.g., for sending / receiving data to / from a memory external to baseband circuit 204). Figure 2 Application circuit 202 (interface for sending / receiving data); RF circuit interface 316 (e.g., for sending / receiving data to / from...). Figure 2 RF circuit 206 (interface for transmitting / receiving data); wireless hardware connection interface 318 (e.g., for transmitting / receiving data to / from near field communication (NFC) components, Components (e.g.) Low Energy) Interface for sending / receiving data to / from components and other communication components; and power management interface 320 (e.g., an interface for sending / receiving power or control signals to / from PMC 212).

[0126] Figure 4 This is a diagram of the control plane protocol stack based on some aspects. In one aspect, control plane 400 is shown as the communication protocol stack between UE 102, RAN node 128 (or alternatively, RAN node 130) and AMF 132.

[0127] In some aspects, PHY layer 401 can transmit or receive information used by MAC layer 402 via one or more air interfaces. PHY layer 401 can also perform link adaptive or adaptive modulation and coding (AMC), power control, cell search (e.g., for initial synchronization and handover purposes), and other measurements used by higher layers (e.g., RRC layer 405). In some aspects, PHY layer 401 can further perform error detection for the transport channel, forward error correction (FEC) coding / decoding for the transport channel, modulation / demodulation of the physical channel, interleaving, rate matching, mapping to the physical channel, and multiple-input multiple-output (MIMO) antenna processing.

[0128] In some aspects, MAC layer 402 can perform mapping between logical channels and transport channels, multiplexing MAC Service Data Units (SDUs) from one or more logical channels to transport blocks (TBs) delivered to the PHY via transport channels, demultiplexing MAC SDUs from transport blocks (TBs) delivered from the PHY via transport channels to one or more logical channels, multiplexing MAC SDUs to TBs, scheduling information reporting, error correction via Hybrid Automatic Repeat Request (HARQ), and logical channel prioritization.

[0129] In some aspects, RLC layer 403 can operate in multiple operating modes, including: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). RLC layer 403 can perform the transmission of upper-layer protocol data units (PDUs), perform error correction via Automatic Repeat Request (ARQ) for AM data transmission, and perform segmentation and reassembly of RLC SDUs used for UM and AM data transmission. RLC layer 403 can also maintain sequence numbers independent of the sequence numbers in the PDCPs used for UM and AM data transmission. In some aspects, RLC layer 403 can also re-segment RLC data PDUs used for AM data transmission, detect duplicate data in AM data transmission, discard RLC SDUs used for UM and AM data transmission, detect protocol errors in AM data transmission, and perform RLC re-establishment.

[0130] In some respects, PDCP layer 404 can perform header compression and decompression of IP data, maintain PDCP sequence numbers (SNs), perform in-order delivery of upper-layer PDUs when re-establishing the lower layer, perform reordering and deduplication of lower-layer SDUs, perform PDCP PDU routing in the case of split bearers, perform retransmission of lower-layer SDUs, encrypt and decrypt control plane and user plane data, perform integrity protection and integrity verification of control plane and user plane data, control timer-based data discarding, and perform security operations (e.g., encryption, decryption, integrity protection, integrity verification, etc.).

[0131] In some aspects, the main services and functions of RRC layer 405 may include broadcasting system information (e.g., included in the Master Information Block (MIB) or System Information Block (SIB) associated with the Non-Access Stratum (NAS); broadcasting system information associated with the Access Stratum (AS); paging initiated by 5GC 120 or NG-RAN 110; establishment, maintenance, and release of RRC connections between the UE and NG-RAN (e.g., RRC connection paging, RRC connection establishment, RRC connection addition, RRC connection modification, and RRC connection release, also used for carrier aggregation and dual connectivity in NR or between E-UTRA and NR); establishment, configuration, maintenance, and release of Signaling Radio Bearers (SRBs) and Data Radio Bearers (DRBs); security functions including key management; mobility functions including handover and context transfer; UE cell selection and reselection control; and Radio Access Technology (RAT) mobility; and measurement configuration for UE measurement reporting. The MIBs and SIBs may include one or more Information Elements (IEs), each of which may include a separate data field or data structure. In some respects, RRC layer 405 can also perform QoS management functions, radio link failure detection and recovery, and NAS message transmission between NAS layer 406 in the UE and NAS layer 406 in AMF 132.

[0132] In some aspects, the following NAS messages can be transmitted during the corresponding NAS program, as shown in Table 1 below:

[0133]

[0134] Table 1

[0135] In some respects, when the same message is used for multiple programs, parameters that indicate the specific purpose of the program (e.g., registration type or TAU type) can be used, such as registration type = "initial registration", "mobility registration update" or "periodic registration update".

[0136] UE 101 and RAN nodes 128 / 130 can exchange control plane data via a protocol stack using an NG radio interface (e.g., an LTE-Uu interface or an NR radio interface), which includes a PHY layer 401, a MAC layer 402, an RLC layer 403, a PDCP layer 404, and an RRC layer 405.

[0137] like Figure 4 As shown, the Non-Access Stratum (NAS) protocol layer 406 forms the highest layer of the control plane between UE 101 and AMF 132. In various aspects, the NAS protocol layer 406 supports the mobility and session management procedures of UE 101 to establish and maintain IP connections between UE 101 and AMF 134. In some aspects, the UE protocol stack may include one or more upper layers located above the NAS layer 406. For example, upper layers may include an operating system layer 424, a connection manager 420, and an application layer 422. In some aspects, the application layer 422 may include one or more clients that can be used to perform various application functions, including providing interfaces to and communicating with one or more external networks. In some aspects, the application layer 422 may include an IP Multimedia Subsystem (IMS) client 426.

[0138] The NG Application Protocol (NG-AP) layer 415 supports the functionality of the N2 and N3 interfaces and includes an initial procedure (EP). The EP is the interaction unit between RAN nodes 128 / 130 and 5GC 120. In some respects, the NG-AP layer 415 services may include two groups: services associated with the UE and services not associated with the UE. These services perform a number of functions, including but not limited to: UE context management, PDU session management, management of corresponding NG-RAN resources (e.g., data radio bearer [DRB]), UE capability indication, mobility, NAS signaling transmission, and configuration transmission (e.g., for transmitting SON information).

[0139] The Flow Control Transmission Protocol (SCTP) layer (optionally referred to as the SCTP / IP layer) 414 may, in part, rely on the IP protocol supported by the IP layer 413 to ensure reliable transmission of signaling messages between RAN nodes 128 / 130 and AMF 132. Layers L2 412 and L1 411 may refer to the communication links (e.g., wired or wireless) used by RAN nodes 128 / 130 and AMF 132 for exchanging information.

[0140] RAN nodes 128 / 130 and AMF 132 can exchange control plane data via the N2 interface through a protocol stack that includes L1 layer 411, L2 layer 412, IP layer 413, SCTP layer 414, and S1-AP layer 415.

[0141] Figure 5This is a diagram of a user plane protocol stack based on some aspects. In this aspect, user plane 500 is shown as a communication protocol stack between UE 102, RAN node 128 (or alternatively, RAN node 130), and UPF 134. User plane 500 may utilize at least some of the same protocol layers as control plane 400. For example, UE 102 and RAN node 128 may exchange user plane data via a protocol stack using an NR radio interface, which includes PHY layer 401, MAC layer 402, RLC layer 403, PDCP layer 404, and Service Data Adaptation Protocol (SDAP) layer 416. In some aspects, SDAP layer 416 may perform mapping between Quality of Service (QoS) streams and Data Radio Bearers (DRBs) and marking of DL packets and UL packets with QoS Stream IDs (QFIs). In some aspects, IP protocol stack 513 may be located above SDAP 416. User Datagram Protocol (UDP) / Transmission Control Protocol (TCP) stack 520 may be located above IP stack 513. The Session Initiation Protocol (SIP) stack 522 can be located above the UDP / TCP stack 520 and can be used by UE 102 and UPF 134.

[0142] The General Packet Radio Service (GPRS) tunneling protocol for the user plane (GTP-U) layer 504 can be used to carry user data within the 5G core network 120 and between the radio access network 110 and the 5G core network 120. For example, the transmitted user data can be packets in IPv4, IPv6, or PPP format. The UDP and IP Security (UDP / IP) layer 503 can provide checksums for data integrity, port numbers for addressing different functions at the source and destination, and encryption and authentication for selected data streams. RAN nodes 128 / 130 and UPF 134 can exchange user plane data via a protocol stack using the N3 interface, which includes L1 layer 411, L2 layer 412, UDP / IP layer 503, and GTP-U layer 504. (As described above...) Figure 4 As discussed, the NAS protocol supports the mobility and session management procedures of UE 101 to establish and maintain IP connections between UE 101 and UPF 134.

[0143] Figure 6 This is a block diagram illustrating components according to some exemplary aspects, which are capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any or more methods discussed herein. Specifically, Figure 6A schematic diagram of hardware resource 600 is shown, which includes one or more processors (or processor cores) 610, one or more memory / storage devices 620, and one or more communication resources 630, each of which can be communicatively coupled via bus 640. For aspects utilizing node virtualization (e.g., NFV), an executable hypervisor 602 provides an execution environment for one or more network slices and / or sub-slices to utilize hardware resource 600.

[0144] Processor 610 (e.g., 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 digital signal processor (DSP) (such as a baseband processor), an application-specific integrated circuit (ASIC), a radio frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processor 612 and processor 614.

[0145] The memory / storage device 620 may include main memory, disk storage, or any suitable combination thereof. The memory / storage device 620 may include, but is not limited to, any type of volatile or non-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 devices, etc.

[0146] Communication resource 630 may include interconnect or network interface components or other suitable devices for communicating with one or more peripheral devices 604 or one or more databases 606 via network 608. For example, communication resource 630 may include wired communication components (e.g., for coupling via Universal Serial Bus (USB), cellular communication components, NFC components, etc. Components (e.g.) (low power consumption) Components and other communication components.

[0147] Instructions 650 may include software, programs, applications, applets, or other executable code for causing at least any one of the processors 610 to perform any or more of the methods discussed herein. Instructions 650 may reside wholly or partially within at least one of the processors 610 (e.g., within the processor's cache memory), memory / storage device 620, or any suitable combination thereof. Furthermore, any portion of instructions 650 may be transferred to hardware resource 600 from any combination of peripheral device 604 or database 606. Thus, the memory of processor 610, memory / storage device 620, peripheral device 604, and database 606 are examples of computer-readable and machine-readable media.

[0148] Figure 7 This is a diagram based on several aspects, including the initial access procedure 700 for PRACH preamble retransmission. (See reference) Figure 7 The initial access procedure 700 can begin with operation 702, at which point initial synchronization can occur. For example, UE 101 can receive a primary synchronization signal and a secondary synchronization signal to achieve initial synchronization. In some aspects, one or more SS blocks received in a burst can be used to perform the initial synchronization at operation 702. At operation 704, UE 101 can receive system information, such as one or more System Information Blocks (SIBs) and / or a Primary Information Block (MIB).

[0149] At operations 706 to 714, a random access procedure may occur. More specifically, at operation 706, a PRACH preamble transmission may occur as message 1 (Msg1). At operation 710, UE 101 may receive a random access response (RAR) message, which may be random access procedure message 2 (Msg2). In Msg2, node (e.g., gNB) 111 may respond using a random access radio network temporary identifier (RA-RNTI), which may be calculated based on preamble resources (e.g., time and frequency allocation).

[0150] In some respects, UE 101 can be configured to perform one or more retransmissions of the PRACH preamble at operation 708 when no RAR is received or detected within a pre-configured or predefined time window. The PRACH preamble retransmission can be performed under a power ramp condition as described below to increase transmission power until a random access response is received.

[0151] At operation 712, UE 101 may transmit Random Access Procedure Message 3 (Msg3), which may include a Radio Resource Control (RRC) Connection Request message. At operation 714, UE 101 may receive Random Access Procedure Message 4 (Msg4), which may include an RRC Connection Setup message carrying a Cell Radio Network Temporary Identifier (CRNTI) for subsequent communication between UE 101 and Node 111.

[0152] In some respects, PRACH preambles can be transmitted from the UE without timing alignment. If the UE is far from the gNB, the PRACH preamble may be received later than the symbol boundary, which could lead to interference. In this regard, a guard period (GP) can be used in conjunction with PRACH preamble transmission to protect upcoming transmissions. If subsequent transmissions are also PRACH-related, a guard period may not be necessary because of the cyclic prefix associated with the PRACH transmission. However, if subsequent transmissions are PUCCH or PUSCH information, a guard period can be used to protect upcoming transmissions. In this regard, in some respects, it is desirable to allocate PRACH preamble formats without guard periods (e.g., PRACH formats A1, A2, and A3) in the earlier portions of the PRACH resource and PRACH preamble formats with guard periods (e.g., PRACH formats B1, B2, and B3) in the later portions of the PRACH resource. Table 2 below shows example PRACH formats associated with short sequence length PRACH preambles (e.g., lengths of 139 or 127).

[0153]

[0154]

[0155] Table 2

[0156] Configuration of PRACH format for short sequence lengths (L = 127 or 139)

[0157] As shown in Table 2, for NR PRACH formats with sequence lengths of 127 or 139, three format categories—Format A, Format B, and Format C—are available. In some respects, Format C can be used for large cell sizes. Format A and Format B are similar because they occupy the same time span. The difference between Format A and Format B is that Format A does not have a guard period (GP), while Format B has a non-zero GP length. However, Format A has a longer cyclic prefix (CP) length compared to Format B because the GP length portion of Format B is used for the CP.

[0158] In some respects, PRACH format A may omit the GP to maximize the CP length within the available resource, thereby increasing PRACH reception power. If multiple PRACHs are concatenated within a configured PRACH resource, the CP in subsequent PRACHs can be effectively used as the GP, resulting in minimal or no interference between two PRACHs within a configured PRACH resource. However, if format A is used for the last PRACH within a configured PRACH resource, some interference may exist between that PRACH and the UL channel in subsequent time slots. Therefore, for the last part of a configured PRACH resource, PRACH format B can be used instead to protect subsequent transmissions by having a guard period at the end of PRACH format B.

[0159] In some respects, a cell can configure the number of repetitions for a single PRACH. However, a cell can configure both PRACH format A and PRACH format B together (e.g., based on the PRACH configuration index received within a system information block).

[0160] In some respects, PRACH resources can be configured in different ways. They can be configured at the slot level, single-symbol level, or multi-symbol level. Furthermore, multiple PRACH sequences can exist in the time domain within a configured PRACH resource. For example, if the configured PRACH resource is a single slot, then four consecutive PRACH formats A2 can be used within it.

[0161] In some respects, PRACH can be configured using system information such as Physical Broadcast Channel (PBCH) information, Residual Minimal System Information (RMSI), or System Information Block (SIB). In other respects, the information size of PRACH configuration can be minimized by transmitting a single PRACH configuration index. The PRACH configuration index can be used to configure PRACH resources and repetition count. The possible number of PRACHs in the time domain can be calculated; for example, if the configured PRACH resource is one time slot (14 OFDM symbols) and the repetition factor is 4, then there are three possible PRACHs in the time domain. In this case, the first two PRACHs use PRACH format A, and the last PRACH uses format B, such as... Figure 8 As shown.

[0162] In some aspects, the preamble format can be selected by transmitting a single PRACH configuration index, which may include preamble formats A1, A2, A3, B1, B2, and B3. Additionally, the PRACH configuration index can be used to determine specific PRACH resources for transmitting the preamble, including subframe number and start symbol number. In some aspects, the PRACH configuration index can be used to determine the repetition factor and / or the number of symbols used for each preamble transmission. In some aspects, the PRACH configuration index can be used to determine the number of PRACH slots within a subframe, the number of time-domain PRACH moments or instances within a PRACH slot, and the PRACH duration.

[0163] Figure 8 A first exemplary PRACH configuration is shown based on several aspects. (Reference) Figure 8 This illustrates time slot 800 as the configured PRACH resource. Assuming a repetition factor of 4 (e.g., formats A2 and B2), three possible PRACH transmissions, such as 802, 804, or 806, can exist within time slot 800. Because only format B includes a guard period, the first two PRACH transmissions 802 and 804 can use format A (e.g., A2), while the last PRACH transmission 806 can use format B (e.g., B2).

[0164] In some respects, if the configured PRACH resources include multiple time slots, then the above, in conjunction with, for example... Figure 8 The disclosed technology can be applied to each time slot or as a whole to all configured PRACH resources.

[0165] In some aspects, PRACH configuration information may include the PRACH resource size and repetition factor, which can be used to determine the PRACH format that can be used within the PRACH resource. In this regard, by transmitting PRACH configuration information such as a single PRACH configuration index, the signaling overhead of configuring PRACH can be minimized. In some aspects, when multiple PRACHs can be transmitted within a configured PRACH resource, one or more of the following techniques can be used to determine the PRACH instance or time used for transmitting the PRACH preamble within the PRACH resource:

[0166] (a) Randomly select a PRACH instance / time within the configured PRACH resources;

[0167] (b) Selecting the PRACH instance / time based on the UE ID or using a hash function based on the UE ID; and

[0168] (c) Selecting a PRACH instance / time based on service priority. For example, the UE may select the first PRACH instance / time for the highest priority service and the last PRACH instance / time for the lowest priority service.

[0169] In some respects, the use of PRACH format B can be based on whether any available symbols remain in the configured PRACH resources.

[0170] In some respects, only a portion of a time slot can be configured for PRACH resources, for example, to avoid the first few symbols used for downlink control or the last few symbols used for uplink transmission. In this case, multiple PRACH times can be adapted within the configured PRACH resource. For this purpose, PRACH format A can be used for the first portion of the configured PRACH resource. However, after subsequent PRACH times occurring in later portions of the configured PRACH resource, the determination of whether to use format A or format B can be based on whether any OFDM symbols remain within the configured PRACH resource.

[0171] Figure 9 A second exemplary PRACH configuration is shown, based on some aspects. (Reference) Figure 9 It shows the PRACH resources configured as time slot 900 (including all 14 OFDM symbols within that time slot). With a PRACH repetition factor of 3, 12 OFDM symbols can be used for PRACH transmissions (e.g., possible PRACH transmissions 902, 904, and 906), where the remaining two symbols (i.e., as...) Figure 9 (Symbols 12 and 13 are shown). In this case, all three possible PRACH transmission times 902, 904, and 906 can be configured with PRACH format A, since symbols 12 and 13 can be used as guard periods, and PRACH format B, which includes guard periods, is not required.

[0172] Figure 10A A third exemplary PRACH configuration is shown, based on some aspects. (Reference) Figure 10AThe diagram illustrates PRACH resource 1008 configured as part of time slot 1000. More specifically, symbols numbered 2-13 of time slot 1000 can be configured as PRACH resource 1008. In this case, the configured PRACH resource 1008 consists of 12 OFDM symbols, and if the PRACH repetition factor is 3, all 12 symbols can be used for PRACH transmissions 1002, 1004, or 1006, where the last PRACH transmission 1006 is based on PRACH format B (so that there is a guard period at the end of the configured PRACH resource), while the other PRACH transmissions (1002 or 1004) can use PRACH format A.

[0173] Figure 10B A third exemplary PRACH configuration is shown, based on some aspects. (Reference) Figure 10B The diagram illustrates PRACH resource 1058 configured as part of time slot 1050. More specifically, symbols numbered 0-11 of time slot 1050 can be configured as PRACH resource 1058. In this case, the configured PRACH resource 1058 consists of 12 OFDM symbols, and if the PRACH repetition factor is 3, all 12 symbols can be used for PRACH transmissions 1052, 1054, or 1056, where the last PRACH transmission 1056 is based on PRACH format B (so that there is a guard period at the end of the configured PRACH resource), while the other PRACH transmissions (1052 or 1054) can use PRACH format A.

[0174] In some respects, if the configured PRACH resources include multiple time slots, then the above, in conjunction with, for example... Figures 9-10B The disclosed technology can be applied to each time slot or as a whole to all configured PRACH resources.

[0175] In some aspects, PRACH configuration information may include the PRACH resource size and repetition factor, which can be used to determine the PRACH format that can be used within the PRACH resource. In this regard, by transmitting PRACH configuration information such as a single PRACH configuration index, the signaling overhead of configuring PRACH can be minimized. In some aspects, when multiple PRACHs can be transmitted within a configured PRACH resource, one or more of the following techniques can be used to determine the PRACH instance or time used for transmitting the PRACH preamble within the PRACH resource:

[0176] (a) Randomly select a PRACH instance / time within the configured PRACH resources;

[0177] (b) Selecting the PRACH instance / time based on the UE ID or using a hash function based on the UE ID; and

[0178] (c) Selecting a PRACH instance / time based on service priority. For example, the UE may select the first PRACH instance / time for the highest priority service and the last PRACH instance / time for the lowest priority service.

[0179] In some aspects, PRACH resource configuration can be performed in multiple ways. For example, PRACH resource configuration can be at the slot level, i.e., a slot will be allocated for PRACH. In this case, the entire slot will be allocated for PRACH transmission. In some aspects, multiple slots can be allocated for PRACH transmission. In some aspects, some OFDM symbols cannot be used for PRACH within a slot configured for PRACH transmission (e.g., the first one or more symbols within the slot can be used for downlink transmission). Since the downlink control resource set (CORESET) is also configured by system information (e.g., RMSI), the total resources configured can be the slots configured for PRACH, in addition to some ODFM symbols configured by system information (e.g., RMSI) for DL ​​control components and possibly one or more guard band symbols. One example is that if a slot is configured for PRACH, the first two symbols are not used for PRACH, and the remaining 12 symbols are available for PRACH transmission (e.g., in the aspect using regular CP). In some aspects, for the case of extended CP, the number of remaining symbols can be 10.

[0180] In some aspects, the configured PRACH resources can be configured at the OFDM symbol level, i.e., OFDM symbols for PRACH will be allocated within them. In this case, start and end symbol information can be used for PRACH resource configuration to indicate the configured PRACH resources, and can be indicated by system information. In some aspects, a bitmap method can be used for PRACH resource configuration, where each bit of the bitmap indicates the OFDM symbol used for the PRACH. Where the configured PRACH resources include multiple time slots, the above techniques can be applied to each time slot or as a whole to the configured PRACH resources.

[0181] RNTI configuration

[0182] In some respects, as described above, multiple PRACH instances / moments can be configured within a single configured PRACH resource. During the PRACH process, the gNB is configured to transmit a Random Access Response (RAR) message in response to the PRACH. Therefore, the gNB must indicate which PRACH instance the RAR is for.

[0183] The RAR message may include an ID indicating that the RAR is a response to a specific PRACH, and this ID may be a Random Access Radio Network Temporary Identifier (RA-RNTI). The RA-RNTI may be transmitted in the downlink to respond to the desired PRACH. In some respects, the RA-RNTI may be included in the downlink control channel, or it may be included in the downlink data channel, or it may be masked in the CRC of the downlink control channel. In this respect, the RA-RNTI must be correctly mapped to the actual transmitted PRACH. Regarding the aspect where the RA-RNTI is a function of the PRACH timeslot, ambiguity may arise because multiple PRACH instances / moments can exist within a single PRACH timeslot. To eliminate ambiguity, the RA-RNTI may be generated based on one or more of the following options.

[0184] Option 1: In some respects, the RA-RNTI can be determined based on one or more of the following: slot index (t_id), frequency index (f_id), OFDM symbol index (sym_id), PRACH instance index, and / or PRACH sequence index (seq_id) associated with the actual transmitted PRACH. More specifically, the RA-RNTI can be determined as RA-RNTI = f(t_id, f_id, sym_id, seq_id), where t_id is the index of the first subframe specifying the PRACH (e.g., 0 ≤ t_id < 10) or the index of the slot within the configured subframe, and f_id is the index of the specified PRACH within that subframe, in ascending frequency domain order (e.g., 0 ≤ f_id < 6). sym_id is the index of the first OFDM symbol specifying the PRACH (e.g., 0 ≤ sym_id < 14), and seq_id is the index of the sequence of configured PRACHs.

[0185] The generalized formula for this option can be expressed as follows: RA-RNTI=A+B×Sym_id+C×t_id+D×f_id+E×seq_id, where A, B, C, D and E are integers (including 0) that can be obtained through higher-level signaling or predefined in the radio specification.

[0186] Option 2: In some aspects, the RA-RNTI can be determined based on one or more of the following: the slot index, the frequency index, and / or the OFDM symbol index within the configured PRACH resources of the actually transmitted PRACH. More specifically, the RA-RNTI can be determined as RA-RNTI = T + Sym_id + 14×(t_id + 10×f_id), where t_id is the index of the first subframe specifying the PRACH (e.g., 0 ≤ t_id < 10) or the index of the slot within the configured subframe, and f_id is the index of the specified PRACH within that subframe, in ascending order in the frequency domain (e.g., 0 < f_id < 6). sym_id is the index of the first OFDM symbol of the specified PRACH (e.g., 0 ≤ sym_id < 14). The generalized formula for this option can be expressed as: RA-RNTI = A + B×Sym_jd + C×t_id + D×f_id, where A, B, C, and D are integers (including 0) predefined by higher layer signaling or in the radio specification.

[0187] Option 3: In some aspects, the RA-RNTI can be determined based on one or more of the following: the slot index, the frequency index, and / or the PRACH instance index within the PRACH resources of the actually transmitted PRACH, where, for example, for a PRACH within a slot, the PRACH instance index is 0, 1, or 2 (e.g., as Figure 9 shown). In this regard, the RA-RNTI can be expressed as follows: RA-RNTI = 1 + t2_id + 6×(t_id + 10×f_id), where t_id is the index of the first subframe specifying the PRACH (e.g., 0 ≤ t_id < 10) or the index of the slot within the configured subframe, and f_id is the index of the specified PRACH within that subframe, in ascending order in the frequency domain (e.g., 0 ≤ f_id < 6). t2_id is the index of the PRACH instance (e.g., 0 ≤ t2_id < 6). The generalized formula for this option can be expressed as: RA-RNTI = A + B×t2_id + C×t_id + D×f_id, where A, B, C, and D are integers (including 0) predefined by higher layer signaling or in the radio specification.

[0188] In the aspect where the RA-RNTI is used for multiple PRACH instances within the configured PRACH resources, the RAR can be mapped to different timings. More specifically, the first RAR timing can be mapped to the first PRACH instance within the configured PRACH resources, and the second RAR timing can be mapped to the second PRACH instance within the configured PRACH resources, and so on.

[0189] Figure 11An exemplary communication exchange 1100 for configuring PRACH format between UE 1102 and Next Generation Node B (gNB) 1104 is shown, according to some aspects. Reference Figure 11 When system information such as SRB 1106 can be transmitted from gNB 1104 to UE 1102, communication exchange 1100 may begin at operation 1108. In some aspects, SIB 1106 may include PRACH configuration information, such as a PRACH configuration index. UE 1102 may use SIB 1106 to determine the PRACH configuration index at operation 1110 and may select a PRACH preamble with a corresponding format based on the PRACH index. At operation 1114 and during the PRACH process, UE 1102 may transmit PRACH preamble 1112 to gNB 1104. At operation 1116, gNB 1104 may determine RA-RNTI based on one or more parameters associated with the PRACH preamble transmission at operation 1114. For example, gNB 1104 may use one or more of the above options to determine RA-RNTI. At operation 1120, gNB 1104 can transmit RAR response 1118 with RA-RNTI. At operation 1124, UE 1102 can transmit Physical Uplink Shared Channel (PUSCH) data 1122 to gNB 1104.

[0190] Figure 12 A flowchart is shown in general of exemplary functions of method 1200 according to some aspects, which can be implemented in conjunction with a PRACH configuration in a wireless architecture. References Figure 12 When the System Information Block (SIB) information (e.g., 190A) includes a PRACH configuration index, method 1200 may begin at operation 1202. The PRACH configuration index may indicate at least a first preamble format and a second preamble format. For example, the PRACH configuration index can be used to obtain the preamble format, PRACH timing resources such as subframe number and start symbol, the number of PRACH slots within a subframe, the number of time-domain PRACH moments or instances within a PRACH slot, and the total PRACH duration.

[0191] At operation 1204, the PRACH preamble (e.g., 192A) can be encoded within the PRACH resource indicated by the PRACH configuration index (e.g., as referenced herein). Figures 8-10BThe PRACH preamble (as discussed) is transmitted to the base station. It can be associated with either a first preamble format or a second preamble format. For example, if the last PRACH time is selected within the PRACH resource, a PRACH transmission using format B is used to utilize the guard period within such a format to protect subsequent transmissions. In cases where a PRACH time different from the last PRACH time within the PRACH resource is selected, it is not necessary to use a PRACH transmission using format A as a guard period.

[0192] At operation 1206, the Random Access Channel Response (RAR) message (e.g., 1904A) received from the base station in response to the PRACH preamble is decoded. The RAR message includes a Random Access Radio Network Temporary Identifier (RA-RNTI). The RA-RNTI may be based on the OFDM symbol index (sym_id), frequency index (f_id), and timing resource index (t_id) associated with the transmitted PRACH preamble within the PRACH resource, or one or more other options as discussed above.

[0193] Figure 13 A block diagram of a communication device is shown, which may include, for example, an evolved Node B (eNB), a next-generation Node B (gNB), an access point (AP), a radio station (STA), a mobile station (MS), or a user equipment (UE). Alternatively, the communication device 1300 may operate as a standalone device or be connected (e.g., networked) to other communication devices.

[0194] A circuit (e.g., a processing circuit) is a collection of circuits implemented in a tangible entity of device 1300, which includes hardware (e.g., simple circuits, gates, logic components, etc.). The relationships between circuit components can change flexibly over time. A circuit includes components that can perform a specified operation during operation (individually or in combination). In one example, the hardware of the circuit may be designed invariably to perform a specific operation (e.g., hard-wired). In one example, the hardware of the circuit may include variablely connected physical components (e.g., execution units, transistors, simple circuits, etc.) to encode instructions for a specific operation, and the physical components include machine-readable media with physical modifications (e.g., magnetically, electrically, or movably positioned invariant aggregate particles).

[0195] When physical components are connected, the fundamental electrical properties of the hardware components change, for example, from an insulator to a conductor, and vice versa. This instruction enables embedded hardware (e.g., an execution unit or loading mechanism) to create circuit components within the hardware via variable connections to perform certain parts of a specific operation during operation. Thus, in one example, a machine-readable medium element is part of a circuit, or other components communicatively coupled to the circuit during device operation. In one example, any of the physical components can be used in more than one component of more than one circuit. For example, during operation, an execution unit may be used at one point in time in a first circuit of a first circuit system and reused at different times in a second circuit of the first circuit system, or in a third circuit of the second circuit system. The following are additional examples of these components relative to device 1300.

[0196] In some respects, device 1300 may operate as a standalone device or be connected (e.g., networked) to other devices. In a networked deployment, communication device 1300 may operate as a server communication device, a client communication device, or both in a server-client network environment. In one example, communication device 1300 may act as a peer-to-peer (P2P) (or other distributed) network device. Communication device 1300 may be a UE, eNB, PC, tablet, STB, PDA, mobile phone, smartphone, web device, network router, switch, or bridge, or any communication device capable of executing instructions (sequentially or otherwise) specifying the actions to be taken by the communication device. Furthermore, although only one communication device is shown, the term "communication device" should also be considered as including any collection of communication devices that individually or collectively execute a set (or more) of instructions to perform any one or more methods discussed herein (such as cloud computing Software as a Service (SaaS)) and other computer cluster configurations.

[0197] Examples as described herein may include logical components or components, modules, or mechanisms, or may operate on logical components or components, modules, or mechanisms. A module is a tangible entity (e.g., hardware) capable of performing a specified operation and which may be configured or arranged in some way. In one example, circuitry may be arranged as a module in a specified manner (e.g., internally or relative to external entities such as other circuitry). In one example, all or part of one or more computer systems (e.g., stand-alone computer systems, client computer systems, or server computer systems) or one or more hardware processors may be configured by firmware or software (e.g., instructions, application portions, or applications) to operate to perform a specified operation. In one example, software may reside on a communication device-readable medium. In one example, when the software is executed by the underlying hardware of the module, it causes the hardware to perform the specified operation.

[0198] Therefore, the term "module" should be understood to encompass tangible entities, that is, entities that are physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transiently) configured (e.g., programmed) to operate or perform any of the operations described herein in a specified manner. Consider the example of modules being temporarily configured, where each module does not need to be instantiated at any given time. For example, if a module includes a general-purpose hardware processor configured using software, the general-purpose hardware processor can be configured as different modules at different times. The software can accordingly configure the hardware processor, for example, to constitute a particular module at one time instance and different modules at different time instances.

[0199] The communication device (e.g., UE) 1300 may include a hardware processor 1302 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory 1304, a static memory 1306, and a mass storage device 1307 (e.g., a hard disk, a tape drive, a flash memory, or other block or storage device), some or all of which may communicate with each other via an interconnect link (e.g., a bus) 1308.

[0200] The communication device 1300 may also include a display device 1310, a numeric input device 1312 (e.g., a keyboard), and a user interface (UI) navigation device 1314 (e.g., a mouse). In one example, the display device 1310, input device 1312, and UI navigation device 1314 may be a touchscreen display. The communication device 1300 may additionally include a signal generation device 1318 (e.g., a speaker), a network interface device 1320, and one or more sensors 1321, such as a Global Positioning System (GPS) sensor, a compass, an accelerometer, or other sensors. The communication device 1300 may include an output controller 1328, such as a serial (e.g., Universal Serial Bus (USB)) connection, a parallel connection, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection, to communicate with or control one or more peripheral devices (e.g., a printer, a card reader, etc.).

[0201] Storage device 1307 may include a communication device-readable medium 1322 on which one or more sets of data structures or instructions 1324 (e.g., software) embodied or utilized by any one or more of the techniques or functions described herein are stored. In some aspects, registers of processor 1302, main memory 1304, static memory 1306, and / or mass storage device 1307 may ( wholly or at least partially) be or include device-readable medium 1322 on which one or more sets of data structures or instructions 1324 embodied or utilized by any one or more of the techniques or functions described herein are stored. In one example, one or any combination of hardware processor 1302, main memory 1304, static memory 1306, or mass storage device 1316 constitutes device-readable medium 1322.

[0202] As used herein, the term “device-readable medium” may be used interchangeably with “computer-readable medium” or “machine-readable medium”. Although the communication device-readable medium 1322 is shown as a single medium, the term “communication device-readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) configured to store one or more instructions 1324.

[0203] The term "communication device readable medium" can include any medium capable of storing, encoding, or carrying instructions (e.g., instruction 1324) for execution by communication device 1300 and causing communication device 1300 to perform any one or more technologies of this disclosure, or capable of storing, encoding, or carrying data structures used by or associated with such instructions. Examples of non-limiting communication device readable media can include solid-state memory, as well as optical and magnetic media. Specific examples of communication device readable media can 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 hard disks; magneto-optical disks; random access memory (RAM); and CD-ROM and DVD-ROM discs. In some examples, the communication device readable medium can include a non-transitory communication device readable medium. In some examples, the communication device readable medium can include a communication device readable medium that is not a transient propagating signal.

[0204] Instruction 1324 can also be transmitted or received via a network interface device 1320 through a communication network 1326 using a transmission medium, wherein the transmission or reception utilizes any of a number of transmission protocols (e.g., Frame Relay, Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), etc.). Exemplary communication networks may include local area networks (LANs), wide area networks (WANs), packet data networks (e.g., the Internet), mobile phone networks (e.g., cellular networks), conventional telephone (POTS) networks, and wireless data networks (e.g., the Institute of Electrical and Electronics Engineers (IEEE) 802.11 series, referred to as...). The standard, the IEEE 802.16 series, is known as The standards include IEEE 802.15.4 series standards, LTE series standards, Universal Mobile Telecommunications System (UMTS) series standards, peer-to-peer (P2P) networks, etc. In one example, network interface device 1320 may include one or more physical jacks (e.g., Ethernet, coaxial cable, or telephone jacks) or one or more antennas to connect to communication network 1326. In one example, network interface device 1320 may include multiple antennas to perform wireless communication using at least one of single-input multiple-output (SIMO), MIMO, or multiple-input single-output (MISO) technologies. In some examples, network interface device 1320 may use multi-user MIMO technology for wireless communication.

[0205] The term "transmission medium" should be understood to include any intangible medium capable of storing, encoding, or carrying instructions for execution by the communication device 1300, and includes digital or analog communication signals or other intangible media to facilitate communication of such software. In this context, the transmission medium is a device-readable medium.

[0206] Additional notes and examples :

[0207] Example 1 is an apparatus for a user equipment (UE), comprising: processing circuitry, wherein, for configuring the UE for a Physical Random Access Channel (PRACH) procedure, the processing circuitry is configured to: decode system information block (SIB) information including a PRACH configuration index, wherein the PRACH configuration index indicates at least a first preamble format and a second preamble format; encode a PRACH preamble for transmission to a base station within a PRACH resource indicated by the PRACH configuration index, wherein the PRACH preamble is associated with either the first preamble format or the second preamble format; decode a random access channel response (RAR) message from the base station, the RAR message including an uplink grant for scheduling Physical Uplink Shared Channel (PUSCH) transmission; and encode data based on the uplink grant for transmission on the PUSCH; and a memory coupled to the processing circuitry, the memory being configured to store at least one of the SIB information and the PRACH configuration index.

[0208] In Embodiment 2, the subject matter according to Embodiment 1 includes a PRACH resource comprising a plurality of PRACH moments, and wherein the PRACH preamble is transmitted within a plurality of PRACH moments having a start symbol indicated by a PRACH configuration index.

[0209] In Embodiment 3, the subject matter according to Embodiment 2 includes, wherein when the first preamble format is one of A1, A2 and A3, the second preamble format is correspondingly one of B1, B2 and B3, and wherein formats A1-A3 have zero guard period lengths, while formats B1-B3 have non-zero guard period lengths.

[0210] In Example 4, the subject matter according to Example 3 includes the following: when the PRACH moment used to transmit the PRACH preamble is the last PRACH moment within the PRACH resource, the PRACH preamble is one of the B1, B2, or B3 formats.

[0211] In Example 5, the subject matter according to Examples 3 to 4 includes the following: when the PRACH time used for transmitting the PRACH preamble is different from the last PRACH time in the PRACH resource, the PRACH preamble is one of the A1, A2, or A3 formats.

[0212] In Example 6, the subject matter according to Examples 1 to 5 includes receiving a RAR with a corresponding Random Access Radio Network Temporary Identifier (RA-RNTI) on the Physical Downlink Control Channel (PDCCH), wherein the RA-RNTI is based on the OFDM symbol index (sym_id), frequency index (f_id), and timing resource index (t_id) associated with the transmitted PRACH preamble within the PRACH resource.

[0213] In Embodiment 7, the subject matter according to Embodiment 6 includes a processing circuit configured to determine RA-RNTI according to the following equation: RA-RNTI=A+B×sym_id+C×t_id+D×f_id, where A, B, C and D are integer values.

[0214] In Embodiment 8, the subject matter according to Embodiments 2 to 7 includes a processing circuit configured to randomly select a PRACH moment from a plurality of PRACH moments for transmitting the PRACH preamble.

[0215] In Embodiment 9, the subject matter according to Embodiments 2 to 8 includes a processing circuit configured to: generate a hash function based on a User Equipment Identifier (UE ID) associated with the device; and select a PRACH time for transmitting the PRACH preamble from a plurality of PRACH times based on the generated hash function.

[0216] In Example 10, the subject matter according to Examples 2 to 9 includes a processing circuit configured to select a PRACH moment for transmitting the PRACH preamble from a plurality of PRACH moments based on a service priority indicator associated with PUSCH data transmission.

[0217] In Example 11, the subject matter according to Examples 1 to 10 includes, wherein the first preamble format and the second preamble format are associated with a short sequence length of 139.

[0218] In Embodiment 12, the subject matter according to Embodiments 1 to 11 includes a transceiver circuit coupled to the processing circuitry; and one or more antennas coupled to the transceiver circuitry.

[0219] Example 13 is an apparatus for a base station (BS) comprising: processing circuitry configured to: encode system information block (SIB) information including a PRACH configuration index, wherein the PRACH configuration index indicates at least a first preamble format and a second preamble format, the first and second preamble formats being associated with a short sequence length of 139; decode a PRACH preamble received within a PRACH resource indicated by the PRACH configuration index, wherein the PRACH preamble is based on either the first or the second preamble format; encode a random access channel response (RAR) message for transmission to a user equipment (UE), the RAR message being encoded with a random access radio network temporary identifier (RA-RNTI) and including an uplink grant for scheduling physical uplink shared channel (PUSCH) transmission; and decode data received on the PUSCH based on the uplink grant; and a memory coupled to the processing circuitry configured to store configuration information.

[0220] In Example 14, the subject matter according to Example 13 includes RA-RNTI based on the OFDM symbol index (sym_id), frequency index (f_id), and timing resource index (t_id) associated with the received PRACH preamble within the PRACH resource.

[0221] In Embodiment 15, the subject matter according to Embodiment 14 includes a processing circuit configured to determine RA-RNTI according to the following equation: RA-RNTI=A+B×sym_id+C×t_id+D×f_id, where A, B, C and D are integer values.

[0222] In Example 16, the subject matter according to Examples 13 to 15 includes a base station that is a next-generation node B (gNB) or an evolved node B (eNB).

[0223] In Embodiment 17, the subject matter according to Embodiments 13 to 16 includes a transceiver circuit coupled to the processing circuitry; and one or more antennas coupled to the transceiver circuitry.

[0224] Example 18 is a computer-readable storage medium storing instructions for execution by one or more processors of a user equipment (UE), the instructions configuring the one or more processors to cause the UE to: decode system information block (SIB) information including a PRACH configuration index, wherein the PRACH configuration index indicates at least a first preamble format and a second preamble format; encode a PRACH preamble for transmission to a base station within a PRACH resource indicated by the PRACH configuration index, wherein the PRACH preamble is associated with either the first preamble format or the second preamble format; and decode a random access channel response (RAR) message received from the base station in response to the PRACH preamble, the RAR message including a random access radio network temporary identifier (RA-RNTI), wherein the RA-RNTI is based on an OFDM symbol index (sym_id), a frequency index (f_id), and a timing resource index (t_id) associated with the transmitted PRACH preamble within the PRACH resource.

[0225] In Example 19, the subject matter according to Example 18 includes a PRACH resource comprising a plurality of PRACH moments, and wherein the PRACH preamble is transmitted within a plurality of PRACH moments having a start symbol indicated by a PRACH configuration index.

[0226] In Example 20, the subject matter according to Examples 18 to 19 includes a first preamble format which is one of A1, A2 and A3 formats, a second preamble format which is correspondingly one of B1, B2 and B3 formats, and wherein formats A1-A3 have zero guard period lengths, while formats B1-B3 have non-zero guard period lengths.

[0227] In Example 21, the subject matter according to Example 20 includes the following: when the PRACH time used for transmitting the PRACH preamble is the last PRACH time in the PRACH resource, the PRACH preamble is one of the B1, B2, or B3 formats; and when the PRACH time used for transmitting the PRACH preamble is different from the last PRACH time in the PRACH resource, the PRACH preamble is one of the A1, A2, or A3 formats.

[0228] Embodiment 22 is at least one machine-readable medium including instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to implement any one of Embodiments 1 to 21.

[0229] Example 23 is an apparatus that includes means for implementing any one of Examples 1 to 21.

[0230] Example 24 is a system for implementing any one of Examples 1 to 21.

[0231] Example 25 is a method for implementing any one of Examples 1 to 21.

[0232] Although one aspect has been described with reference to specific exemplary aspects, it will be apparent that various modifications and changes can be made to these aspects without departing from the broader scope of this disclosure. Accordingly, the specification and drawings should be regarded as illustrative rather than restrictive. The drawings, which form a part of this document, illustrate specific aspects of the subject matter to be practiced in an illustrative rather than restrictive manner. The aspects shown have been described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other aspects may be utilized and derived from this disclosure, such that structural and logical substitutions and changes can be made without departing from the scope of this disclosure. Therefore, this specific embodiment is not intended to be restrictive, and the scope of the aspects is defined only by the appended claims and the full scope of the authorized equivalents of such claims.

[0233] Such aspects of the subject matter of this invention may be mentioned individually and / or collectively herein merely for convenience, and if more than one is actually disclosed, it is not intended to voluntarily limit the scope of this patent application to any single aspect or inventive concept. Therefore, although specific aspects are shown and described herein, it should be understood that any arrangement calculated to achieve the same purpose may substitute for the specific aspects shown. This disclosure is intended to cover any and all modifications or variations of the aspects. Combinations of the foregoing aspects and other aspects not specifically described herein will be apparent to those skilled in the art upon review of the above description.

[0234] A summary of the specification is provided to allow the reader to quickly determine the nature of the technical disclosure. This summary is based on the understanding that the technical disclosure will not be used to interpret or limit the scope or meaning of the claims. Furthermore, in the above detailed description, it can be seen that various features are concentrated in a single aspect for the purpose of simplifying this disclosure. The disclosed method should not be construed as reflecting an intention to require more features than expressly recited in each claim for the claimed aspect. Rather, as reflected in the following claims, the inventive subject matter lies in all features less than those of a single disclosed aspect. Therefore, the following claims are incorporated herein by reference, wherein each claim exists independently as a separate aspect.

Claims

1. An apparatus for wireless communication, comprising: The processing circuitry, wherein, in order to facilitate the Physical Random Access Channel (PRACH) procedure, is configured to cause the User Equipment (UE) to: Decode the system information block (SIB) information, which includes the configuration of PRACH resources, wherein the configuration of the PRACH resources includes multiple PRACH instances; Identify a specific PRACH instance among the plurality of PRACH instances within the PRACH resource; The PRACH preamble is encoded at the specific PRACH instance within the PRACH resource for transmission to the base station, wherein the PRACH preamble is associated with a first preamble format or a second preamble format, depending on the determined PRACH instance. Decode the Random Access Channel Response (RAR) message from the base station, the RAR message including uplink grants for scheduling Physical Uplink Shared Channel (PUSCH) transmissions; and Data is encoded based on the uplink grant for transmission on the PUSCH. The RAR message is associated with a Random Access Radio Network Temporary Identifier (RA-RNTI), wherein the RA-RNTI is based on: Index of OFDM symbols; Frequency index; and Time slot index; The RA-RNTI is associated with the specific PRACH instance within the PRACH resource.

2. The apparatus of claim 1, wherein the configuration of the PRACH resource includes a PRACH configuration index, wherein the PRACH preamble is transmitted using a start symbol indicated by the PRACH configuration index.

3. The apparatus according to claim 2, wherein, When the first preamble format is one of formats A1, A2 and A3, the second preamble format is correspondingly one of formats B1, B2 and B3, wherein formats A1-A3 have zero guard period lengths and formats B1-B3 have non-zero guard period lengths.

4. The apparatus according to claim 3, wherein, When the specific PRACH instance used to transmit the PRACH preamble is the last PRACH instance within the PRACH resource, the PRACH preamble is one of the formats B1, B2, or B3.

5. The apparatus according to claim 3, wherein, When the specific PRACH instance used to transmit the PRACH preamble is different from the last PRACH instance within the PRACH resource, the PRACH preamble is one of the formats A1, A2, or A3.

6. The apparatus of claim 2, wherein determining the specific PRACH instance comprises randomly selecting the specific PRACH instance from the plurality of PRACH instances.

7. The apparatus of claim 2, wherein the processing circuit is configured to: A hash function is generated based on the User Equipment Identifier (UE ID) associated with the device; and The specific PRACH instance is selected from the plurality of PRACH instances based on the generated hash function.

8. The apparatus of claim 2, wherein the processing circuit is configured to: The specific PRACH instance for transmitting the PRACH preamble is selected from the plurality of PRACH instances based on the service priority indicator associated with the PUSCH transmission.

9. The apparatus according to claim 1, further comprising: A transceiver circuit coupled to the processing circuit; as well as One or more antennas coupled to the transceiver circuit.

10. The apparatus of claim 1, wherein the OFDM symbol index is an index of the first OFDM symbol of the particular PRACH instance.

11. A method for operating a base station, the method comprising: The system information block (SIB) information, which includes the configuration of PRACH resources, is encoded, wherein the PRACH resources include multiple PRACH instances; Decode the PRACH preamble received at a specific PRACH instance among the plurality of PRACH instances within the PRACH resource, wherein the PRACH preamble is based on a first preamble format or a second preamble format; A Random Access Channel Response (RAR) message is encoded for transmission to a User Equipment (UE). The RAR message is encoded using a Random Access Radio Network Temporary Identifier (RA-RNTI) and includes an uplink grant for scheduling Physical Uplink Shared Channel (PUSCH) transmissions. The RA-RNTI is associated with a specific PRACH instance within the PRACH resource, and the RA-RNTI is based on: Index of OFDM symbols; Frequency index; and Time slot index; and The data received on the PUSCH is decoded based on the uplink authorization.

12. The method of claim 11, wherein the base station is a next-generation node B, i.e., a gNB, or an evolved node B, i.e., an eNB.

13. The method of claim 11, wherein the base station comprises: The processing circuit, wherein the encoding of the SIB information, the decoding of the PRACH preamble, and the encoding of the RAR message are performed by the processing circuit; A transceiver circuit coupled to the processing circuit; as well as One or more antennas coupled to the transceiver circuit.

14. The method of claim 11, wherein the OFDM symbol index is an index of the first OFDM symbol of the particular PRACH instance.

15. A non-transitory computer-readable storage medium storing instructions for execution by one or more processors of a user equipment (UE), wherein, when executed by the one or more processors, the instructions cause the UE to: Decode the system information block (SIB) information, which includes the configuration of PRACH resources, wherein the PRACH resources include multiple PRACH instances; A PRACH preamble is encoded at a specific PRACH instance among the plurality of PRACH instances within the PRACH resource for transmission to the base station, wherein, depending on the determined PRACH instance, the PRACH preamble is associated with a first preamble format or a second preamble format; and The Random Access Channel Response (RAR) message received from the base station in response to the PRACH preamble is decoded. The RAR message includes an uplink grant for scheduling Physical Uplink Shared Channel (PUSCH) transmissions. The RAR message is encoded using a Random Access Radio Network Temporary Identifier (RA-RNTI), which is associated with the specific PRACH instance within the PRACH resource. The RA-RNTI is based on: Index of OFDM symbols; Frequency index; and Time slot index.

16. The non-transitory computer-readable storage medium of claim 15, wherein the configuration of the PRACH resource includes a PRACH configuration index, wherein the PRACH preamble is transmitted using a start symbol indicated by the PRACH configuration index.

17. The non-transitory computer-readable storage medium of claim 15, wherein the OFDM symbol index is an index of the first OFDM symbol of the particular PRACH instance.

18. The non-transitory computer-readable storage medium of claim 15, wherein the instructions, when executed by the one or more processors, further cause the UE to: Identify the specific PRACH instance among the plurality of PRACH instances within the PRACH resource.

19. The non-transitory computer-readable storage medium according to claim 15, wherein, When the first preamble format is one of formats A1, A2 and A3, the second preamble format is correspondingly one of formats B1, B2 and B3, wherein formats A1-A3 have zero guard period lengths and formats B1-B3 have non-zero guard period lengths.

20. The non-transitory computer-readable storage medium of claim 15, wherein the instructions, when executed by the one or more processors, further cause the UE to: The specific PRACH instance for transmitting the PRACH preamble is selected from the plurality of PRACH instances based on the service priority indicator associated with the PUSCH transmission.

Images